Posts by renderwiz

    Is there a setting that makes the "Synchronize Views" stay on as a default the next time Sketchup and Enscape is opened?


    I typically leave it on all the time, but when I reopen Enscape and open my file, it is turned off again.


    Problem is I sometimes do not notice and accidentally render with the wrong FOV.


    Thanks!

    Keep in mind when using this method... For print or 4k output if you want your background at full resolution (ie not blurry) depending on your camera fov you will need a panorama that is at least 16000 pixels wide (90 fov = 4 x ~4000 ) For a narrower fov it could be as high as 32000 or so. So if you want a custom background for high res output, it may be more practical to just do it in post. If you are only doing screen res ( or blurry backgrounds work for you) the panorama approach can be done with less resolution.

    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.

    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 :-)

    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.


    Thanks!

    I also use this regularly and it would be nice to implement in enscape if/when possible.


    Not to burst anyone's bubble but both unity and unreal have had this feature request for some time and it appears to be impossible with current gpu tech. Perhaps once real time raytracing is implemented it will be.

    Understood.... Thank you.


    A diameter of a Kilometer for a background horizon is not uncommon. I will make sure to keep it in mind when testing.


    Hopefully we will get better control for horizons.

    Another good practice is not to use a large terrain mesh/ground plane around your building. The larger your scene's extends the more has to fit on a limited shadow texture resolution, which inevitably leads to light leaking and other issues we've seen here.

    Clemens Musterle


    Thank you for that insight. I have three questions about this:


    1) For large scenes (such as a city, large campus, etc) would it be useful to attempt to isolate just the visible geometry for a given viewpoint?


    2) To actually isolate geometry, is turning on/off layers sufficient or should the hidden portions be deleted from the model?


    3) Would including background geometry such as a treeline that is a significant distance away from my building design possibly cause light leaks in my views of that building?


    If the answer to #3 is yes, then we really need the ability to control the horizon imagery better. I have been using opacity mapped geometry to workaround the limitations of not being able to update the horizon interactively. This approach creates a much larger overall model. If we were able to load horizons as any other texture without having to restart the program, the need for this type of background geometry could be avoided in some situations.

    Just to be clear, hdri does contribute to 'fill lighting' They do not make hard shadows. However, that is not a requirement for hdri to be useful. The biggest thing that hdri does is provide convenient believable fill lighting. Direct lighting (for exteriors anyway) can be handled very believably through non hdri light sources.


    What enscape also provides for is to automatically position their sun (non hdri light source) to match the 'sun' in the hdri.


    So your high res hdri is only needed for crisp backgrounds, as for lighting they are downsampling it. So if you are going to replace your background anyway, definitely reduce the size of your hdri.


    Ideally, Enscape would allow us to specify separate lighting (low res hdr) and background (high res ldr) images.

    This is with the latest preview... 2.4.2.2392. As you can see there is a very clear change from sharp to blurry shadows on my end. I am going to send this file via feedback now.




    @Demian


    Please clarify.... If an asset is placed with a Released version of Enscape, will I as a user of Enscape in the future always be able to open an old project and successfully create a rendering with those assets placed previously?


    Your comments seems to imply that the available assets can/will be removed and that we should not count on them being available when opening old projects?

    Very interesting... not at all what I was experiencing.


    Unfortunately I did not save any of those images as they were unacceptable to me, and from my previous discussions with support was under the impression this was a known issue. I will reinstall the latest and send to you.

    Looks pretty good actually.. I can see the effect, but certainly some people would like it to be stronger. The pots contrast hides the effect there. The AO effect by enscape is also not the "sharpest" but it is also not bad either, keep in mind it is realtime.


    There are other cues in reality that make an object appear grounded. For example it is pretty much impossible for a chair leg to rest on the ground *exactly* ...one thing you can do is raise your elements off the ground slightly.


    Many people use a stronger AO effect to make up for these missing cues... mainly because it takes A LOT longer to model all of them. I am all for shortcut like this btw :-) A renderer is a just tool to communicate ideas, and ideally we should be able to use any and all shortcuts that work for us. Another one I miss is rounded edges, but I do not think we will get this any time soon. More control over AO is lower hanging fruit.


    If we were given an "AO pass" we could make up for this ourselves in post efficiently. This would seems to be a decent compromise if the Enscape team doesn't want to clutter the precious UI ;-)

    Currently in many circumstances the automatic ao settings do not produce a strong enough effect and element still appear to float.


    jan1 appears to be aware of AO, and has obviously missed the fact that Enscape is already implementing it. This would seems to confirm that the built in settings are not obvious enough?


    jan1 do you have an example?

    As I mentioned, it is inconsistent, but I am certain it is happening. I would not have chosen the wrong folder several times yesterday :-) Unfortunately, I have rolled back to a previous version.


    In sketchup, it is possible that this is being affected by the dialogue for linking proxies or opening textures. If I remember correctly one of the "incorrect" folders that images were going to was a proxy folder I was using. You should try one of those actions between your save operations.