Posts by landrvr1

    Tnx Demian. The problem is really apparent on highly reflective wood and stone, of course. The specular reflections are just not nearly accurate enough and end up looking more like blobs than anything in the real world, lol. In Vray/Corona/etc it's pretty common place to disable specular on most interior architecture projects. Product studies are usually the one area when folks still use it, but I rarely see it done with archviz. Just an opinion, of course! Unreal and Unity both have more than one place to disable and/or tightly control specular reflections.

    Sean, I also attempted with the last formal build and new preview build to add the code that disables RTX:


    -------

    You should be able to disable RTX for recent versions by adding the line:

    rtx_0

    to the UserPref.cfg file which you can find at:

    C:\Users\%USERNAME%\AppData\Roaming\Enscape

    --------


    The crashes still occured - even after completely removing Enscape using the Windows program dialog, and then starting with a fresh install.

    Hey Sean/Demian, this is a copy of the email text I sent to Peter this morning; as he was asking similar questions:

    -----

    Hey Peter,

    The crashing occurs after the Enscape render window attempts to open. The progress bar completes, and it looks like it's getting ready to fire up the view, but then SketchUp crashes. No SketchUp crash error message appears. The program simply terminates. I am able to access all other Enscape setting dialog boxes such as General Settings, Visual Settings, etc. Enscape itself doesn't seem to have a problem loading, only when it's time for the render window.

    It's the same with the EXE demo file on your website with the 2.7.0 build. The exe is loading, but at the end of the progress bar journey the exe terminates.

    This happens even on a basic NEW SketchUp scene with no objects (even after deleting the human figure and starting Enscape render window). I'm using 2019.

    There's no specific, identifiable pattern that causes the crash to occur that I've been able to find. If I open SketchUp, then do a file load, the crash occurs. If I double click on the main project file and bypass the initial SketchUp splash screen, the crash occurs. I've tried turning off all layers in my scene except a 'blank' layer, then starting up Enscape render window, but still get the crash. I'll be willing to try anything you'd like, just let me know.

    I'd be happy to send you a scene file but, like I mentioned, this happens even with a default starter scene.

    Let me know if you need more info!

    Tnx

    ------

    Sean, let me know if you need anymore info...

    Tnx Demian. Fortunately I've a long way to go because the drive gets full, but in a year from now.....? It would be great to have the option of specifying where those temp files are located. In that respect I could simply keep that folder within the project folder structure - or a central location for bitmaps that get used over and over.


    I've noticed some odd behavior with respect to light leaks: If you use a large ground plane you'll get light leaks. This happens regardless of whether or not you use a single, large plan or a series of connected planes.


    In my example, the ground plane is 36" thick. The light leaks happen regardless of what kind of material is applied. The leaks happen whether I'm right next to the object or far away.


    The box shown is comprised of 4" thick walls, floor, and ceiling.


    I have another project in which this phenomena is only happening on the top floor of a 3 story building. I suspect this is because I have full architecture all around some interior rooms in those lower floors, and all that architecture is acting as GI light leak blockers. In fact, when I simply duplicate that massive ground area and place it over the stacked white boxes, the light leaks vanish.


    If this is simply a known limitation of Enscape, let me know. However, I'm not sure how anyone could do large scenes with this issue.....??!

    I don't think it has anything to do with the preview version. The most likely culprit is that your GPU is underpowered. What I'm seeing there is the exact same thing that tends to happen in non-ray traced, 100% raster based engines such as Lumion or Twinmotion. In order to get rid of that happening in those platforms, you have to do a fair amount of GI tweaking - which isn't really an option with Enscape because you shouldn't have to....

    It's my understanding that Enscape - like all ray tracing enabled engines (realtime GPU or offline CPU) - uses a fine balance of classic raster vs ray tracing. This is especially the case with GI/shadows/AO. I don't know precisely how Enscape works, but if your GPU isn't powerful enough than Enscape will probably keep defaulting to raster based output.

    When I import a model as an FBX, and a bitmap folder is created, I don't understand why Enscape is creating a duplicate copy of that bitmap in a temp folder within AppData? That temp folder is filling up fast. Why the temp folder creation and duplication? Is there a setting to simply reference the main bitmap created? Tnx!

    Agreed. Are you aware of the Oculus developer tool which allows you to easily increase the resolution when using the link cable?


    On my phone now but if you Google it you can find how it works. It is a simple hack.


    Be aware that after a restart your computer you will have to re-enter the higher supersampling resolution again. Worth the hassle though.

    Sweet! Tnx for that. Gotta try it. Question: Do you know how to display the framerate in the Quest?

    NICE! Can you describe your scene? Poly count? Complexity? I can certainly appreciate any approach which is unteathered, but with clients we need a rock solid platform that's replicable/reliable. Repeat engagements with the same clients must be consistent and worthwhile. The hackable approach to wireless seems fun, but I'm going to avoid it for now. The biggest pitfall is going to be a drop in framerate. Remember, motion sickness sets in with pretty much anyone when those FPS fall below 60. A hacked wireless solution is just asking for trouble, lol.

    Of course, if all you're showing is a simple model....

    Would love more details on your scene.

    I'm much more interested in true sideloading of a file onto the Quest - not streaming. In that case there will definitely need to be compromises in scene size and visual fidelity. Of course, that's still a crazy hack solution, lol.