2

I am working on an export / import addon for a custom model file format which stores its geometry in the so-called "render batches", the structures aimed at optimizing geometry for effecient live OpenGL rendering. I am trying to convert "raw" geometry data from Blender to that system.

If you don't want to read the detailed explanation, skip to 'individual steps I need to do' part.

In short, each render batch is a sequence of faces (only vert and face index information is required) which are:

1) A loose separate part of geometry (island).

2) Share one material.

3) Represent the same batch type (3 batch types A, B and C are used for internal rendering purposes, I store them as vertex groups in Blender. C = no vertex group, B = vertex group Batch B (if not in A), A = vertex group Batch A.

UV map is handled per-vertex because there are essentially no loops.

My current workflow is using tons of operators and is roughly this:

1) Create a temporary object in python 2) Triangulate 3) Cut mesh by materials using an operator. 4) Cut mesh by UV islands (Seams From Islands (+ mark sharp) -> Edge Split) 5) Cut mesh by vertex groups.

There are two issues resulting from the fact that mesh is actually being cut:

  • Normals become sharp, where they are supposed to be smooth due to the cutting seam.

  • I am treating a piece of geometry with one material as one single batch. So, distant islands using the same material are becoming one batch, which kills the benefits of render batch optimization for rendering.

a) Is there a way to either separate the mesh correctly based on the rules I have specified above, and somehow preserve the original normals on export? b) Or, alternatively, is there a way to non-intrusively create a list of these batches, again based on the said rules, without altering the mesh, and thus preserving the correct normals?

I know that the explanation may be ambiguous, so I created a visualization for the render batch system:

Render batches

(1) Pieces of geometry are sharing the same material, but are not connected to each other. Should result into multiple batches for each island.

(2) Piece of geometry is sharing the same material (there is a little mistake on the picture. Mat2_Batch1 on the left instead), but is separated by different batch type vertex groups. Thus, 2 separate batches.

(3) Piece of geometry is sharing the same same material, geometry is connected, no batch vertex groups (assumed it is type C). Thus, 1 batch.

Individual steps I need to do

1) Get faces sharing same material (easy, done)

2) From the result of a previous step, find groups of faces separated by UV islands

3) Then same with different vertex group (we assume face is in vertex group if all 3 verts of it are in.)

4) Find individual (loose) groups of faces in the resulted sorted chunks of geometry.

Any help would be greatly appreciated, I am completely stuck on this.

D. Skarn
  • 695
  • 4
  • 16
  • Any links / examples or information re the "custom model file format"? – batFINGER Jun 19 '18 at 08:42
  • Sure. https://wowdev.wiki/WMO#MOBA_chunk This is the render batches chunks. It to points to corresponding vertex and face index arrays. Note, that array of face indices is flat and should be iterated by triplets to get faces (only triangles are possible). If something is still confusing, let me know. I know the way this format works very well. – D. Skarn Jun 19 '18 at 09:10
  • Am I right to say that triangulate op does not change the vertices array? So same positions between the original mesh and the triangulated copy. If this is confirmed (I've rapidly looked at the source code and that seems to be the case, but..), you can retrieve the original normals from the original mesh, I think. – lemon Jun 21 '18 at 08:34
  • Also, you can have some ideas from this question. https://blender.stackexchange.com/questions/75332/how-to-find-the-number-of-loose-parts-with-python/75384#75384. Please in the provided answers, have a look at @batFINGER 's one (which is surely the fastest) and mine eventually in complement (other approach that can give you ideas too). – lemon Jun 21 '18 at 08:37
  • 1
    Yes, correct, triangulation does not change normals or vertices. And that is not the problem. The problem is actually splitting a mesh, because that changes normals, and transferring them is always a rough approximation based on vertex position (but we can't always guarantee that the correct loop will be chosen on transfer). – D. Skarn Jun 21 '18 at 08:39
  • About normals, why splitting the original mesh is needed? Can't you identify/calculate subparts without actually separate them? About loose parts, the linked question above can help to do it. About materials, this can be easy (map by material without cutting anything). About UV islands, I don't know though. – lemon Jun 21 '18 at 08:47
  • Indeed, I want to avoid actual mesh splitting. It looks like I've just found a solution so far. Will need to implement it properly and run tests in the game engine. But by just selecting islands, it appears to be working. Have yet to do vertex groups too.

    https://hastebin.com/gaguxufebi.py

     – D. Skarn Jun 21 '18 at 09:05
  • Not sure you will get anywhere near the recursion limit. In this example for instance given a mesh of 2 edge connected verts, (recursion => binary tree) there would need to be over pow(2, 700) vertices in the island. – batFINGER Jun 21 '18 at 10:12
  • A long strip of more than 900 faces connected to each other should be near the standard recursion limit of 1000 with my implementation, since it calls itself recursively for each connected face. In my case, splitting larger islands into smaller ones, not based on any rules is actually not bad. May even have a positive effect on FPS in the game. I will look at your implementation in detail too though. – D. Skarn Jun 21 '18 at 11:47

0 Answers0