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)

Post a reply to this message

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

Am 06.11.2018 um 23:19 schrieb Cousin Ricky:

> 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?

Because someone somewhen implemented it that way.

I could dig in old code to find out when it was first introduced, but I 
doubt whether that information would be of any added value: Current 
versions support it, we know old versions supported it, and now you 
present evidence that scenes used it. Under these circumstances this 
undocumented feature is here to stay, at least for now.

Maybe I'll add warnings (if I find the time and don't forget about it) 
but that'll be it.

> 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.

The syntax diagrams are a very one-sided thing: They only document what 
you can expect to /work/ - they do /not/ document what you can expect to 
/fail/.

(This is a bit different from, say, C++ where the language specification 
also mandates what a compiler must reject.)

Post a reply to this message

On 11/6/18 5:19 PM, Cousin Ricky wrote:

> 
> -------------- [BEGIN CODE] --------------

> #declare Object = sphere { 3 * z, 1 }
> sphere { Object pigment { red 1 } }
> --------------- [END CODE] ---------------
> 


I'd say it works that way by design. How else would you use Object?
(I think the name Object is obfuscating.)

It is similar to
#declare MyTexture=texture{pigment{Red}};
sphere { 0, 1 texture {MyTexture}}

Maybe less confusing with a different name:

#declare MySphere = sphere {0, 1};
sphere {MySphere}
-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

On 11/7/18 10:02 AM, William F Pokorny wrote:
> 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.

done... also saw mention of 40 character limit to identifier names that 
i corrected as well

Post a reply to this message

On 2018-11-07 6:33 PM (-4), clipka wrote:
> Am 06.11.2018 um 23:19 schrieb Cousin Ricky:
> 
> I could dig in old code to find out when it was first introduced, but I 
> doubt whether that information would be of any added value: Current 
> versions support it, we know old versions supported it, and now you 
> present evidence that scenes used it. Under these circumstances this 
> undocumented feature is here to stay, at least for now.
> 
> Maybe I'll add warnings (if I find the time and don't forget about it) 
> but that'll be it.

No worries.

Post a reply to this message

On 2018-11-07 7:02 PM (-4), dick balaska wrote:
> On 11/6/18 5:19 PM, Cousin Ricky wrote:
> 
>>
>> -------------- [BEGIN CODE] --------------
> 
>> #declare Object = sphere { 3 * z, 1 }
>> sphere { Object pigment { red 1 } }
>> --------------- [END CODE] ---------------
>>
> 
> 
> I'd say it works that way by design. How else would you use Object?
> (I think the name Object is obfuscating.)

Yes, that was a poor choice of identifier name.  'MyObject' would have 
been a better choice for this illustration.  It is not at all clear that 
this was by design; the first line could have been:

   Object = box { -1, 1 translate -4 * z }

and it would still parse; but sphere { box } makes no sense, so why 
should sphere { ArbitraryObject } be a deliberate design?

> 
> It is similar to
> #declare MyTexture=texture{pigment{Red}};
> sphere { 0, 1 texture {MyTexture}}
> 
> Maybe less confusing with a different name:
> 
> #declare MySphere = sphere {0, 1};
> sphere {MySphere}

The point wasn't that I could slide a sphere of sphere past the parser; 
that just happened to be the way I *accidentally* coded it many years 
ago, when I was just getting my POV legs.  The point is that the 
sphere{} construct (or indeed, any primitive keyword) could be used as a 
wrapper for anything at all!

Post a reply to this message

Am 11.11.2018 um 15:20 schrieb Cousin Ricky:

> Yes, that was a poor choice of identifier name.  'MyObject' would have 
> been a better choice for this illustration.  It is not at all clear that 
> this was by design; the first line could have been:
> 
>    Object = box { -1, 1 translate -4 * z }
> 
> and it would still parse; but sphere { box } makes no sense, so why 
> should sphere { ArbitraryObject } be a deliberate design?

It is deliberate that `sphere { SphereObject }` works as observed. The 
fact that `sphere { ArbitraryObject }` also works is simply a side 
effect of how the former is implemented.

It is actually easier to implement this way, because to the parser all 
object variables look alike at first glance. Checking whether it is 
actually a sphere would be extra work, and besides it is guaranteed to 
have no ill side effects.

If it makes you more comfortable, simply consider `sphere` an alias for 
òbject` in this context.

Post a reply to this message