Posts by MatthiasL

    Right now our assets don't support holding an explicit light source definition (as you'd get from adding a light object from the Enscape toolbar), but simply have emissive materials on some surfaces. In order to get proper lighting you should always add a light source to them. We hope that we can include that in future versions, so you won't have to set that up manually anymore.

    Hope that clears things up :)

    Okay, there we go. Adding a "true" lighting capability to the props would be great given if it then can be tweaked via the Enscape light dialog.

    You have to disable the Safe Frame setting in the capture section of the visual settings.

    But what if I want/need that safe frame to frame/line up my shots properly? Can't have both?


    Switching to the predefined right/left/front/back positions in orthographic viewmode disables grass rendering, yet the top down view doesn't. Is this intended?

    Furthermore it forces you into White Background mode - can this also be changed?

    Thanks for Your reply, Adrian Renner! Well, just had a further look at them and they indeed are pretty much all lit albeit very unevenly so, see this example:

    I think another relighting pass on those props might be needed. Nevertheless they are a great step forward!

    Some constructive feedback:

    I love the new Asset library content, especially all the lamps are a welcome addition. Some lamps are equipped with an pre-installed Enscape light, some are not - unfortunately there is no way to tell from the Asset library. This could be easily solved by adding something like a little lamp icon or so next to the items that are pre-equipped with an Enscape light.


    This way we could easily determine which of the props are equippped with a light and which ones are not.

    Other than that: Load times on the asset library are way better now. Skies also look great, already noticed this in the preview which I used here: Putting preview 5 to work

    Well, this is - again - rather unsatisfactory and really frustrating.

    Back when we subscribed which was over a year ago this feature was already on the agenda. Since then is has been subsequently pushed back and back again. We always strive to deliver multiple design choices to our customers. The incessant absence of this feature hinders us tremendously in delivering a satisfying presentation as we have to switch the presentation which again completely breaks immersion and sure does not help in convincing already demanding customers.

    Christian Radowski Now the thread works - nevertheless I'm answering here. The feature view dependant geometry has been promised already for 2.6, then been pushed back for 2.7. What it should achieve is that we can have - as the name suggests - different geometry per view. This would enable us to provide design alternatives to our customers within one presentation instead of what we're doing now: using different presentations for each design variant, breaking immersion every time we have to switch. Is there any information on how to use it or if it is even implemented in this build?

    Unfortunately, there is no way to align Enscape view with SketchUp view (which carries the edges) easily, and there is no way as we know to rendering edges with Enscape as well.

    There is, it just involves some postprocessing. Activating live sync should usually line up the views of Sketchup and Enscape. Use an "edges only" Sketchup style then export both the Sketchup and the Enscape view. Only thing you'll then have to do is to throw the exported Sketchup and Enscape view into Photoshop, scale them until they match, blend to liking and crop.

    + =

    You kiiiind of have a point there. Twinmotion - while offering some great features - though is pretty clunky to use and has no constant instant sync. Plus last time I checked even the smallest standalone exports exceeded 1GB which is ridiculous. Furthermore Twinmotion is backed by Epic which I'd suppose give them access to way different ressources.

    If you transition quickly from day to night the auto exposure seems to react too slow, resulting in a initially too dark night portion of the exported video. To solve this a "look ahead" on the auto exposure for video export would be needed.