 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le Forgeron wrote:
>
> [...]
>
> If keyword, instead of positional syntax, had been used, it would be
> far more easier to use the poly object, and p.b.i might be full of them.
> Instead of a long collection of values (with a lot of zero), using
> keyword would have make it easier (*):
>
> poly { x6 1 y5 1 z4 1 const -10 }
>
> If later the user wants to add a x^2yz^3 term, it's also far easier than
> retrieving the correct position in the list:
>
> poly { x6 1 y5 1 z4 1 const -10 x2yz3 -3 }
>
It is fairly possible to program this with macros, think of something
like:
Poly4(1*X6, 1*Y5, 1*Z4, -10*Const)
Poly5(1*X6, 1*Y5, 1*Z4, -10*Const, -3*X2YZ3)
X6, Y5, Z4 and all the others would be (4D) vectors:
#declare X6=<6, 0, 0, 1>;
#declare Y5=<0, 5, 0, 1>;
#declare Z4=<0, 0, 4, 1>;
#declare X2YZ3=<2, 1, 3, 1>;
#declare Const=<0, 0, 0, 1>;
And the macro would just have to analyze the components of the vectors and
place 'Vector.t' at the appropriate positions in the poly object. I
currently don't have the time to write it, but it's really quite easy
(although it would take some time to parse for a 15th order poly).
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <7e1unus8h9amgktm4ktrh7b1g77bgmevnb@4ax.com>,
ABX <abx### [at] abx artpl> wrote:
> Yes, 'path' sounds nice. So one vote for 'connection' and one for 'path'. Any
> other vote? My heart is now for 'path_type FLOAT' becouse it is made with
> short words and I don't like that I have to reserve new token for every new
> type of interpolation. There are also subtypes for interpolations when I can't
> choose nice names. For example there are two toroidal connection types: one by
> Ron Parker and one by Slime (IIRC). Making type float is better IMO. What do
> you think?
I find keywords much easier to read and write than numbers, I feel that
you should only use a number for a numeric value. And I really hope you
meant "path_type INT". (there's no difference as far as POV is
concerned, but for documentation you would want to say it is an integer
value)
I would do something like:
type multisphere
type catmull_rom
type cubic
type linear
...
"type" already exists, and spline names can be used for all splines
instead of just in the sphere_sweep shape, so you aren't adding a huge
number of one-use keywords.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Sep 2002 13:51:11 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> That's ok for technical inclined people, not for user-friendliness.
I don't like user-friendliness at some places. While I agree that making tools
user-friendly increases market but at the same time it increases "stupidity"
when it is applied in wrong place - where some level of intelligence is
expected from user and additional tools like declarations and macros are
served.
> But from a user-friendliness aspect, when Joe user (with a degree in
> math, a.k.a not a mathemacaly ignorant) wants to have a poly equation to
> be rendered, he has to carrefully spot the place for all values, and
> simple things like x^6+y^5+z^4-10=0 turn into a nightmare of values.
If HF_Sphere macro can create complicated smooth mesh from pattern why another
macro can't create poly object definition from apropriate input data ?
> As a bad thing is always worth something, I believe iso-surface wouldn't
> have been there so early if poly would have been easier in syntax, and
> their success might have been reduced...
:-)
> P.S.3: You might ask what the relation with your question... my answer
> is 'Think about user-friendliness, dismiss if you want, but think about it'.
I think I think :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> Le Forgeron wrote:
> And the macro would just have to analyze the components of the vectors and
> place 'Vector.t' at the appropriate positions in the poly object. I
> currently don't have the time to write it, but it's really quite easy
> (although it would take some time to parse for a 15th order poly).
Please, do not waste your time at writing such kludging-macro, when the
best solution would have been to change the syntax of the poly objects
so as to parse only the useful information. At worst, if backward
compatibility is an issue, a new 'poly2' syntax would be able to provide
the new one while the old 'poly' remained unchanged. (just like the new
mesh2... same core object, different syntax!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Sep 2002 09:30:20 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> I find keywords much easier to read and write than numbers
POV's SDL doesn't help me to make decision. Patterns has names and internal
functions hasn't. Type of interpolation for splines has names and types for
interpolation for images hasn't. Methods usually hasn't names. Noise generator
types have no names.
> I feel that you should only use a number for a numeric value.
Then how to call two different algoithms for connections along torus fragments
to make it readable ?
> And I really hope you
> meant "path_type INT".
Of course.
> "type" already exists, and spline names can be used for all splines
> instead of just in the sphere_sweep shape, so you aren't adding a huge
> number of one-use keywords.
I will reconsider this.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le Forgeron wrote:
>
> [...]
>
> Please, do not waste your time at writing such kludging-macro, when the
> best solution would have been to change the syntax of the poly objects
> so as to parse only the useful information. At worst, if backward
> compatibility is an issue, a new 'poly2' syntax would be able to provide
> the new one while the old 'poly' remained unchanged. (just like the new
> mesh2... same core object, different syntax!)
I disagree, the current syntax isn't exactly easy to use in hand written
code but wrapper macros can much improve that. Adding more than 100 new
keywords is really not a good idea IMO, it would enormously blow up the
already large parser (the current parsing code for the poly object is
really compact). Your suggestion would also introduce a disturbing double
meaning to the x, y and z identifiers.
A serious advantage would of course be the potential for signatures and
the shortest code contest.
If a new syntax is made for poly objects i would suggest using 'exponent
vectors':
poly2 {
<6, 0, 0>, 1,
<0, 5, 0>, 1,
<0, 0, 4>, 1,
<0, 0, 0>, -10
}
poly2 {
<6, 0, 0>, 1,
<0, 5, 0>, 1,
<0, 0, 4>, 1,
<0, 0, 0>, -10,
<2, 1, 3>, -3
}
You could still declare symbols for the vectors but the parser would be
kept clean from unnecessary clutter.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Sep 2002 17:01:24 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Your suggestion would also introduce a disturbing double
> meaning to the x, y and z identifiers.
You mean triple probably. Don't forget x, y and z in functions.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <6uiunuc15f15ikpe3mdavli2tc3q5h8tg7@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
> > I find keywords much easier to read and write than numbers
>
> POV's SDL doesn't help me to make decision. Patterns has names and internal
> functions hasn't.
Huh? The internal functions have names, they are just defined through
the functions.inc file instead of being built-in. If you use the
function ID numbers directly, you are doing it wrong, and your scene
probably won't work in future versions.
> Type of interpolation for splines has names and types for
> interpolation for images hasn't.
And I can remember the keywords for spline types a lot easier than the
numbers for image interpolation.
> Methods usually hasn't names.
Methods? POV doesn't have...oh, you mean like the media sampling methods?
That is one case where I might have used numbers. The only keywords I
can think of are "random" or "monte_carlo" (which I'm not entirely sure
is right), "even_spacing", and "supersampled", and none of them seem
very appropriate. I would have used "sampling_method" instead of
"method" though...or a completely different syntax, somethign like:
sampling {type, PARAMS}
> Noise generator types have no names.
I don't like the way noise generators were done, either in syntax or in
the way they were done internally. I think that feature was just a hack.
I would have used names such as perlin_noise, old_pov_noise, pov_noise,
lewis_noise, etc, and a completely different syntax. There would be a
global generator that could be set to any of these, but a noise
generator could be defined in the file as a function, something like:
global_settings {
noise_generator function {perlin_noise {}}
noise_generator FUNCTION_IDENTIFIER
}
#declare myNoise = function {perlin_noise {range MIN, MAX ...}}
Patterns and other things that use noise would be able to use any
function as the noise source.
> > I feel that you should only use a number for a numeric value.
> Then how to call two different algoithms for connections along torus fragments
> to make it readable ?
torus and torus2, torus1 and torus2, toroidal1 and 2, or something
similar...it is done in other places: the spiral patterns, atan and
atan2 functions, etc...
If keywords make sense, I think they should be used instead of numbers.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 11 Sep 2002 11:33:53 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> > > I find keywords much easier to read and write than numbers
> >
> > POV's SDL doesn't help me to make decision. Patterns has names and internal
> > functions hasn't.
>
> Huh? The internal functions have names, they are just defined through
> the functions.inc file instead of being built-in.
So what's the problem to define keywords for types this way ?
> Patterns and other things that use noise would be able to use any
> function as the noise source.
Interesting idea. Are you reserving rights to make patch for it ? ;-)
> torus and torus2, torus1 and torus2, toroidal1 and 2, or something
> similar...it is done in other places: the spiral patterns, atan and
> atan2 functions, etc...
>
> If keywords make sense, I think they should be used instead of numbers.
If keyword make sense it can be always added as identifier during parsing.
Otherwise it seems overloading for parser. I can't say I fully understand how
parser works but I imagine with every new token it can slow down a little.
Further I imagine patches for 3.5 will introduce a lot of new tokens so
prasing can be overloaded. Tell me if it works differently.
On the other hand I wonder if some propability of occurences could be
introduced to parser. As source library from IRTC could be investigated for
probability of keywords. Most probable keywords could be compared with parsed
token first.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <48punuklg3k2jl8trmqh5r6r3eokpq9del@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
> > Huh? The internal functions have names, they are just defined through
> > the functions.inc file instead of being built-in.
> So what's the problem to define keywords for types this way ?
Slower parsing, for one. ;-)
Requiring an external include file. Potential conflicts with future
keywords if you use all lower-case, not fitting in with the rest of the
language if you use upper-case. Providing an include file and using
integer codes would be much better than nothing though.
> > Patterns and other things that use noise would be able to use any
> > function as the noise source.
> Interesting idea. Are you reserving rights to make patch for it ? ;-)
Heh, implementing it in the current POV would take a huge amount of
work. I'm mainly thinking of it as something to be considered for the
4.0 rewrite.
> If keyword make sense it can be always added as identifier during parsing.
> Otherwise it seems overloading for parser. I can't say I fully understand how
> parser works but I imagine with every new token it can slow down a little.
> Further I imagine patches for 3.5 will introduce a lot of new tokens so
> prasing can be overloaded. Tell me if it works differently.
I doubt adding a token slows things down significantly, for more complex
scenes it probably takes a smaller and smaller fraction of the total
time, and for POV 4.0, the scene will probably be compiled into
bytecodes for a virtual machine to run...more tokens would slow down
compiling slightly, but compiling will be a small fraction of the total
time used before the scene renders.
> On the other hand I wonder if some propability of occurences could be
> introduced to parser. As source library from IRTC could be investigated for
> probability of keywords. Most probable keywords could be compared with parsed
> token first.
Or the parser could do something similar on the fly: if a token is
matched, move it to the front of the list. Tokens that occur more often
will spend more time towards the front of the list. Not as efficient,
but simpler and adapts to the scene...for example, a mesh file will have
a very different occurance distribution from other scenes, mainly having
"triangle" or "smooth_triangle", "{}" braces, ",", "<", and ">"
characters, and numbers. After the first triangle, these will be at the
top of the token list. I did something similar for Sapphire: when a
symbol is resolved it moves to the front of the symbol table.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
