Does POV provide any means where I can test for the intersection between
two objects?

Post a reply to this message

No, not unless you're prepared to jump into the code and try to find some
means of it.  I wonder whether there is a modified version of POV-Ray to do
this?  Can you be a little more specific?  (If you only need a recursive
sphere type detection I might be able to help)

--
Lance Birch
Remove the smiley to e-mail.
http://www1.tpgi.com.au/users/ambient/lance

Post a reply to this message

I want to define limits for object interaction. Instead of having one
object pass into and through another, I want to have either the smaller
object leave a hole in the larger, or for the two objects bounce off
each other. 

Concepts that I'm thinking of include animating wind blowing trees.
Branches should not pass through each other, while loose leaves should
not pass through the trees.

Post a reply to this message

Stephen Waelder <wae### [at] wfnet> wrote:

> I want to define limits for object interaction. Instead of having one
> object pass into and through another, I want to have either the smaller
> object leave a hole in the larger, or for the two objects bounce off
> each other. 
> 
> Concepts that I'm thinking of include animating wind blowing trees.
> Branches should not pass through each other, while loose leaves should
> not pass through the trees.

Hi!

Actually I think what you are describing is a *very* difficult problem,
from a mathematical point of view. Since objects can be described by at
least a fourth grade polynomial, you are asking for the solution space
of two fourth grade polynomials *or worse*. 
With that said we can be satisfied with a heuristic algorithm for your
problem, such as just throwing away a couple of rays from the center of
one of the objects and see if they hit the intersection of the two 
objects (which actually is a simple problem to solve). Now one way to 
implement this would be to hardcode it into povray. Or better yet, we
can add a function to povray which allows one to get the next 
intersection of a specified ray with a set of objects. The later 
solution would be preferable since it could be used for a lot of things
(if think it have been suggested before in povray.programming).
Does anyone feel the surge to implement this and to specify a nice
syntax for it? (And while your at it, why not throw in a function to
get the gradient at a specified point for a given object...)

/ Mathias B.

Post a reply to this message

On Wed, 1 Apr 1998 20:37:30 +0200, mbr### [at] swipnetse (Mathias Broxvall)
wrote:

>Or better yet, we
>can add a function to povray which allows one to get the next 
>intersection of a specified ray with a set of objects. The later 
>solution would be preferable since it could be used for a lot of things
>(if think it have been suggested before in povray.programming).

I'm the one who suggested this on povray.programming.  I've kinda
halted efforts on my superpatch project until V3.1 comes out, but I
was planning to include such a thing in it.  It's not that difficult
to do, and if someone really, really needs it I can take a couple of
hours and code it up.

>Does anyone feel the surge to implement this and to specify a nice
>syntax for it? 

I like trace( <origin-vector>, <direction-vector> ) or the alternate
form, trace( <origin-vector>, <direction-vector>, <#declared-object>).
This way, you can check for any intersection, or just ones with a
specified object.

>(And while your at it, why not throw in a function to
>get the gradient at a specified point for a given object...)

Assuming you really meant to say the normal vector, this isn't too
bad, either.  The syntax would be something along the lines of
normvect( <#declared-object>, <point-vector> ).  I'm not happy with
the "normvect" word, but "normal" is already taken.

Post a reply to this message

It'd be great if you could go ahead and add those features, even without the
superpatch.  Also CC the code to the pov team in case they would consider
adding it to pov 3.1.  I think it would facilitate a lot of fancy includes
such as crude physics models for animations.

Ken

Ronald L. Parker wrote in message <3522b674.31204900@10.0.2.33>...
>On Wed, 1 Apr 1998 20:37:30 +0200, mbr### [at] swipnetse (Mathias Broxvall)
>wrote:
>
>I'm the one who suggested this on povray.programming.  I've kinda
>halted efforts on my superpatch project until V3.1 comes out, but I
>was planning to include such a thing in it.  It's not that difficult
>to do, and if someone really, really needs it I can take a couple of
>hours and code it up.
>
>I like trace( <origin-vector>, <direction-vector> ) or the alternate
>form, trace( <origin-vector>, <direction-vector>, <#declared-object>).
>This way, you can check for any intersection, or just ones with a
>specified object.
>
>Assuming you really meant to say the normal vector, this isn't too
>bad, either.  The syntax would be something along the lines of
>normvect( <#declared-object>, <point-vector> ).  I'm not happy with
>the "normvect" word, but "normal" is already taken.
>

Post a reply to this message

Ronald L. Parker <ron### [at] farmworkscom> wrote:

> I like trace( <origin-vector>, <direction-vector> ) or the alternate
> form, trace( <origin-vector>, <direction-vector>, <#declared-object>).
> This way, you can check for any intersection, or just ones with a
> specified object.

Hmm, I like the later one better than the first one (of course the
object can be a union/merge!?) since it could cause some 
missunderstandings regarding *what* we are tracing otherwise.
(You have to "know" what objects already have been parsed etc...)
But otherwise I'd realy like it if you could implement this.

> Assuming you really meant to say the normal vector, this isn't too
> bad, either.  The syntax would be something along the lines of
> normvect( <#declared-object>, <point-vector> ).  I'm not happy with
> the "normvect" word, but "normal" is already taken.

Yepp, I do. With these additions and the macro facility from the
isosurface patch one can make some realy *cool* include files.
Btw, I'd be glad to compile a macintosh port of your work when
you are finished (I assume you are using pc and/or unix) if you
like to (both of "this" and the "superpatch").
Cheers

/ Mathias Broxvall.

Post a reply to this message

On Thu, 2 Apr 1998 16:22:10 +0200, mbr### [at] swipnetse (Mathias Broxvall)
wrote:

>Ronald L. Parker <ron### [at] farmworkscom> wrote:

>> Assuming you really meant to say the normal vector, this isn't too
>> bad, either.  The syntax would be something along the lines of
>> normvect( <#declared-object>, <point-vector> ).  I'm not happy with
>> the "normvect" word, but "normal" is already taken.
>
>Yepp, I do. With these additions and the macro facility from the
>isosurface patch one can make some realy *cool* include files.

Now that will require the "superpatch", or at least part of it.  I
think I would also have to add extra code to the macro parser to
handle any new functions I might add, and I'm not sure of the
complexity of that part.

>Btw, I'd be glad to compile a macintosh port of your work when
>you are finished (I assume you are using pc and/or unix) if you
>like to (both of "this" and the "superpatch").

That would be "and," though my puny 486/33 running FreeBSD isn't quite
powerful enough to build POV, and I haven't kept the makefiles
up-to-date.

Post a reply to this message

Stephen Waelder wrote:
> 
> I want to define limits for object interaction. Instead of having one
> object pass into and through another, I want to have either the smaller
> object leave a hole in the larger, or for the two objects bounce off
> each other.
> 
> Concepts that I'm thinking of include animating wind blowing trees.
> Branches should not pass through each other, while loose leaves should
> not pass through the trees.

Unfortunately there is no general formula or algorithm for determining
if two objects intersect.  One fellow asked me about two months ago
how to determine if two boxes intersect; I'm still working on it.

Regards,
John

-- 
"What can I say?  Everyone likes flowers, even us evildoers." -- Zorak

Post a reply to this message