Best practice for instanced collision generation.

   7015   3   1
User Avatar
Member
453 posts
Joined: 2月 2013
Offline
I am working on a very performance-sensitive project and I want to get the most out of Houdini Engine.

My question is this: What would be the most performance-efficient way to add collision to Unreal on a Houdini Engine instanced object.

Currently, I am generating a tunnel from repeating concave and complex segments. I generate the segment and its collision in Houdini.
I have one instance node, a tunnel segment and a few collision boxes on the geometry level of my hda. In the instance node I generate points to place the collision boxes and the tunnel segments. I presume the most efficient thing to do would be to instance boxes separately from the tunnel segments so as to generate as few boxes as possible. (So if for example, several tunnel segments are instanced on a straight line, their ceiling and ground could be represented with one collision box, each.) For this I would need to generate one collision box and instance it with different scale values (and eventually bake that into a blueprint). Is this efficient?
Or would it be better to generate a few collision boxes of different sizes and instance them without scaling? Or would it be better to create one (optimized) complex collision mesh, make it a complex collision in Unreal and instance it with every tunnel segment? Or would it be best to generate the collision for the tunnel segment in the Unreal StaticMesh Editor (so that I only instance tunnel segments with built-in collision)?
Or is there an even better way to do this?

- Note: I am using tunnel segments as an example. I want information that I can apply to any instance type, like maybe a forest or city generation tool. I am interested in “under the hood” information on the performance impact of different techniques.

- Note 2: This topic is relevant to (and should take into account) the discussion in https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=38283 [sidefx.com] and RFE #61716 . Is there an ETA on RFE #61716?

Thanks in advance!
User Avatar
Member
402 posts
Joined: 3月 2013
Offline
You're probably best off sticking with Unreal StaticMesh Editor for the moment if performance is crucial. This is for the reasons you already mentioned, that is, the absence of simple collision primitives support in Engine (RFE #61716).

That said, this is only an educated guess on my part. If you can spare some time, it be best you performance test each of your techniques and just see which one is faster of if it even makes a material difference.

RFE #61716 is on its way. We're working on it. I can't make any hard promises as to when that will be in other than that it will be a few months but less than a year.

As it does require an API change in Houdini Engine, we can't simply release it even its done as it will break peoples plugins. We have to wait for a new release of Engine.
User Avatar
Member
453 posts
Joined: 2月 2013
Offline
Are there any news on the RFEs? - I saw that an attribute for naming objects inside Houdini Engine was added recently. That was nice.


Does the instance blueprint internally use the same technology for instancing as the UE4 foliage painting tools?
User Avatar
Member
173 posts
Joined: 4月 2014
Offline
We have box and sphere support in Houdini Engine now, but only in 15.5, this work cannot be backported to 15.0, unfortunately. We are looking into adding support for generating collision objects from those in our plugins (I believe Unity plugin has already support for this).

You would need to mark your spheres and boxes (ones you want to use for collision) as members of some primitive group (say unreal_collision_box/unreal_collision_sphere). Then when we are processing geo/sop we'll look for those and use them as collision primitives when we are generating the rest of geo/sop static meshes.
  • Quick Links