 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Margus Ramst wrote:
>
> Bonsai wrote:
> >
> > I wanted to do the sponge in pure csg. So I did a lot of differences, that
> > resulted in this long rendertime.
> >
>
> Why differences? You should get *much* faster rendering if you created the
> sponge as an union, i.e. stack a lot of little blocks to make up the sponge
> structure, instead of progressively cutting holes out of one big block.
I did it that way once and while it was faster it wasn't signifigantly
faster. With that many edges you lose a lot of time doing anti-aliasing.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Gilles Tran wrote:
>
> Bonsai wrote:
>
> > But when I want to do the cut away with a sphere it goes back to the 1 or 2
>
> What about cutting away the (correctly positioned) individual parts first ? It
> should render faster than making the union first and cutting the union after.
>
> One fun thing would be to make the sponge out of triangles... I would render
> very quickly I guess.
Been there. Done that. Didn't help render times much. Memory use did decrease
however.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Bonsai wrote:
> ... but I was interested in the inner structures. Took my machine 2 days to
> render at 800x600. I think I have to work on the code...
The inner structure is very interesting. :)
There are normally a few ways to speed things up. 1) Make meshes, but you can't
because you 're cutting away a chunk. 2) Use unions instead of real CSG, but
that way you'd get artifacts between edges of adjacent cubes. So you're stuck
with a long render. Unless you have megapov and want to try an isosurface. I
have code for an iso-menger-sponge at my website you can use.
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Did you try hierarchal bounding for the CSG?
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"David Fontaine" <dav### [at] faricy net> schrieb im Newsbeitrag
news:3AB### [at] faricy net...
> Did you try hierarchal bounding for the CSG?
Not yet. Do you mean that I should bound smaller parts of the sponge per
hand. Would this really decrease render time when I do the cut away?
Until now I was trying to get my new sponge macro to work. Now I can give
sponge is now made of many little mengersponges with recursion level 1.
My next idea is to do only differences with the little sponges that
intersect with the sphere and forget the sponges that are inside the sphere.
This should be easy for the sphere. Other objects might be very hard to cut
away with this approach...
Bonsai
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Bonsai wrote:
> Not yet. Do you mean that I should bound smaller parts of the sponge per
> hand. Would this really decrease render time when I do the cut away?
Hmm, I'm not sure exactly how that worked. You split the CSG components into
however many groups, then those into however many smaller groups, etc, and bound
all the groups, with zero or minimal overlap of any two groups at the same
nesting level. Something like:
difference {
box {}
merge {
merge {
...
bounded_by {}
}
bounded_by {}
}
merge {
merge {
...
bounded_by {}
}
bounded_by {}
}
bounded_by {}
}
You could split it into 27 parts (3x3x3), each of the 20 edge parts splits
again... maybe it would be more efficient to split the x axis into three, then
the y, then the z, then start the next recursion level... Essentially you make a
bunch of nested bounding that serves to partition the space into smaller and
smaller pieces. It's very efficient because the intersection algorithim is
essentially "walking the tree". It might be tricky to get it arranged so that
you don't have coincident surfaces or anything.
--
David Fontaine <dav### [at] faricy net> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |