In article <3eaa90a3@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> The amount of consumed memory _IS_ the problem. 
> Each triangle consumes quite a lot of memory. 
> (Rendering 1 million triangles consumes 180 MB RAM, at least that is 
> what I just measured.)

And I've seen 256MB modules for less than $30, 1GB is well within the 
reach of a serious hobbyist. A 1GB system could handle several million 
triangles, more or less depending on how efficiently the mesh can be 
stored.


> > that could be used for actual rendering.
> >
> ?! You mean I should buy 256 GigaB RAM?

No...just enough to hold what you need to render, and use some 
intelligence in setting up the scene. A high resolution mesh of an 
entire planet is ridiculous when you are viewing it from orbit. If you 
are close enough to see details, you don't need anything close to the 
entire planet.


> Furthermore, adding the complexity at render-time will effectively be 
> faster because we save such a lot of parse time: 

You assume there is no way to increase loading speed. In your planet 
example, a low-res planet mesh would take little time to parse, and a 
high-res landscape height field would be much faster loading than an 
equivalent mesh, because it involves opening a binary image file instead 
of parsing a scene description. A binary mesh format would make loading 
high-res meshes faster.


> First of all, there may be reasons: It is hard to know which triangles 
> are needed for reflection. (I mean: Ever saw the hollow (culled) back-face 
> of a planet on a reflective surface of a space craft?)

It's not going to matter. You aren't going to be able to tell the 
difference between a high-res and low-res planet mesh when seen 
directly, certainly not when you are viewing a reflection of it on a 
ship.


> And then, maybe you are not aware about how many triangles you need 
> for a decent landscape...

Quite a few. Not enough to be a problem. I have mentioned the example of 
grass and other plants though, which could probably benefit from it.


> The easiest solution for the mentioned problem would be to implement a 
> height sphere for POVRay using only 2 bytes per triangle (storing the 
> data as 16 bit spherically-mapped height field). 

It's unnecessary, and not the easiest solution, but it is possible. It 
might be possible to add some additional optimizations to improve speed.


> But the more general solution would be some support for auto-generated 
> "artificial" complexity in meshes (added at render time). 

Auto-generated mesh complexity is not a bad idea, but doing it at render 
time involves inefficiencies that could make it slower than just doing 
it on the mesh and storing the higher resolution version. On the other 
hand, it only does it to the parts of the mesh where it is needed...so 
in some cases, it could be faster.


> Or, maybe, support for "mesh textures" for primitive objects (i.e. 
> height fields on top of sphere, cylinder/cone, torus)

There's macros that make spherical and cylinderical height fields. Not 
toroidal or cubical though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message