I currently have a grass object defined as a mesh which I tile 
repeatedly over an area.  The placement of the object is random within 
this area, meaning some areas are more densely covered than others (a 
very nice effect, I think).  However, the problem comes at the edge of 
the area I want covered.

I have a box {MIN, MAX} that I place the grass mesh in multiple times. 
Originally, I adjusted the boundaries of the area I used so that no 
grass would be outside of this box.  This was quite fast, as my scene 
would render in less than a minute (it took about 3 minutes to parse, 
but there's a lot of other stuff going on as well).  Unfortunately, it 
meant that portions along the side were very likely to not have any 
grass at all.

My next attempt was to have a more generous area to place the grass in, 
letting portions of the mesh fall outside of my bounding area.  I then 
ran a check at parse time to see if the mesh did indeed cross over the 
boundary; if it did, then it would be clipped to the boundary area.  If 
it fell inside the boundary completely, no clipping would occur.

This was much more satisfactory, and had exactly the effect I wanted, 
but took more than 45 minutes to render (compared to less than 1, 
before).  I was surprised that clipping caused such a problem.

I have not yet reduced the problem to a simpler scene, but has anyone 
else encountered a problem similar to this?

...Chambers

PS I should note that I am using the current 3.7 beta; I'll try to make 
the attempt with 3.6 later and see what effect that has on things.

Post a reply to this message

Ben Chambers wrote:
> PS I should note that I am using the current 3.7 beta; I'll try to make 
> the attempt with 3.6 later and see what effect that has on things.

Testing with 3.6 reveals the same dramatic slowdown.  I'm now trying to 
reduce the scene to the simplest form possible which still retains this 
dramatic decrease in speed.

...Chambers

Post a reply to this message

Well, I've reduced it as much as possible.  Render times are 30s for the 
unclipped version, and 50s for the clipped version on a test scene. 
Doesn't seem too bad, until you realize that generating the mesh during 
the parse takes 20s on its own, the so render times now seem to be 10s 
and 30s.  A 3x slowdown seems quite abnormal to me.

However, in examining the test I was doing, it is entirely possible that 
the clipped version is simply rendering more detail (since it shows 
grass up to the border), and that is the cause for the slowdown.  I 
suppose this would be minimized when there's a greater area which does 
not intersect the border, so I'll test with that.

I'll post my scene and include file (note that the include file has a 
limited texture applied, for the actual scene I'm working on I use a 
more varied texture) in p.b.scene-files, as well as two sample shots in 
p.b.images.

...Chambers

Post a reply to this message

Ben Chambers wrote:
> However, in examining the test I was doing, it is entirely possible that 
> the clipped version is simply rendering more detail (since it shows 
> grass up to the border), and that is the cause for the slowdown.  I 
> suppose this would be minimized when there's a greater area which does 
> not intersect the border, so I'll test with that.

A further test confirmed, that a scene where 90+% of the visible grass 
is not intersecting the border results in only an 8% slowdown in trace 
time.  I guess the problem all along was the large proportion of space 
edges in my scene; that is, in my scene a lot of grass patches intersect 
the area boundaries, meaning more computations are needed.

Sorry to bother everyone, this has been a fun little dialogue by myself 
:)  Of course, if anyone can think of another way to speed up this 
thing, I'd very much like to hear it.

...Chambers

Post a reply to this message