ChamanSingh <nomail@nomail> wrote:
> I will also appreciate if someone gives some links to a Multi-Core
> implementation of PovRay.

  http://povray.org/

-- 
                                                          - Warp

Post a reply to this message

Well, in my eyes it makes sense to invest some Rupees and buy additional 
memory. Memory is not that expensive, and the results pay off.

There was a time I tried with a small amount of memory, but I feel much 
better now with the current amount of RAM. I can do all the scenes I want, 
the way I want.

I hope it's possible for you to get more RAM.

Post a reply to this message

"ChamanSingh" <nomail@nomail> wrote in message 
news:web.48982d491b7d5971b5cc26d30@news.povray.org...
> Hello,
>
> I have very large triangulated surface mesh and it seems that PovRay
> allocate large memory during calculation. Isn't ray tracing is an
> embarassingly parallel procedure ? Therefore, I was wondering if it
> is possible to have low memory footprint version of PovRay where
> performance is not the most important criteria.

Changing something like that is a huge undertaking. It would require a 
massive change to the inner workings of POV.

> I will also appreciate if someone gives some links to a Multi-Core
> implementation of PovRay.

The official 3.7 beta version of PovRay is multi-threaded. I use it on a 
quad core with great effect. It can be downloaded from 
http://www.povray.org/beta/

Rarius

Post a reply to this message

ChamanSingh wrote:
> I have very large triangulated surface mesh and it seems that PovRay
> allocate large memory during calculation. Isn't ray tracing is an
> embarassingly parallel procedure ? Therefore, I was wondering if it
> is possible to have low memory footprint version of PovRay where
> performance is not the most important criteria.

If you don't have too much RAM, but performance isn't important, just let it
swap to disk like crazy :)

Post a reply to this message

Hello Sven,

I wish things were that simple, but what can I do when my lab data generate
data of more than few TeraBytes and not few GB. Yes, your suggestion is very
great but impractical in many senses.

I just wanted to get an unbiased opinion about this topic, and looking at the
response, I think, we may have to re-implement PovRay type system with very low
memory requirements.

And I must say that Povray is wonderful.

Thanks and With Warm regards

csv

"Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
> Well, in my eyes it makes sense to invest some Rupees and buy additional
> memory. Memory is not that expensive, and the results pay off.
>
> There was a time I tried with a small amount of memory, but I feel much
> better now with the current amount of RAM. I can do all the scenes I want,
> the way I want.
>
> I hope it's possible for you to get more RAM.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> ChamanSingh wrote:
> > I have very large triangulated surface mesh and it seems that PovRay
> > allocate large memory during calculation. Isn't ray tracing is an
> > embarassingly parallel procedure ? Therefore, I was wondering if it
> > is possible to have low memory footprint version of PovRay where
> > performance is not the most important criteria.
>
> If you don't have too much RAM, but performance isn't important, just let it
> swap to disk like crazy :)

I think, it is neither professionally nor technically sound answer.

With regards and Warm Wishes/

csv

Post a reply to this message

ChamanSingh <nomail@nomail> wrote:
> I just wanted to get an unbiased opinion about this topic, and looking at the
> response, I think, we may have to re-implement PovRay type system with very low
> memory requirements.

  You won't be able to reduce the memory footprint of a mesh by any
rational means while keeping the entire mesh in memory.

  The only option would be to load only part of the mesh at a time
(ie. only the parts which are needed). Some high-end renderers support
this, but it's a quite complicated thing to implement. One possible
approach is to use the octree POV-Ray already uses for meshes so that
only those nodes which are requested are loaded, and least used nodes
freed. It's not trivial, though.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> ChamanSingh <nomail@nomail> wrote:
> > I just wanted to get an unbiased opinion about this topic, and looking at the
> > response, I think, we may have to re-implement PovRay type system with very low
> > memory requirements.
>
>   You won't be able to reduce the memory footprint of a mesh by any
> rational means while keeping the entire mesh in memory.
>
>   The only option would be to load only part of the mesh at a time
> (ie. only the parts which are needed). Some high-end renderers support
> this, but it's a quite complicated thing to implement. One possible
> approach is to use the octree POV-Ray already uses for meshes so that
> only those nodes which are requested are loaded, and least used nodes
> freed. It's not trivial, though.
>
> --
>                                                           - Warp

Personally, I've long considered pov to have a low memory footprint anyway.
There is one thing that this post reminded me of, though.  This is applies to
running povray under windows using the GUI - open documents do take up more
memory.  I've dealt with some a fairly large meshes, something like ~8Mb when
saved as an include by itself.  If you have the document open in one of the
tabs, it does take up that extra bit of RAM.  In this case, when we are talking
about terabytes, an analogous concept could be used by splitting the large
mesh(es) into smaller chunks, then loading and rendering only the visible
portions of the mesh, or even splitting the image into chunks and rendering
each chunk separately.

  Personally, I am kind of curious as to what type of data this is.  If a mesh
that dense is completely within the camera view, the resolution required to
tell the difference between that mesh and another with 1/100th of the triangles
must be very high.  If not all of the mesh is visible, then it can be split into
pieces.

-Reactor

Post a reply to this message

ChamanSingh wrote:

> Nicolas Alvarez <nic### [at] gmailcom> wrote:
>> ChamanSingh wrote:
>> > I have very large triangulated surface mesh and it seems that PovRay
>> > allocate large memory during calculation. Isn't ray tracing is an
>> > embarassingly parallel procedure ? Therefore, I was wondering if it
>> > is possible to have low memory footprint version of PovRay where
>> > performance is not the most important criteria.
>>
>> If you don't have too much RAM, but performance isn't important, just let
>> it swap to disk like crazy :)
> 
> I think, it is neither professionally nor technically sound answer.

Any solution built into POV-Ray would behave a bit similar to the operating
system's virtual memory anyway. Like Warp said: "One possible
approach is to use the octree POV-Ray already uses for meshes so that
only those nodes which are requested are loaded, and least used nodes
freed." Except for the octree (which surely is an advantage), that sounds
like the "swap to disk the least recently used piece of memory" operation
the OS does whenever it feels low on physical RAM.

Post a reply to this message

ChamanSingh nous illumina en ce 2008-08-06 12:05 -->
> Hello Sven,
> 
> I wish things were that simple, but what can I do when my lab data generate
> data of more than few TeraBytes and not few GB. Yes, your suggestion is very
> great but impractical in many senses.
> 
> I just wanted to get an unbiased opinion about this topic, and looking at the
> response, I think, we may have to re-implement PovRay type system with very low
> memory requirements.
> 
> And I must say that Povray is wonderful.
> 
> Thanks and With Warm regards
> 
> csv
> 
> 
Do you need to see the whole mesh, or only part of it? When rendering, with ANY 
renderer, you almost never need the full precision data set. You are limited by 
the pixel size and number, and any precision that result in sub-pixel changes is 
normaly unneeded.

If you see it all, then, reduce the number of nodes by 100 to 10000 times, or 
even more. Reduce the numerical presision, you quite probably don't need more 
than 2 or 3 decimal places. In this case, you can get several triangles per 
pixel, even after dividing their number by 1000...

If you only see part of it, look if you can get subsets. You then only read 
those that are going to be rendered.
Even here, you can surely reduce the numerical precision down to about 4 or 5 
decimal places.


-- 
Alain
-------------------------------------------------
Capitalism: That's MY shit.

Post a reply to this message