"Christoph Hormann" <chr### [at] gmxde> schrieb im Newsbeitrag 
news:dg0ifb$2oi$1@chho.imagico.de...

> Could you elaborate?  Lots of mesh instances of course take memory (much 
> less than copying the mesh though) but this should scale without problems 
> as long as you have enough memory and the performance should be O(log n) 
> as long as the trees do not overlap too much.


It's only my experience, that with millions of objects my computer gets slow 
even with 2 GB memory.
Beside, with about 11 million copies of anything the coordinates file alone 
takes 1.5 GB memory.
Problems are much more severe with  normal meshes or CSG objects, but it 
depends on the object complexity.
I'll try to make a bit of more exact statements in the next days.


> - Esp. with lower tree density you have the problems that trees with their 
> bottom below visibility (only the top looking above a mountain ridge for 
> example) don't get placed.


That's true, therefore the method is best in densily populated cases, but I 
can think of some workarounds.


> To avoid this but still keep the number of trees placed low you can use 
> the normal scene space placing and trace a 'visibility ray' to the camera 
> location to check if to actually place the tree.  If you trace this ray 
> from the top of the tree this will solve the issue.  The major 
> disadvantage is of course this is very slow (lots of unsuccessful tests, 
> two traces per test)


This works not always. In some cases you can see only parts of an object, 
but not base or top.
Especially at near overhangs you can need perhaps 5 or more traces.
Of course it takes time, therefore I usually decouple coordinates generation 
and scene rendering.


> - it only works for camera types you have written a mapping function for. 
> For this might be good to have scene language support for image 
> space/scene space transformation.


That's the biggest drawback.
Of course its possible to increase the cam_ang value for the camera angle 
during the coordinate generation, if you don't use extreme camera types or 
settings.

Post a reply to this message

"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> schrieb im 
Newsbeitrag news:4323d0cd@news.povray.org...

> I'd probably use my Surcoat-Macros, and an idea I just had: if I'd place a
> parallel lightsource in place of the camera and view from above, the hills
> should throw shadows onto the terrain itself. So I only get bright spots
> (where placing of objects will take place) where the camera sees it. If I
> then "grow" a rim around that area, I'd have a little more space in all
> directions... Hm. Need to think about this more.


This is one possibility and I used such a method in my IRTC entry "Meadow".
If you blur such a black/white image with photoshop, you can use it to shoot 
test rays from above.
If you hit a non-black pixel, you can populate the place.
But usually it is complicated to define the orthogonal camera and to align 
the results to your scene.
I gave up this technology, because I'm too weak in trigonometry.


> Anyways, how did you create the tree? POV-Tree, or did you do it yourself?


The tree is only a demo tree I always use for tests or far distances like in 
my images "Boreal" or "Meadow"
( http://www.povcomp.com/hof/Boreal_big.html and 
http://www.irtc.org/ftp/pub/stills/2002-02-28/meadow.jpg ).

You can download the tree from http://www.dartnall.f9.co.uk/ , then go to 
galleries and then to arboretum.
It comes as a usual mesh object. With the new version of Poseray you can 
import such a mesh and save it as a mesh2 object.
This makes an enormous difference in memory usage and render speed, at least 
in this case.


Norebrt Kern

Post a reply to this message

Norbert Kern wrote:
> 
> It's only my experience, that with millions of objects my computer gets slow 
> even with 2 GB memory.

What exactly gets slow?  Everything (placing the trees of course, 
parsing the generated trees, rendering) should be roughly proportional 
to the number of objects (rendering even faster) as long as you don't 
exceed memory.

> Beside, with about 11 million copies of anything the coordinates file alone 
> takes 1.5 GB memory.

And of course parsing such a file will take some time.  You might be 
able to improve this by storing the numbers with different accuracy 
(normal vectors usually do not require a lot of decimal places).  And 
when you position objects you should not use macros, better calculate a 
matrix and write it to the file.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Norbert Kern wrote:
> This demo scene shows three effects useful for planting many things like
> grass, trees, rocks or stones.
> 
> 1. If you want to show a dense forest from near to a far distance, you may
> need millions of tree copies. Even povray has problems with millions of
> mesh2 copies.
> But if you show only the visible ones, you need only 75000 trees like in
> this demo file.
> The trick is to define random vectors from the camera position, which point
> only to visible parts and to use them in the trace command.
> 
> 2. The problem with this method is that parts far away seem less dense
> populated as nearer parts.
> The solution is to find the maximum distance to be populated. Then you  can
> use the inverse quadratic relationship to plant with equal density despite
> different distances.
> 
If you know the approximate distance, is it also possible to use
different levels of detail for far away and close objects?
> 3. I always wanted to draw directly on a test image and to use it for
> different planting effects. This would give maximum control over the result.
> The second image shows the POV logo's image used in the demo scene.
> 
> I'll post an (unoptimized) demo file at binaries.scene-files.
> 
> 
> Norbert Kern
> 
> 
> 
>

Post a reply to this message

> What exactly gets slow?  Everything (placing the trees of course,
> parsing the generated trees, rendering) should be roughly proportional
> to the number of objects (rendering even faster) as long as you don't
> exceed memory.


I think it's a combination of all this. Perhaps I find an easy way to try 
out.
In this case about 10 % of an area is populated which is defined by the 
camera field of view and found maximum distance.
I include an image from above with land is white and trees are red.


> And of course parsing such a file will take some time.  You might be
> able to improve this by storing the numbers with different accuracy
> (normal vectors usually do not require a lot of decimal places).  And
> when you position objects you should not use macros, better calculate a
> matrix and write it to the file.


This is an excellent idea, but how can I make this?
Times I worked with matrices are 17 years ago.
Usually I need a scale operation (should be different in all three axes), 
three consecutive rotations around y, x and y again and a translation at the 
end.

Post a reply to this message

Attachments:
Download 'Tree_Logo_abovecK.png' (65 KB)

Preview of image 'Tree_Logo_abovecK.png'

"andrel" <a_l### [at] hotmailcom> schrieb im Newsbeitrag 
news:432### [at] hotmailcom...

> If you know the approximate distance, is it also possible to use
> different levels of detail for far away and close objects?

If you use mesh2 objects, you shouldn't save memory, but for other objects 
this is the way to go.
Of course you have to generate such different objects with equal appearence.
In this case the nearest tree is 20 times nearer than the ones far away.
If you can see a continous range of tree copies, it can be possible to 
detect the boundaries between the different meshes.


Norbert Kern

Post a reply to this message

There is a small, but critical error in the zip file I posted at 
binaries.scene-files.
Sorry for any inconvenience.

I posted a corrected file at the same thread.

Post a reply to this message

> I gave up waiting for it to finish, and I think it did only 300 trees. 
> Not sure this shortcut of yours is anything short at all.


It's my fault, I posted an incorrect zip.
In the meantime, I posted a correct one at the same thread.

Norbert Kern

Post a reply to this message

I made some trials.
You are right with the rough proportionality, if you don't reach memory 
limits.
Surprisingly it takes only 600000 tree copies to reach the limits of my 2 GB 
machine. Why?
If I subtract the base scene file memory need, Povray (v3.5) needs 3 KB per 
tree.
The tree is a mesh2 object with 57000 faces, 23 MB memory need and two 
simple textures.
For a simple pointer 3 KB seems very much.


Norbert Kern

"Christoph Hormann" <chr### [at] gmxde> schrieb im Newsbeitrag 
news:dg0shl$4o6$1@chho.imagico.de...

> Norbert Kern wrote:
>> It's only my experience, that with millions of objects my computer gets 
>> slow even with 2 GB memory.

> What exactly gets slow?  Everything (placing the trees of course, parsing 
> the generated trees, rendering) should be roughly proportional to the 
> number of objects (rendering even faster) as long as you don't exceed 
> memory.

Post a reply to this message

Norbert Kern wrote:
> I made some trials.
> You are right with the rough proportionality, if you don't reach memory 
> limits.
> Surprisingly it takes only 600000 tree copies to reach the limits of my 2 GB 
> machine. Why?
> If I subtract the base scene file memory need, Povray (v3.5) needs 3 KB per 
> tree.
> The tree is a mesh2 object with 57000 faces, 23 MB memory need and two 
> simple textures.
> For a simple pointer 3 KB seems very much.

Not a simple pointer, you need a lot of other stuff (The transform for 
each instance alone is 256 byte (2*4*4*8)).

IIRC you save a lot if your mesh is textured as a whole and not 
internally (Mesh textures are copied).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message