StaticBody3D's need specific groups

[citizenken]

Thanks for developing this asset, it has some pretty great potential I think, and is a little easier conceptually to use than Vehicle3D. One major error I ran into incorporating this into my game was the face that are are specific terrain types that are expected which correspond to groups on a StaticBody3D surface.

My steps to reproduce:

• Create a new simple vehicle, using the default settings
• Create a new StaticBody3D box or plane
• Add both to a parent Node3D

When the project is run, the following error is thrown

E 0:00:01:0812   instance_set_transform: Condition "!v.is_finite()" is true.
  <C++ Source>   servers/rendering/renderer_scene_cull.cpp:922 @ instance_set_transform()

The car will be unable to move and wheel's return false when is_colliding() is called. Since this is a C++ error, debugging is super hard as we don't have a good stacktrace.

To resolve:

• Add a "Road," "Dirt" or "Grass" group to the StaticBody3D

The errors disappear and the car moves as expected.

Additional testing:

• Taking one of the cars from the demo and dropping it into the test scene. Same error, same inability to drive
• Dropping the test vehicle into the demo scene works as expected

I think the lowest-hanging solution to this is a note in the README. Aside from that, potentially logging a warning or info log message here indicating that no collider with the list of groups was detected could help diagnose the issue.

Thanks again for the hard work, and I'll be happy to PR if you'd like.

[DAShoe1]

Thanks for the report! Looks like I missed setting a default surface type when refactoring this from my own project to release here. I honestly think this needs a better solution than using node groups as it is too error prone, I'm just not sure what that is yet. In the meantime, I'll patch this up quickly.

[citizenken]

How are groups error prone? Maybe utilizing something like node metadata would be an option? See this link https://forum.godotengine.org/t/what-is-the-purpose-of-object-meta-data/27571. I think extracting the configuration from the wheel script makes sense, it seems like info that should be available from the colliding object. There isn't a ton of data required, from what I can see, so a simple key/value like metadata could solve it. Just a thought.