On 11/6/18 5:19 PM, Cousin Ricky wrote:
> I've been going through some archived scenes (vintage 2003 - 2006) from 
> a long-scraped computer and merging them with my main POV directory 
> tree.  Most of the images were not archived, so I've been cleaning up 
> the scene files and re-rendering them.  After rendering one scene 
> successfully, I noticed what seemed to be a syntax error: two spheres in 
> a union, each of which contained a declared object!  Why did it not halt 
> with a parse error?
> 
> The following simplified scene illustrates the strangeness:
> 
> -------------- [BEGIN CODE] --------------
> #version 3.5;
> global_settings { assumed_gamma 1 }
> light_source { <-1, 1, -1> * 1000, rgb 1 }
> #declare Object = sphere { 3 * z, 1 }
> sphere { Object pigment { red 1 } }
> --------------- [END CODE] ---------------
> 
> This renders to completion with all POV versions and #versions from 3.5 
> through 3.8.0-alpha.9893777.  Replacing 'sphere' in either line with 
> other object types also does not cause a parse error; whatever shaped is 
> defined in the #declare is rendered.
> 
> I admit this is a minor issue, as it does not cause a correct scene file 
> to fail.  Still, it does not appear legal according to the syntax diagrams.
> 
> POV-Ray versions:
>    3.5 Unix (.Linux.gcc) [official download]
>    3.6.1 (g++ 3.4.1 @ i686-pc-linux-gnu) [official download]
>    3.7.0.unofficial (g++ 4.8 @ x86_64-unknown-linux-gnu) [self-compiled
>      official]
>    3.8.0-alpha.9893777.unofficial (g++ 7 @ x86_64-pc-linux-gnu) [self-
>      compiled alpha]
> OS: openSUSE Leap 15.0 (GNU/Linux)

I've run across the mixed type case. In other words not sphere{ 
Sphere_ID, but say box{ Sphere_ID } as you mentioned works too.

When I looked at the code (year or two back) it seemed like the parser 
was set up to allow it. I guessed for the matching case where it 'might' 
be a help with respect to clarity with an unintended side effect of 
allowing the mixed type cases too.

I let it go at the time with the thought sphere {}, box {}, et al are in 
fact objects internally in the general sense - and object {} allows 
references to object IDs.

That said, because object {} allows light source IDs too (due looks like 
support perhaps?), and given the way things work, you can code something 
like:

#declare Light00 = light_source { <-1, 1, -1> * 1000, rgb 1 }
box { Light00 pigment { green 1 } }

which is strange looking. I've never tested whether the 'texture' gets 
applied to any looks like object in that case. I'd hope it would for 
consistency sake. Anyway, my take from looking at this issue in the past 
was to let it go as is - I didn't open an issue for it.

Christoph is working on parser stuff of late. Perhaps this is behavior 
which could/should? be changed. If you want to push for change - open an 
issue on github. It would be up to him whether to do anything with it.

---
Aside 1 (documentation, Jim!): I noticed just now the lemon object is 
not documented in the object {} syntax as a valid FINITE_SOLID_OBJECT - 
and it should be. See:

   http://wiki.povray.org/content/Reference:Object

Aside 2: The parser mechanisms with respect to * IDs by declares is 
implemented inconsistently. You cannot use warp IDs for example: warp { 
Warp00 } which I often forget & want (have to hack support with macros). 
We have too some cases where due bugs in the original implementations of 
* IDs things don't work. #declare density_map = issue, for example, see 
the pull request:

https://github.com/POV-Ray/povray/pull/346

for details.

Perhaps Christoph will go after some of these 'aside 2' issues too in 
the current parser work, but understand all to well the actual 
difficulty and lack of time. I have a too long open todo to test his 
recent parser updates against my parser test cases and have not yet 
found the day or so it takes to run them and review results.

Bill P.

Post a reply to this message