Josh

BTW, your scale for this scene is far too big. I recommend using real-world units, where one meter = one unit space. Otherwise you may encounter unexpected problems. At the very least it will make your art pipeline problematic, because all your loaded models will need to be rescaled.

You're right, those values won't get set unless the agent has already been initialized by calling the Navigate() method. I fixed this for the next build. In the meantime you can just call these methods after a call to Agent::Navigate(). Be careful with the max acceleration value. I set both to 1000 and the agent started rubber-banding comically.

This guy is bragging about displaying 35,000 boxes at 60 FPS, but Ultra does the same thing at 1200 FPS: https://github.com/UltraEngine/Benchmarks#instanced-geometry-1

Here you go: //Create navmesh auto navmesh = CreateNavMesh(world, 512, 512, 512, 8, 8); //navmesh->SetDebugging(true);// visualize navmesh geometry navmesh->Build(); //Create player auto player = CreateCylinder(world, 0.4, 1.8); player->SetNavigationMode(false);// prevent player from triggering navmesh update player->SetColor(0, 0, 1); player->SetScale(10.f, 10.f, 10.f); auto agent = CreateNavAgent(navmesh); agent->SetPosition(0.f, 50.f, 0.5); player->Attach(agent);

Navmesh generation is working: Still testing this...

This topic is completed, thanks everyone for your participation.

For an RTS, you may want to use a navigation mesh: https://www.ultraengine.com/learn/CreateNavMesh?lang=cpp This will also handle large crowds.

I don't understand this part.

Mesh::Modify() already updates the bounds so there is no need to call it yourself. A much more intensive process is converting the vertex data into the format the GPU uses, which is more compressed than the vertex layout the user sees. However, this is all happening on the main thread, which gets up to 16 ms to execute before there is any problem, and your meshes should be updating in chunks of a limited size, so I think there's not much room for improvement here.

@Drew_BentonOur renderer and logic thread are separate, so you've got a full 16 milliseconds for your code to execute before you have to worry about performance of the ECS. In computing terms, this can usually be considered an eternity. However, I will watch these videos and maybe it will give me some ideas.

Do some tests to see how much mesh->UpdateBounds() takes. Use Microsecs() for best accuracy. Optimization is good but you should only optimize things that are slow. If something is not taking any appreciable time in the first place, then optimizing it is not worthwhile.

It looks like copying a vector does not copy the capacity, so there is no need to call shrink_to_fit: std::vector<int> t; t.reserve(1000); auto a = t; Print(t.capacity()); Print(a.capacity());

Yeah, there's no mem leak. At first it looks like the memory usage is going up like crazy but eventually it gets to a point where it just stops and stays even, after maybe ten seconds.

Actually, I am not even sure there's a memory leak at all. Memory usage is incrementing by 10,000 bytes every 8 seconds, but I am using a Vulkan memory management library that could be allocating more memory periodically for some reason...I will look into this further...

There is also a small memleak in the rendering routine. I'm trying to find it now, but it isn't bad. It works out to about 4 megabytes per hour.

I've reported this to Invision Power Services.

When you use std::function any arguments in that function stay in memory as long as the function does. In many cases this can create circular references.

I think this is weird design. You could call a class method from within the callback. If the same class might use different types of callbacks, then you would probably just create a class for your pick handling: class PickFilter { public: virtual bool Filter(shared_ptr<Entity> e) { return true; } }; class ColliderPickFilter : public PickFilter { public: virtual bool Filter(shared_ptr<Entity> e) { return e->collider != NULL; } }; bool Callback(shared_ptr<Entity> e, shared_ptr<Object> extra) { auto filter = extra->As<PickFilter>(); if (filter) return filter->Filter(e); else return true; }

Shouldn't you be able to store the function pointer in a class member?

Yes, and CreateThread will likely be faster as well, although it should not really matter because continuously creating a lot of threads is bad design.

For some reason STL can be quite slow in debug mode. I actually wrote my own sorting routine to overcome some of this in some intensive code. Writing a sort routine is hard, but I remembered how from my Blitz3D days because that language did not support anything like that. It took me back to my old "brute force" programming days where I would just write code until it worked.

If you are using a window, events are constantly being emitted. I am adding a FlushEvents() function in the next build, which will clear the event queue.

Updated 1.0.1 Fixed memleak in CreateThread function Small improvements to widget events and window cursor handling Replaced Sleep function with high-resolution version on Windows Correct RENDERSTART event will now be sent indicating failure on integrated graphics Added Widget::SetItemState() method, for selecting multiple items Added FlushEvents() function Moved EventQueue and EventListener classes into Core:: namespace Textures loaded from plugins will now convert RGB/BGR images to a valid format