cgrant

Members
  • Content count

    395
  • Joined

  • Last visited

Community Reputation

1823 Excellent

About cgrant

  • Rank
    Member
  1. There seems to be a disjoint in the question you are asking and the information used for illustration. Maybe the following will help clarify what you are trying to achieve. 1. If you are cooking high poly mesh, I would refrain from doing so as a tri-mesh is not optimal for PhysX so I would try using convex meshes where appropriate. With that said I don't recall if PhysX limits the number of vertices in a tri-mesh, but it does for convex meshes. Runtime cooking of a few convex meshes is not that slow, but I would image the cost would add up if you are cooking a lot of meshes. The trade-off here would be whether or not you have a hard load-time requirement. 2. When you cook any representation, be resulting binary stream can be serialized to disk and reloaded. This is where I got confused as the 2 snippets posted just shows 2 ways of creating a triangle mesh representation, not the offline/runtime method as you would think. The first snippet posted would be the same offline/runtime. The only difference being with offline method, some external tool is used to cook the data using the same method as you would at runtime. However, instead of just turning around and consuming the buffer after cooking, the tool would save the stream to disk. Whenever the app is run, the cooked data is read from disk into a stream and used to create the tri-mesh representation. See the documentation regarding PxPhysics::createTriangleMesh Hope that helps clarify the issue.
  2. Source code organization is not enforced by the language. This is an organizational decision. Still doesn't answer your question, but one can only speculate why your compile time is so slow. In my experience I find that heavily templated code usually compiles much slower than the non-templated version. I have no experience with UE4 source code so I don't know if this applies.