OK, I don't know exactly if I should bug Ron directly or post it here an hope
he sees it. Since this isn't a bug report but rather a new feature request,
I'll post it here and see what others think about it.
The trace function in the Superpatch is a wonderful thing, but 2 things would
make it even more wonderful (in my opinion, at least):

1) It is rather cumbersome check the normal vector to confirm an intersection -
maybe a new Boolean flag as an indicator?

2) Something I'm currently working at requires a check whether an intersection
occurred within a specified distance from the start point. This extra check is
rather slow; therefore 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.

Comments? Suggestions? Prompt inclusion in the next Superpatch ;)?

Thanks
Margus

Post a reply to this message

On 18 Nov 1998 06:04:43 -0500, Margus Ramst <mar### [at] peakeduee> wrote:
>OK, I don't know exactly if I should bug Ron directly or post it here an hope
>he sees it. Since this isn't a bug report but rather a new feature request,
>I'll post it here and see what others think about it.

Normally, I'd say you should bug me directly, but since I ended up
asking for outside opinions on this one anyway, I think it's okay.
Maybe I should get Twyst to make me a superpatch forum on 
PatchStation.  (That's not too farfetched: that's currently the
only place to get the superpatch, so why not support it there?)

>The trace function in the Superpatch is a wonderful thing, but 2 things would
>make it even more wonderful (in my opinion, at least):
>
>1) It is rather cumbersome check the normal vector to confirm an intersection -
>maybe a new Boolean flag as an indicator?

This is true.  I thought about having it take two vector parameters 
and store the intersection and normal into them, returning a boolean 
for whether it succeeded or failed.  The only problem with this is it 
makes it less friendly for cases when you know there'll be an 
intersection, as you can currently do this in that case:
  sphere { trace( my_hfield_obj, Start_Vect, -y ), .5 }

You could, of course, use "#if (vlength(mynormal))" but that's a
few more operations (including a square root) than you really need.

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.  This is a
completely nonintuitive result, and I'd be surprised if anyone
actually uses it.  Unfortunately, this behavior is documented,
so I'm not sure what to do about it.  Should we realize we're
parsing a conditional expression with the expectation of getting
a single float value and parse relational operators differently 
in that case?  How do you parse <, <=, >, and >= as vector 
operators returning a scalar value?  Opinions on this, especially 
from people who are using the rather bizarre current semantics, 
are welcome.

>2) Something I'm currently working at requires a check whether an intersection
>occurred within a specified distance from the start point. This extra check is
>rather slow; therefore 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, though it would be 
easy enough to add an optional parameter on the end after the 
already-optional normal vector.  Realize, though, that this won't
gain you as much as you might think (except a tiny bit of parse 
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.

Post a reply to this message

Ron Parker wrote in message <3652d7e6.0@news.povray.org>...
>On 18 Nov 1998 06:04:43 -0500, Margus Ramst <mar### [at] peakeduee> wrote:
>>OK, I don't know exactly if I should bug Ron directly or post it here an
hope
>>he sees it. Since this isn't a bug report but rather a new feature
request,
>>I'll post it here and see what others think about it.
>
>Normally, I'd say you should bug me directly, but since I ended up
>asking for outside opinions on this one anyway, I think it's okay.
>Maybe I should get Twyst to make me a superpatch forum on
>PatchStation.  (That's not too farfetched: that's currently the
>only place to get the superpatch, so why not support it there?)

OK. Done. =)

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

Post a reply to this message

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