The scene below shows that the Round_Box_.. #macro in 'shapes.inc'
doesn't work well with negative values.  The elements of
the 'negative one' are misplaced.  I didn't take time yet to
see where's the problem, but I can say that the 'old' RoundedBox
#macro by John VanSickle works as expected.

Fabien.

// ================================
#include "colors.inc"
#include "shapes.inc"

camera {location <15,50,-20> look_at <0,8,0> angle 30}

// bad
  object {
          Round_Box_Union (<-5,0,0>,<-10,15,-5>,.4)
          pigment {Red}
          }

// good
  object {
          Round_Box_Union (<5,0,0>,<10,15,5>,.4)
          pigment {Yellow}
          }

light_source {<1200,1600,1400> White*1}
light_source {<-1200,1600,-1400> White*1 shadowless}

Post a reply to this message

But what do you expect to see
when using a negative value ?

Post a reply to this message

Fabien Mosen wrote:
> The scene below shows that the Round_Box_.. #macro
> in 'shapes.inc' doesn't work well with negative values.

Thanks for the report.
I will fix this but it won't be included in RC2.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> Thanks for the report.
> I will fix this but it won't be included in RC2.

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

Subject: Problem in 'balcony.pov' and change suggestion for 'shapes.inc'
Date: Mon, 11 Mar 2002 11:03:02 +0100
From: Christoph Hormann <chr### [at] gmxde>
Newsgroups: povray.pre-beta
news://news.povray.org/3C8C80D6.8EE78941@gmx.de


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:

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