Posts by Alexander Devaykin

    Hello Setsudo


    Currently loading textures includes three time consuming processes:

    1. Find the best distribution of the textures into a limited number of arrays (texture size and pixel format must be equal for all textures in an array)

    2. Scale/convert textures to assign to selected array

    3. Upload to GPU


    To accelerate the first step, you might want to have textures grouped by the size and format (number of channels). This way the best distribution may be found faster. This is one of the most cheap steps, so you will probably not win much time here.


    For the second step the best case would be to have textures in the power of two resolution and grouped by size/format. This way resizing and converting to a matching size and format will be skipped for the textures that match the chosen storage arrays perfectly. Maximal texture size is currently limited to 2048x2048px. This is where you can win the most.


    For the third step you cannot do much except for reducing texture sizes. If you have to upload 1000 textures, you will have to wait anyway.


    This information is valid for version 2.5. In furure releases we may introduce a bit more clever way to choose texture sizes to lose less quality and use less memory. If particular OpenGL features support will grow, we may get rid of grouping textures in arrays completely. So again, the information above may not be valid for the future releases.


    To sum up:

    Implementing powers-of-two image sizing

    Will help, especially if lots of textures have the same size and format.

    Rudimentary image atlas-ing to the extent that SketchUp and Revit would support it.

    Will help, but be aware that max texture size is 2048x2048 currently.

    Implementing a maximum image size 2k or 4k etc

    Yes, 2k is the max size.

    Can I make these graphics some factor of the real world size and expect them render perfectly sharp?

    No. But it may change in the future releases.

    What's that look like in practice?

    In future releases (not 2.6) Enscape will probably choose texture size taking into account world size.


    I hope that helps.

    Hi Ryan

    we cannot reproduce the problem so far. I think the fastest way to fix it would be to have an example project file from you so we could test it on our hardware.

    It must not be exact that model - if you could create a minimal reproducible example, it would be great.


    By the way, driver version 19.Q3 for your GPU exists already.

    When I check "show safe frame" it never works and the Preview feature before render that would show the safe frame works 50% of the time. I suppose this is a bug?

    should have been fixed in the latest preview (released yesterday afternoon).

    Hello SSB1995

    Please send us feedback via feedback button on Enscape panel. Please mention your forum post.

    We will have a look at what exactly version do you use, why preview versions crash and will probably ask you for the sample project where you have broken materials.


    Next preview will be released soon with some bugfixes. If you wish you can wait for it first to see if your problems are fixed there first.

    The new tracking system is far easier to setup, but we have run into a little more precision issues when it is up and running unfortunately.

    I think it also heavily depends on the tracking cameras resolution. Try to precise track vertical position based on an horizontal edge of a table two meters away from you with the camera resolution you see when calibrating device - no wonder there is some imprecision. I also think it was not the main purpose of device to have 1mm precise tracking. It is enough to have stable tracking with some small differences between sessions for 99,9% of use cases.


    though it seems like the sort of thing that should be provided with Oculus's SDK as a developer tool

    Fun fact is that the new controllers were not provided by the SDK for a long time after device release - one always has got old models. New models will be in the next preview.

    Thanks for the info! To me it sounds like a hardware/driver issue. Enscape does not know anything about display configuration - we only know that we've got particular GPU and start using it for rendeing. The only reason to crash I can imagine is that the display has e.g. 4k resolution so GPU is out of memory when Enscape starts fullscreen. But to prove this guess we need logs :)

    I tried to follow your process but unfortunately I can't send you logs when Enscape is freezing at 95% cause sketchup window is also frozen.

    You don't need to have Enscape window runnign to send logs - return to SketchUP (or open it again if it was closed together with Enscape) and click Feedback button on the panel. But you will have to repeat the runs in the same order as mentioned in my first reply so we could be sure that the latest log file belongs to the frozen Enscape and pre-latest to the normal-working case.

    Hi,


    I got the same issue but because of my new dual screen.

    I figured out that when I"m running Enscape with my LG monitor plugged on my laptop, Enscape is freezing at 95%. When I"m unplungging the monitor it works fine.

    Did not find out the solution for that yet.


    Thanks for your help.

    That's an interesting observation. Could you please submit feedback with logs as follows:

    1. Run Enscape with unplugged second display

    2. Run Enscape with plugged-in second display, having it freezed at 95%

    3. Send feedback including logs and mention your forum user name in the comment.


    It is important to not run Enscape after (2) so we could be sure the latest log file is from the case when Enscape freezes and the pre-latest is from the normal run.