Take a close look at the box statement below.

box{<-1.0, 1.0, -1.0>,< -1.0, -1.0, -1.0>}

This will render with out error in v3.1a. Why ? I would think
a divide by zero error of something would happen. I know a
scale <0,1,0> will yeild a warning and Pov will automaticaly
add a scale by 1 in the 0 vectors BUT if built with a 0 demension
it is unaware ?
Given a zero demnsion in the x and z directions what is
it rendering. An infininatly thin y axis box ?

Ken Tyler

Post a reply to this message

Ken wrote in message <365### [at] pacbellnet>...
>Take a close look at the box statement below.
>
>box{<-1.0, 1.0, -1.0>,< -1.0, -1.0, -1.0>}
>
>This will render with out error in v3.1a. Why ? I would think
>a divide by zero error of something would happen. I know a
>scale <0,1,0> will yeild a warning and Pov will automaticaly
>add a scale by 1 in the 0 vectors BUT if built with a 0 demension
>it is unaware ?
>Given a zero demnsion in the x and z directions what is
>it rendering. An infininatly thin y axis box ?
>
>Ken Tyler
>
As far as I can tell, it's because it's not scaling it. The XYZ coords are
valid, as far as Pov is concerned, because it builds to those dimensions.

Also, a scale <0,1,0> doesn't scale an object down to 0. Look at how scale
works.. It's a percentage. think "scale by X" instead of "scale to X".
the way the math works (forgive me if I'm wrong.. i'm rusty..) is thus:

Scale <0,1,0> = vector.x / (1/scale.x) , vector.y / (1/scale.y) , vector.z /
(1/scale.z)
hence the division by 0 errors.

(No idea why it doesn't use multiplication... it would be easier, and have
no problem with a 0 value.... )

--
Twyst
============================================================
for pov-ray news, reviews, and tutorials
http://twysted.net
e-mail: twy### [at] twystednet
============================================================

Post a reply to this message

On Tue, 17 Nov 1998 10:54:00 -0700, Twyst <twy### [at] twystednet> wrote:
>As far as I can tell, it's because it's not scaling it. The XYZ coords are
>valid, as far as Pov is concerned, because it builds to those dimensions.

but you'd have a coincident surface problem that makes it unusable in any
practical sense, so you might as well use triangles or a polygon.

>Also, a scale <0,1,0> doesn't scale an object down to 0. Look at how scale
>works.. It's a percentage. think "scale by X" instead of "scale to X".

No, it does scale down to zero.  Effectively, it would project into a
plane.  While it's true that scale doesn't mean "scale to x," the result
is the same when x is zero, because anything multiplied by zero is zero.

The problem with zero scale is, the way transforms work is backwards of 
what one might expect.  The object doesn't move, the rays get transformed 
from "world space" into "object space" using the inverse of the specified 
transform.  Scales by zero are noninvertable (as is any matrix with a zero
determinant, such as an inappropriate combination of two shear transforms)
and therefore impossible to use in such a scheme.  Yes, it's avoiding 
division by zero, but there is no reasonable alternative.  

This model is also what makes nonlinear transforms difficult or impossible: 
a straight ray in world space turns into a curve when you try to transform 
it into object space, assuming you can even find an inverse transform, and
finding the intersection of an arbitrary curve with an object tends to be 
a bit tougher. (Though there are a class of transformations which are 
not linear yet still map lines to lines. These are the oft-requested 
perspective transforms, commonly stated as "scale X by Y".  They are not
invertible everywhere.)

Post a reply to this message

> Take a close look at the box statement below.
>
> box{<-1.0, 1.0, -1.0>,< -1.0, -1.0, -1.0>}

Would this be considered a 1D object ?
Dan recently accused me of posting a 1D image and
I think this is a much closer approximation.

Ken Tyler

Post a reply to this message

Ken wrote:
> 
> > Take a close look at the box statement below.
> >
> > box{<-1.0, 1.0, -1.0>,< -1.0, -1.0, -1.0>}
> 
> Would this be considered a 1D object ?
> Dan recently accused me of posting a 1D image and
> I think this is a much closer approximation.
> 
> Ken Tyler

So, what's the cross product of 1d vectors?

I think I'd be more worried if it parsed that and actually rendered a box on
the screen. Hmmm... if a ray were sent out that just happened to hit, say,
<-1,0,-1>, it would display it, wouldn't it? I'm not sure whether that's a
good thing or not--there's really nothing there for it to hit...

-Mark R.

Post a reply to this message

Mark Radosevich wrote:

> Ken wrote:
> >
> > > Take a close look at the box statement below.
> > >
> > > box{<-1.0, 1.0, -1.0>,< -1.0, -1.0, -1.0>}
> >
> > Would this be considered a 1D object ?
> > Dan recently accused me of posting a 1D image and
> > I think this is a much closer approximation.
> >
> > Ken Tyler
>
> So, what's the cross product of 1d vectors?
>
> I think I'd be more worried if it parsed that and actually rendered a box on
> the screen. Hmmm... if a ray were sent out that just happened to hit, say,
> <-1,0,-1>, it would display it, wouldn't it? I'm not sure whether that's a
> good thing or not--there's really nothing there for it to hit...
>
> -Mark R.

  Truth is it produced nothing. It parses just fine but
nothing appears. I also tried using 2D vectors. This did
produce a result exactly as one would expect. It produced
a single face of the box.
  How would Pov determine the inside of the object ? Would
it just take the normalized vector as it would a plane ?

Ken Tyler

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

On Wed, 18 Nov 1998 00:05:36 -0800, Ken <tyl### [at] pacbellnet> wrote:
>  Truth is it produced nothing. It parses just fine but
>nothing appears. I also tried using 2D vectors. This did
>produce a result exactly as one would expect. It produced
>a single face of the box.
>  How would Pov determine the inside of the object ? Would
>it just take the normalized vector as it would a plane ?

Which normal would it use?  In an abstract sense, both faces
of the box occupy the same space.  

Most likely, this object will behave almost exactly like a
polygon object.  You can use it in CSG, but it wouldn't be
very useful except perhaps in a union.  (Don't try merge -
coincident surfaces.)

Post a reply to this message