Skybox and background image

  • I desperately need to be able to use a Skybox for lighting and reflections but also use a background that is NOT the skybox, wondering if I could get a second channel just for a background image?

    Similar to every render engine, or if that is not possible then I'd like to have a flat color background enabled while skybox is present, currently I need to use geometry to create this but it really gets in the way

  • I'm dealing with this at the moment on a project as well. I have a panoramic image I'd like to use as a background, but it's from non-HDR drone photos and I can't use it for IBL. I can composite a background on still images, but for the video I'm trying to do, I basically have to keep the background out of frame. If I use the image as a distant billboard - the lighting casts shadows on the billboard geometry, so that solution wasn't really working either.

  • Solo can you please elaborate what you are trying to achieve? Are you trying to work around the deficiency of only having an LDR sky or are you going for an artistic effect. (e.g. proper reflections with white background)

  • jan1 what do you mean by screen backgrounds? A static image that is not somehow projected? If you mean that, no we don't support it. That would look really odd in real-time when moving around. You can use the white background and merge it with a static image in post.

  • I would like to use a screen mapped background too. Good for still images. Some HDRI producer sell HDRI plus backplate images for this need.

    Screen means camera mapping, it's like a static wall paper in the background. It's a standard feature of render engines.

    Also abstract backgrounds like gradients could be used to present objects in VR, for example product design.

  • Micha I understand what you mean. The problem with static textures as background, in real-time they look really disorienting. I recorded your votes on the feature request.

    On the other hand, gradients and custom color backgrounds already work out of the box. Enscape does not have a user friendly setting, but all you need to do is make an image that has a ratio of 2:1 use any color or gradient you like and use that as skybox. (It will affect the lighting though.)

  • Here are 2 use cases....

    1. Separate high resolution LDR pano background visible to camera only... lower res HDR pano for lighting.

    This would allow us to have sharp background in VR without loading a 1000 GB HDR (jk), and control the rotation separately. Regarding rotation, it is very unlikely that the angle which produces proper lighting from an HDR will also have the exact background I want.... often we want to rotate the background separate from the lighting HDR. This would also allow for tweaking the visible pano to provide a different brightness, etc. I also may want to have a panoramic image as a visible background, but use your builtin in lighting model. By separating the two functions, this should become doable.

    2. Separate image as projected background (backplate).

    Enscape is not just VR... currently one can produce still images and animation, both would look odd if viewed with vr headset. It is an accepted expectation that images and animations of a design must rise to a higher level of finish than VR, since we have the opportunity to do so when it is not in realtime (if the archviz person doesn't 'bother' to do so, he can be regarded as either incapable or possibly just lazy) Allowing projected backgrounds would provide an efficient workflow to achieve this. Currently, we those who care are going to make it happen anyway.... the request is simply to provide tools that improve workflow for what is a reasonably expected use of the software.


  • ^^^^ What he said,

    There are so many scenarios where a seperate back plate is needed independent of the HDRI, it's not like I'm asking for something unique, it's a standard feature of most if not all half decent render software's.

    wait until my next crazy request, a shadow catcher, I'll leave that for another thread.

  • It is our goal to implement solutions that work in real-time and look good on high fidelity renderings.

    What you want is not a static background, but use a custom horizon. In your case, to be specific, just a segment of horizon.

    The work-flow would be as follows: take an LDR image and make the sky potion transparent in your favorite image editor. Then place the LDR image to act as horizon in Enscape. This makes use of our procedural sky and your very specific scenery. And because the image is part of the horizon, it will look add (because only but of horizon) but not disorienting, since it will move in sync with the camera.

    We have a feature request that is for this and I added your votes.

  • Sean,

    Thanks for your attention to this.

    I have used the horizon method you describe with limited success.

    It would be a decent workaround if we can either load the horizons while Enscape is open (like a texture in a material) or have much more control over the vertical position and scale of a partial panorama.

    Right now we can rotate only... in order to get a precise position of a background, current workflow is - close enscape, edit image, save image, open enscape, view position of background... close enscape, edit image, save image, open enscape, view position of background... repeat.

    Also, when reinstalling our custom horizons are deleted.

    Thanks again :-)

  • renderwiz Yea... The official statement to that is: don't touch the horizons

    Making good horizons is not that trivial, that is why they currently are not exposed yet. As we add features we try to design and balance them to be user friendly and easy to use.

  • I understood easier loading of custom horizons was already a feature request. I do agree that good horizons are not that trivial. I did not realize trivial was the goal. I am not happy with the horizons that ship with Enscape... I suppose I will just have to keep making my own and deal with the workflow inefficiencies.

    Fyi, there is a concurrent issue that has been discovered with using geometry for background horizons. Creating geometry that is far from the center of the model has negative affects on shadow quality. I was hoping with better control over horizons we could avoid that issue.

    In the meantime, Solos request for custom background color seems logical for keying.