Instance collision

[aidandavey]

This PR aims to add collision for the foliage instancer, mentioned in issue #43

The headlines :

• Physics shapes exclusively handled using the PhysicsServer
• Only creates and destroys edge cells
• Provides visualizations via the Rendering Server
• Works for scene files with multiple shapes
• Supports Game and Editor modes
• Allows teleporting

Some further details:

It will read any CollisionShape3Ds found in the Terrain3DMeshAsset scene file and store their Shape3Ds and transforms.

When terrain collision is rebuilt in Terrain3DCollision it also spawns shapes for the instances using data read from the data/region/instances dictionary and the Shape3D and transforms stored in the MA.

In Dynamic mode:

1. Build an array of cell positions to build, skipping cells which already exist.

2. Build a dictionary of instances in said cells.

3. Decompose cells outside of the collision radius and store the instances within for recycling.

4. Compare the list of recyclable instances against the list of instances to build. Decompose unneeded instances to their component shapes, store for recycling.

5. Generate the new instances, preferably:

   A. Recycle an old instance, simply transforming the shapes. Or...
   B. Reuse spare shapes, transform and update base meshes. Or...
   C. Generate brand new shapes.

6. Destroy and remaining shapes and update an internal RID/shape_id map.

Full mode for instance collision was shelved.

For both Editor and Game modes, the PhysicsServer3D is used. The main reason for this was I kept hitting the 2^18 object limit when stress testing Full mode.

For Editor modes, visualizations are provided via the RenderingServer.

To test it, add a new Terrain3DMeshAsset and use RockA.tscn as the scene file. Paint some rocks using the foliage instancer and run the scene.

Future plans:

1. Have a body per MA - allow individual layers and other physics settings
2. Manual mode - allow the user to enable and destroy instance collision by cell through the API
3. Roll up of the shape transforms - currently it takes the local transform only
4. Enable update by MA per cell, to improve performance in the editor (if needed)
5. Use hash maps instead of Dictionaries

[CavemanIke]

When collision is rebuilt in Terrain3DCollision it also spawns bodies and shapes for the instances using data read from the data/region/instances dictionary and the Shape3D stored in the MA.

If this is creating a body with the shape for each instance, I think an optimization can be had here. If a single body is used and the same shape is added to it multiple times with transforms matching the instances, it will use significantly less memory. Through my tests, adding 250K bodies using the same shape RID results in ~400 megabytes of additional RAM usage. Using a single body, but adding 250K of the same shape to it at different transforms was only ~100 megabytes extra RAM usage. Rebuilding shapes on a single body is also extremely fast compared to creating multiple bodies.

[aidandavey]

Work on only updating edge cells, and spawning body per cell, shape per instance

This will be helpful:

Terrain3DInstancer::_get_cell(const Vector3 &p_global_position, const int p_region_size) will give the cell index for the current region.

so cell_local_pos.xz = instance_pos.xz - cell * cell_size.

[aidandavey]

@TokisanGames I think this working nicely now. Could you please review and let me have your feedback?

[TokisanGames]

Thanks, I will look when I can. I am a bit behind.

You could add edit the collision document, and document the new functions in the XML (generate it then edit it) if you like.

Merge branch 'TokisanGames:main' into Instance-collision

Never merge. Only rebase. See the contributing doc.

[aidandavey]

Thanks, I will look when I can. I am a bit behind.

You could add edit the collision document, and document the new functions in the XML (generate it then edit it) if you like.

Merge branch 'TokisanGames:main' into Instance-collision

Never merge. Only rebase. See the contributing doc.

Thanks and no worries, I actually dreamed an improvement last night so I need another day or so to try it out.

I'll also take a look into editing the docs and sorry for the merge.

[TokisanGames]

As the user traverses the instancer cells and they leave behind 10 instances of TreeA and approach 10 instances of TreeA, it would be more efficient to just move the transforms, and store any remaining in an unused cache rather than delete and recreate them every time. The latter is slower, will likely fragment memory, and probably run into any limits faster. The former is what the terrain collision does. It builds a fixed number of shapes at initialization, then never creates nor destroys any until shutdown.

Merge branch 'TokisanGames:main' into Instance-collision
Revert "Merge branch 'TokisanGames:main' into Instance-collision

This also isn't what we want. Do an interactive rebase, drop both of these commits. Rebase your PR, and force push.

[aidandavey]

As the user traverses the instancer cells and they leave behind 10 instances of TreeA and approach 10 instances of TreeA, it would be more efficient to just move the transforms, and store any remaining in an unused cache rather than delete and recreate them every time. The latter is slower, will likely fragment memory, and probably run into any limits faster. The former is what the terrain collision does. It builds a fixed number of shapes at initialization, then never creates nor destroys any until shutdown.

Merge branch 'TokisanGames:main' into Instance-collision
Revert "Merge branch 'TokisanGames:main' into Instance-collision

This also isn't what we want. Do an interactive rebase, drop both of these commits. Rebase your PR, and force push.

Yes I saw the fixed number of shapes in the terrain collision which is great when there is a fixed number of shapes of the same type.

I can manage active and inactive shapes for each shape type, but how many to create of each?

What do you think about creating shapes only when there are no unused ones?

[TokisanGames]

What do you think about creating shapes only when there are no unused ones?

Yes, and in the cleanup, save 10 and delete the rest. Or, we have a fixed cell size and a calculated mesh density. It could be a number based on density, clamped between 5-20.

Or, if the camera has moved to a new cell block, triggering an update, we know how many are needed in the new blocks, and how many are extra in the old blocks. You could just move all of those, create as needed, free the rest, store none.

The latter is probably best. In OOTA, we have some 60+ meshes and growing. We don't need 600 unused shapes hanging around. The same types of foliage grow together in an area, so in this scenario, it doesn't store unnecessarily, and the reuse count is high, and it gradually changes retained types as the planted foliage changes.

[TokisanGames]

This PR still isn't rebased properly. None of these commits should be in your branch.

You should never use git merge, nor sync on github desktop as detailed in the contributing guide. The Files changed tab in your PR shows a lot of files and changes that are not part of your work.

• Read the link above and the linked Godot PR workflow.
• Backup the files you're working on.
• Make a new branch called instance-collision-back, for a backup, then return to the instance-collision branch for this work.
• Do an interactive rebase:
  git rebase -i HEAD~25 where 25 is the number commits in your branch.
  Your editor opens with the list of commits like,

pick abcedef Some commit desc 1
pick defb233 Another desc
pick ab2f444 Yet another

• Find the commits that are not yours, confirm with this list, and look at each one on the commit tab in your PR. Change pick to drop.
• Save and quit the editor, and address any conflicts or complaints it has, until git status reports you're back to normal - not in the middle of a rebase.
• Run a diff of your modified files against your backups and confirm they are the same. If not, fix them with a new commit.
• Run git diff main to compare your current branch against your local main. Confirm this has all of, and only the changes you want.
• git push -f to force push your branch into this PR, and review the Commit and Files tabs to make sure you don't have extra commits and changes not made by you.
• Properly rebase off of upstream main: git pull --rebase upstream main
• Do another interactive rebase and compare against your Commit tab. Change pick to fixup on commits that don't need to be separate and it will roll them into the previous commit. Generally, you should have one commit per:
  • feature
  • fix for changes prior to this PR
  • demo changes
  • doc changes
• Commits that fix your previous commits in this PR should be squashed.
• For now though, keep the first 4 intact and separate, which have the code for the non-physics server node creation.
  You can do the interactive rebase multiple times, so take it slow, and do a little bit at a time, and check your work.
• When finished, force push again and review your Commit and Files tabs.
• Remove your backup up files and branch.

Watch this.
https://www.youtube.com/live/Kel3ZQDx7kM?si=34KdMIJj-j9vB26A

[TokisanGames]

This PR has a build script and a godot-cpp that it should not have. That's probably why android is failling.

[aidandavey]

OK I'm finally happy with this