I've gone thru and tested these bugs on beta 25,
I hope it's handy to have them listed in one place.

Animation Frame Zero
--------------------
When using animation the numbering of the first frame filename is
forced to 1 when starting at frame 0.
+kfi0 +kff2 +ki0 +kf2 +fn
results in two frames 1 and 2, not three frames 0, 1, and 2.

Facets Pattern Error
--------------------
Using facets as a controlling pattern for a normal map results in an
unspecified error. This should be caught at parse time to
give a specific error. Existed 3.6 as well.

Malformed Nested #declare Doesn't Raise Error
---------------------------------------------
A declare of the form...
#declare Weird = #declare Aval = 1;
parses without an error. This is probably should raise an error,
or at least a warning, since it can terminate inside nested
#if and #while statements. Existed in 3.6 as well.

Partial Transparency Blocky Artifacts
-------------------------------------
When looking thru a partially transparent object, there can
be block edged light spots, and raster lines (about 32x32 pixels).

Partial Transparency Shadow Issue
---------------------------------
Shadows of overlapping objects, with partially transparent textures,
can have speckled shadows, probably due to coincident intersections.

Reflective Texture Maps Abrupt Exit
-----------------------------------
Texture maps containing reflective textures can cause a crash.

Transform Block Misaligns Texture in Union
-----------------------------------------
Use of transform {} may misalign textures in unioned objects.

Post a reply to this message

Thanks for doing this, it is handy.

-- Chris

Tim Attwood wrote:
> I've gone thru and tested these bugs on beta 25,
> I hope it's handy to have them listed in one place.
> 
> Animation Frame Zero
> --------------------
> When using animation the numbering of the first frame filename is
> forced to 1 when starting at frame 0.
> +kfi0 +kff2 +ki0 +kf2 +fn
> results in two frames 1 and 2, not three frames 0, 1, and 2.
> 
> Facets Pattern Error
> --------------------
> Using facets as a controlling pattern for a normal map results in an
> unspecified error. This should be caught at parse time to
> give a specific error. Existed 3.6 as well.
> 
> Malformed Nested #declare Doesn't Raise Error
> ---------------------------------------------
> A declare of the form...
> #declare Weird = #declare Aval = 1;
> parses without an error. This is probably should raise an error,
> or at least a warning, since it can terminate inside nested
> #if and #while statements. Existed in 3.6 as well.
> 
> Partial Transparency Blocky Artifacts
> -------------------------------------
> When looking thru a partially transparent object, there can
> be block edged light spots, and raster lines (about 32x32 pixels).
> 
> Partial Transparency Shadow Issue
> ---------------------------------
> Shadows of overlapping objects, with partially transparent textures,
> can have speckled shadows, probably due to coincident intersections.
> 
> Reflective Texture Maps Abrupt Exit
> -----------------------------------
> Texture maps containing reflective textures can cause a crash.
> 
> Transform Block Misaligns Texture in Union
> -----------------------------------------
> Use of transform {} may misalign textures in unioned objects. 
> 
>

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Malformed Nested #declare Doesn't Raise Error
> ---------------------------------------------
> A declare of the form...
> #declare Weird = #declare Aval = 1;
> parses without an error. This is probably should raise an error,
> or at least a warning, since it can terminate inside nested
> #if and #while statements. Existed in 3.6 as well.

  This is not a bug nor an error, just a side-effect of how the parser works.

  When the parser finds "#declare Weird = " it will then recursively parse
for "anything that evaluates to something which can be declared". This
"anything" is parsed like any other SDL. This includes, among other things,
the possibility if putting #-commands in there.

  Thus the next thing it finds is "#declare", which is just fine, and
will parse that (creating the identifier 'Aval' and assigning "1" to it).
When this is done, parsing will continue as normal, and whatever comes
after that in-between #declare will be assigned to 'Weird'.

  It's exactly this kind of parsing which allows doing things like:

#declare Weird = some_macro(1, 2, 3);

where the macro may have anything inside it (including #declares and such).

  Your example line does, in fact, give an error, because there's nothing
to assign to 'Weird' because nothing comes after the second #declare.
This, however, would be perfectly ok:

#declare Weird = #declare Aval = 1; 2;

  It may look a bit weird, but it's well defined: While parsing the parameter
to #declare, a second #declare is found, which is parsed recursively. After
it has been parsed, parsing continues normally, so it finds the '2' and
assigns it to 'Weird'.

  I'm not sure if changing this behavior is desirable. It would make a lot
of other things a lot harder to parse.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood wrote:
> I've gone thru and tested these bugs on beta 25,
> I hope it's handy to have them listed in one place.
> 
> Transform Block Misaligns Texture in Union
> -----------------------------------------
> Use of transform {} may misalign textures in unioned objects. 

Transform Block Misaligns clipped_by Object in Union
-----------------------------------------
Use of transform {} misaligns any clipped_by object inside a union. This 
produces incorrect CSG.

Some code:

// code
union{
  sphere{0,1
   clipped_by{
    plane{y,0}
   }
  }
  sphere{0,1
   scale<1,.5,1>
   clipped_by{
    plane{-y,0}
   }
  }
  pigment{rgb 1}
  transform{
   translate y
   rotate z*45
  }
}
// end code

Sam

Post a reply to this message

>> Malformed Nested #declare Doesn't Raise Error
>> ---------------------------------------------
>> A declare of the form...
>> #declare Weird = #declare Aval = 1;
>> parses without an error. This is probably should raise an error,
>> or at least a warning, since it can terminate inside nested
>> #if and #while statements. Existed in 3.6 as well.
>
>  This is not a bug nor an error, just a side-effect of how the parser 
> works.
>
>  When the parser finds "#declare Weird = " it will then recursively parse
> for "anything that evaluates to something which can be declared". This
> "anything" is parsed like any other SDL. This includes, among other 
> things,
> the possibility if putting #-commands in there.
>
>  Thus the next thing it finds is "#declare", which is just fine, and
> will parse that (creating the identifier 'Aval' and assigning "1" to it).
> When this is done, parsing will continue as normal, and whatever comes
> after that in-between #declare will be assigned to 'Weird'.
>
>  It's exactly this kind of parsing which allows doing things like:
>
> #declare Weird = some_macro(1, 2, 3);
>
> where the macro may have anything inside it (including #declares and 
> such).
>
>  Your example line does, in fact, give an error, because there's nothing
> to assign to 'Weird' because nothing comes after the second #declare.
> This, however, would be perfectly ok:
>
> #declare Weird = #declare Aval = 1; 2;
>
>  It may look a bit weird, but it's well defined: While parsing the 
> parameter
> to #declare, a second #declare is found, which is parsed recursively. 
> After
> it has been parsed, parsing continues normally, so it finds the '2' and
> assigns it to 'Weird'.
>
>  I'm not sure if changing this behavior is desirable. It would make a lot
> of other things a lot harder to parse.
>
It's not really a high priority to fix, but it probably should at least
raise a warning, since the Weird #declare can terminate inside #if and
#while loops, and without a semicolon.

Here's a more complete test scene that shows some of this weirdness...

camera {
   location  <0.0, 0.5, -4.0>
   direction 1.5*z
   right     x*image_width/image_height
   look_at   <0.0, 0.0,  0.0>
}

light_source {
  <0,1,-10>
  color rgb <1,1,1>
}

background {rgb <1,1,1>}

#declare pass_text = text {
   ttf "timrom.ttf","PASS",0.1,0
   pigment {rgb <0,1,0>}
   translate <-1,0,0>
};

#declare fail_text = text {
   ttf "timrom.ttf","FAIL",0.1,0
   pigment {rgb <1,0,0>}
   translate <-1,0,0>
};

// misformed #declare
#declare Weird = #declare Aval = 1;

// other properly formed statements
#declare PigVal = pigment {rgb <0,0,0>};
#declare ObjVal = sphere {<0,0,0>,1};

#if (true=true)
#local c=0;
#while (c=0)

// this object ends the misformed #declare and doesn't render
object {pass_text}

// this object renders normally
object {fail_text}

#local c=1;
#end
#end

Post a reply to this message

In article <47a87d61@news.povray.org>, war### [at] tagpovrayorg says...
> Tim Attwood <tim### [at] comcastnet> wrote:
> > Malformed Nested #declare Doesn't Raise Error
> > ---------------------------------------------
> > A declare of the form...
> > #declare Weird = #declare Aval = 1;
> > parses without an error. This is probably should raise an error,
> > or at least a warning, since it can terminate inside nested
> > #if and #while statements. Existed in 3.6 as well.
> 
>   This is not a bug nor an error, just a side-effect of how the parser wo
rks.
> 
>   When the parser finds "#declare Weird = " it will then recursively pa
rse
> for "anything that evaluates to something which can be declared". This
> "anything" is parsed like any other SDL. This includes, among other thing
s,
> the possibility if putting #-commands in there.
> 
>   Thus the next thing it finds is "#declare", which is just fine, and
> will parse that (creating the identifier 'Aval' and assigning "1" to it).
> When this is done, parsing will continue as normal, and whatever comes
> after that in-between #declare will be assigned to 'Weird'.
> 
>   It's exactly this kind of parsing which allows doing things like:
> 
> #declare Weird = some_macro(1, 2, 3);
> 
> where the macro may have anything inside it (including #declares and such
).
> 
>   Your example line does, in fact, give an error, because there's nothing
> to assign to 'Weird' because nothing comes after the second #declare.
> This, however, would be perfectly ok:
> 
> #declare Weird = #declare Aval = 1; 2;
> 
>   It may look a bit weird, but it's well defined: While parsing the param
eter
> to #declare, a second #declare is found, which is parsed recursively. Aft
er
> it has been parsed, parsing continues normally, so it finds the '2' and
> assigns it to 'Weird'.
> 
Well, its also open to interpretation. Logically, it would *also* be 
possible to consider the original statement to mean:

#declare Aval = 1;
#declare Weird = Aval;

Since it *is* recursing. The parser though is treating things like a 
function call, apparently, so sees:

declare global:Weird {
  declare global:Aval {
    return 1
  }
  'Error! This language "requires" a returned value.
}

Its a wacky way to handle variable declarations, and probably the reason 
why "most" languages separate variables and functions/macros, which much 
clearer syntax.

-- 
void main () {

    if version = "Vista" {
      call slow_by_half();
      call DRM_everything();
    }
    call functional_code();
  }
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> // misformed #declare
> #declare Weird = #declare Aval = 1;

> // other properly formed statements
> #declare PigVal = pigment {rgb <0,0,0>};
> #declare ObjVal = sphere {<0,0,0>,1};

> #if (true=true)
> #local c=0;
> #while (c=0)

> // this object ends the misformed #declare and doesn't render
> object {pass_text}

  It's not "misformed" from the point of view of the parser. It's just
a side-effect of the recursive nature of parsing #-commands. #-commands
can be embedded almost everywhere (which is sometimes necessary to make
some things work), often even in-between other #-commands.

  I'm not sure how the parser could be modified to raise a warning
about this. It simply doesn't see anything wrong with it, as it works
in an entirely logical way.

  I'm not saying the current way of parsing is perfect. It does sometimes
cause problems. For example, I just can't implement a + operator for
strings even though I really would have wanted to, and it's due to this
parsing logic. The problem is that if the parser checks for every string
element if a '+' follows it, it messes up #debug. For instance this:

#debug "a\n"
#debug "b\n"

will print:

b
a

  That's because after "a\n" it checks if a '+' follows, and while doing
that it parses the second #debug, after which it sees that no '+' follows,
after which it finishes parsing the first #debug, and thus the lines are
printed in the wrong order.
  (It's possible to temporarily disallow parsing of #-commands, but that
breaks things too if I try to use it to check for the '+'. It will parse
the next '#' as an independent token, after which there's no way to
easily re-join it with the 'debug' following it, which will then cause
a parsing error because the parser just sees a lone '#' symbol.)

  But anyways, even though this way of parsing is not perfect, it's logical
and quite flexible. Being able to embed #-commands almost everywhere is
quite handy. That way you can embed eg. loops inside object definitions, etc.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Its a wacky way to handle variable declarations, and probably the reason 
> why "most" languages separate variables and functions/macros, which much 
> clearer syntax.

  OTOH it allows embedding #-commands almost everywhere, which is quite
handy. For example, you can put #while loops inside object declarations,
etc.

-- 
                                                          - Warp

Post a reply to this message

>> Its a wacky way to handle variable declarations, and probably the reason
>> why "most" languages separate variables and functions/macros, which much
>> clearer syntax.
>
>  OTOH it allows embedding #-commands almost everywhere, which is quite
> handy. For example, you can put #while loops inside object declarations,
> etc.
>
Maybe in 4.0 we should have strict semicolons for #declares?

I still think it'd be good to give a warning that a #declare ends inside
an uncompleted control structure. Think about a loop... if the
first object is "eaten" by the #declare, then the remaining iterations
are rendered, then the #while statement really belongs to the body
sometimes and the #declare sometimes, it's poorly defined.

#declare Weird =
#while (...)
  object {...}
  ...
#end

Does anyone actually use this for anything?

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> Does anyone actually use this for anything? 

  Ever heard of this thing called POV-Ray Short Code Contest? ;)

-- 
                                                          - Warp

Post a reply to this message