Josh

Adding the prefab works now, but still skipping if the prefab is in a map file...

At the moment this isn't really actionable information. What is different about your demo and the performance benchmark apps? Are you constantly streaming geometry in?

Can confirm, here is a test file that shows the problem test.zip

I've poked around in the file but I can't find anything that's unique about it that would be causing a problem when many other animated glTF files load correctly. There is a problem in my loader, because both Windows Object Viewer and the Babylon.js glTF viewer both load it correctly, but I don't know how to solve it. I recommend running this through Blender or whatever other method you were using that makes it export a model Ultra can load correctly. I am attaching the model here for future investigating, but I don't plan to continue working on this for now. Human_2.zip

If I drag him into a viewport, then scale and rotate him he actually looks fine. However, the moment animation is applied, he turns into The Thing:

Vulkan validation layers were quite slow, and there's also more code being executed in the driver in OpenGL. So the results you are posting right now are not surprising.

Spiderpig game model.

Typically your file format should start with some sort of identifier like "SPGM" for the first four bytes or so. This is usually how binary file formats are identified.

Preview.exe has been rebuilt and may work better now.

This may be fixed in 0.9.5 now.

Problem is resolved in 0.9.5, on the beta branch.

A fix for this is available on Steam now.

I just checked and during the first render there are no cameras being used. I get a black screen until the program switched over to the main menu. I cannot find any cameras being created in loadingWorld. I think you want this: // LOADING loadingWorld = CreateWorld(); loadingUi = CreateInterface(loadingWorld, font, framebuffer->GetSize()); loadingUi->SetRenderLayers(2); loadingUi->root->SetColor(0.5f, 0.5f, 0.5f, 1.0f); float labelHeight = float(framebuffer->GetSize().y) * 0.2f; int centerX = float(framebuffer->GetSize().x) * 0.5f; int centerY = float(framebuffer->GetSize().y) * 0.5f; auto loadingLabel = CreateLabel("LOADING...", float(framebuffer->GetSize().x) * 0.05f, centerY - labelHeight * 0.5f, float(framebuffer->GetSize().x) * 0.95f, labelHeight, loadingUi->root, LABEL_CENTER | LABEL_MIDDLE); float fonstScale = labelHeight / 14.0f; loadingLabel->SetFontScale(fonstScale * 0.5f); loadingCamera = CreateCamera(loadingWorld, PROJECTION_ORTHOGRAPHIC); loadingCamera->SetPosition(float(framebuffer->GetSize().x) * 0.5f, float(framebuffer->GetSize().y) * 0.5f, 0); loadingCamera->SetRenderLayers(2); loadingCamera->SetClearMode(CLEAR_DEPTH); //CAUSES AN ISSUE loadingWorld->Render(framebuffer);

I am mostly concerned at the prospect of the window client area changing size while rendering is happening on another thread. Will need to get out another monitor and test this some more...

This and so many other things...

139 is TEXTURE_BC4. The engine currently does not account for this format, but I just added this. The displacement map on the server does not use this format, and when I ran the example this format was never used. However, you might have an old copy of the texture in your local cache that uses BC4, maybe. You can delete the folder C:|ProgramData\Ultra Engine\WebCache to force the app to re-download the textures from the server.

No, it just loads data from a stream which may not have any file path associated with it at all.

Mark as solution when you feel it is resolved.

Do you mean OpenGL?

This makes sense. The button is being stored as part of the emitted event. You can clear the events in the main loop to get rid of them like this: //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { while (PeekEvent()) WaitEvent();// Clears event queue if (window->KeyDown(KEY_SPACE)) { Print(int(btn.use_count())); EmitEvent(EVENT_DATA, btn); Print(int(btn.use_count())); } world->Update(); world->Render(framebuffer); }

This file mimics the beginning of a Leadwerks MDL file. I added some more checks that prevent the loader from trying to load this as such.

The assert statements were removed entirely, and the error you got will now include the texture pixel format, which could tell us which texture is failing. I suspect it is the unsigned integer RGBA texture, and I think the problem has to do with texture completeness requirements prior to being used as a bindless texture.

Fixed. You may see more than one of these events emitted in the current build, but at least one will be.

0.9.5 Some window and graphics initialization fixes.

I did get the DestroyWindow error sorted out.