ConvexHullShape that takes pre-centered vertices
Posted: Wed Oct 16, 2013 10:09 pm
Hi Norbo,
I recently added support for ConvexHullShape objects to my asset pipeline and it appears there is currently no way in Bepu (at least in my version, which I think is current in this regard) to create a ConvexHullShape without having it do a number of one-time calculations that seem better suited to the content pipeline.
To save runtime costs, I now create a ConvexHullShape in the content processor and extract the surface local vertex array, the minimum/maximum radius, the center and the volume of the ConvexHullShape. When the game prepares an asset that needs this ConvexHullShape, I now create one using a new constructor:
As you can see, this constructor merely copies the input array. For my purposes, I don't intend to ever change the resourced vertex data so it seems OK for me to share the vertices across any users of the data, but maybe that would be a concern for other people but I can't imagine that really being the case. I just didn't want to duplicate the data without a clear reason for it.
Additionally, I wanted to preserve the volume of the convex hull that is calculated within the content pipeline, so I added a new constructor overload that returns the calculated volume. I preserve that in my serialized data.
After I create the ConvexHullShape in the pipeline with this ctor, I extract the localSurfaceVertices and serialize those along with the rest of the calculated values.
Something I wonder about is how the ConvexHullShape doesn't actually retain the volume internally; it seems the creation of CompoundShape objects would be incurring extra cost when dealing with ConvexHullShapes within the compound since it looks like it is calling ComputeVolume which re-evaluates all vertices to calculate the volume whenever the volume is needed. I haven't done buoyancy with Bepu yet but it seems like it might help if the volume were cached? That's why I originally wanted to retain the calculated volume, I assumed that I would need to restore a cached value but it seems there isn't a cache value to set. Thanks for any insight there.
It would be great if these or functionally similar changes were to make their way into Bepu code at some point, or if you have a better suggestion about how to reduce runtime costs of creating convex hulls that might be even better.
Thanks,
I recently added support for ConvexHullShape objects to my asset pipeline and it appears there is currently no way in Bepu (at least in my version, which I think is current in this regard) to create a ConvexHullShape without having it do a number of one-time calculations that seem better suited to the content pipeline.
To save runtime costs, I now create a ConvexHullShape in the content processor and extract the surface local vertex array, the minimum/maximum radius, the center and the volume of the ConvexHullShape. When the game prepares an asset that needs this ConvexHullShape, I now create one using a new constructor:
Code: Select all
public ConvexHullShape(Vector3[] localSurfaceVertices, float minRadius, float maxRadius)
{
if (localSurfaceVertices.Length == 0)
throw new ArgumentException("Vertices list used to create a ConvexHullShape cannot be empty.");
vertices = new RawList<Vector3>();
vertices.Elements = localSurfaceVertices;
vertices.count = localSurfaceVertices.Length;
minimumRadius = minRadius;
maximumRadius = maxRadius;
}
Additionally, I wanted to preserve the volume of the convex hull that is calculated within the content pipeline, so I added a new constructor overload that returns the calculated volume. I preserve that in my serialized data.
Code: Select all
public ConvexHullShape(IList<Vector3> vertices, out Vector3 center, out float volume)
Something I wonder about is how the ConvexHullShape doesn't actually retain the volume internally; it seems the creation of CompoundShape objects would be incurring extra cost when dealing with ConvexHullShapes within the compound since it looks like it is calling ComputeVolume which re-evaluates all vertices to calculate the volume whenever the volume is needed. I haven't done buoyancy with Bepu yet but it seems like it might help if the volume were cached? That's why I originally wanted to retain the calculated volume, I assumed that I would need to restore a cached value but it seems there isn't a cache value to set. Thanks for any insight there.
It would be great if these or functionally similar changes were to make their way into Bepu code at some point, or if you have a better suggestion about how to reduce runtime costs of creating convex hulls that might be even better.
Thanks,