 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] hotmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
simple question:
How can I texture a mesh2 as a whole?
Norbert Kern
"Christoph Hormann" <chr### [at] gmxde> schrieb im Newsbeitrag
news:dg1in5$a72$1@chho.imagico.de...
> IIRC you save a lot if your mesh is textured as a whole and not internally
> (Mesh textures are copied).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Norbert Kern wrote:
> simple question:
> How can I texture a mesh2 as a whole?
>
If you have a textureless (no texture_list) mesh2 object called 'Mesh2':
#declare Textured_Mesh2=
object {
Mesh2
texture { ... }
}
;-)
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
|
|
| |
| |
|
|
|
|
| |
