Question about larger renders

[mehrdadart]

Hi friends,

I am going to increase the amount of RAM on my computer so I must change my 32bit windows with a 64 bit. Does Mandelbulb 3D support windows7 64bit properly? I searched too much about this issue on the web specially in fractalforum and did not find any answer. Nor did I find any special version of Mandelbulb 3D for 64bit windows. Does the same version for 32bit supports 64bit too? Now with 2 Gb RAm I can not render images larger than 4000x4000 pixels in Mandelbulb 3D. But I need images as large as 10000x10000 pixels !!! Can anybody help me with this matter?

Kindest Regards,
Mehrdad

[bib]

Hi
I'm not sure if M3D supports 64bits. Let's see Jesse's answer. FYI I have 4 GB RAM on Vista and the larger images I can render are about 9000x9000.

However sometimes it's frustrating with such large images because the main rendering takes a long time, and then it fails when hard shadow calculation kicks off.

So maybe an enhancement suggestion to Jesse : test that there will be enough memory for hard shadows BEFORE the main rendering.

Cheers

bib

[mehrdadart]

Aw. Does windows Vista 32bit really support 4 Gb of RAM? I have not ever worked with Vista. Then, I think you should be able to render larger images with 4Gb RAM. Should not you?

 And, yeah, I have had the same problem with hard shadow calculation while rendering large images. Does it need more RAM to calculate it or does something else happen?

Thank you for sharing your experiences.

Best, Mehrdad

[Jesse]

Hi Mehrdad and Bib,

M3D is only 32 bit, so it can use theoretically up to 4 GB of Ram, but the operating systems gives them only 2 to 3.5 GB.
That depends on the specific operating system and the settings, on some system you have to set it from 2 GB default to a higher value!
I dont knoe how this is done in 64 bit system, all i know is that XP personal limits it to 2 GB, in XP professional you can set in the startup
file to a higher value, in Vista there is also an option to set it to 3 GB.

The hard shadow calculation does not need more memory, but the 15 bit ambient needs very much - not the newer 24 bit versions!
The Ram amount is about 24 bytes per pixel in normal usage, plus 4 bytes per pixel with 24 bit SSAO plus some minor extra mem.

So you can calculate with some extraamount that a 100 megapixel image x 30 bytes = 3 GB is the absolute limit, with 2GB limit less.

By now i can not compile a 64 bit version, and i certainly would have to rewrite whole parts.

[knighty]

MB3D is win32. By default, the maximum memory per win32 process is 2GB (even on 64bit windows, according to msdn). This explains why you can go beyond 9000x9000 or so, because MB3D seems to use at least 18 bytes per pixel (18 when saving .M3I files).

A simple (to implement) solution for bigger renderings would be to divide them into multiple tiles.

(jesse was faster  )

[mehrdadart]

What do you mean exactly about dividing? Do you have a perfect and accurate way for such a dividing? If we change the position of the viewer to have one of the tiles rendered the angle of view will be different for each division. Do you have a better way?

On the other hand, has not yet anybody tried Mandelbulb 3D on 64bit windows? It might work properly?!!!

Best, Mehrdad

[Jesse]

The 64 bit systems can run 32 bit software, but that makes not a 64 bit software out of them because they are using only 32 bit pointers, capable of using only 4 GB maximum.

I could find a way of a hard disc rendering, but the ambient shadows needs to have the whole Z buffer in memory...
it would increase the maximum size nevertheless.  But this only an idea by now.

[mehrdadart]

Hi Jesse,

Thanks for your answer. But, you should understand that many of Mandelbulb 3D users might need larger prints. I am going to have an exhibition of some of my fractals printed in large sizes. so, I need Large images!!!   Do not you have any solution? Can you make it possible to divide the render to smaller tiles like 2, 4 or 8 tiles to be rendered one after another seperately? As "Knighty" has stated it might be the best solution to have larger renders. I hope it is possible to have such a nice option for renders in your wonderful software. I am enjoying it really.

Best,
Mehrdad

[Jesse]

Only if i get 20% of the income 

To be serious, also if you make tiles, for the SSAO functions you need the informations about the other tiles,
so the problem stays.  I need to make an AO that does not depend on the Z buffer...

[knighty]

if you make tiles, for the SSAO functions you need the informations about the other tiles,
so the problem stays.

SSAO... and also DOF
I was thinking about dividing the image into more tiles. the lower limit for the size of each tile would be the SSAO/DOF max radius. If the former is too large then the problem wouldn't be solved this way.

[Jesse]

SSAO... and also DOF
I was thinking about dividing the image into more tiles. the lower limit for the size of each tile would be the SSAO/DOF max radius. If the former is too large then the problem wouldn't be solved this way.

Yes, unfortunately the radius for the SSA0 is always very large, so a better way would be to process only some rows of the image at a time
and held the complete Z buffer in memory... what is not a solution for the sorted DoF, gosh.

[Thunderwave]

I have Windows 7 64 bit, and it runs just fine.  I don't know about large images but, can you just pan each area and render them separately? Panning should not effect the image right?

[Jesse]

The problem is a general one with tilings and the SSAO (and DOF)... even if the tiles are fitting,
because the tiles need to know if there are objects in the other tiles to calculate shadows from it,
there would be no proper shadows on the edges of the tiles...

[cytotox]

I know this topic is not so new anymore, but still the problem is valid.

Using Vista 64 bit and 4 GB RAM, I have been able to render image sizes of 10000 by 6250 (i.e. 62.5 Megapixels) without problems. Rendering an image @ 11173 by 7630 (=85.3 Megapixels) is also possible, including hard & ambient shadow calculation (SSAO24 or SSAO24r). However, when trying to calculate DOF (no matter if 1 or 2 passes, sorted or forward), there is always the famous "out of memory" popup window. So, it seems that DOF calculation is the most demanding on memory resources ...

In this regard, it does not make any difference if M3D is told to calculate all of the post processings automatically, or if the render is saved after ambient shadow calculation, and DOF calculation is initiated after re-booting the system, starting M3D and loading the saved file ...

I've recently upgraded my RAM to 8 GB (it is actually supported & used by Vista, as e.g. the taskmanager shows). However, the memory restrictions still apply, indicating that the 2 GB barrier for 32bit programs is the major limitation for larger renders run on a 4 GB system.

I have been wondering about rendering in slices: if we allow for a certain overlap (e.g. 30 %) to compensate for possible artefacts in ambient shadow calculation near the image borders (and what about DOF in this regard?), could we use one of those programs like panorama maker to assemble a larger image? I think I may try this out one day ...

[Jesse]

I have this topic in mind, if you are using only DEAO and no DoF, there would be no memory problem if the image would be tiled in some way.
So this would be an option i have on the todo list, rendering tiles that can be glued afterwards in the program.
But i want to enhance the DEAO especially for low raycounts.

The DoF effect could be seperated for not to high radii, but i have no time for this yet.

Of course, more than 4 GB of memory can't help a single 32 bit application, unfortunately...