 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What's the difference between merge and union? I noticed that one (I think
it was merge) took quite a bit longer then the other.
Thanks!
-Ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ian Burgmyer wrote:
>
> What's the difference between merge and union? I noticed that one (I think
> it was merge) took quite a bit longer then the other.
>
> Thanks!
> -Ian
There is a major difference between the two. The union is really not
a true CSG operation and could be more accurately described as a group
container. This makes it possible to combine several elements into one
item that can then be translated, rotated, and scaled as if they were
just on object.
A merge operation on the otherhand is a true CSG operation and has
specific uses. The main feature of a merge operation is that it will
remove the interior surfaces of over lapping objects. This is useful
it you don't want a "cell" effect when over lapping several objects
since the merge operation removes all internal faces. You will in most
cases use this operation only when using clear objects but the are some
special cases where you can use it with solid colored objects as well.
I would have to dig deep to give you an example of the last but would
gladly do so if you are interested.
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There is a major difference between the two. The union is really not
> a true CSG operation and could be more accurately described as a group
> container. This makes it possible to combine several elements into one
> item that can then be translated, rotated, and scaled as if they were
> just on object.
In other words, just use a group in Moray ;)
> A merge operation on the otherhand is a true CSG operation and has
> specific uses. The main feature of a merge operation is that it will
> remove the interior surfaces of over lapping objects. This is useful
> it you don't want a "cell" effect when over lapping several objects
> since the merge operation removes all internal faces. You will in most
> cases use this operation only when using clear objects but the are some
> special cases where you can use it with solid colored objects as well.
> I would have to dig deep to give you an example of the last but would
> gladly do so if you are interested.
Yeah, I'm interested! I'd like to see how the merge operation ticks.
Don't go through too much trouble, though :)
Thanks!
-Ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ian Burgmyer wrote:
> In other words, just use a group in Moray ;)
sigh ! A modeller user.
> > A merge operation on the otherhand is a true CSG operation and has
> > specific uses. The main feature of a merge operation is that it will
> > remove the interior surfaces of over lapping objects. This is useful
> > it you don't want a "cell" effect when over lapping several objects
> > since the merge operation removes all internal faces. You will in most
> > cases use this operation only when using clear objects but the are some
> > special cases where you can use it with solid colored objects as well.
> > I would have to dig deep to give you an example of the last but would
> > gladly do so if you are interested.
>
> Yeah, I'm interested! I'd like to see how the merge operation ticks.
>
> Don't go through too much trouble, though :)
>
> Thanks!
> -Ian
Found it. This example is excellent for this thread because it uses both
a union to group together cones with and then uses the merge function in
a non typical usage that clears the inside surfaces. I will leave it as
an experiment to the user to find out why it works. Test in 1 week...
// Super neat geometric shape using the merge function
#declare SnowTex =
texture {
pigment { rgb 1 }
finish {
crand 0.1
ambient 0.6
diffuse 0.2
specular 1
roughness 0.001
brilliance 2
reflection 0.02
}
}
#declare MB =
union {
cone { <0,0,0>,1.3,< 0, 1, 0>,-0.25 open}
cone { <0,0,0>,1.3,< 0,-1, 0>,-0.25 open}
cone { <0,0,0>,1.3,< 1, 0, 0>,-0.25 open}
cone { <0,0,0>,1.3,<-1, 0, 0>,-0.25 open}
cone { <0,0,0>,1.3,< 0, 0, 1>,-0.25 open}
cone { <0,0,0>,1.3,< 0, 0,-1>,-0.25 open}
}
#declare Fk =
merge {
sphere { <0,0,0>,1.1 }
object { MB rotate 0*y}
object { MB rotate 45*z}
object { MB rotate 45*y}
object { MB rotate 45*x}
}
object { Fk
texture { SnowTex }
scale 2
}
camera { location<0,0,-9> look_at 0}
light_source { < 100,225,-200> rgb 1}
Enjoy,
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I will leave it as
> an experiment to the user to find out why it works. Test in 1 week...
I think I know. Is it because the geometry of the objects in the merge CSG
block are not traced?
I did a little checking and experimenting with the image. Then, I did a tad
bit of research in the manual to confirm my findings.
-Ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Think the proper term might be /inversed clipped_by/ seeing as how
there are no structures left within the bounds of the master object.
That is to say, no surfaces exist unlike using a form of
'intersection' or 'difference' (the only pair of things everything
else seems to be based on when "cutting").
Just happened to think, if a unioned CSG is completely opaque is there
no ray testing done within said CSG? Sure this has been asked a
thousand times before so maybe it's in the VFAQ, I'll go look : )
Bob
Ian Burgmyer <the### [at] hotmail com> wrote in message
news:37e40019@news.povray.org...
> > I will leave it as
> > an experiment to the user to find out why it works. Test in 1
week...
>
> I think I know. Is it because the geometry of the objects in the
merge CSG
> block are not traced?
>
> I did a little checking and experimenting with the image. Then, I
did a tad
> bit of research in the manual to confirm my findings.
>
> -Ian
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes <inv### [at] aolcom> wrote:
: Just happened to think, if a unioned CSG is completely opaque is there
: no ray testing done within said CSG?
AFAIK when you shoot a ray, you get _all_ the intersections of that ray
and every surface it hits.
That's why shadow calculations of semi-transparent objects are so fast and
max_trace_level independent.
--
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 Fri, 17 Sep 1999 18:09:32 -0700, Ken <tyl### [at] pacbellnet> wrote:
>
>
>Ian Burgmyer wrote:
>>
>> What's the difference between merge and union? I noticed that one (I think
>> it was merge) took quite a bit longer then the other.
>>
>> Thanks!
>> -Ian
>
> There is a major difference between the two. The union is really not
>a true CSG operation and could be more accurately described as a group
>container.
Interesting distinction you make there. I'd say union is the true
CSG operation - since it's what we'd generally consider atomic - and
merge is the imposter; it's able to be synthesized by clever
combination of intersection and inverse.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19 Sep 1999 05:17:31 -0400, Nieminen Juha <war### [at] cctutfi> wrote:
> AFAIK when you shoot a ray, you get _all_ the intersections of that ray
>and every surface it hits.
In most cases, yes. Not in the case of meshes, though. It's also
possible that POV automatically ignores objects that are entirely
further away than the closest intersection so far. If it doesn't,
it should.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> > There is a major difference between the two. The union is really not
> >a true CSG operation and could be more accurately described as a group
> >container.
>
> Interesting distinction you make there. I'd say union is the true
> CSG operation - since it's what we'd generally consider atomic - and
> merge is the imposter; it's able to be synthesized by clever
> combination of intersection and inverse.
Since I was responding to a question in the new users group I defend my
reply as appropriate for conveying a new concept. Had he asked for info
on and, or, and not operations I probably would have remained silent and
would have let you answer it yourself.
I like to think of CSG operations as to how they perform physically in
an operation. My idea of more better analogies would be:
union = gluing
intersection = cutting
difference = scooping
merge = melting and gluing
clipping = cutting and hollowing
inverse = inside outing
There ! That should give you something to cry in despair over for a while :)
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Haha! This is kinda what I was looking for in the first place!
It sums everything up pretty well ;)
-Ian
> I like to think of CSG operations as to how they perform physically in
> an operation. My idea of more better analogies would be:
>
> union = gluing
> intersection = cutting
> difference = scooping
> merge = melting and gluing
> clipping = cutting and hollowing
> inverse = inside outing
>
> There ! That should give you something to cry in despair over for a while
:)
>
> --
> Ken Tyler
>
> See my 1000+ Povray and 3D Rendering and Raytracing Links at:
> http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwicom> wrote:
: It's also
: possible that POV automatically ignores objects that are entirely
: further away than the closest intersection so far. If it doesn't,
: it should.
How can it know if the object is further or not without testing the
ray-object intersection?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: intersection = cutting
: difference = scooping
I have always thought about the difference as cutting parts out from the
main object.
: clipping = cutting and hollowing
Is clipping considered CSG? Note that the 'S' stands for 'solid' :)
I think that it would also be useful if you explained the difference
between intersection and clipping and when it's better to use clipping
instead of intersection.
--
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 20 Sep 1999 06:32:51 -0400, Nieminen Juha wrote:
>Ron Parker <par### [at] fwicom> wrote:
>: It's also
>: possible that POV automatically ignores objects that are entirely
>: further away than the closest intersection so far. If it doesn't,
>: it should.
>
> How can it know if the object is further or not without testing the
>ray-object intersection?
By taking the dot product of each of the six bounding box coordinates
with the ray direction. If they're all further away, then the object
must be.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : intersection = cutting
> : difference = scooping
>
> I have always thought about the difference as cutting parts out from the
> main object.
In english the word "scooping" implies that but perhaps not as definitavely as
you have stated it.
> : clipping = cutting and hollowing
>
> Is clipping considered CSG? Note that the 'S' stands for 'solid' :)
>
> I think that it would also be useful if you explained the difference
> between intersection and clipping and when it's better to use clipping
> instead of intersection.
You might be right here.
Intersections will slice or cut an object and then apply a face where the
slice has been made.
Clipping slices an object but will not leave a face where the slice has
occured. Instead the object that has been sliced will now appear to be
hollowed out since all solid objects in POV-Ray are not truly solid.
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwicom> wrote:
: By taking the dot product of each of the six bounding box coordinates
: with the ray direction. If they're all further away, then the object
: must be.
You forget that the bounding box is not necesarily around the object...
nor it is a box... :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipped_by should be used instead of difference when the new surface is
not seen (for example, if you clip a torus and attach two cylinders to the
ends to form a bended tube, the clipped surfaces are inside the tube and thus
are not seen).
Why it should be used? Because it's faster to render.
--
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 20 Sep 1999 11:15:00 -0400, Nieminen Juha wrote:
>Ron Parker <par### [at] fwicom> wrote:
>: By taking the dot product of each of the six bounding box coordinates
>: with the ray direction. If they're all further away, then the object
>: must be.
>
> You forget that the bounding box is not necesarily around the object...
>nor it is a box... :)
You forget that if it's not around the object, it shouldn't matter to the
ray-intersection routine (obviously in practice it works in such a way that
vampire objects are possible, but that's a side-effect that could easily
disappear with better optimization.) And rest assured that finite objects
have bounding boxes whether or not such boxes are specified in the script;
that's how the min_extent and max_extent keywords in the superpatch work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 19 Sep 1999 20:10:33 -0700, Ken <tyl### [at] pacbellnet> wrote:
>intersection = cutting
Ken, I've always thought of intersection as an area of common overlap
among objects.
--
Alan ---------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Same here...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwicom> wrote:
: You forget that if it's not around the object, it shouldn't matter to the
: ray-intersection routine (obviously in practice it works in such a way that
: vampire objects are possible, but that's a side-effect that could easily
: disappear with better optimization.) And rest assured that finite objects
: have bounding boxes whether or not such boxes are specified in the script;
: that's how the min_extent and max_extent keywords in the superpatch work.
How does it calculate the bounding box of an object like this?
intersection
{ sphere { x*1000, 1001 }
sphere { -x*1000, 1001 }
}
--
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 21 Sep 1999 09:22:29 -0400, Nieminen Juha wrote:
>Ron Parker <par### [at] fwicom> wrote:
>: You forget that if it's not around the object, it shouldn't matter to the
>: ray-intersection routine (obviously in practice it works in such a way that
>: vampire objects are possible, but that's a side-effect that could easily
>: disappear with better optimization.) And rest assured that finite objects
>: have bounding boxes whether or not such boxes are specified in the script;
>: that's how the min_extent and max_extent keywords in the superpatch work.
>
> How does it calculate the bounding box of an object like this?
>
>intersection
>{ sphere { x*1000, 1001 }
> sphere { -x*1000, 1001 }
>}
It calculates the intersection of the bounding boxes of the individual
spheres, so it would bound by box{<-1,-1001,-1001>,<1,1001,1001>}. I
didn't say it was always correct; in fact, I've mentioned before that
min_extent and max_extent aren't always entirely accurate for every
object. If you specify your own bounding volume, of course, it uses
that one if it's smaller than the computed one.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwicom> wrote:
: It calculates the intersection of the bounding boxes of the individual
: spheres, so it would bound by box{<-1,-1001,-1001>,<1,1001,1001>}. I
: didn't say it was always correct; in fact, I've mentioned before that
: min_extent and max_extent aren't always entirely accurate for every
: object. If you specify your own bounding volume, of course, it uses
: that one if it's smaller than the computed one.
Thanks for the information. Every day I learn something new about povray :)
Another question:
What does "smaller" mean? I mean that how does it define "this box is
smaller than that one"?
--
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 22 Sep 1999 06:19:40 -0400, Nieminen Juha wrote:
> What does "smaller" mean? I mean that how does it define "this box is
>smaller than that one"?
It bases it on volume. The box with the smaller volume is smaller,
regardless of its actual dimensions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <par### [at] fwicom> wrote:
:> What does "smaller" mean? I mean that how does it define "this box is
:>smaller than that one"?
: It bases it on volume. The box with the smaller volume is smaller,
: regardless of its actual dimensions.
What happens when the user-defined bounding object is not a box?
--
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 23 Sep 1999 06:30:16 -0400, Nieminen Juha wrote:
>Ron Parker <par### [at] fwicom> wrote:
>:> What does "smaller" mean? I mean that how does it define "this box is
>:>smaller than that one"?
>
>: It bases it on volume. The box with the smaller volume is smaller,
>: regardless of its actual dimensions.
>
> What happens when the user-defined bounding object is not a box?
Presumably the bounding box of the bounding object is used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23 Sep 1999 06:30:16 -0400, Nieminen Juha <war### [at] cctutfi> wrote:
> What happens when the user-defined bounding object is not a box?
If it is an infinite object, it is ignored and the default bounding
box is used instead. If it is finite, its bounding box is used for
vista and light buffer calculations (and the max() and min() in the
SUperPatch) and forray-shape intersection test the nested bounding
objects hierarchy is used (i.e. bounding box of bounding object is
checked first, then the bounding object and lastly the bounded object
itself)
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
