POV-Ray : Newsgroups : povray.binaries.images : Forest generation (or; crude packing) : Re: Forest generation (or; crude packing) Server Time
11 Aug 2024 17:20:15 EDT (-0400)
  Re: Forest generation (or; crude packing)  
From: Florian Brucker
Date: 31 Mar 2004 06:24:45
Message: <406aaa7d@news.povray.org>
Xplo Eristotle wrote:
> Florian Brucker wrote:
> 
>>> Because of the random nature of the code and the need to test against 
>>> every other tree when placing a new one, scenes with a lot of trees 
>>> take a long time to parse; 
>>
>>
>> A way to improve this would be something like bounding boxes

> I plan to implement something like that, yes...

> ...but not like that. If I'm reading this right, I could accomplish the 
> same effect right now by using multiple "forests" stitched together, 
> which isn't what I want; the "clear areas" around trees in adjacent 
> cells would overlap because those trees don't get checked against each 
> other.

> Instead, I would divide the area into sections and only check against 
> the trees in the sections near where the new tree is trying to be 
> placed. 
> .. am I making any sense?

That's what I tried to say with

 >> Of course you have to add an object which overlapps a border into
 >> both cells it touches.

:)

> I suppose if you 
> really wanted to be thorough, you could have a second algorithm take 
> over when the first one loses its confidence and walk a fine grid, 
> testing each point on the grid to make sure something can't fit there; 
> at some point this would be far more efficient than random placement 
> that fails over and over again.

I think a totally random approach might be a really bad idea. I thought 
more along the terms of "Take a set of cylinders which is in perfect 
order. Now find some random translations which can be applied on each 
cylinder so that the set looks totally random with as little 
intersections as possible".

> 3D is easy. The math gets a little more complicated.
Yep

> 3D using cylinders is easy.. kinda. The math that tests for overlap gets 
> even more complicated, but the algorithm basically stays the same.
Sure the tests get more complicated. While you can simply compare the 
radius with the distance of two spheres, you have to take the direction 
of the main-axis into account when dealing with cylinders. It would not 
only be harder to implement, it would also take longer to parse :(

> 3D using cylinders under the influence of gravity which not only moves 
> the cylinders but also rotates them when they touch other objects.. 
Yep. That would be the best result of course :)

> And you may want a sumpercomputer to run the 
> simulation... ;)
Got one? Hehe.

I once started trying simulating it with SimPOV, but I couldn't get it 
to work properly. Perhaps I'll try again.

Florian


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.