For me it is also the settings window(s).. for current previews it happens for both the general and visual settings window.
Yes, this is how I am using Alt + Tab (Tab, Tab, Tab, etc).
I see a Sketchup Icon for each Enscape dialogue box open at the time. These only activate the Sketchup window *sometimes*. When the Enscape dialogue box has focus it only brings up that dialogue box, not the Sketchup window.
+1 for window focus consistency
Enscape dialogue boxes with Sketchup do not allow for Alt Tab to work properly. When I Alt Tab back to Sketchup I see an icon for each Enscape dialogue box open. None of these activate the Sketchup session only the Enscape dialogue box. I must manually minimize whatever window is above sketchup to see it. If I close all Enscape dialogue boxes it works properly. It seems to happen when the dialogue box has focus... If the rendering window has focus it does not seem to occur.
I have been pulling my hair out as I Alt Tab a LOT while working.
I was about to create a request for a proper Changelog and found this post. Perhaps this is the appropriate place to make this comment, please advise.
The current "Version History" reads more like a "What's New". It primarily addresses new features or improvements. but is silent on minor changes .
There are typically several additional minor changes that go into each update than is listed in the Version History which nonetheless impact the look for a rendering created with a previous version.
Would it be possible to have detailed view of Version History?
This is a problem for me currently as well. I have a project nearing the final stages of presentation for which I must use aggressive post production denoising techniques (which take MUCH longer than any extra render time I would have to wait for) I have even toyed with multiple render output and averaging them in post to remove noise. The problem is that this type of artifact is inconsistent with Enscape... sometimes reflections are not noisy and it is hard to predict.
I posed a solution several months back which I am certain would not require significant effort. If one zooms into a problem area, like the one Micha pointed out, and renders a cropped version of the scene, this type of artifact is generally much better. It also improves on shadow glitches. If we can render tiled images with some overlap, this would be a quick workaround for those times when artifacts like this are not acceptable, or when higher resolutions are needed. These tiles could be composited outside of enscape automatically, such as in photoshop, or ice.
Yes, this absolutely hinders my workflow. I am very surprised to hear this is not being fixed. I have been unable to achieve the exposure I wanted on at least 2 exterior renderings in recent months.
Are their any workarounds (such as typing in a specific exposure level) ?
If there is a need for a type of "Low Exposure Mode" (logarithmic scaling for the slider?) so that setting low exposures are more sensitive, why not allow us to manually turn on/off such a "Low Exposure Mode" mode rather than force it to be automatic and compromise the middle range of exposure?
This seems to be a known issue. See link below... it was confirmed at 2.5.2.
It was my understanding this is being looked into, but please send an email directly to support to make sure, this is not acceptable.
Thanks. I was referring to custom proxies which come through as a wireframe box.
I believe this is the workflow that houseofmanuela was asking about.
Demian Gutberlet .... if there is not already a request to make linked file / custom proxy representations persistent upon reload, please add one. Thanks!
...you can colour code your assets....
Gadget I have tried this method of customizing the "proxy box" only to have them reset to the original simple box. It seems to be related to when Enscape reloads the proxy, definitely if the proxy changes (ie. adjusting a material on the proxy, which I do a lot) but possibly at other times. This also seems to affect the AW Proxy representation. Have you found a method to make these types of custom proxy representations be persistent? Or do you experience these type of issues as well?
+1 for either solution
I would like an indication of proxy direction and what file is being referenced.
It could be a simplified version similar to your library but not necessary to be even that complex.
Colors or arrows can indicate direction.
Text with the filename or including the file thumbnail could indicate source.
It was worth a shot....
Use cases not working:
1. Sun Shadows cause random glitches at specific distances from camera.
2. Sun Shadows seem affected by overall scene size.
3. Shadow softness of artificial lights seems affected by scale of scene.
4. Working at small scales. Revit files facets hard coded to sizes of scene and do not work well for details.
5. Working at very large scales.
6. Grass height limits. What if i want Super short grass?
7. Etc, etc.
If scenes must fit within a range of sizes to work well, there will always be cases that dont work. Why not give those users a way to deal with it? It could even be a user cfg variable. We have already had the opportunity to adjust distance parameters via that method.
Architectural photographers regularly use "Fake" lights... Just saying.
I would like a global scale adjustment within Enscape.
Enscape is translating our scenes prior to rendering. During that translation, would it not be possible to apply a global 'scale' to EVERYTHING? This would include camera distance. The end result would be imperceptible in many ways, but would allow us to workaround several hard coded rendering optimizations currently in place.
Enscape makes several assumptions about how it will render depending on the specific size of a scene / object and the distance the camera is away from them. There are optimization techniques being used (cascading shadow maps + other shadow maps techniques) that break down sometimes at specific distances from the camera. Apparently overall scene size can make a difference as well.
I have manually scaled my scene to get around shadow issues, and also grass height issues (when we were not able to control height) Several other users have tried manually applying a scale with limited success. The main downside to that approach is that one must make a permanent change to the model. I propose a "global scale" that is only applied during rendering. This would also allow for Revit users who wish to render smaller scenes to have smooth curved surfaces.
There are likely many other benefits, and since the Enscape team does not want to provide fine grain control over render settings, this type of "global scale" would allow those who run into rendering glitches an outlet to attempt to work around them.
Transmutr is similar... however doesn't convert native Max files.
Theoretically a plugin within Max *could* make use of all the data available to Max and *could* successfully preserve more of the original material settings from Max.
For most people transmutr would be just as, if not more useful.
My favorite part... image 3... you found a way to use the "Yes!" guy from axyz in a conversational way
I should have been clearer... was referring to loading textures within Enscape while using Sketchup. This usually is a problem with HDRI loading. I switch these often between image exports and Enscape ends up saving image exports to my HDRI folder.
Here is what I understand about the confusing behavior related to save locations (and a Request!)
Currently (2.52) it will remember the last location an image is saved OR location a texture is opened from. This last part confuses me regularly. I expect the software to remember my last location for saving an image SEPARATELY from the last location I open a texture from. Each of the different tasks... save an image, save a file, open a texture, etc, etc. should remember separately as they are alternated between regularly and it creates an inconsistency that causes confusion.
Please make this a request Demian Gutberlet !
macservice123 you might test to see if this is what you are experiencing. If not please report back.