Ron Parker wrote:

> ...Opinions on this, especially
> from people who are using the rather bizarre current semantics,
> are welcome.


Since "=" is a float operator, and since float operations are
operated over each element of a vector (for example,
<1, 2, 3> * 4), the current implementation makes sense.

Better than the vlength solution may be the direct approach :

#macro IsZeroVector(V)
 ( (V.x=0) & (V.y=0) & (V.z=0) )
#end

#if (IsZeroVector(mynormal))
....
#end
  
> 
> >2) I'd like to have an option of specifying the length of
> >the trace vector and have trace() return 0 (no intersection) when this length
> >is exceeded.
> 
> Again, this requires an additional parameter

You asked for opinions, so....

Again, this seems an application where macros would prove
quite useful.  The burden of proof should be against modifying core
code when macros can serve similar functionality without substantial
overhead. But if the test is one which will be performed often
(and the obvious collision detection application may well provide
such a case), then perhaps the encoding is justified.

Dan

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

On Wed, 18 Nov 1998 18:00:06 -0600, Dan Connelly <djc### [at] flashnet>
wrote:

>> ...Opinions on this, especially
>> from people who are using the rather bizarre current semantics,
>> are welcome.
>
>Since "=" is a float operator, and since float operations are
>operated over each element of a vector (for example,
><1, 2, 3> * 4), the current implementation makes sense.

It's consistent, yes, but surely you can't argue with a
straight face that it makes sense.  I think it'd be nice
to compare two vectors without having to muck with macros
(which incur a biggish parsing penalty)

Post a reply to this message

Ron Parker wrote:
/.../ 
> I agree that there's a problem.  Perhaps the proper solution is to
> make it easier to compare vector quantities, so that something like
> "#if (mynormal=0)" will work.  Then, the code to compare the normal
> vector would be almost the same as the code to compare a boolean,
> without having to add yet another parameter to an already big list.
> 
> Right now, inexplicably, the expression "mynormal=0" returns a
> vector with true wherever the corresponding component of
> mynormal is zero and false wherever it's not.

Uh... You lost me there. Surely #if (mynormal=0) returns an error? What do you
mean by "mynormal=0 returns a vector with true"? Could you explain?
Otherwise this one is a minor problem; I don't know whether trace() will be
mostly used in cases of quaranteed intersection or not.

/.../
> time) over testing the result yourself, because the built-in trace 
> functions don't have any limits on depth.  That is, it'd still have 
> to find all the intersections and check the distance to the closest 
> one, just like you're doing now in POV code.  Of course, some
> objects could have more optimal tests, but that would make for
> some pretty big changes.

You could optionally limit the trace function with a bounding sphere (or have
the user specify a bounding object?): when this is hit, trace() would return 0.

Margus

Post a reply to this message

Margus Ramst wrote:

> Uh... You lost me there. Surely #if (mynormal=0) returns an error? What do you
> mean by "mynormal=0 returns a vector with true"? Could you explain?
> Otherwise this one is a minor problem; I don't know whether trace() will be
> mostly used in cases of quaranteed intersection or not.

#declare a = (<1, 2, 3> = 2);
#render concat("a : <", str(a.x,0,0), ", ", str(a.y,0,0), ", ", str(a.z,0,0), ">\n")
sphere {a, 1}

Dan
-- 
http://www.flash.net/~djconnel/

Post a reply to this message

On Thu, 19 Nov 1998 03:45:00 +0200, Margus Ramst <mar### [at] peakeduee> wrote:
>Uh... You lost me there. Surely #if (mynormal=0) returns an error? 

#if (mynormal=0) is indeed an error, but not for the reason you think it
is.  (mynormal=0) is a valid expression, but it returns a vector result.
Dan has posted code to show you what it does, or you can read the 
description in the docs under "vector operators."

>You could optionally limit the trace function with a bounding sphere (or have
>the user specify a bounding object?): when this is hit, trace() would return 0.

The way POV works is to first find all intersections, then find the closest
one (except in certain cases like isosurfaces and some other objects.)  The
existing code doesn't have a concept of bounding a ray, because there is no
use for such a thing in tracing light rays.  What you're asking for can't be
done any more efficiently in C than it can in POV script, except for certain
objects that could be optimized with much labor.

Post a reply to this message

On Thu, 19 Nov 1998 01:05:16 GMT, Ronald L. Parker <par### [at] mailfwicom> wrote:
>On Wed, 18 Nov 1998 18:00:06 -0600, Dan Connelly <djc### [at] flashnet>
>wrote:
>
>>> ...Opinions on this, especially
>>> from people who are using the rather bizarre current semantics,
>>> are welcome.
>>
>>Since "=" is a float operator, and since float operations are
>>operated over each element of a vector (for example,
>><1, 2, 3> * 4), the current implementation makes sense.
>
>It's consistent, yes, but surely you can't argue with a
>straight face that it makes sense.  I think it'd be nice
>to compare two vectors without having to muck with macros
>(which incur a biggish parsing penalty)

Even the official documentation says "Admittedly this isn't very useful but 
its consistent with other vector operations."

I failed to mention the other point I wanted to make, which is that I'm 
proposing only to change the behavior in a case that is currently a syntax 
error.  Someone using the code you posted to demonstrate this feature would 
still get the same results.  Someone doing "#if (mynormal=0)" would get what 
they expect instead of a syntax error saying that a float value was expected.
If someone did

  #declare mybool=(mynormal=0);
  #if (mybool) 

it wouldn't work (mybool would be a vector, despite its name) but the obvious
way of doing it would now work and with much less work (for both the script
writer and the parser) than the way it has to be done now.

Post a reply to this message

This is a good idea.  The simplest generalization would be
for a vector to have its components logically or'ed when used
in a boolean context.... I don't know how distributed through 
the code is the logical evaluation of parameters, but I suspect
this could be done in a compact fashion (wherever the error is generated,
a conversion could be done instead).

Dan


Ron Parker wrote:
> I'm
> proposing only to change the behavior in a case that is currently a syntax
> error.  Someone using the code you posted to demonstrate this feature would
> still get the same results.  Someone doing "#if (mynormal=0)" would get what
> they expect instead of a syntax error saying that a float value was expected.
> If someone did
> 
>   #declare mybool=(mynormal=0);
>   #if (mybool)
> 
> it wouldn't work (mybool would be a vector, despite its name) but the obvious
> way of doing it would now work and with much less work (for both the script
> writer and the parser) than the way it has to be done now.

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

In article <3654B0CB.BFF188F2@flash.net>, Dan Connelly wrote:
>This is a good idea.  The simplest generalization would be
>for a vector to have its components logically or'ed when used
>in a boolean context.... I don't know how distributed through 
>the code is the logical evaluation of parameters, but I suspect
>this could be done in a compact fashion (wherever the error is generated,
>a conversion could be done instead).

The problem with this is, you want to or them for != and and them
for =.  You have to actually do the conversion a bit further down
the parse tree, but I've already figured out how it is to be done.

Post a reply to this message

On 19 Nov 1998 23:24:11 -0500, root <root@parkrrrr.> wrote:

[snip]

In case anyone cares, that was me.  Clearly I need to fix my 
.slrnrc on the root account. :)

Post a reply to this message

I see... The bounding object feature would still offer more ease of use in all
kinds of collision detection applications; but since this can also be done in
POV script without any significant disadvantage, I won't whine if it isn't
implemented in the source.
Btw. I think there might be some advantages to using light ray bounding, for
example with light attenuation and radiosity... Not sure, though.

Margus

Ron Parker wrote:
> 
> The way POV works is to first find all intersections, then find the closest
> one (except in certain cases like isosurfaces and some other objects.)  The
> existing code doesn't have a concept of bounding a ray, because there is no
> use for such a thing in tracing light rays.  What you're asking for can't be
> done any more efficiently in C than it can in POV script, except for certain
> objects that could be optimized with much labor.

Post a reply to this message