Christoph Hormann wrote:

> 
> Rune, i already made a proposal for fixing this some time ago:


Thanks, but there is a small mistake (maybe things have changed
since ?).  The two first replaced lines must be :

    #local AA = <min(A.x, B.x), min(A.y, B.y), min(A.z, B.z)>
                + EdgeRadius;
    #local BB = <max(A.x, B.x), max(A.y, B.y), max(A.z, B.z)>
                - EdgeRadius;

(it's a matter of 'A' instead of 'AA')

Fabien.

Post a reply to this message

I've been meaning to report this problem forever. The other problem that I
had noticed with Round_Box is that if the radius is exactly half the length
of one of the edges, you get "Parse Error: Degenerate cylinder, base point =
apex point". For example:
  #include "shapes.inc"
  Round_Box_Union (<5,0,0>, <10,15,5>, 2.5)

FWIW, here's my corrected version of the Round_Box macro in shapes.inc,
which fixes both problems.

// -----BEGIN-----
#macro Round_Box(A, B, EdgeRadius, UseMerge)
   #local AA = <min(A.x, B.x), min(A.y, B.y), min(A.z, B.z)> + EdgeRadius;
   #local BB = <max(A.x, B.x), max(A.y, B.y), max(A.z, B.z)> - EdgeRadius;
   #local LBF = AA;
   #local RBF = < BB.x, AA.y, AA.z>;
   #local RBB = < BB.x, AA.y, BB.z>;
   #local LBB = < AA.x, AA.y, BB.z>;
   #local LTF = < AA.x, BB.y, AA.z>;
   #local RTF = < BB.x, BB.y, AA.z>;
   #local RTB = BB;
   #local LTB = < AA.x, BB.y, BB.z>;

   #if(UseMerge)
      merge {
   #else
      union {
   #end
      sphere {LBF, EdgeRadius}
      sphere {RBF, EdgeRadius}
      sphere {RBB, EdgeRadius}
      sphere {LBB, EdgeRadius}

      sphere {LTF, EdgeRadius}
      sphere {RTF, EdgeRadius}
      sphere {RTB, EdgeRadius}
      sphere {LTB, EdgeRadius}

      #if (AA.x != BB.x)
         cylinder {LBF, RBF, EdgeRadius}
         cylinder {RBF, RBB, EdgeRadius}
         cylinder {RBB, LBB, EdgeRadius}
         cylinder {LBB, LBF, EdgeRadius}
      #end

      #if (AA.y != BB.y)
         cylinder {LBF, LTF, EdgeRadius}
         cylinder {RBF, RTF, EdgeRadius}
         cylinder {RBB, RTB, EdgeRadius}
         cylinder {LBB, LTB, EdgeRadius}
      #end

      #if (AA.z != BB.z)
         cylinder {LTF, RTF, EdgeRadius}
         cylinder {RTF, RTB, EdgeRadius}
         cylinder {RTB, LTB, EdgeRadius}
         cylinder {LTB, LTF, EdgeRadius}
      #end

      box {AA-EdgeRadius*x, BB+EdgeRadius*x}
      box {AA-EdgeRadius*y, BB+EdgeRadius*y}
      box {AA-EdgeRadius*z, BB+EdgeRadius*z}
   }
#end
// -----END-----

Anders

Post a reply to this message

Anders K. wrote:

> I've been meaning to report this problem forever. The other problem that I
> had noticed with Round_Box is that if the radius is exactly half the length
> of one of the edges, you get "Parse Error: Degenerate cylinder, base point =
> apex point". 


Maybe it's time to fix an inconsistency between primitives.
Here's how RC1 acts with zero-dimension volumes :

box {<10,10,10>,<10,10,10>}
  Rendering goes without a warning.

cylinder {<10,10,10>,<10,10,10>,1}
  Parsing stops with an error.

cone {<10,10,10>,1,<10,10,10>,2}
  Parsing stops with an error.

triangle {<10,10,10>,<10,10,10>,<10,10,10>}
  Rendering goes, but a warning is issued.

plane {0,0}
   Parsing stops with an error.

torus {0 0}
  Rendering goes without a warning.

sphere {0,0}
   Rendering goes without a warning.

Of course, these are very specific cases, but they can easily
happen in scenes with automatic object generation.  IMO, the
best thing that POV-Ray should do is render anyway, with a
warning, as it currently does with 'degenerate' triangles.

Fabien.

Post a reply to this message

Fabien Mosen wrote:
> Maybe it's time to fix an inconsistency between primitives.
> Here's how RC1 acts with zero-dimension volumes :
> 
> box {<10,10,10>,<10,10,10>}
>   Rendering goes without a warning.

OK, I think.

> cylinder {<10,10,10>,<10,10,10>,1}
>   Parsing stops with an error.

The disc-cylinder can't be calculated, because the normal isn't known.

> cone {<10,10,10>,1,<10,10,10>,2}
>   Parsing stops with an error.

Same.

> triangle {<10,10,10>,<10,10,10>,<10,10,10>}
>   Rendering goes, but a warning is issued.

Doesn't behave like box does.

> plane {0,0}
>    Parsing stops with an error.

Again the normal is unknown.

> torus {0 0}
>   Rendering goes without a warning.

Same as box.

> sphere {0,0}
>    Rendering goes without a warning.

Same as box.

> Of course, these are very specific cases, but they can easily
> happen in scenes with automatic object generation.  IMO, the
> best thing that POV-Ray should do is render anyway, with a
> warning, as it currently does with 'degenerate' triangles.

The only inconsistency I see is the warning at the triangle. All 
objects which generate an error can't be calculated due to the missing 
normal.

Felix Wiemann

Post a reply to this message

Felix Wiemann wrote:

> The disc-cylinder can't be calculated, because the normal isn't known.


Your explanations are mostly right, but belongs to POV-Ray's internal 
cooking.  From a user's point of view, managing exceptions in #macros or
loops can be annoying.  All in all, I still think that simply removing
the 'degenerate' object is the best thing POV-Ray can do.

I guess that the degenerate triangle doesn't stop parsing because
it would be a PITA to manually remove one or two triangles from
a several thousand triangles externally generated mesh.  If an
external utility generated a net of cylinders, for example, to
represent a mesh as a wireframe, it would still be a PITA to
catch the degenerate ones.  That's why POV-Ray should remove
them with a simple warning, and not stop.

Fabien.

Post a reply to this message

Fabien Mosen wrote:
> 
> Anders K. wrote:
> 
> > I've been meaning to report this problem forever. The other problem that I
> > had noticed with Round_Box is that if the radius is exactly half the length
> > of one of the edges, you get "Parse Error: Degenerate cylinder, base point =
> > apex point".

This could be caught in the macro, but if you really need it, you can
always write a wrapper macro for that yourself.  The problem would also be
what to do if the radius is even larger.  

> 
> Maybe it's time to fix an inconsistency between primitives.
> Here's how RC1 acts with zero-dimension volumes :
> 
> [...]
> 
> Of course, these are very specific cases, but they can easily
> happen in scenes with automatic object generation.  IMO, the
> best thing that POV-Ray should do is render anyway, with a
> warning, as it currently does with 'degenerate' triangles.

A warning for boxes with two identical points would be practicable, but i
don't see much use in that.  Cylinders with two identical points and
non-zero radius don't form a defined shape therefore the error is
inevitable (if radius is zero you could just render nothing, like the box,
but this is an even rarer situation).

If you have code automatically generating such objects you can always
catch those special situations yourself, just write a wrapper macro and
usage would not be much more difficult.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> If you have code automatically generating such objects you can always
> catch those special situations yourself, just write a wrapper macro
> and usage would not be much more difficult.

Do you want to use a macro for 20000 objects (e.g. generated by a 
modeller) ? That would be *really* slow.

Felix Wiemann

Post a reply to this message

Fabien Mosen wrote:

> I guess that the degenerate triangle doesn't stop parsing because
> it would be a PITA to manually remove one or two triangles from
> a several thousand triangles externally generated mesh.  If an
> external utility generated a net of cylinders, for example, to
> represent a mesh as a wireframe, it would still be a PITA to
> catch the degenerate ones.  That's why POV-Ray should remove
> them with a simple warning, and not stop.

You're right, that's a good idea.

Felix Wiemann

Post a reply to this message

Felix Wiemann wrote:
> 
> Do you want to use a macro for 20000 objects (e.g. generated by a
> modeller) ? That would be *really* slow.

The modeller should take care of this itself.

In fact i even think a box with two identical points should generate an
error or warning since it is not very clear if this results in no object
or a single point.  Equally it's not clear what to make of a cylinder with
identical end and base point (you could expect nothing, a point or a
sphere), just dropping it would be incorrect.  

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> Felix Wiemann wrote:
>> 
>> Do you want to use a macro for 20000 objects (e.g. generated by a
>> modeller) ? That would be *really* slow.
> 
> The modeller should take care of this itself.

And if the modeller doesn't? :)

> In fact i even think a box with two identical points should generate
> an error or warning since it is not very clear if this results in no
> object or a single point.

A single point, I think. But you're right, a warning would be a good 
idea.

> Equally it's not clear what to make of a cylinder
> with identical end and base point (you could expect nothing, a point
> or a sphere), just dropping it would be incorrect.

I expect a disc. :)
Of course dropping would be incorrect, but I think that generating a 
warning (so the user is noticed that something may go wrong) is a 
better and more flexible solution than stopping with an error.

Felix Wiemann

Post a reply to this message