Very Large (HUGELY MASSIVE) Renders ~ Suggestions Please ??

Started by cyphyr, February 14, 2007, 12:05:00 PM

Previous topic - Next topic

cyphyr

Im interested in the possibility of rendering some very large images at high resolutions. I'm talking about images in excess of 15000px x 10000px. There is a reason for the extreeme resolutions. Obviously this will impact sevearly on the memory constraints of any system. In tests I cant even start the render at anything over 6000px x 4000px (interestingly this shows up in the render view as "Render View:6000x4000 (viewing at 24% : 24%)" didn't know it did that...) without getting error messages saying "trImage: unable to allocate pixelmap: size xxxxxxx bytes". What I would like to be able to do is use the "Crop Regon" function or similar to render out segments that can later be comped together to form the final large image. The trouble is when using "Crop Regon" Terragen still uses the full image size and allocates memory accordingly, hence error messages.

Would it be possible in future itterations of Terragen, or via the SDK and 3rd party plugins, to produce an option that will render only a selected region and not the unselected black area? I can see that this could run into problems if reflective objects were used but otherwise could this be done.

The other option of simply pointing the camera in different directions to produce the final set of imaages will not work since the edges of each image will have a parralax effect that will not match up to the adjoining image sections. This could be got round I guess by implementing a "custom" lens filter.

Will any of the above be possible in future versions?

Thanks for your feedback

Richard Fraser (cyphyr)
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

Volker Harun

Well,
why would somebody want to render that large  ;D ;D ;D

Beyond that question: Go for stitcher (http://stitcher.realviz.com/) or any program that is suitable to stitch images together to a whole (normaly to make a single photography out of a panorama-turn)

Regards,
Volker

Will

I think he is ooking for a program that will allow his to do all this without the memery problum to which I would say that the only way around it now I could think of is someone makes a program that moves the camera around foryou based on which render you are doing.

Regards,

Will
The world is round... so you have to use spherical projection.

Volker Harun

Will,
you are right. On the one hand. On the other hand:
Quote from: cyphyr on February 14, 2007, 12:05:00 PM
...What I would like to be able to do is use the "Crop Regon" function or similar to render out segments that can later be comped together to form the final large image. The trouble is when using "Crop Regon" Terragen still uses the full image size and allocates memory accordingly, hence error messages.
...
The other option of simply pointing the camera in different directions to produce the final set of imaages will not work since the edges of each image will have a parralax effect that will not match up to the adjoining image sections. This could be got round I guess by implementing a "custom" lens filter.
...
He does not want to wait - at least not in planetside's time units.  ;D ;D ;D

Will

Yea I know Im just saying that I don't think sticher would help to much in this case. as for the time it would take for planetside well it would be equal to aprox. 70PSTUs to finally get to this.

Regards,

Will
The world is round... so you have to use spherical projection.

Tim O'Donoghue

You can use the Crop Region feature to split the render into 2 or more parts. Once you determine the max render size for your memory, use the Crop Region to make the max size or smaller.

Volker Harun

Will, you should leave your feelings behind yourself and should use knowledge. Just doubting did not help anybody yet.

Well, I did use stitcher for photographies.

And as long as you do not have a perfect stand for a camera, it is a hazard.
Second, for photographies, you need an adapter for getting the focal point exactly on top of the rotating point of the stand.

Both is not necessary in a rendering program.

Regards,
Volker Harun

Reference:
http://www.renderosity.com/mod/gallery/index.php?image_id=876682
http://www.renderosity.com/mod/gallery/index.php?image_id=877477


Will

Well apprently terragen allocated the memory like it was not cropped meaning that he would still run out of memory.

I know stiticher works and I have used it to do this type of thing but is happening here (at least in my perseption) is that his system is running out of memory and thus can't get the render done in the first place.

regards,

Will
The world is round... so you have to use spherical projection.

Volker Harun

When using stitcher with a renderer you go a different way:
First reduce the camera's FoV (From 60° to i.e. 30°).
Second start for example at the top-left of the area you want to render.
You render a full-size 4000x3000 picture.
Then turn the camera and render the next part.
And so on.
Last you will have a couple of renders which make together a whole and you do not encounter any memory problems.  ;D

Will

hmm I didn't think about it that way, but it makes perfect sence now... oh and your right dout never got anyone anywhere.

regards,

Will
The world is round... so you have to use spherical projection.

cyphyr

Hmmm I had forgot stitcher, it may well be a solution. I had in the past used it with mixed success on digital camera images; the problem always was that even with the greatest of care lining the images up was troublesome (yes I always used a tripod) and particularly adjusting for different levels of exposure ment a loss of fidelity in the final image (the dreaded virtical bands). Of course with an entirely digitally rendered image these very likely would not be an issue. Good idea, thanks :) I'm still, however, interested in any comments about the adaptability of the upcomming SDK and particularly using it to create custom lenses.

I'm aware that an image of this size will take a long time (a VERY long time) to render all its segments and this is not someting I want to start in the near future. I'm figuring that it would take a month or so to render all the images based on each section taking an average of a day to render (blue sky will render a lot faster than complex terrain and water for example). Obviously the renders would have to be optomised (equally) regarding detail leavel, AA, samples and other time hit qualities.  I dont think this is an unreasonable amount of time to spend on a single image and the final result could be awe inspiring. Imagine standing in front of a 4 foot wide landscape where you could see every single leaf and blade of grass!!

Thanks again

Richard Fraser (cyphyr)
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

Oshyan

As you have found rendering at this size in one go is simply an impossibility at this time. The reason crop rendering doesn't help is because it still outputs to an image of that size, so the image size must be allocated, and we're talking about HDR images plus alpha, not to mention antialiasing buffers, etc. The *base* size for only a 32 bit image (24 bit + 8 bit alpha) at 15,000x10,000 would already be around 600MB uncompressed. Along with the rest of the memory TG2 needs to allocate this means that you'd quickly run into the 2GB 32 bit memory limitation, and since TG2 isn't 64 bit optimized yet that's about all you have.

For now I think the zoom+camera move option is your best bet. You can mimimize camera distortion by massively reducing the FoV. Some simple calculations should tell you how many tiles at what render size you would need for a given size of final image with a known total FoV. A simple example, if your final FoV is 60 and you reduced to FoV 1 for renders, you could render 60x60 small-ish images and stitch together with minimal distortion to get the full-sized version. If you have some Excel or database (Filemaker for example) skills I'm sure you could setup a simple calculation that would output the appropriate values to a format that could be brought into a .tgd fairly easily. You would need the animation-capable version to render this, but I presume you're already registered, hopefully with the Animation module as well.

The one major caveat to the stitching approach is that if you use Global Illumination you are bound to get edges that don't match due to differences in lighting calculations. I would definitely recommend against GI in this case. You can use the Fill Light setup in the File Sharing area as an alternative.

In the future there are a few things that will help with all this. First we do plan to implement a "render to disk" function that should greatly reduce demands on RAM for rendering of any size image, particularly very large sizes like this. That alone will probably solve your problem. We do also hope to make a native 64bit verison which could then take advantage of more RAM and probably render on a high-end system all the way through without a problem (for example with 4+GB of RAM). The render to disk option would be the more accessible and likely solution however. Finally there may be other optimizations introduced which would help with memory use in such situations, but it's not clear how significant an effect there might be nor what specific optimizations will be possible. In general we hope to reduce memory use as much as reasonably possible though.

As far as what will be possible with the SDK, I'm afraid that's not really fully determined at this point. I do think it's possible you'll be able to make custom camera projections, but I'm not sure whether you would be able to modify the crop function to work as you indicated. Further details will have to wait until we are closer to SDK release.

- Oshyan