 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22 May 2000 03:55:44 -0400, Warp wrote:
> Actually it's represented as a series of intersections of inverted objects
>or something like that.
Nope. It could be, but it's not, and changing it didn't help the speed
any so it remains the way it was, as a separate CSG type.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povray org> wrote:
: Nope. It could be, but it's not
How is it represented then?
I remember this was a question in the 'hard-core povrayer test'. Someone
said it's represented as an intersection of inverted objects or something
similar, if I remember correctly.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24 May 2000 03:56:35 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Nope. It could be, but it's not
>
> How is it represented then?
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.
> I remember this was a question in the 'hard-core povrayer test'. Someone
>said it's represented as an intersection of inverted objects or something
>similar, if I remember correctly.
Difference is represented as an intersection. Perhaps that's what you're
thinking of.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> 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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24 May 2000 09:17:50 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 May 2000 22:01:44 -0400, ron### [at] povrayorg (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] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 25 May 2000 00:51:27 +0300, Peter Popov wrote:
>On 23 May 2000 22:01:44 -0400, ron### [at] povrayorg (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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 24 May 2000 18:26:36 -0400, ron### [at] povrayorg (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] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
