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.

Looks like a great start! There is a camera command to enable the screen-space reflection effect: camera->SetSsr(true); You can set this in the third-person controls component code after the camera is created.

Reported to AMD: https://community.amd.com/t5/general-discussions/opengl-bindless-texture-crash-in-driver-24-10-1/td-p/719064 https://github.com/GPUOpen-Drivers/AMD-Gfx-Drivers/issues/27 In the meantime I recommend reverting to driver 24.7.1.

Okay, it looks like in the latest drivers these commands cause problems if they are used on samplers that come from bindless texture handles: textureSize textureQueryLevels I think I just need to encode this information in the light entity data and remove these calls...

PBR shader family crashes, but unlit shader family seems to work correctly. The error is in the driver, no OpenGL errors occur. Commenting out RenderLighting in Shaders/PBR/Fragment.glsl prevents the crash... #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { auto displays = GetDisplays(); auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); auto framebuffer = CreateFramebuffer(window); auto world = CreateWorld(); auto cam = CreateCamera(world); cam->Move(0, 0, -2); cam->SetClearColor(0.125); auto box = CreateBox(world); auto mtl = CreateMaterial(); auto fam = LoadShaderFamily("Shaders/Unlit.fam"); //auto fam = LoadShaderFamily("Shaders/PBR.fam"); mtl->SetShaderFamily(fam); mtl->SetColor(0, 0, 1, 1); box->SetMaterial(mtl); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { box->Turn(0, 1, 0); world->Update(); world->Render(framebuffer, true); } return 0; }

Same result if I revert the engine to 0.9.7...

Installed 24.10.1 and I get the same result you described. Testing further...

Currently I am on driver 24.7.1. Updating now...

Is this all good now?

I added a prompt when another model format is saved and a collider is present.

Thanks, I am sorry you lost some time figuring that out. Originally Ultra was going to just use glTF as its main file format. However, it became clear over time that a proprietary custom format would be better suited. Colliders were originally a separate file, but now they are part of our custom file format.

The glTF format supports multiple UV sets. The texture coordinates passed to the fragment shader are a vec4, so the second set is included by default.

Simply unrolling the loop raised the framerate to 153 when MAX_MATERIALS is set to 4. I had a strange feelings loops were slow but this is really surprising! https://gamedev.stackexchange.com/questions/147206/glsl-shader-performance-reduced-by-loop

Simply restructuring the code brought the framerate back up to 193 / 127 when MAX_MATERIALS is set to 1 and 4. I would prefer for the extra materials to have no impact at all when they are not in use. Shader code performance often behaves in unpredictable ways. More testing...

I think the fragment shader does not like the fact I am declaring an array of four materials. I probably need to restructure it so only one material variable is used.

The difference seems to be entirely due to the way the PBR shader is coded. If I look straight up to try to fill the screen with the sky, the framerate in my build of 0.9.8 is a little bit higher than 0.9.7, so it seems there is probably nothing in the C++ rendering code that is wrong...

Yes, it is much lower. I expected the material painting to create a performance penalty, but not such a big one. Testing the default start scene from Ultra 0.9.7 on a GEForce 1080 0.9.7: 194 FPS 0.9.8 with MAX_MATERIALS set to 1: 169 FPS 0.9.8 with MAX_MATERIALS set to 4: 37 FPS Material painting is worth having reduced performance, when multiple materials are in use, but I would expect something more like a 20% reduction in performance, not nearly as much as we see here, and it's also not in use in this scene so the impact should be zero. More testing...

I found the cause of this.

Red means the files do not exist in the project folder.

It looks like your project is not using the current shaders?

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