Terrain Mesh + Static Objects

[JC Denton]

Hello!

I have my simulation running in unreal, where I have a terrain mesh that I can export as a mesh or heightmap. But I also have numerous static meshes that the vehicle can  drive on also such as extended dirt pathways, large flat rocks etc.

I can't call from Chrono-> into Unreal to ray cast these objects in this case and let Unreal do the height queries, since there isn't a synchronous method of doing so.

How best to add these to the simulation? Should I treat them as static bullet colliders and add them that way, or should I be converting each of these pathways into a terrain patch of their own? Is there a realistic limit on how many terrain patches I can add?
The overall poly count of all my meshes is quite high so I would like to anticipate any performance issues ahead of time.

Thanks!
-JC

[Marcel Offermans]

Hello JC,

On 07-Aug-23 17:47, 'JC Denton' via ProjectChrono wrote:
> I have my simulation running in unreal, where I have a terrain mesh
> that I can export as a mesh or heightmap. But I also have numerous
> static meshes that the vehicle can  drive on also such as extended
> dirt pathways, large flat rocks etc.

Understood.

> I can't call from Chrono-> into Unreal to ray cast these objects in
> this case and let Unreal do the height queries, since there isn't a
> synchronous method of doing so.

You are aware that there is an option to provide a way to provide a
"functor" object for doing such raycasts in your custom terrain to
calculate the height, normal and friction at any point? See
https://api.projectchrono.org/development/classchrono_1_1vehicle_1_1_ch_terrain.html#a8e3e66a8f15858149786fe234dda23bd
for the methods to register such functors. If you have terrain that
needs to be used differently (I'm not that familiar with the terrain
code in Unreal) then this is a hook you might be able to leverage. Or
did you try this and is something else blocking you from making this work?

> How best to add these to the simulation? Should I treat them as static
> bullet colliders and add them that way, or should I be converting each
> of these pathways into a terrain patch of their own? Is there a
> realistic limit on how many terrain patches I can add?
> The overall poly count of all my meshes is quite high so I would like
> to anticipate any performance issues ahead of time.

In general I would say that if you just provide a huge mesh (or multiple
smaller ones) the speed of the default implementation is likely to
become an issue (it was in my case, which is why I ended up using the
functors I mentioned above).

Hope this helps (a bit).

Greetings, Marcel

[JC Denton]

Hi Marcel,

Thanks again for your insight.

I know about the functor to run raycasts on my terrain, and I was planning to use that for my traditional terrain mesh. I can't call into Unreal's terrain data
with that function since there is no thread safe method of doing so that I know of, however I can copy that mesh into the Chrono side so it can query it whenever it needs.

My concern lies more with the non terrain type meshes that are still drivable, but seperate meshes. I have long spline type pathways, rocks, rubble and other debris that can also be driven upon.

These separate meshes have simplified primitive and convex colliders.

I have begun the process of extracting all collision shapes from unreal and making static versions of them on the Chrono Bullet side, but not sure how nicely Chrono's tire models will interact when driving over those non terrain objects, or
perhaps it ignores them entirely. I have to make a distinction between drivable mesh and a terrain type mesh. But I will for sure have to do some work in that height/normal query to determine what its driving over, and may need to trace against
my static meshes also, which could start getting expensive without optimizations.

Guess we will see what happens!

Will report back

[Marcel Offermans]

Hello JC,

On 10-Aug-23 23:05, 'JC Denton' via ProjectChrono wrote:
> Thanks again for your insight.

yw!

> I know about the functor to run raycasts on my terrain, and I was
> planning to use that for my traditional terrain mesh. I can't call
> into Unreal's terrain data with that function since there is no thread
> safe method of doing so that I know of, however I can copy that mesh
> into the Chrono side so it can query it whenever it needs.

Understood. If there is no other way then it sounds like you will need
to somehow make a copy.

> My concern lies more with the non terrain type meshes that are still
> drivable, but seperate meshes. I have long spline type pathways,
> rocks, rubble and other debris that can also be driven upon.
>
> These separate meshes have simplified primitive and convex colliders.
>
> I have begun the process of extracting all collision shapes from
> unreal and making static versions of them on the Chrono Bullet side,
> but not sure how nicely Chrono's tire models will interact when
> driving over those non terrain objects, or
> perhaps it ignores them entirely. I have to make a distinction between
> drivable mesh and a terrain type mesh. But I will for sure have to do
> some work in that height/normal query to determine what its driving
> over, and may need to trace against
> my static meshes also, which could start getting expensive without
> optimizations.

As far as I'm aware, at least the semi-empirical tire models only
interact with some form of "terrain" implementation (using raycasts). In
a previous simulation I was involved in (not using Chrono) all 3D meshes
that were tagged as "drivable" were pre-processed and converted into a
single mesh that was specifically designed to drive on. It was optimized
for allowing fast raycasts, and even slightly "smoothed" to account for
particular nasty polygons in the original mesh that might be tricky when
driven on (small gaps, 90 degree angles, etc). It sounds like you are
probably heading in a similar direction here.

> Guess we will see what happens!
>
> Will report back

Looking forward to hearing more about your progress!

Greetings, Marcel