Josh

Update for this is available now.

Another update, just fixes a small memleak issue reported by @klepto2

I think it is. I just checked with the source build. You are opted into the beta branch on Steam, right? The current build number of the editor on Steam is 485.

Okay, two more things I found: I added a global list of entities, but since it stores weak pointers it won't get cleaned up until the user calls GetEntities() if large numbers of entities are deleted. I added an internal call to this method in the world Update method, so it will always trim the list of dead entities. Your example is adding entities in faster than the rendering thread can keep up. The entities are being added each frame, but the rendering thread keeps them around a little bit longer, so it is being overwhelmed. There is a renderable entity limit of 65536 (some entities take up more than one slot, so it can be a little less than this). This is because the engine stores entity IDs as unsigned short integers on the GPU. There is a tendency for things to grow a little bit when numbers of items fluctuate, due to the nature of how memory resizing is implemented. STL vectors for example get bigger when they need to, but they don't release memory if the are resized to a small size, with the idea they may need to grow again. In the same manner, I don't ever make GPU storage buffers smaller, I just let them grow as needed, and if the application needs less space, I just keep the extra memory as a reserve. As long as the memory display in VS studio looks flat after a few moments, then you are good. I will check to see if there is anything else I can improve and then do another build and upload these fixes. #include "UltraEngine.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280 * displays[0]->scale, 720 * displays[0]->scale, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a world auto world = CreateWorld(); auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->Move(0, 2, -8); shared_ptr<Entity> main_instance = CreatePlane(world, 10.0, 10.0, 256, 256); //shared_ptr<Entity> main_instance = CreateModel(world); vector<shared_ptr<Entity>> instances; int n = 0; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { instances.clear(); ++n; if (n == 100) { n = 0; for (int i = 0; i < 100; i++) instances.push_back(main_instance->Instantiate(world)); } world->Update(); world->Render(framebuffer); window->SetText("MEM: " + String(GetMemoryUsage() / 1024) + " kb"); } return 0; }

With this simple example that excludes the entities from any world we can see the mem usage is very stable. #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(); shared_ptr<Entity> main_instance = CreatePivot(nullptr); vector<shared_ptr<Entity>> instances; while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { instances.clear(); for (int i = 0; i < 100; i++) { instances.push_back(main_instance->Instantiate(nullptr)); } world->Update(); world->Render(framebuffer); window->SetText("MEM: " + String(GetMemoryUsage() / 1024 / 1024) + " mb"); } return 0; }

Okay, I can confirm double the meshes were being drawn as needed. This was an easy fix. I am trying to track down the source of the memory increase. It does not appear to have anything to do with the rendering thread.

The number of instances drawn will normally be higher than the number of instances that exist in view: 1 depth prepass + 1 main pass + 3 for each directional light. That would account for about 500 instances, and your app is reporting 1000. It's probably reporting that number incorrectly based on some stuff that never gets drawn, but I will investigate. I can confirm the memory increase. It should not be too hard to figure out what is failing to release.

General update with recent fixes. Added some additional debugging information in rendering thread. Temporarily removed "Save as Prefab" popup menu in order to focus on graphics and bug fixing.

Okay, thanks, and this is version 0.9.4 of the editor, right?

Hi, what GPU do you have?

Does this still happen if you remove all lights from the scene?

Using a new project and the current beta branch on Steam, I copied this code into the main.cpp file, ran it, pressed the enter key about 10 times to reload the map, with no errors. https://www.ultraengine.com/community/topic/63031-render-crash-if-recreateworld-same-world/?do=findComment&comment=305162

Fixed, an update will be available later today.

Yeah, it should work if you use CreateBufferStream to create a stream. This command does not require a buffer as an argument, and it is better not to provide one. Then, before saving or loading call stream:Seek(0) to make sure the file position is at the beginning of the file.

I believe this issues is solved. Please let me know if that is not the case.

I am changing it so that event listeners store a weak pointer to an extra object and automatically self-delete if an extra object is defined but gets deleted elsewhere.

I updated pro build on Steam this morning. You sure this is happening with the latest build?

Very convenient!

I was able to easily fix this and will have an update for you later today. Thanks for your help!

That is interesting. I assumed the camera in Windows Object Viewer was always the same scale. I will take a closer look at this after the live chat is done.

The problem here just seems to be that the model is really big. In the glTF spec it states: So the best solution is to point out to the maker of whatever software you are using that the glTF units are always in meters so that they can fix the error. Since we have an open specification that describes exactly how things work, we don't have confusion about who should fix what. We all just conform to what the spec says. If you know the name of the top-most model, you might be able to manually edit the gltf file in a text editor and insert a scale property, since it's just a JSON file.

It looks like @Dreikblack has managed to isolate this issue. I am working on the solution now:

3ds max does support glTF: https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-5B4C8EC2-2230-4F9F-B3C6-48D9E347E37D https://help.autodesk.com/view/3DSMAX/2023/ENU/?guid=GUID-7ABFB805-1D9F-417E-9C22-704BFDF160FA Maya doesn't appear to support it. There are some third-party exporters, but I don't know how well those work. An FBX to glTF converter is included in Ultra, and it should just work if you drop the FBX file in your project. The main problem with FBX is it doesn't support PBR materials, so you wind up having to adjust a lot of materials after importing the model, whereas glTF just works.

Awesome, thank you, I can produce this error very easily. Now to solve it...