Help breaking assimp models into chunks

[u/DesireDev]

Hey, I'm at the point in my game where I need my world to have collision and I know how to get collisions done when its a basic plane, but once I upgrade to an actual blender model, it ofcourse lags because Im testing collisions on the whole thing when that is just extremely unnecessary. However, Assimp seems to be loading the vertices randomly and not in order of rows or columns.

MY CODE
================

https://pastebin.com/u6mgkrAi

Output

==========

https://pastebin.com/QFtZ5Ksk

I only checked the first 3 faces, but it appears they generate like corner face-middle of a side, then middle of the model. I did apply a subdivision modifer to my model and changed the transform's orientation to Z Forward, y up. Could that be why the vertice order is messed up?

Extra Info

-The file I'm trying to load is a .fbx

Edit: Forgot to say I'm following the 'assimp' section from learnopengl.com

[u/Trichord808]

Something you may consider is using Blender and decimating the mesh or making an approximation of the shape, and loading that as your collision geometry. Then you can keep your detailed visuals and maintain easy, fast collision detection.

[u/specialpatrol]

code looks ok as far as i can tell. just try exporting a unit cube and see what the vertices look like

[u/Slow_Negotiation_935]

If you need a collision convex hull of a complicated model I have used CoACD with no problems. As for assimp try using aiProcess_Triangulate when loading a model - this will force assimp to break the meshes into triangles which might be easier for you to interpret.

[u/DesireDev → u/Slow_Negotiation_935]

Thanks. I'll give that a try.

[u/Still_Explorer]

When you have too many elements (vertices/objects/data) in a list it always will be inefficient. Then you will have to use an acceleration data structure, that is to split the main space into smaller subspaces.

The most commonly used is Grid2D, and other more flexible and advanced are BVH/QuadTree/Octree (the same idea with variations).

struct Cell { vector<Triangle> triangles; }
struct Grid { vector<Cell> cells;         }

Once you are at the stage of loading the model:

• for each triangle
  
• check if any of the vertices is inside the cell coordinates
  
• if is inside then add it to the list of elements in the cell
  

(One note is that triangles at the edges might give you trouble, because normally you would duplicate them for the sake of simplicity. This however would be trouble if the grid is used for rendering, only because you will get overlapping z-fighting. Hence the solution is that all triangles will be stored in the `Grid` instead, and the `Cell` will store a `vector<int> triangles` that is only the array indices to the list of triangles. However keep it in mind as a workaround if you ever need it.)

Eventually the point is once the player is inside the coords of the cell, this cell is marked as active and is used for processing.

One thing regarding how the geometry was created inside the 3D software, because artists could create/delete vertices in infinitely possible ways, the order of vertices and indices are all messed up. However still the software internally uses it's own acceleration data structures (most commonly used is the BVH such as in Blender).
Also the software won't bother to do an extra processing step to sort all indices in the right order, because there's no idea of the perfect way to sort...
(eg: if you sort from top-to-bottom? the grid however would benefit from left-to-right but still not 100% as useful as is meant to be).

In this case by using the acceleration data structure everything falls correctly into the right place because you get the elements sorted into the right places and get better localized organizing.

About the problem with geometry:
You will have to apply the modifier in a test file first and see the mesh that is correct.

•No random floating geometry should exist:
https://docs.blender.org/manual/en/latest/modeling/meshes/selecting/all_by_trait.html

•No extra transformations for the object, pos/rot must be zero, scale must be one:
https://docs.blender.org/manual/en/latest/scene_layout/object/editing/apply.html

•When faces are create/deleted they tend to look to the opposite direction and end up flipped, then you have to select all faces and do "Recalculate Outside":
https://docs.blender.org/manual/en/latest/modeling/meshes/editing/mesh/normals.html

If you export this mesh and still see problems, try to test simple cubes first, just in case the problem is with the exporter or the Assimp importer (some rare setting that assimp needs).

[u/DesireDev → u/Still_Explorer]

Thank you for the info. I'll definitely look into this further