POV-Ray : Newsgroups : povray.general : Re: Round_Box #macro (in shapes.inc) and negative values Server Time
7 Nov 2024 04:52:45 EST (-0500)
  Re: Round_Box #macro (in shapes.inc) and negative values (Message 1 to 8 of 8)  
From: Felix Wiemann
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 22 Apr 2002 13:56:30
Message: <r4j1aa.1c1.ln@wiemann.my-fqdn.de>
Christoph Hormann wrote:
> The modeller should take care of this itself.

An if it 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 might be helpful.

> 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 it's not clear what's the resulting object, but why not 
dropping it *with a warning*, so the user is noticed that something may 
go wrong? What's the problem with that? Isn't that better than stopping 
with an error?

Felix Wiemann


Post a reply to this message

From: Christoph Hormann
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 22 Apr 2002 14:11:16
Message: <3CC45243.AC4824D1@gmx.de>
Felix Wiemann wrote:
> 
> > The modeller should take care of this itself.
> 
> An if it doesn't? :)

Don't blame POV-Ray.

> Of course it's not clear what's the resulting object, but why not
> dropping it *with a warning*, so the user is noticed that something may
> go wrong? What's the problem with that? Isn't that better than stopping
> with an error?

Having no object may cause secondary problems.  What if the the code uses
things like trace() or min/max_extend() and relies on reasonable results?

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

From: Slime
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 22 Apr 2002 15:02:26
Message: <3cc45e42@news.povray.org>
> > 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. :)


What normal do you suggest this disc should have?

> Of course it's not clear what's the resulting object, but why not
> dropping it *with a warning*, so the user is noticed that something may
> go wrong? What's the problem with that? Isn't that better than stopping
> with an error?

Hmm... there are good arguments either way for this. Personally, I'd rather
have the error, since I probably generated the problematic cylinder with a
macro that generates random cylinders or something, and I'd like to know
that there's a problem rather than rendering for a while, only to discover
that a cylinder is missing.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]


Post a reply to this message

From: Anders K 
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 22 Apr 2002 17:10:16
Message: <3cc47c38$1@news.povray.org>
There's a huge difference between a box with two identical points and a
cylinder with two identical points. For a box with two identical points, the
standard formula for a box is still valid; no special checks are needed for
this case. There is no reason to arbitrarily disallow such a box.

For a cylinder with two identical points, however, there is no way to
compute the direction of the cylinder, which is needed to figure out how to
align the end caps. An attempt to render this cylinder would result in a
division by zero. So the current behavior makes sense in both cases.

Anders


Post a reply to this message

From: Anders K 
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 22 Apr 2002 17:12:13
Message: <3cc47cad$1@news.povray.org>
There's a huge difference between a box with two identical points and a
cylinder with two identical points. For a box with two identical points, the
standard formula for a box is still valid; no special checks are needed for
this case. There is no reason to arbitrarily disallow such a box.

For a cylinder with two identical points, however, there is no way to
compute the direction of the cylinder, which is needed to figure out how to
align the end caps. An attempt to render this cylinder would result in a
division by zero. So the current behavior makes sense in both cases.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}


Post a reply to this message

From: Anders K 
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 23 Apr 2002 10:27:12
Message: <3cc56f40$1@news.povray.org>
There's a huge difference between a box with two identical points and a
cylinder with two identical points. For a box with two identical points, the
standard formula for a box is still valid; no special checks are needed for
this case. There is no reason to arbitrarily disallow such a box.

For a cylinder with two identical points, however, there is no way to
compute the direction of the cylinder, which is needed to figure out how to
align the end caps. An attempt to render this cylinder would result in a
division by zero. So the current behavior makes sense in both cases.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}


Post a reply to this message

From: Anders K 
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 23 Apr 2002 10:29:23
Message: <3cc56fc3@news.povray.org>
There's a huge difference between a box with two identical points and a
cylinder with two identical points. For a box with two identical points, the
standard formula for a box is still valid; no special checks are needed for
this case. There is no reason to arbitrarily disallow such a box.

For a cylinder with two identical points, however, there is no way to
compute the direction of the cylinder, which is needed to figure out how to
align the end caps. An attempt to render this cylinder would result in a
division by zero. So the current behavior makes sense in both cases.

Anders


--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}


Post a reply to this message

From: Anders K 
Subject: Re: Round_Box #macro (in shapes.inc) and negative values
Date: 23 Apr 2002 10:35:14
Message: <3cc57122$1@news.povray.org>
Hey!! Why did you set the followups to povray.general without telling
anyone, Christoph? No wonder my messages haven't been showing up in
povrray.beta-test!

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.