Josh

This is added now.

I have updated the attached file. The email that gets sent out will now refer to that page.

Ah, here it is: https://www.ultraengine.com/community/clients/purchases/437-nature-starter-kit/

How did you navigate to that page? Can you show me a link to it? I could not find it.

Fixed

Does that mean the current build works correctly?

Hi, unfortunately this is not enough information for me to proceed. It is not clear what the exact steps are that I need to take to produce any error. I can try to guess what you are doing, but I am unable to recreate any problematic behavior based on the description.

Hi, unfortunately there is not enough information for me to proceed. I will need your scene in order to test it.

Thank you all for your persistence. We have the best users, don't we folks?

Fixed slope constraints being ignored by foliage paint tool. Fixed slope constraints not being loaded from map files.

It's up now.

0.9.6 Fixed problem with grossly inefficient memory usage in mesh layer visibility data.

Okay, I found something quite bad. A lot of multi-threading in Ultra is done by adding a function to a queue of functions to be executed in the other thread, and then passing that batch of functions at a specific time, like this: auto pixmap = visibilitymap->Copy(); world->physicsthreadmanager->AddCommand(std::bind(&Physics::PhysicsMeshLayer::SetVisibilityMap, meshlayer->physicsmeshlayer, pixmap)); The problem is that in the MeshLayer::SetInstanceVisible method, I was doing this every time the visibility of an instance was changed. If the mesh layer was filled, then this resulted in a new copy of the visibility map being made for every single instance. So if you had a 2048x2048 terrain with density set to 1.0, it would result in 4,194,304 pixmaps being created, with a size of 256 x 2048 bytes each, for a total of 2 terabytes of memory. The solution is to add the mesh layer into an STL set when the visibility map is modified, and then in the World::Update method, just add an instruction to update the visibility map of each mesh layer once: void World::UpdateMeshLayers() { for (auto meshlayer : modifiedmeshlayervisibility) { auto pixmap = std::dynamic_pointer_cast<Pixmap>(meshlayer->visibilitymap->Copy()); physicsthreadmanager->AddCommand(std::bind(&Physics::PhysicsMeshLayer::SetVisibilityMap, meshlayer->physicsmeshlayer, pixmap)); } modifiedmeshlayervisibility.clear(); } I apologize for this oversight.

Okay, if I create a 2048x2048 terrain, add one layer, then change the density from 2.0 to 1.0, then the memory usage skyrockets to something like 12 GB. That's definitely not right...

If you don't mind, can you switch the installation to 0.9.5 and see if the same problem occurs in this or previous versions?

0.9.6 Removed the padding bytes for buffer memory allocations, since they did not reveal any problems but could possibly cause problems without thorough testing.

0.9.6 Fixed major memleak in editor that was caused by World::Update never getting called, so data was just piling up.

Any feedback on this?

When you do this, are you holding down the spinner arrow so the density changes gradually many times? That's the only way I was able to raise the memory up much. It appears there could be a mem leak, and then when the density is set a lot of times, the effect is magnified.

Yeah, that is an interesting detail...

0.9.6 Added extra padding before and after a memory buffer. A magic number if written here. If a memory overwrite affects the block, these values will be modified and the error will be detected. (I did not detect any memory overwrites in the editor on my machine.)

The editor now includes some extra info in these errors so at least we can tell if it's malloc or realloc that are failing.