Ultra Loading

[Alienhead]

I have no reason why or even a place to look for this bug but it takes about 4 to 5 mins to load Ultra Editor up now, since the auto - convertors were removed. Even a blank project takes about 4 / half mins to load Ultra up.

 

[klepto2]

I have the same issue and it started after adding a new gltf model (a larger one) into the project.

Now everytime the editor is started, it takes a lot of time. In the log i can see, that the model is reconverted everytime to mdl (including all textures etc).

[klepto2]

As a sidenote: The main reason for the long loading time (regardless the not wanted conversion) is, that the conversion of texture to dds seems to be extremely slow in the latest build. It takes minutes for just a simple 2k jpg. 

[Josh]

I think this behavior has been disabled now.

[Josh]

3 hours ago, klepto2 said:

As a sidenote: The main reason for the long loading time (regardless the not wanted conversion) is, that the conversion of texture to dds seems to be extremely slow in the latest build. It takes minutes for just a simple 2k jpg. 

Can you post a link to download this texture? I just tried one and it converted in a few seconds:
https://polyhaven.com/a/tiger_rock

[klepto2]

Ok, i think the bottleneck were some textures saved originally in png with a size of 4k. These textures take a lot of time to convert. jpgs of the same size worked fast. Will test it a bit more and provide you the textures which convert slow later.

[Josh]

Is this all good now?

[klepto2]

Converting textures alone, works flawless and only takes a few few seconds (even when the size is above 2k). But when converting a gltf model to mdl it is painfully slow. 

As you can see it takes more than 5 minutes for just 23 textures. (around 5 materials) and i have killed the preview exe to not disturb the process. With the preview exe running it doubles the amount of time.

[Josh]

BC7 / BC6 compression is extremely slow. If you try converting a 1024x1024 RGBA image to BC7 in Visual Studio, it will take about five minutes just to save. I had to use a special library from Intel with its own compiler in order to make it fast enough for practical use.

The images above say they are 21 MB each, so they are probably 4K textures with mipmaps? That compression performance is actually pretty great and I think I deserve a medal for this achievement. (Try compressing them in Visual Studio if you disagree! It will take you five hours.)

The reason we tolerate this is because BC7 gives us artifact-free compression. DXT5 compresses much faster, but has blocky artifacts.

DXT compression also causes a green tint effect with dark colors.

In any case, using 4K textures is probably excessive.

If you would like me to test further please provide a link to download a model, but what you are showing me seems like what I would expect.

[klepto2]

I know that it is expensive, and I usually use just 1k textures, which are much faster to compress. The model I have used is from Kitbash and "pipelined" via (KitBash3D) Cargo and blender 4.1 (gltf-export) (I downloaded the 4k by "accident").  The problem with these models are that they use up to 200 textures which is very much and this is why I experienced the long loading time (with normal models with baked textures or lower texture count you might not notice it)

I know that bc7 (and bc6) are expensive, and you have done a great job with it. But I would still suggest some important UX improvements on this part:

• The process should not block the editor 
• rule of thumb → if something takes longer than 100ms, show a progress screen with proper update/progress info
• if it is non-blocking, show progress in the status bar with information of what file is processed right now.

In general, for a better UX you should report more info to the user on certain actions.
Just a few samples where this might apply:

• Model/Texture-Conversion
• GI-Building
• Scene-Loading