About asset collision data serialization, cooking and OCD levels

Started by
0 comments, last by irreversible 2 years, 7 months ago

I'm finally getting around to writing some dedicated collision code for my model assets and I've spent a couple of days googling to see what the best way to go about it might be. My takeaway so far, with respect to Bullet in particular, is something along the lines of “all discussion is outdated” or “don't serialize”. Which is not very satisfactory.

So I'll throw out the question out here and see where the consensus lands. On a scale of storing everything as text to aggressively pushing a binary interface at all times, what would your pipeline look like (again, for assets, not the world itself)?

  1. text-based representation/descriptor for everything (in my case XML-compatible markup)
  2. create a binary representation of the text descriptor
  3. serialize only tri meshes (see 4); for simple and simple compound shapes (containing boxes, spheres, k-DOPs, etc.) store a text or binary descriptor and proceed as in 1 or 2
  4. aggressively serialize all shapes during asset cooking (supposedly create a Bullet instance, construct the shapes/hierarchy and bake the proxy chunks into the collision data)
  5. something in between? Different?

As an aside - my level geometry is dynamic and I know I can both parallelize and (re)build it kinda-sorta fast enough for my use case (at least for now), though I'm sure my next question (which I'm totally not thinking of yet) would be about whole world serialization.

As another aside - PhysX seems to provide a far more intuitive approach to serialization (based on my cursory reading of the docs at least), although I'm again not sure whether it actually encourages aggressively serializing individual objects or favoring collections of objects once they're already added to the world.

This topic is closed to new replies.

Advertisement