 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm playing with gems. (I "wish" they were the real thing. Just POV
stuff, though.)
I'm observing some anomolous (to me) behavior. I'm using a declaration
to define the gem structure. If I use an "intersection" of box objects,
I get a dirty or noisy material as a result. If I use an intersection
of planes, I get a very clean crystaline result. The code and resultant
images are below.
Using planes...
// ----------------------------------------
// ----------------------------------------
#declare xAngle = 45.0;
#declare yAngle = 45.0;
#declare zAngle = 45.0;
#declare xPlane = 1.0;
#declare yPlane = 1.0;
#declare zPlane = 1.0;
// ----------------------------------------
#declare CrystalJewel = intersection
{
plane { x, xPlane }
plane {-x, xPlane }
plane { y, yPlane }
plane {-y, yPlane }
plane { z, zPlane }
plane {-z, zPlane }
plane { x, xPlane rotate xAngle*y }
plane {-x, xPlane rotate xAngle*y }
plane { x, xPlane rotate -xAngle*y }
plane {-x, xPlane rotate -xAngle*y }
plane { y, yPlane rotate yAngle*z}
plane {-y, yPlane rotate yAngle*z}
plane { y, yPlane rotate -yAngle*z}
plane {-y, yPlane rotate -yAngle*z}
plane { z, zPlane rotate zAngle*x}
plane {-z, zPlane rotate zAngle*x}
plane { z, zPlane rotate -zAngle*x}
plane {-z, zPlane rotate -zAngle*x}
bounded_by {sphere {0, 1.7321}}
no_shadow
}
// ----------------------------------------
Using boxes...
// ----------------------------------------
// ----------------------------------------
#declare BrilliantJewell = intersection
{
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate -45*x }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*x }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate -45*y }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*y }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate -45*z }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*z }
bounded_by {sphere {0, 1.7321}}
#if (clock_on)
rotate frame_number * (360/final_frame)
#end
no_shadow
}
// ----------------------------------------
The texture and interior definitions are identical, I just swap out one
or the other () declarations from above using the below macro...
// ----------------------------------------
// ----------------------------------------
#macro Jewel( t_, i_ )
object
{
CrystalJewel //Octahedron
texture { t_ }
interior { i_ }
}
#end
// ----------------------------------------
The result using boxes...
[Image]
The result using planes...
[Image]
Why cant I get the same result using a box as I can using plane objects?
Thanks for your input.
- Patrick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Oops! My images didn't see to upload.
<p>Trying again. Using boxes...
<br><img SRC="cid:par### [at] daeoria org" height=141 width=291>
<p>Using planes...
<br><img SRC="cid:par### [at] daeoriaorg" height=141 width=291>
<p>Patrick Hagerty wrote:
<blockquote TYPE=CITE>I'm playing with gems. (I "wish" they were
the real thing. Just POV
<br>stuff, though.)
<p>I'm observing some anomolous (to me) behavior. I'm using a declaration
<br>to define the gem structure. If I use an "intersection" of box
objects,
<br>I get a dirty or noisy material as a result. If I use an intersection
<br>of planes, I get a very clean crystaline result. The code and
resultant
<br>images are below.
<p>Using planes...
<p>// ----------------------------------------
<br>// ----------------------------------------
<br>#declare xAngle = 45.0;
<br>#declare yAngle = 45.0;
<br>#declare zAngle = 45.0;
<br>#declare xPlane = 1.0;
<br>#declare yPlane = 1.0;
<br>#declare zPlane = 1.0;
<br>// ----------------------------------------
<br>#declare CrystalJewel = intersection
<br>{
<br> plane { x, xPlane }
<br> plane {-x, xPlane }
<p> plane { y, yPlane }
<br> plane {-y, yPlane }
<p> plane { z, zPlane }
<br> plane {-z, zPlane }
<p> plane { x, xPlane rotate xAngle*y }
<br> plane {-x, xPlane rotate xAngle*y }
<p> plane { x, xPlane rotate -xAngle*y }
<br> plane {-x, xPlane rotate -xAngle*y }
<p> plane { y, yPlane rotate yAngle*z}
<br> plane {-y, yPlane rotate yAngle*z}
<p> plane { y, yPlane rotate -yAngle*z}
<br> plane {-y, yPlane rotate -yAngle*z}
<p> plane { z, zPlane rotate zAngle*x}
<br> plane {-z, zPlane rotate zAngle*x}
<p> plane { z, zPlane rotate -zAngle*x}
<br> plane {-z, zPlane rotate -zAngle*x}
<p> bounded_by {sphere {0, 1.7321}}
<br> no_shadow
<br>}
<br>// ----------------------------------------
<p>Using boxes...
<br>// ----------------------------------------
<br>// ----------------------------------------
<br>#declare BrilliantJewell = intersection
<br>{
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
-45*x }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
45*x }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
-45*y }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
45*y }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
-45*z }
<br> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate
45*z }
<p> bounded_by {sphere {0, 1.7321}}
<p> #if (clock_on)
<br> rotate frame_number * (360/final_frame)
<br> #end
<p> no_shadow
<br>}
<br>// ----------------------------------------
<p>The texture and interior definitions are identical, I just swap out
one
<br>or the other () declarations from above using the below macro...
<p>// ----------------------------------------
<br>// ----------------------------------------
<br>#macro Jewel( t_, i_ )
<br>object
<br>{
<br> CrystalJewel //Octahedron
<p> texture { t_ }
<br> interior { i_ }
<br>}
<br>#end
<br>// ----------------------------------------
<p>The result using boxes...
<br>[Image]
<p>The result using planes...
<br>[Image]
<p>Why cant I get the same result using a box as I can using plane objects?
<p>Thanks for your input.
<p>- Patrick</blockquote>
</html>
Post a reply to this message
Attachments:
Download 'c:\windows\temp\nsmail94.png' (70 KB)
Download 'c:\windows\temp\nsmailob.png' (33 KB)
Preview of image 'c:\windows\temp\nsmail94.png'
Preview of image 'c:\windows\temp\nsmailob.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Patrick Hagerty who wrote:
>I'm playing with gems. (I "wish" they were the real thing. Just POV
>stuff, though.)
>
>I'm observing some anomolous (to me) behavior. I'm using a declaration
>to define the gem structure. If I use an "intersection" of box objects,
>I get a dirty or noisy material as a result. If I use an intersection
>of planes, I get a very clean crystaline result. The code and resultant
>images are below.
What's happening is that a box rotated by +45 is exactly the same as a
box rotated by -45, so you're getting the coincident surface problem.
See "2.4.2.5 Why are there strange dark pixels or noise on my CSG
object?" in the documentation.
If you delete three of the rotated boxes in your intersection it will be
the same shape but without most of the speckles. The remaining speckles
are caused by the fact that each of the rotated boxes have two faces
that are coincident with the unrotated box. E.g. the box that's rotated
by y*45 has the top and bottom face still in the same plane.
You can fix that by making the first box have a slightly different size.
#declare BrilliantJewell = intersection
{
box { <-1.0001, -1.0001, -1.0001>, <1.0001, 1.0001, 1.0001> }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*x }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*y }
box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*z }
By the way: Don't post images to this newsgroup. Binary files should
only be posted to a .binaries newsgroup.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Of course! I did the "plane" method first and forgot that I'm dealing with
more surfaces with boxes than I am with planes.
Thanks!
Mike Williams wrote:
> Wasn't it Patrick Hagerty who wrote:
> >I'm playing with gems. (I "wish" they were the real thing. Just POV
> >stuff, though.)
> >
> >I'm observing some anomolous (to me) behavior. I'm using a declaration
> >to define the gem structure. If I use an "intersection" of box objects,
> >I get a dirty or noisy material as a result. If I use an intersection
> >of planes, I get a very clean crystaline result. The code and resultant
> >images are below.
>
> What's happening is that a box rotated by +45 is exactly the same as a
> box rotated by -45, so you're getting the coincident surface problem.
> See "2.4.2.5 Why are there strange dark pixels or noise on my CSG
> object?" in the documentation.
>
> If you delete three of the rotated boxes in your intersection it will be
> the same shape but without most of the speckles. The remaining speckles
> are caused by the fact that each of the rotated boxes have two faces
> that are coincident with the unrotated box. E.g. the box that's rotated
> by y*45 has the top and bottom face still in the same plane.
>
> You can fix that by making the first box have a slightly different size.
>
> #declare BrilliantJewell = intersection
> {
> box { <-1.0001, -1.0001, -1.0001>, <1.0001, 1.0001, 1.0001> }
> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*x }
> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*y }
> box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*z }
>
> By the way: Don't post images to this newsgroup. Binary files should
> only be posted to a .binaries newsgroup.
>
> --
> Mike Williams
> Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK. I tried it. It worked.
I was simply failing to think in three dimensions. A plane is two dimensional,
a box is three dimensional. That's what I get for doing most of my POV-Ray
work in the evening after a day of mind numbing work.
Thanks again.
Patrick Hagerty wrote:
> Of course! I did the "plane" method first and forgot that I'm dealing with
> more surfaces with boxes than I am with planes.
>
> Thanks!
>
> Mike Williams wrote:
>
> > Wasn't it Patrick Hagerty who wrote:
> > >I'm playing with gems. (I "wish" they were the real thing. Just POV
> > >stuff, though.)
> > >
> > >I'm observing some anomolous (to me) behavior. I'm using a declaration
> > >to define the gem structure. If I use an "intersection" of box objects,
> > >I get a dirty or noisy material as a result. If I use an intersection
> > >of planes, I get a very clean crystaline result. The code and resultant
> > >images are below.
> >
> > What's happening is that a box rotated by +45 is exactly the same as a
> > box rotated by -45, so you're getting the coincident surface problem.
> > See "2.4.2.5 Why are there strange dark pixels or noise on my CSG
> > object?" in the documentation.
> >
> > If you delete three of the rotated boxes in your intersection it will be
> > the same shape but without most of the speckles. The remaining speckles
> > are caused by the fact that each of the rotated boxes have two faces
> > that are coincident with the unrotated box. E.g. the box that's rotated
> > by y*45 has the top and bottom face still in the same plane.
> >
> > You can fix that by making the first box have a slightly different size.
> >
> > #declare BrilliantJewell = intersection
> > {
> > box { <-1.0001, -1.0001, -1.0001>, <1.0001, 1.0001, 1.0001> }
> > box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*x }
> > box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*y }
> > box { <-1.0, -1.0, -1.0>, <1.0, 1.0, 1.0> rotate 45*z }
> >
> > By the way: Don't post images to this newsgroup. Binary files should
> > only be posted to a .binaries newsgroup.
> >
> > --
> > Mike Williams
> > Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oops! My images didn't see to upload.
Just a heads-up for the next time: images belong into
povray.binaries.images, its standard behaviour here to upload the image
there with a comment like "In regard to the thread entitled ... in ...".
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Patrick Hagerty" <pat### [at] daeoriaorg> wrote in message
news:43655054.BFA2ECB2@daeoria.org...
> OK. I tried it. It worked.
>
> I was simply failing to think in three dimensions. A plane is two
> dimensional,
> a box is three dimensional. That's what I get for doing most of my
> POV-Ray
> work in the evening after a day of mind numbing work.
>
> Thanks again.
Hello Pat,
Not meaning to be a pain, and it doesn't impact your gem solution, but just
to explain pedantically in order to be safe... In PovRay's Constructive
Solid Geometry, a plane is considered a 3-Dimensional object - ie. like a
box, the plane has an inside and an outside, except the inside of a plane
extends infinitely. A triangle or polygon, however is two-dimensional - it
has no inside nor outside.
If you invert the normal of the plane, eg, from y to -y, the plane will look
identical, however "inside" and "outside" are reversed. This will make a
big difference to the behaviour of unions, intersections and differences.
It also impacts on media.
Cheers,
Brian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Brian,
Thanks a lot. That's really good to know.
I'd appreciate your input, if you don't mind. I'm getting ready to launch into
a new round of gem experimentation. (I started with the planes, then tried boxes
and had the problem I started this thread about.) I'm thinking about using a
mesh object to attempt a more complex and more extensively faceted gem. Do have
any thoughts or warnings you'd care to share as I get ready to attempt this?
- Patrick
Brian Elliott wrote:
> "Patrick Hagerty" <pat### [at] daeoriaorg> wrote in message
> news:43655054.BFA2ECB2@daeoria.org...
> > OK. I tried it. It worked.
> >
> > I was simply failing to think in three dimensions. A plane is two
> > dimensional,
> > a box is three dimensional. That's what I get for doing most of my
> > POV-Ray
> > work in the evening after a day of mind numbing work.
> >
> > Thanks again.
>
> Hello Pat,
>
> Not meaning to be a pain, and it doesn't impact your gem solution, but just
> to explain pedantically in order to be safe... In PovRay's Constructive
> Solid Geometry, a plane is considered a 3-Dimensional object - ie. like a
> box, the plane has an inside and an outside, except the inside of a plane
> extends infinitely. A triangle or polygon, however is two-dimensional - it
> has no inside nor outside.
>
> If you invert the normal of the plane, eg, from y to -y, the plane will look
> identical, however "inside" and "outside" are reversed. This will make a
> big difference to the behaviour of unions, intersections and differences.
> It also impacts on media.
>
> Cheers,
> Brian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Acknowledged, sir. I will be sure to do so in the future, and I extend my
apologies to all for violating protocol.
- Patrick
Tim Nikias wrote:
> > Oops! My images didn't see to upload.
>
> Just a heads-up for the next time: images belong into
> povray.binaries.images, its standard behaviour here to upload the image
> there with a comment like "In regard to the thread entitled ... in ...".
>
> Regards,
> Tim
>
> --
> aka "Tim Nikias v2.0"
> Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
