Josh

Interfaces that are used in 3D graphics do not have a window to return, since they were not created on any window.

I believe I have solved the core issue but am waiting to confirm it. It would be nice to have an example that that easily demonstrates the problem.

The core problem of this issue is now solved and will be included in an upcoming update. I never did get the nonuniform feature working. I am not sure if it even works, and I am not sure if it has a negative impact on performance, and I just don't care,

Hi, can you please upload a map that demonstrates this problem? I tried to recreate it with the attached map but I don't know how. start.zip

Yes, that is a bit more clear, thank you. I am working on something that I believe may solve this issue automatically.

Are you saying that the editor crashing is related to the preview app not closing? How do you know these things are related?

Updated the editor. Editing should be a bit snappier now, especially terrain.

Probably?

You should be getting big 2+ GB updates on Steam.

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.