Could you share the skybox image or give a link to the web standalone where this skybox is not showing up? Sounds like a bug to me.
emcminn it was a multithreading issue. Geometry data could have been modified in one thread, while the other one was processing this data. This bug was for a long time there already, it's just occasion that with 2.8 it started to be a problem, due to some other changes and tweaks. As it usually happens with undefined behavior bugs which are hard to identify and reproduce.
Is a 1.1GB Sketchup model too big for Enscape on a 2080 Ti?
It depends on what takes up that space. With 1 GB of pure geometry data you will very probably have some issues. Not memory related though.
When I launch Enscape is gets to about 60% and then I notice the CPU maxes out and then crashes both Enscape and Sketchup. I did send the latest crash/log files the last time this happened.
We have received it, thank you! According to the logs Enscape detects it is frozen and shuts down. It may be a false positive, because the project seems to be pretty big and some operations may really take longer than expected. We collect such cases to find a good solution. Thank you for providing your case again! It would be great to have the project too to have a repro case to work with, if possible. Contact me via PM if you can share it.
A temporary workaround for you would be to switch to the draft quality mode - freeze is detected while preparing data structures for global illumination rendering.
This sounds like physics simulation for walking slows down because of the big amount of geometry. This is expected with the growing number of objects we analyze for collision detection. The same applies for the screenshot/panorama rendering. Even if it does not slow down that much for a single screenshot, for stereo panorama multiply the slowdown by 64.
DeKoetsier it very probably due to the amount of geometry on the scene - Enscape simply needs some time to converge to the stable result while doing each panorama slice.
Easy way to check if this time is expected is to make a normal screenshot in 2048x2048 resolution and measure how long it takes. Than multiply this time by 64 - the number of screenshots needed for stereo panorama, and it should roughly match the time you measured for complete stereo panorama.
It also depends on the scene complexity. Rendering very detailed large landscape is expected to take more time than what Demian has probably used to test.
The model is 222 mb, so quite large. I'm running the latest preview version and a 2080ti
222 mb is nothing for Enscape on 2080 Ti If driver update will not help, please contact our support and provide the project file if you can.
The shots are awesome!
I see one usability issue with the table in the kitchen - will be hard to squeeze onto the chairs between the table and the wall
Is he talking by the phone while driving!? Call police!
Would be great to see a screenshot to tell more or less for sure.
My first guess would be that the texture files are not accessible for Enscape for some reason. She may send us feedback with logs (also mention we have talked about it on the forum).
Did you try to launch Enscape with that model and see what happens?
The biggest VRAM consumers are textures and Enscape itself (frame buffer, acceleration structures, shadow maps and so on). Geometry usually does not take much space. Views, sheets, etc. do not have any significant effect on the Enscape memory consumption at all.
To use as little memory as possible for Enscape itself, you should try to switch to "Draft" quality mode prior to starting Enscape with that model. Also keep Enscape window small - if you have a 4k display and have Enscape fullscreen - you have lost a few gigabytes of VRAM already.
Textures are scaled down with respect to the world size they occupy, where possible. Even if you have hundreds of textures in the project it will be somewhat hard to waste more that 1-2 gigabytes for textures.
What will really be bad is startup time. Exporting and processing all the geometry and scaling textures may take much time. But you still could try and see what will happen.
I'm having the same issues, I cant seem to get it back to working tho, every time I render the just get the black screen. After you close it down I can not get enscape window to open again. Have to close down and open the fole up again and give it another shot.
We cannot tell much from this symptom alone. Please send the logs - black screen can be a result of a dozen of issues. Very probably it is GPU memory related, however.
The following can help if it is memory related:
1. Capture in a lower resolution. If works perfectly every time - you are out of memory because of the capture resolution.
2. If you have an RTX GPU - make sure you have the latest driver and try disabling RTX.
3. Change rendering quality to "Draft" - it will also reduce memory consumption and will disable several rendering passes which could have issues.
These options may become a workaround for the urgent case. For better diagnostics - please send us the logs.
There is an incompatibility between 2.8 preview version project format and web runtime, which means that web standalones created with 2.8 wll work only when 2.8 stable release will be published and web runtime will be updated to that version.
Sorry to hear that.
I have a brand new system, I was rendering the same images last week and now I can't. And it crashes my enscape and my revit.
I did send the report. I have clients waiting on my rendering ...
Didn't see your report yet, but.
Something has changed since last week if it worked well back then.
1. Driver update? If so - try to roll back to the previous version.
2. DeviceLost ist very often (but not for 100%) a sign for the insufficient memory. Another GPU memory consuming application running in background? Maybe you changed capture resolution to some huge one?
I hope this will help you to tackle the issue. Otherwise we will see what is wrong from the logs.
Can someone help me about this glitches?.
This could never be reproduced on our side so we could fix it If you have a reproducible case - you are very welcome to share it with us!