Wraparound camera request and reasoning

[FlynnAD]

Hi Planetside,

Upon searching the forums, there are numerous posts of people who have trouble making skyboxes, having seams, having poor contrast, having to use fake fill lights, etc. While there are tutorials, and people working on better tutorials (http://forums.planetside.co.uk/index.php?topic=13558.0 seems to be the latest skybox post), could I ask Planetside to PLEASE program a wraparound camera into TG2?

-Having one wraparound camera node would allow all the skybox problems to go away instantly (except perhaps for gamers who need a skybox and not a spherical map).
-No need for lengthy tutorials or user learning curves on skyboxes.
-No tiling problems. No contrast problems.
-You get 1 image file when you're done. Gone are the 6x skybox files you need. No bloated hard drives anymore.
-No other programs, free or expensive, are required. No one has to leave TG2 to compile images in 1, 2 or 3 other programs. Work in TG2, render in TG2, done.

-Further reasoning: now that TG2 has animation functionality, it's great to make moving cloud scenes. I'd love to render a wraparound cloud animation straight out of TG2 and then simply link those files, as they are, into another 3d program (such as 3dsmax) to use as a spherical environment reflection map for some shiny 3d object. But right now, if I need a moving cloud environment spherical map in 3dsmax, even for 100 frames, I'd have to render 600 frames in TG2, then somehow batch process those files in another program or two (can you imagine doing it by hand?). The skybox process multiplies if I need 200 frames or more - that's 1200 frames in TG2 whereas it could simply be 200 if there was a wraparound camera.

-Further reasoning: while working within TG2, it would be really helpful to have a wraparound camera to make quick test renders (at low, fast settings) to speedily see how the clouds look all around you. For example, if I know that my camera will spin around (even if the clouds are still), finalizing the location, size, density, etc., would be so much faster if we could click a new cloud seed, then click a wraparound-render and see an image where the clouds are on all sides of the scene. Done. Comparatively, right now, you could render that same scene 6x to see all your clouds only to realize that you need a new cloud seed. Start over. Click new cloud see or shift your transform node, click render 6 more times. Or you could try to spin the 3d preview window around (pausing each time to let the preview window refresh enough detail, then spinning some more, pausing, then spinning some more, pausing). Or you could set up 6 cameras to flip through in the 3d preview window (instead of orbiting around). All of these workarounds "work", they're just not ideal. If there was a wraparound camera, at low settings, I could probably get a decent-sized, low-quality test image in a matter of seconds. This would be even faster than spinning or waiting for the 3d preview window to refresh.

I understand a wraparound/spherical camera is not a necessity and you're probably spending your programming efforts on new functionality. However, this would be so helpful, and I hope the explanations above make sense.

Sincerely,
-Matt

[penboack]

I would like to second this.
However, I think that it should simply be a render setting and does not require an additional node.
In Vue Infinite you simply enable two settings in the Render Settings (Panoramic View, and Spherical Render). Render the image, load the EXR / HDRI into CINEMA 4D / MAYA / Houdini / modo, job done.
The process of doing this in Terragen is, by comparison, very time consuming, both in terms of additional render time (rendering 6 images instead of 1) and post render processing.

[Oshyan]

We do intend to add a "spherical camera" or similar render option, but I don't know when we'll be able to do it. I can say at least that the next version will include some GI caching options that will help a lot with using GI and getting even lighting across a panorama. So while the process is still somewhat laborious, getting good results will not be nearly as difficult.

- Oshyan

[coremelt]

just a note to say I'd really like to see this as well.  I also thought maybe you could do some trick with a 180 degree field of view to simplify this... um, no but it looks kind of cool

[freelancah]

From what I've talked with Vue users it seems that they dont actually use the spherical wraparound camera at all. Ive been told that it's much much faster to render high res skyboxes and bake em to equirectangular format in post..Ofcourse when time is not a factor I suppose it could be of some use

[FlynnAD]

My hunch (which could easily be incorrect) is that people making video games are more likely to use skyboxes, while people making VFX or arch viz renderings would much rather prefer a single spherical image to use in a reflection slot or an environment HDRI lighting slot.

Even if a certain percentage of users would not use a wraparound camera, I'm guessing that it would still be valuable enough for other users (me, for one) that we'd pay for that particular node capability, even if it came out before or after a software release and wasn't a free update. Just think of how much the time costs for a professional to go through all the setup of a skybox and post-processing. Make skyboxes a few times, and you've already racked up more cost in time than cost in paying for a wraparound camera node.

I'm also not a programmer so I don't fully understand the depth or complexity of this, but wouldn't a wraparound camera option also release the need for GI caching and other tricks for creating clean skyboxes? Isn't it "simply" a matter of writing an algorithm for distorting the render lens and turning all objects on (not clipping anything outside the field of view)?

Anways, I don't want to make this a rant, just a plead. Thanks for creating some powerful software.

-Matt

[Kadri]

...
I'm also not a programmer so I don't fully understand the depth or complexity of this, but wouldn't a wraparound camera option also release the need for GI caching and other tricks for creating clean skyboxes? Isn't it "simply" a matter of writing an algorithm for distorting the render lens and turning all objects on (not clipping anything outside the field of view)?
...

I am not a programmer too FlynnAD . It is probably the best to wait for Planetside to reply here.
But what i know in these past years from here , is that there are many optimizations in the render engine as in other 3D engines .
The most i call now from my mind is that objects , terrains behind the camera are not calculated (so to speak roughly).
There are-was(?) some render errors because of this for example.  
Matt does have to make some changes probably to make this happen.
How much he has to change, knows he best obviously , but it could be harder than we think.
He probably could do kind of an automatic self moving camera that do all this things inside the engine (for optimized memory use) and spit the kinda stitched (or bucketed(?) ) image to the desktop at finish.
Putting all the 360 degree scenery to memory and render so much displacement etc. at ones could be tough probably !

Yeah it is a slow day today  

I am curious too  

[freelancah]

My hunch (which could easily be incorrect) is that people making video games are more likely to use skyboxes, while people making VFX or arch viz renderings would much rather prefer a single spherical image to use in a reflection slot or an environment HDRI lighting slot.

Correct, alltho modern game engines do work with skydomes too

Just think of how much the time costs for a professional to go through all the setup of a skybox and post-processing. Make skyboxes a few times, and you've already racked up more cost in time than cost in paying for a wraparound camera node.

I've made skyboxes and the conversion to equirectangular format takes less than 15 minutes in post, assuming the seams are fine, which the GI cache feature helps.
Personally I'd still prolly bake em in post since the general feel from my Vue contacts is that it takes hours and  hours more to render straight into equirectangular format

I'm also not a programmer so I don't fully understand the depth or complexity of this, but wouldn't a wraparound camera option also release the need for GI caching and other tricks for creating clean skyboxes? Isn't it "simply" a matter of writing an algorithm for distorting the render lens and turning all objects on (not clipping anything outside the field of view)?

I believe if the solution would be simple, it would've been done already. I think there's more problems to it than people think.
The GI caching has other uses than just skyboxes, mostly helping GI flickering in animations

But yeah generally I agree with you. It would be a nice feature to have.  Perhaps after the GI-function has been released we could have an automated skybox feature. With this the conversion of skybox to equirectangular would not be far away

[penboack]

I have done some testing of this in Vue and the render times are around 4.5 times a normal render with otherwise identical settings.
In Terragen using the current system the render time would be 6 times a normal render as you need to produce 6 images.
You would obviously expect render times to be much longer, in the order of 6 times longer, because there is a lot more to render!

However, I would say that the render time is not so important anyway, because it can be done on another machine freeing up your workstation. The additional time to convert 6 images into an HDRI is the real issue.

I believe that for Arch Viz, VFX, Commercials, and no doubt a whole load of things I haven't even thought of, this would be a very useful addition to Terragen.

[freelancah]

What do you exactly mean by normal render? From what Ive been told it's much faster to do a skybox in Vue than to render a spherical image. So much faster that it's beneficial to convert a skybox into equirectangular in post rather than render it directly..  I dont know about the impact of scene complexity on these but since Ive seen the works that have been used for these..they havent been simple at all. I dont know if Vue has had any upgrades on these since most of the discussions took place over a year ago

Edit: How did you take into account the rendering resolution?  Cubic face size is the width of an equirectangular image divided by Pi. Important for tests

[penboack]

By normal render camera, I mean the standard 35mm camera.
The rendering resolution was taken into account.
I'm using Vue 10, they made significant changes and improvements to the renderer in the Vue 10 release.
Of course it is not a rigorous test, merely indicative...

However, there is one other factor to think about. Because Terragen is spherical planet based you always are likely to have something interesting to look at in all directions. Vue is set based (1), there may not be anything behind the camera. Consequently this functionality might be rather more useful in Terragen than it is in Vue!

(1) Edit: BTW Vue çan do spherical planets, but it isn't its strong point and few people use it that way.

[freelancah]

Then that sounds quite nice actually. I'd definitely use it if the tradeoff in rendering time is even near to those figures

[King Mango]

My hunch (which could easily be incorrect) is that people making video games are more likely to use skyboxes, while people making VFX or arch viz renderings would much rather prefer a single spherical image to use in a reflection slot or an environment HDRI lighting slot.

Actually the predominant engines UDK/CrySandbox/Hammer each use different approaches for skybox rendering. UDK generally goes with a dome that can either be cylindrically mapped and the top half of a spherical render applied, a full sphere again using a (full) spherical render, or again a dome that is planar mapped from above and a render that's been shot off the reflection of a chrome ball. A skybox is also a practical solution through far less common nowadays as the sky is no longer separate from the scene but placed at an extremely large scale so as to encompass the entire world and reduce parallax.

CryEngine is an overly complex box with multiple renders for each cardinal box face. Yikes!

Hammer makes the best looking skyboxes imo due to its ability to handle HDRI. And they exclusively use cube to cross format.

As an alternative to a hemispherical render I could explain my planar mapped chrome ball method that I've used before in Vue in a bid to reduce texture memory. It's only real draw back is that you do not really get a good result from the terrain, but the sky comes out quite acceptable from a single 2k texture. I am sure TG2 can recreate the same scenario. Here's a small version of one of the textures that should give an idea of my approach.