3.4 extreme loading and bad quality

  • Big thumbs up to the new load screen!:thumbsup:


    Has the Dev team found the root cause of the slow load times?

    Not yet, but Paul's feedback report could be very helpful here. :)

  • I recently had some problems with my PC that resulted in me adding an additional 32Gb Ram (Now 64) and replacing my SSD/HD combo with 2x Samsung 980 SSD's, as a result, I've reinstalled everything from Windows 11 up.

    So far everything has worked perfectly without any hiccups, I've been rendering multiple stills, videos and panos in 332 without even the fans kicking in.

    I installed 3.4.1 +87719 yesterday afternoon and did a test using a model I'm working on and whilst it was a lot slower than 332 to initialize it worked. The model HAS NO PROXIES YET, it's just a couple of empty rooms.

    The model this morning isn't complex but it does have a fair number of proxies, most are Enscape trees, hedges etc but some are my own, such as sofa's, beds, plants etc. As I mentioned above I don't use custom assets. Once I reinstalled 332 and reset the asset library everything worked perfectly.

    Attached is one of the renders from the model.

  • The driver has been updated to the most current AMD PRO driver downloaded today (9/24/22.) from their website. Enscape was upgraded to 3.4.1+85781. SKP instantly crashes when placing an enscape object such as a light sphere into an empty model and without enscape itself running. Feedback already sent.


    Maybe the enscape lights are proxy objects themselves and the same problem Paul is having?

  • Paul Russam , jlo , hbc_visual , thanks a lot for all the feedback and cooperation. Everything will be forwarded to our developers accordingly, I appreciate it.

  • SKP instantly crashes when placing an enscape object such as a light sphere into an empty model and without enscape itself running.

    I'm getting a similar crash testing 3.4.2 w/ Sketchup 2021 on a couple machines w/RTX4000 and A4000. Not every file, but I have one where it is pretty repeatable. I've tried a number of (studio) driver versions - 513.46 seems to work slightly better than 516.94 or 517.40 but I've crashed with all of them. It just throws up a Sketchup BugSplat, no Enscape error, if you can point me to the skp log file directory I'd be happy to send them.


    Going back to 3.4.1 or up to 3.5 preview doesn't make a difference. I can't go back to 3.3 because I have another file that crashes out in that version (which rendered fine in 2.9.)

  • Demian Gutberlet Just wondering if there is an update on this, or if you have found any reasons for the behavior?

    Unfortunately this is still a behavior we're looking into, though it seems to be not as easily reproducible and thus resolvable as we hoped - I'll get together with our developers once more and may have to request further information from anyone who still experiences this. Thanks for a bit more patience once again.

  • Unfortunately this is still a behavior we're looking into, though it seems to be not as easily reproducible and thus resolvable as we hoped - I'll get together with our developers once more and may have to request further information from anyone who still experiences this. Thanks for a bit more patience once again.

    I'm curious as to what is being tested to try and reproduce the issue. From a performance standing, 3.4 is slow and laggy in our projects.


    Does the community have a standard benchmark scene? Similar to say the Blender classroom scene? It may help with identifying issues that could be hard for the dev team to "reproduce". Issues could be as simple as a driver or hardware updates and having a baseline to compare would help with troubleshooting. At least in theory it makes sense.

    Can Enscape create a simple stress test scene?

  • I’m on 3.3 but I did try 3.4.icantremember.

    I mentioned this before (maybe even in this thread)

    In 3.4.x everything was working/rendering fine UNTIL I used some of my own proxied objects (beds, sofa etc) at which point loading and rendering times turned to molasses, using any Enscape’s own proxied stuff (trees, hedges etc) didn’t affect things.


    I also think that enabling DLSS changes how Enscape manages texture files quite dramatically … I noticed some unusual folders full of used texture files when I was cleaning 3.4.x from my system that I don’t think exist in 3.3.


    Now …. A bit of amateur guessing makes me think that ‘maybe’ materials with textures, bumps, displacements etc maps WITHIN a proxied object are not being processed properly/in a timely manner ‘if’ DLSS is on.


    Maybe AN answer is to use Enscape’s ’make your own assets’ feature but I have 100+ sofas, beds, flowers etc, a lot of which are edited versions of each others and I almost definitely do not have the original obj’s any more. So …. I have absolutely no intention of starting again.


    Everything above is guess work but if anyone else want to test my guesswork go ahead.

  • jtubb , we do not have a dedicated test scene yet, but this is also not something that would've helped us further too much, although I totally get the idea of course, and will think of something we may want to use in the future for easier troubleshooting.


    In this case, Paul Russam , thank you again also for all the valuable feedback - We were able to pin the cause behind this down further and it does really seem to be related to how models and their materials are being loaded when imported as proxies (your submitted .skp files were really helpful).


    We're looking into a fix currently so you'll also be the first to be kept in the loop once I have further news surely soon.

  • Paul Russam , jtubb , hbc_visual , jlo , m0nstertaco I'm happy to inform you that the specific cause behind this issue has been found and we're looking into resolving this issue through an upcoming service pack update or preview. I'll again keep you posted once again when it comes to the actual version releasing with this fix.


    I appreciate all of your patience and especially cooperation. :)

  • Paul Russam , jtubb , hbc_visual , jlo , m0nstertaco I'm happy to inform you that the specific cause behind this issue has been found and we're looking into resolving this issue through an upcoming service pack update or preview. I'll again keep you posted once again when it comes to the actual version releasing with this fix.


    I appreciate all of your patience and especially cooperation. :)

    This is great news! - are you able to share any details about the underlining cause?

  • This is great news! - are you able to share any details about the underlining cause?

    The long loading times were mainly caused by how we are (were soon) loading proxies/proxy materials into the scene. So in case you do experience this at the moment and are using the latest versions, you could temporarily import the files directly into SketchUp. I understand if that isn't feasible though with your project(s).

  • The long loading times were mainly caused by how we are (were soon) loading proxies/proxy materials into the scene. So in case you do experience this at the moment and are using the latest versions, you could temporarily import the files directly into SketchUp. I understand if that isn't feasible though with your project(s).

    Hi Demian


    Great to hear that you have pin pointed the issues :-) Good work! is the bug fixed in the latest preview (3.5.8), or is it still under developement?