 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was inspired by an image posted here (I wish I could remember the
author's name), and decided to make my first macro to generate a similar
shape. I couldn't figure out how to do this shape with just Tori and
Sphere CSG, and had to use a Cone as well. Unfortunately the 'seams'
are visible where the spheres are cut out and join with the tori. Is
this an inherent problem with POV accuracy and rounding errors, or is
there a flaw in my math? More importantly, is there a way to fix it? I
will attach my source as well as the picture.
Also the opening on the far side of the sphere doesn't seem to show up
in this view, but I've checked with a top down view and it is definitely
there. Maybe it's just the angle.
P.S. This is my second post. When I made my first post, I was unaware
of the 'reflective sphere on checker plane' requirement for first posts.
Hopefully this one satisfies the requirements. ;-)
Post a reply to this message
Attachments:
Download 'iso-8859-1' (2 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Try setting a higher number in max_trace_level in the global_settings.
When I am doing glass objects, I start with something like 12 and step
down during successive renders until I get to the lowest setting that
works.
There might be another way to do this ...
Aaron
"Sun Tzu" <sun### [at] nospamhotmail com> wrote in message
news:3ec983aa@news.povray.org...
I was inspired by an image posted here (I wish I could remember the
author's name), and decided to make my first macro to generate a similar
shape. I couldn't figure out how to do this shape with just Tori and
Sphere CSG, and had to use a Cone as well. Unfortunately the 'seams'
are visible where the spheres are cut out and join with the tori. Is
this an inherent problem with POV accuracy and rounding errors, or is
there a flaw in my math? More importantly, is there a way to fix it? I
will attach my source as well as the picture.
Also the opening on the far side of the sphere doesn't seem to show up
in this view, but I've checked with a top down view and it is definitely
there. Maybe it's just the angle.
P.S. This is my second post. When I made my first post, I was
unaware of the 'reflective sphere on checker plane' requirement for
first posts. Hopefully this one satisfies the requirements. ;-)
Post a reply to this message
Attachments:
Download 'iso-8859-1' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Welcome the traditional way! That image is beautiful.
I've looked briefly at your code, but can't give a qualified comment on the
math. I can only say, that in order to get seamless CSG it needs to be
flawless (and that's why I would've tried with blobs).
See you soon again,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Sun Tzu" <sun### [at] nospamhotmailcom> wrote in
news:3ec983aa@news.povray.org:
> I was inspired by an image posted here (I wish I could remember the
> author's name), and decided to make my first macro to generate a
> similar shape. I couldn't figure out how to do this shape with just
> Tori and Sphere CSG, and had to use a Cone as well. Unfortunately the
> 'seams' are visible where the spheres are cut out and join with the
> tori. Is this an inherent problem with POV accuracy and rounding
> errors, or is there a flaw in my math? More importantly, is there a
> way to fix it? I will attach my source as well as the picture.
>
> Also the opening on the far side of the sphere doesn't seem to show up
> in this view, but I've checked with a top down view and it is
> definitely there. Maybe it's just the angle.
...
I think the author of the image you refer to is me:
http://news.povray.org/povray.binaries.images/31443/
(Your approcah to make such a shape is somewhat different from mine.)
You can get rid of the "seems" if you add these lines to you macro:
#local rnil = r1*1e-6;
#local cutconebigger =
cone {<0,0,0>,0, <0,r1+1,0>,(r1+1)*tan(asin((hole+r2)/(r1-r2))) + rnil}
- and replace "cutcone" with "cutconebigger" in the 4 intersection
statements that are similar to this:
intersection {
difference {
object{ torus_os ... }
object{ torus_is ... }
}
object { cutcone ... }
}
When merging objects, the objects should "overlap" each other slightly.
Btw.: Your macro can be improved. (I can post my suggestion if you like.)
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I did play with increasing the max_trace_level variable. The last
render was done with max_trace_level set to 50.
"Aaron Gillies" <no### [at] spamcom> wrote in message
news:3eca2c00@news.povray.org...
Try setting a higher number in max_trace_level in the global_settings.
When I am doing glass objects, I start with something like 12 and step
down during successive renders until I get to the lowest setting that
works.
There might be another way to do this ...
Aaron
"Sun Tzu" <sun### [at] nospamhotmailcom> wrote in message
news:3ec983aa@news.povray.org...
I was inspired by an image posted here (I wish I could remember the
author's name), and decided to make my first macro to generate a similar
shape. I couldn't figure out how to do this shape with just Tori and
Sphere CSG, and had to use a Cone as well. Unfortunately the 'seams'
are visible where the spheres are cut out and join with the tori. Is
this an inherent problem with POV accuracy and rounding errors, or is
there a flaw in my math? More importantly, is there a way to fix it? I
will attach my source as well as the picture.
Also the opening on the far side of the sphere doesn't seem to show
up in this view, but I've checked with a top down view and it is
definitely there. Maybe it's just the angle.
P.S. This is my second post. When I made my first post, I was
unaware of the 'reflective sphere on checker plane' requirement for
first posts. Hopefully this one satisfies the requirements. ;-)
Post a reply to this message
Attachments:
Download 'iso-8859-1' (4 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes , yours was the image. Thank you for posting it. I enjoyed seeing it
and trying to create something similar.
This was my first atempt at creating a macro so I'm sure there are many
things that can be improved. Please give me your suggestions so that I can
learn. :-)
In the mean time I will try what you suggest regarding the slightly bigger
cone for intersecting with the tori, so that they overlap the cut out
spheres a bit.
"Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
news:Xns### [at] 204213191226...
> "Sun Tzu" <sun### [at] nospamhotmailcom> wrote in
> news:3ec983aa@news.povray.org:
>
> > I was inspired by an image posted here (I wish I could remember the
> > author's name), and decided to make my first macro to generate a
> > similar shape. I couldn't figure out how to do this shape with just
> > Tori and Sphere CSG, and had to use a Cone as well. Unfortunately the
> > 'seams' are visible where the spheres are cut out and join with the
> > tori. Is this an inherent problem with POV accuracy and rounding
> > errors, or is there a flaw in my math? More importantly, is there a
> > way to fix it? I will attach my source as well as the picture.
> >
> > Also the opening on the far side of the sphere doesn't seem to show up
> > in this view, but I've checked with a top down view and it is
> > definitely there. Maybe it's just the angle.
> ...
>
> I think the author of the image you refer to is me:
> http://news.povray.org/povray.binaries.images/31443/
> (Your approcah to make such a shape is somewhat different from mine.)
>
>
> You can get rid of the "seems" if you add these lines to you macro:
>
> #local rnil = r1*1e-6;
> #local cutconebigger =
> cone {<0,0,0>,0, <0,r1+1,0>,(r1+1)*tan(asin((hole+r2)/(r1-r2))) + rnil}
>
> - and replace "cutcone" with "cutconebigger" in the 4 intersection
> statements that are similar to this:
>
> intersection {
> difference {
> object{ torus_os ... }
> object{ torus_is ... }
> }
> object { cutcone ... }
> }
>
>
> When merging objects, the objects should "overlap" each other slightly.
>
>
> Btw.: Your macro can be improved. (I can post my suggestion if you like.)
>
>
> Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Sun Tzu" <sun### [at] nospamhotmailcom> wrote in
news:3eca674d$1@news.povray.org:
> Yes , yours was the image. Thank you for posting it. I enjoyed
> seeing it and trying to create something similar.
=)
> This was my first atempt at creating a macro so I'm sure there are
> many things that can be improved. Please give me your suggestions so
> that I can learn. :-)
...
0)
Not bad for a first try at writing a macro ;)
1)
Note that if you use #declare instead of #local inside the macro,
then the declared variable will exist and have a value also after
POV-Ray has finished parsing the macro.
2)
It can also be wise to store values, shapes, transformations etc.,
that are needed many times, in variables instead of calculating
them over and over again.
3)
When you store a primitive shape in a variable it is not necessary
to put it into an object {} statement.
4)
Transformations that are common to all shapes in a CSG operation
can be applied to the resulting CSG shape instead.
E.g.:
difference {
object { torus_os ... rotate <0, 30, 0> }
object { torus_is ... rotate <0, 30, 0> }
}
- is equal to:
difference {
object { torus_os ... }
object { torus_is ... }
rotate <0, 30, 0>
}
5)
Many CSG operations can be simplified.
E.g. this expression:
difference {
difference {
object { insphere_os }
object { insphere_is }
}
union {
object { cutcone ... }
object { cutcone ... }
object { cutcone ... }
object { cutcone ... }
}
}
- can be simplified to this:
difference {
object { insphere_os }
object { insphere_is }
object { cutcone ... }
object { cutcone ... }
object { cutcone ... }
object { cutcone ... }
}
6)
Note that intersection {} and difference {} are closely related.
I.e. this expression:
difference {
object { Shape1 }
object { Shape2 }
}
- can be rewritten as
intersection {
object { Shape1 }
object { Shape2 inverse }
}
And further:
intersection {
difference {
object { Shape1 }
object { Shape2 }
}
object { Shape3 }
}
- as:
intersection {
object { Shape1 }
object { Shape2 inverse }
object { Shape3 }
}
But IIRC there are some differences with regards to
automatic bounding. (But I don't remember exactly what.)
7)
It is my opinion that unless it makes things a lot simpler,
then you should avoid putting texturing and interior expressions
inside macros that genrates shapes.
E.g.: Your "material { Crystal }" statement inside your macro
8)
With POV-Ray versions 3.1 and later it should not ever
be necessary to enclose single variable names in brackets.
E.g.: (hole)
9)
Try to use more descriptive variable names.
(Yes, I know; it can sometimes be very hard to find good names.)
Below is my suggestion for a complete rewrite of your macro.
Tor Olav
#macro MakeThingy(Ra, Rb, Thickness, Rhole)
#local Rdiff = Ra - Rb;
#local Rmaj = Rb + Rhole;
#local RminO = Rb;
#local RminI = RminO - Thickness;
#local ROO = Ra;
#local ROI = ROO - Thickness;
#local RII = Ra - 2*Rb;
#local RIO = RII + Thickness;
#local Hcone = Ra + 1;
#local Rcone = Hcone*tan(asin(Rmaj/Rdiff));
#local vUp = sqrt(Rdiff*Rdiff - Rmaj*Rmaj)*y;
#local Angle = degrees(acos(-sqrt(1/3)));
#local Nil = Ra*1e-6;
#local OuterSphere_OuterSurface = sphere { 0*y, ROO }
#local OuterSphere_InnerSurface = sphere { 0*y, ROI }
#local InnerSphere_OuterSurface = sphere { 0*y, RIO }
#local InnerSphere_InnerSurface = sphere { 0*y, RII }
#local Torus_OuterSurface = torus { Rmaj, RminO translate vUp }
#local Torus_InnerSurface = torus { Rmaj, RminI translate vUp }
#local CutCone = cone { 0*y, 0, Hcone*y, Rcone }
#local CutConeSmaller = cone { 0*y, 0, Hcone*y, Rcone - Nil }
#local Trans0 = transform { }
#local Trans1 = transform { rotate -Angle*z rotate 30*y }
#local Trans2 = transform { rotate -Angle*z rotate 150*y }
#local Trans3 = transform { rotate -Angle*z rotate 270*y }
#local Spoke =
intersection {
difference {
object { Torus_OuterSurface }
object { Torus_InnerSurface }
}
object { CutCone }
}
#local CutCones =
union {
object { CutConeSmaller transform { Trans0 } }
object { CutConeSmaller transform { Trans1 } }
object { CutConeSmaller transform { Trans2 } }
object { CutConeSmaller transform { Trans3 } }
}
merge {
difference {
object { OuterSphere_OuterSurface }
object { OuterSphere_InnerSurface }
object { CutCones }
}
difference {
object { InnerSphere_OuterSurface }
object { InnerSphere_InnerSurface }
object { CutCones }
}
object { Spoke transform { Trans0 } }
object { Spoke transform { Trans1 } }
object { Spoke transform { Trans2 } }
object { Spoke transform { Trans3 } }
}
#end // macro MakeThingy
object {
MakeThingy(1000, 350, 10,100)
// rotate 120*y
// rotate degrees(acos(-sqrt(1/3)))*z
material { Crystal }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
10)
Please don't use html formatted text when posting to this news server.
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen wrote:
> #macro MakeThingy...
Nice name :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote in news:3ECAAD86.BF1C2643@pacbell.net:
>
>
> Tor Olav Kristensen wrote:
>
>> #macro MakeThingy...
>
> Nice name :)
Ehhhmm ...
=)
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
