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

>> Well, then you better get system with a 64 bit processor,
>>
> Oh, have one for me?

Sure, it costs only about 400 Euros more than an Aldi PC ;-)
<http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=85825&parentId=48612>

> But, I agree: The fact that a genuine mesh does not fit into RAM is
> not a POVRay bug because I see little chance to significantly reduce
> genuine mesh RAM consumption (after looking at the POV code).

Indeed, there is little that can be done about it.  And it already uses
"only" 32-bit floats...

    Thorsten

Post a reply to this message

Christopher James Huff wrote:
> In article <3eaadd08@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
> wrote:
> 
> 
> This seems to be the main advantage. Subdividing and displacing a big 
> mesh could take a lot of CPU time, and limiting it to the needed areas 
> would not be easy, so you would store more triangles than necessary. My 
> main point is that memory use seems to be more of a side benefit, if it 
> really can give a speed benefit. (time/CPU is much more costly than 
> memory or storage)
> 

There has to be a reason why the reyes algorithm is still used ;-)
The problem is that if you hit a memory limit there often is not much 
you can do about it besides buying more memory, with time/CPU you can at 
least wait. And it's not only the geometry that has big memory 
requirements but also radiosity, photon mapping, etc..

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3eaa7ff7@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>>> Well, then you better get system with a 64 bit processor,
>>>
>> Oh, have one for me?
> 
> Sure, it costs only about 400 Euros more than an Aldi PC ;-)
><http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=85825&parentId=48612>
>
:) Nice, but...

>The Sun Blade[tm] 150 workstation is an affordable, full-featured, 64-bit
>workstation with a 550/650-MHz UltraSPARC[R] IIi processor, up to 2 GB of
>memory
>
Oh, just up to 2 GB of RAM?
The issue was to be able to use more than 4 GB...

Wolfgang

Post a reply to this message

Christopher James Huff wrote:

>> Just tell my why I should use "intelligence" doing complicated
>> viewport and culling calculations (think of animations) which require
>> a separate mesh include file for each frame if the problem could be
>> delt with in an easier and (as I think) more elegant way?
> 
> I never mentioned viewport calculations or culling. It doesn't require
> huge amounts of work...just don't use high resolution meshes where low
> res meshes are adequate.
> 
The alternative is to use 100 million triangles. 
95% will be useless but the foreground needs needs the fine grid. 

Either smart "intelligent" mixed-resolution meshes with (at least 
primitive) viewport culling or a very fine mesh is required. 
OR, subdivision at render time. 
Anything else?

>> > A binary mesh format would make loading
>> > high-res meshes faster.
>> ...and smaller on HD.
> 
> Really, who cares about file size? It is only an issue when transferring
> files. I view it as simply a side effect of using a format more
> convenient for fast loading.
> 
When rendering films, file size gets interesting, especially if you 
need a separate mesh for each frame. And when rendering the film in 
a distributed environment the issue is transferring the meshes. 

But that's not the major issue we're talking about here. 

>>   This means, if you use a very deep scene (fly along a valley),
>>   it would produce nice scenery from a low/med-resolution mesh
>>   with constant grid size.
> 
> Which could be done just as well before rendering.
> 
Which results in a 100 million triangle mesh.
Or requires some "intelligent" mixed-resolution mesh and triangle culling. 
AND it requires knowledge of the camera position which means that a 
separate mesh is needed for each frame. 

Oh dear... we're back at the beginning. 

I don't know if you never tried to put up a POV camera in a topography 
mesh valley and looked at all the ugly triangles in the foreground. 
Only solution (without patching POVRay) I see is doing some really 
non-trivial calculations on the input topography data extracting a 
mesh with fine grid in foreground and larger grid in the background. 

Wolfgang

Post a reply to this message

In article <3eaafb9d@news.povray.org>,
 Simon Adameit <sim### [at] gaussschule-bsde> wrote:

> There has to be a reason why the reyes algorithm is still used ;-)

Not with raytracing. As far as I know, Reyes is limited to scanline only.

-- 
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

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

> Oh, just up to 2 GB of RAM?
> The issue was to be able to use more than 4 GB...

Since when is a system limited by the amount of physical memory? - It has a
40 GB harddisk in the standard configuration, so you can use 39 GB as swap
space!  Or do you expect they allow you to put 4000 Euros worth of RAM into
a entry level system? ;-)

If you want more RAM and have the necessary pocket money to spend, I would
recommend one of these systems:

<http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/pSerie
s/pSeries.html>
<http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=48620&parentId=26829>

;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

> Either smart "intelligent" mixed-resolution meshes with (at least
> primitive) viewport culling or a very fine mesh is required.
> OR, subdivision at render time.
> Anything else?

Culling is of little use for ray-tracing, it is a typical scanline render
acceleration technique.

However, I recall a paper (in ACM TOG iirc) about an optimized level of
detail algorithm for terrain modeling that was suitable for ray-tracing.
And I am sure somebody has already invented a method for fitting huge meshes
such that they can be used by ray-tracing - RAM to store meshes of whole
planets has _not_ been affordable or available for a long time after all.
And the need to store those meshes has existed for a much longer time!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Culling is of little use for ray-tracing, it is a typical scanline render
> acceleration technique.
> 
I was talking about culling as a technique to keep the mesh include file 
small. Because if you have a 100 million triangle mesh of a planet but 
only see 5% of them, you can try and do viewport culling -- otherwise 
the mesh will not fit into memory. 

>And I am sure somebody has already invented a method for fitting huge
>meshes such that they can be used by ray-tracing 
>
What about 1 byte per triangle? 

It only works for planets with 2 byte height info with the height 
info being the height difference to a sphere surface. 

If I have time, maybe I'll implement that. 

The general problem is that each vertex uses up at least 3*4 bytes. 
The only way I could imagine saving space is a better triangle-to-vertex 
mapping. 

Or, in-memory compression...

Yes, one could do in-memory compression when using a hierarchy. 
It will probably even be faster than using swap memory for the mesh. 

Wolfgang

Post a reply to this message

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

> > Culling is of little use for ray-tracing, it is a typical scanline render
> > acceleration technique.
> > 
> I was talking about culling as a technique to keep the mesh include file 
> small. Because if you have a 100 million triangle mesh of a planet but 
> only see 5% of them, you can try and do viewport culling -- otherwise 
> the mesh will not fit into memory. 

That's still holding 5 million triangles, and breaking things like 
reflections. You don't seem to get it...that is an example of setting up 
the scene wrong. You are using a much higher resolution mesh than you 
need.

-- 
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

Christopher James Huff wrote:

>> I was talking about culling as a technique to keep the mesh include file
>> small. Because if you have a 100 million triangle mesh of a planet but
>> only see 5% of them, you can try and do viewport culling -- otherwise
>> the mesh will not fit into memory.
> 
> That's still holding 5 million triangles, and breaking things like
> reflections. You don't seem to get it...that is an example of setting up
> the scene wrong. You are using a much higher resolution mesh than you
> need.
> 
Okay, then please give me your advice: How should I set up the scene 
correctly? I'll do just that and we'll see if it looks nice. 

I want to animate a space ship which flies to a planet, along a valley 
in the topography and back up into space. 

Wolfgang

Post a reply to this message