I'm playing with material for my IRTC animation entry.

I aggressively cut back on my trees until I got my landscape to parse in 
three seconds. Unfortunately, it looks kind of bare now. :-(

Actually, this is only about the first 20% of what I rendered--the full 
sequence was too big to upload here.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

This summer...There is another word for EXCITEMENT!
Roget's Thesaurus: The Motion Picture
     -- posted by dr_dank on Slashdot

Post a reply to this message

Attachments:
Download 'trees.mpg' (576 KB)

William Tracy <wtr### [at] calpolyedu> wrote:
> I aggressively cut back on my trees until I got my landscape to parse in
> three seconds. Unfortunately, it looks kind of bare now. :-(

Looks nice, but yes, it could benefit from some more trees. If you are going to
use that camera angle, what about only parsing the trees in view? Declare the
camera location and check if the tree you are generating is within view. Should
save you quite some parse time.

Wow.. I think this is my first post here since 2003 or something... Anyway, I
was thinking of something like this:


// +k1 +kff99
// Change Camera_Location.y to 40 to see how it works.
// - Peter

#local Local_Clock = clock;

#local Camera_Location = <0,15,Local_Clock*50>;

camera{
        location Camera_Location
        look_at Camera_Location*<1,0,1>+z*2
}

light_source{Camera_Location+<1,2,-5>,1}

#local S = seed(1337);

#local Z = -100;
#while (Z < 200)
        #local Tree_Location = <-10+rand(S)*20,0,Z>;
        #if((Z > (Camera_Location.z-10)) & (Z < (Camera_Location.z+15)))
                cylinder{Tree_Location,Tree_Location+y*2,0.5 pigment {rgb y*1}}
        #end
#local Z = Z+0.5;
#end

plane{y,0 pigment {checker rgb 1 rgb 0.5 scale 6}}

Post a reply to this message

Peter Hertel wrote:
> If you are going to
> use that camera angle, what about only parsing the trees in view?

Wow, that's a very neat idea.

I'm going to have to poke around some more and get a better idea of 
where the bottlenecks really are--most of the time seems to be spent 
actually parsing the meshes, and there's only two plant meshes in this 
scene (one tree and one bush).

Cranking down the number of leaves/branches per plant made most of the 
difference, but I hit a point of diminishing returns, and reduced the 
total number of trees to squeeze out that last bit of performance.

So, at this point I really don't know if eliminating off-screen meshes 
is going to help. Those mesh files are getting parsed anyway, and the 
overhead associated with large numbers of trees seems to come simply 
from the sheer number of rand() calls.

I'll play with your idea if I have time, but probably I'll just bite the 
bullet and accept one or two extra seconds of parse time per frame. :-)

> Wow.. I think this is my first post here since 2003 or something...

I hope that you'll post more in the future. :-)

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

With so many of even the larger [near-earth asteroids] remaining 
undiscovered, the most likely warning today would be zero -- the first 
indication of a collision would be the flash of light and the shaking of 
the ground as it hit.
     -- From http://impact.arc.nasa.gov/intro_faq.cfm, allaying the 
fears of the American public

Post a reply to this message

> there's only two plant meshes in this
> scene (one tree and one bush).

If they are exactly the same (included only once, then transformed) the number
of times you use the mesh would not matter much. But if you change the mesh by
rand() calls for every tree or bush (which it seems like to me), I think parse
time would benefit a lot.

> Cranking down the number of leaves/branches per plant made most of the
> difference, but I hit a point of diminishing returns, and reduced the
> total number of trees to squeeze out that last bit of performance.

At this resolution the mesh doesn't need to be very detailed anyway, so you
might be able crank up the number of branches but lower the quality ("sub
division") of the mesh without seeing any difference.

> So, at this point I really don't know if eliminating off-screen meshes
> is going to help. Those mesh files are getting parsed anyway, and the
> overhead associated with large numbers of trees seems to come simply
> from the sheer number of rand() calls.

Dependable on how you parse the trees, it might be difficult to do while still
keeping the same location for the trees during the whole scene. If you don't
parse all the same rand() calls in the same order for every frame, the trees
would change position/apperance. Hard to explain, but if you try to change this
in my code example you see what I mean: (Move the Tree_Location declaration into
the "Z"-loop)

#if((Z > (Camera_Location.z-10)) & (Z < (Camera_Location.z+15)))
#local Tree_Location = <-10+rand(S)*20,0,Z>;
cylinder{Tree_Location,Tree_Location+y*2,0.5 pigment {rgb y*1}}
#end

> I'll play with your idea if I have time, but probably I'll just bite the
> bullet and accept one or two extra seconds of parse time per frame. :-)

Agreed, if you can not benefit more than a few seconds, the time taking to
implement this idea would probably surpass the extra time spent rendering
anyway. :-)

> > Wow.. I think this is my first post here since 2003 or something...
>
> I hope that you'll post more in the future. :-)

We'll see ;-)

Have a nice day.

-Peter

Post a reply to this message

Peter Hertel wrote:
> If they are exactly the same (included only once, then transformed) the number
> of times you use the mesh would not matter much. But if you change the mesh by
> rand() calls for every tree or bush (which it seems like to me), I think parse
> time would benefit a lot.

I use rand() when rotating the trees, scaling them, and positioning 
them. I don't actually manipulate the mesh itself, and there's only one 
tree mesh in the scene.

Randomly rotating the trees about the Y axis is surprisingly effective 
at creating "different" trees. :-)

> At this resolution the mesh doesn't need to be very detailed anyway, so you
> might be able crank up the number of branches but lower the quality ("sub
> division") of the mesh without seeing any difference.

I've reached the point where individual branches are only one or two 
polygons. There's not really anywhere left to go, short of ditching 
Povtree for a program that doesn't insist on making every leaf be a 
separate object.

> Dependable on how you parse the trees, it might be difficult to do while still
> keeping the same location for the trees during the whole scene.  If you don't
> parse all the same rand() calls in the same order for every frame, the trees
> would change position/apperance. Hard to explain, but if you try to change this
> in my code example you see what I mean:

I know exactly what you mean, having been bitten by it in the past. :-) 
(In a still image actually, where I wanted to change one part of a 
macro-generated landscape without changing another part...no such luck.)

If I really want to cut down on the time spent placing trees, I'll write 
a macro that places the trees, writes the information to a file, and 
includes the file in every subsequent frame. :-)

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

Guns don't kill people, catchphrases kill people.
     -- jwo7777777, posting on Slashdot

Post a reply to this message