|
 |
On 6/13/20 2:20 PM, Bald Eagle wrote:
>
...
>
> A few points:
>
> Directly:
> 1. Does the code as pasted give the desired result? I made an array of all 18
> points and used those in a spline, and I got a larger sphere (r = 3.701) that
> touches the outer part of the prism.
>
Le_Forgeron was careful to exclude the control points and use only the
inner loop, but seems like using all points would work in this
particular case...
My first guess would be not all the points were walked in your case -
that you perhaps left the for loop end the same? Supposing you have the
loop start and end right, the second guess would be there is something
going on when there are loops within loops. This certainly not the
normal set up when walking a spline.
> With regard to names / syntax (recent commentary/questions about #declare /
> #undef, and rewriting things in povr has my mind in that mode):
>
> Why do we have # before things like for, etc. and not others?
I don't know the history. In the parser there is code forcing it where
not there depending on the version setting (declare keyword IIRC is
one). Of late I think Christoph was pushing toward only language control
needing the # prefix, but guessing some there based upon particular
corrections from him. Mostly, the parser treats the # as a space. It can
be there or not. This is something which trips me up pretty often
because I code a lot in tcl and bash where a leading # indicates a comment.
Not tried it, but wonder if I took scenes and just stripped all the
'#'s, if they'd would work? If so, maybe we just make '#'s all illegal
to get consistency?
> dimension_size is "long" and I find awkward to remember. array_size, size_of,
> or something like that would be a nice alternative.
I don't know, I think dimension_size is more descriptive of what it does.
>
> Inside of various declarations, I often add an extra comma, so if I were coding
> Jerome's scene, I will frequently write
> sphere {0, LOWEST, pigment {color red 1 }}
> ^
> and POV-Ray does not like that.
> I believe there are a few other places where extra commas generate an error that
> prevents rendering - I will try to be mindful of those and point them out.
>
I have a hypothesis we are supposed to be using fewer commas, not more.
Remember when in maps - or splines? - someone complained about commas
being needed in some places and not others? Also having to have some
commas, but not with the last item etc.
Christoph did something in v38 so the commas are now less often required
- or illegal - they can now mostly be there or not. The changes,
perhaps, encourage us to think they can be used, or not, most everywhere.
In the parser code there is a bit of code used specifically to look for
commas for certain keywords. I suspect this got updated to accept spaces
(no comma token/optional) - or, it always worked this way and he added
calls to it in more places. For commas to be ignored the parser needs to
call that code. It must look for a comma to ignore it, and in many
places where spaces only have long worked, it - today - does not.
This gets us to intended best practice given his changes, which I
believe, is a continuing push toward fewer commas everywhere, not more.
Meaning for spheres we want to encourage: sphere { 0 1 pigment... } usage.
I too still tend to insert the comma and a space between the 0 and 1
above - and in many other places - because I long have. I believe for
quite some long time, it's just been an extra character if you already
have a space. A character which needs to be parsed.
Aside: Our documentation still shows commas everywhere and in only a few
places commas as optional. For example, the prism in this discussion I
believe will run fine if you turn all the commas not inside the point <>
vectors (commas are needed there due the negative values) to spaces.
What I've not done is to systematically test not using commas. Are there
still constructs after Christoph's recent changes where they are still
needlessly forced or illegal?
Anyway... My take.
Bill P.
Post a reply to this message
|
|
