![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 24 May 2000 09:17:50 -0400, Warp wrote:
>Ron Parker <ron### [at] povray org> wrote:
>: It's represented as a merge. There are special cases in the code for
>: merges. IIRC, it could be represented as the inverse of the intersections
>: of the inverses of the constituent objects, but it isn't.
>
> What is the algorithm for the ray-intersection test for merges (briefly
>and clearly exaplained, if possible :) )? I'm interested in knowing it.
1. Find all intersections.
2. Pop an intersection off the stack. If none remains, no intersection
with this object occurred.
3. Test to see if that intersection is inside any subobject other than the
one it is on the surface of. If so, throw it away and go to 2.
4. That's it. Do whatever you do with the intersection you now have. Don't
forget to flush the stack, put the seat down, and turn off the light.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
These are my opinions. I do NOT speak for the POV-Team.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker <ron### [at] povray org> wrote:
: 1. Find all intersections.
: 2. Pop an intersection off the stack. If none remains, no intersection
: with this object occurred.
: 3. Test to see if that intersection is inside any subobject other than the
: one it is on the surface of. If so, throw it away and go to 2.
Yes, pretty simple.
How do you know that the point is inside an object? You ask that
object "hey! is this point inside you?"?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 24 May 2000 11:05:52 -0400, Warp wrote:
> How do you know that the point is inside an object? You ask that
>object "hey! is this point inside you?"?
Yes, exactly. That's one of the reasons meshes (in the official POV)
can't be used in CSG: they don't have a proper implementation of that
method.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
These are my opinions. I do NOT speak for the POV-Team.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 23 May 2000 22:01:44 -0400, ron### [at] povray org (Ron Parker)
wrote:
>>Merge is internally represented as a complex CSG. It takes more memory
>>and generally takes longer to render than the equivalent union. This
>>is not true in some special cases but this shouldn't be one of them.
>
>Actually, it is internally represented as a merge. Difference is the
>operation you're thinking of.
I know a difference is an intersection with the inverse. What I meant
was that merge { object { A } object { B } } is equivalent to
union
{ intersection { object { A } object { B inverse } }
intersection { object { B } object { A inverse } }
}
>In this case, a ray will never hit internal walls anyway, so there is
>probably no difference in speed.
Merging may have actually helped (the problem has been solved by
manual bounding etc.) if it helped POV bound the individual stones. I
can't say more without testing it.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usa net
TAG e-mail : pet### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 25 May 2000 00:51:27 +0300, Peter Popov wrote:
>On 23 May 2000 22:01:44 -0400, ron### [at] povray org (Ron Parker)
>wrote:
>
>>>Merge is internally represented as a complex CSG. It takes more memory
>>>and generally takes longer to render than the equivalent union. This
>>>is not true in some special cases but this shouldn't be one of them.
>>
>>Actually, it is internally represented as a merge. Difference is the
>>operation you're thinking of.
>
>I know a difference is an intersection with the inverse. What I meant
>was that merge { object { A } object { B } } is equivalent to
>
>union
>{ intersection { object { A } object { B inverse } }
> intersection { object { B } object { A inverse } }
>}
This is the symmetric difference, equivalent to
difference {
union {object {A} object {B}}
intersection {object {A} object {B}}
}
(except for the coincident surface problems the latter causes) and
logically similar to exclusive-or.
I think merge is actually equivalent to
intersection {
object { A inverse }
object { B inverse }
inverse
}
but it's not represented that way internally. The code actually has
special cases for merge, unlike for difference.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
These are my opinions. I do NOT speak for the POV-Team.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 24 May 2000 18:26:36 -0400, ron### [at] povray org (Ron Parker)
wrote:
>I think merge is actually equivalent to
>
>intersection {
> object { A inverse }
> object { B inverse }
> inverse
>}
It certainly looks like it, yes. Thanks for the info.
>but it's not represented that way internally. The code actually has
>special cases for merge, unlike for difference.
Yes, I saw your reply to Warp after I posted :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usa net
TAG e-mail : pet### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |