Posts by burggraben

REMINDER! If you encounter any issues with Enscape (e.g. crashes, installation problems) or your subscription please reach out to our dedicated support team directly through the Help Center or by using the Support button as detailed HERE! Thank you for your understanding.

    Nice to hear that the problem has been resolved! We will provide more information about the washed out colors when we have something to share :)

    So I tested it some more and I can live without the eye calibration and just run the headset on SteamVR instead of the VarjoOpenXR engine. The only major problem left with 3.5 are the washed out colors. Does this affect every hearset or just a few? Do you need me to provide any log files or are you able to reproduce it on your end?

    Hmm does it perform the eye calibration / pupil distance every time? Did it remember the previous setting before doing the workaround?

    In 3.4 we didn't use OpenXR; everything went through SteamVR again. Only in 3.5 we have the ability to use Varjo's runtime directly but this causes problem and we have to launch through SteamVR again.

    Yes, by default the Varjo headset does this every time the headset is put on. Makes it really convenient to switch users. For a single-user headset you can set it to remember the eye calibration permanently. I'll test again today if it really is the case that it doesn't do eye calibration when set to SteamVR, or if it just didn't do it last time because it recognized I am the same user. Might have been a false alarm, if 3.4 always used SteamVR.

    If eye distance calibration works with SteamVR, I am not even sure what the benefits of using VarjoOpenXR would be. I guess maybe eye tracking / foval rendering (if the app would support it). In that case - I'll just live with using SteamVR as runtime.

    @Demian @Enscape


    Because of the bug above I have seperate 3D view for Revit only and for Enscape only. But I found that this is a good practice in larger project anyway, even if this bug wouldn't exist, because Revit and Enscape have different optimal visibility settings.

    *However*, it is cumbersome to manage the fact that some 3D view should never be opened in Enscape. Currently I am prefixing the name of Revit-only 3D view with something highly visibly like X___ to make sure the go to the bottom of the list in Enscape's View Management. It would be great if we had a way to exclude certain 3D models from Enscape's View Management. Or maybe the other way araund, explicitly tag the 3D model which are for Enscape and only those show up in View Management.

    Nice to hear that the problem has been resolved! We will provide more information about the washed out colors when we have something to share :)

    Works perfectly as a workaround. I guess it would be nice if you would add VarjoOpenXR to your whitelist eventually. VarjoOpenXR did seem to work just fine with Enscape 2.4.


    But it work fine for now. Not even sure what I am missing by setting is to SteamVR instead of VarjoOpenXR. It seem to not do the eye calibration / pupil distance measurment in when putting the headset on and I guess eyetracking isn't available either (but almost no software supports that anyway).


    To understand more about this problem could you please:

    • Close SteamVR, uninstall 3.4, install 3.5.1, restart your PC, open 3.5.1 and enter VR. Does the problem persist?
    • Set the SteamVR runtime as the default OpenXR runtime instead of the Varjo one. In SteamVR settings you will have to enable the advanced settings and navigate to the Developer tab where you can set the SteamVR as the default OpenXR runtime.


    Reinstalling, restarting doesn't make a difference.


    Seeting the runtime to the SteamVR runtime allows me to enter VR mode in 3.5.1. the Varjo runtime does work for 3.4, but not for 3.5.1.

    I can confirm that the thumbsticks work are expected in 3.5.1. Now if only the world wasn't washed out, I could jump onto the 3.5 bandwagon. :)

    burggraben I just tested 3.5.1 and the Index controllers do not need a click on the thumbstick to move around and up/down. Maybe the scale of your project it too big and the movement seems very slow?

    Thanks for checking. I actually meant the washed out color bug(see screenshot in previous post above), not the stick move bug. I wanted to got back to 3.5.1 to test it again, but I might have used 3.5.0 last time. In 3.5.1 I it is stuck at "Searching for VR headset". Going back to 3.4 without any other changes fixes it.


    I use a Varjo Aero for amazing visual clarity + Valve Index controllers. The relevant part of my log is probably this:



    Did you introduce an OpenXR whitelist in 3.5.1? If yes, please put the Varjo the Varjo runtime on it, it works just fine in 3.4.

    Also maybe an error dialog for unsupported OpenXR runtime would be nice instead of just getting stuck at "searching for headset"


    I am stuck with 3.4 for now.

    Hey burggraben thanks again for the report. We did manage to reproduce, however the release timeline didn't allow us to ship a fix with 3.5 anymore.
    I'm sorry about that, but this will be fixed in one of the upcoming updates for 3.5

    Thanks Clemens! Another bug report (you probably aeady know, but just to make sure): In 3.5 I have to push down / click the joysticks on the Index to navigate around. In 3.4 it was enough to move them left/right up/down. In 3.5 left/right up/down + click.

    Also, here is a bug report about washed out colors for the latest alpha. In 3.5 in VR the colors are very washed out. It is definitely a software issue, because when the desktop is viewed in VR, then the colors are not washed out. See VR screenshot below, with the VR view in the background with washed out colors and a desktop overlay without washed out colors. Problem does not exist in 3.4.


    Guys, this bug still exists in the release version of 3.5. Have to keep using 3.4 until this is fixed. Did you manage to reproduce?

    burggraben just a heads-up for this: We've adopted the VR teleportation behavior as suggested. Feel free to give it a try in this new Preview :)

    Tested and works great. I really like the fact that there is now no haptic feedback when teleport is successful, but there is a haptic feedback when the teleport ist unsuccessful. That is exactly the way is should be as on a sucessful teleport I have visual feedback anyway, but on a unsuccessful feedback I have no visual feedback, so the haptic feedback is actually helpful.


    Can I suggest one more thing? I am frequently on large sites that include the surroundings of a building. Typically a 4000x4000m square. This is useful because you can model the view you get out of a projects window. Sometimes I end up on the other end of it and need to go back to the building.

    In 3. 4 I exploited the bug that teleports are executed in quick succession when the trigger is held in a certain dead zone, between no press and full pressed. It would be much more intuitive if Enscape would repeatedly execute teleports when the trigger is fully pressed. Just the same way a keyboard works. To type a single "!" I press the trigger once. To type "!!!!!!!!!!!!!!!!!!!!" I just keep the key down. Please consider doing the same for teleports.


    Also, here is a bug report about washed out colors for the latest alpha. In 3.5 in VR the colors are very washed out. It is definitely a software issue, because when the desktop is viewed in VR, then the colors are not washed out. See VR screenshot below, with the VR view in the background with washed out colors and a desktop overlay without washed out colors. Problem does not exist in 3.4.


    Thanks for listening. Index constrollers would be nice, but are not an absolute must. Getting rid of the teleport vibration is way more important. Please don't make it just "less distracting" as in a more subtle vibration. It's simply not needed at all. I can't think of a single VR application where teleporting causes a vibration feedback in my hand. It's completely counter intuitive. I already have visual feedback that my teleport suceeded, I simply don't need a vibration in my hand. If I quickly jump around a model, it's like a constant vibration in my hand.


    If you really want to make use of hand vibrations you could add collision checking to the model and vibrate the controller when my hand collides with furniture to make VR feel more real.


    Hey burggraben thanks for your feedback! Vive index controllers will be shipped after the 3.5 release, we've updated Enscape to the new OpenXR standard, which unfortunately doesn't allow us to automatically retrieve the controller models anymore, so we have to build & integrate these manually for every controller type on the market, which takes some time.
    We'll reconsider the vibration feedback on teleport to be less distracting!



    Actually I am going to correct myself here. There IS a vibration feedback in 4.4, but it is so subtle that it always registered at "button pressed" feedback. The vibration in 3.5 is way to strong. Whiel we are on the topic of teleporting: Sometimes when pressing the trigger I teleport multiple times in quick succession an end up on the other side of the universe involuntarily. Easily reproduces when squeezing the trigger slowly. There is a "zone" in the trigger which registers as press and the code fails to check if the trigger was released again before firing a second "pressed" event. Easily fixable.

    Hey burggraben thanks for your feedback! Vive index controllers will be shipped after the 3.5 release, we've updated Enscape to the new OpenXR standard, which unfortunately doesn't allow us to automatically retrieve the controller models anymore, so we have to build & integrate these manually for every controller type on the market, which takes some time.
    We'll reconsider the vibration feedback on teleport to be less distracting!

    Thanks for listening. Index constrollers would be nice, but are not an absolute must. Getting rid of the teleport vibration is way more important. Please don't make it just "less distracting" as in a more subtle vibration. It's simply not needed at all. I can't think of a single VR application where teleporting causes a vibration feedback in my hand. It's completely counter intuitive. I already have visual feedback that my teleport suceeded, I simply don't need a vibration in my hand. If I quickly jump around a model, it's like a constant vibration in my hand.


    If you really want to make use of hand vibrations you could add collision checking to the model and vibrate the controller when my hand collides with furniture to make VR feel more real.

    Instead of my Index controllers I now see the Vive controllers in this preview. A step back, but I can live with that.

    However, on top of that I now get a super annoying vibration now every single time I teleport. It's not even a good vibration, it gives me a error-beep kind of feeling, like Enscape is trying to warn me. Plus, it is drains the battery of my right controller. Please let me turn that feature off. Please.

    The cause will be in the GPU because the passes that use rays will be slower but it will also be visible in the CPU graph due to SteamVR's additional synchronization in very low FPS scenarios."

    Sorry but this doesn' make any sense at all on a technical level. There are at least two things that don't make any sense.


    1 As you can see from my video the GPU is bored. Total GPU usage as a percentage is low and individual frame time on the GPU is fantastic. The problem is the CPU and the CPU should *not* be a problem when displaying a trivial model with 50x50 holes.


    2 SteamVR "additional synchronization" (whatever your dev refers to) would not cause this to be "visible in the CPU graph". Windows task manager also shows a crazy 90%+ CPU usage after a while of looking at the model.


    I really mean no offense. Really, from my heart. But it feels like your developer is guessing where the problem is. In my personal team - at this point - I would elevate this issue to a senior developer.

    Hi Demain,


    I can try optimizing the model, but I have no control over the specific triangulation model used. This model isn't modeled in a software like 3ds Max which would give you total control over optimization. It is a typical architectural workflow where models are created in Autodesk Inventor and exported directly as a Revit family. This is a BIM-specific workflow and intented by Autodesk to be used as a BIM-workflow. It suppors creation of 3D models for graphical purposes, but also allows to add BIM-data to models. In particular BIM-data like ducts and pipe, etc.

    Guess what one of the most important shapes in BIM devices is? Correct, it's a circle. Every pipe, every duct that I model is based on a circle. After creating the circle I tell Inventor it is a hot water pipe and Inventor exports is in a certain way that I have no control over on the triangulations level, but which is specifically intented for BIM and Revit.


    I would suggest that the Inventor > Revit > Enscape workflow is one which should be supported in Enscape.


    The optimization your developer suggest is a workaround at best. And - judging from the picture - it would only reduce the triangles by a factor of 6. We're talking about a truly trivial amount of triangles to handle for a modern PC with a 4090 graphics card and high-end CPU. Rather than hand-optimizing millions of circles in thousands of models after the Autodesk inventor export, I would much rather devote my resources to fixing the bad implementation in that proplematic secret library you're using.


    Like I said if that an open source library I will gladly devote developer resources myself to it.

    Thanks so much for digging deeper into this. Unfortunately it happens with several of my custom models and I can't pin point exactly what to avoid.


    Two questions:

    1 --

    Is this library which is using the CPU to do raycasting, avoided if I enable RTX in VR and do the raycasting on the GPU? (Probably not.)


    2 --

    Can you name the library? Is it open-source or proprietary? I am willing to give up my rights to the latest Revit model I sent you, so it can be reported as a bug upstream. Since your library probably wont work with Revit natively I am even willing to export in a format that reproduces it for the upstream library.

    If it is an open source library I am willing to dedicate dev resources to have it fixed.


    Yes I will have a fix developed and pushed usptream to the library if possible. It is that important to me.