Jump to content

Josh

Staff
  • Posts

    22,901
  • Joined

  • Last visited

Everything posted by Josh

  1. 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
  2. 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:
  3. 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.
  4. 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.
  5. Preview.exe has been rebuilt and may work better now.
  6. Josh

    Thumbs

    This may be fixed in 0.9.5 now.
  7. Problem is resolved in 0.9.5, on the beta branch.
  8. 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);
  9. 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...
  10. 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.
  11. No, it just loads data from a stream which may not have any file path associated with it at all.
  12. Mark as solution when you feel it is resolved.
  13. 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); }
  14. 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.
  15. 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.
  16. Fixed. You may see more than one of these events emitted in the current build, but at least one will be.
  17. 0.9.5 Some window and graphics initialization fixes.
  18. I did get the DestroyWindow error sorted out.
  19. I think getting integrated graphics to work will take longer and it is not currently supported, although we are a lot closer now than we were before.
  20. Lunch has just finished. Now I am uploading...
  21. This is interesting. There is some high-intensity code in the terrain materials building system. I was at one point going to move this to a compute shader because I thought it was too much for the CPU. However, once I had rewritten the algorithm to work with shaders, it was then running fast enough that I kept it on the CPU. (I actually had to write my own sorting code to make it work.) There are two assert statements in the algo that did not have any messages. Simple adding some text in the second argument to Assert was enough to slow down the code to a crawl, which is what you saw. This is not normally something you need to worry about, but the Assert statements were being called more than a million times. I will upload a new build after lunch. You are probably asleep right now.
×
×
  • Create New...