Exporting OBJ and FBX physically break edges - no love for the game making community?

This is from the Unity docs (this is not Blender-related!!!):

“The Unity Editor shows too many vertices or triangles (compared to what my 3D app says)
This is correct. What you are looking at is the number of vertices/triangles actually being sent to the GPU for rendering. In addition to the case where the material requires them to be sent twice, other things like hard-normals and non-contiguous UVs increase vertex/triangle counts significantly compared to what a modeling app tells you. Triangles need to be contiguous in both 3D and UV space to form a strip, so when you have UV seams, degenerate triangles have to be made to form strips - this bumps up the count.”

Link: http://docs.unity3d.com/Documentation/Components/class-Mesh.html

You are simply wrong. Sorry for my good english.

Too many issues are being conflated here.

  • Blender recalculates normals of any imported models.
  • Blender does not support multiple normals per vertex (not at the user level at least)
  • Edge split modifier breaks up geometry (which often isn’t what you want)
  • Some applications expect smooth-groups, which blender doesn’t support (though hard edges can be converted into smooth groups - I’ve done this with some exporters before).
  • Random Problems with Import/Export — with various applications.

There are doubtless improvements to be made here, but I still don’t know what the original post was talking about.

Note: FBX, you can export hard/soft edges without applying the edge-split modifier. This isnt ideal since without the modifier you wont see the result in the viewport, just noting that it works.

Note: that many graphics formats for display Cal3D, DirectX, X3D (and other game model formats that are for loading in game engines).
will - break up geometry where vertices’s have different UV/normals/color.
Of course this isn’t nice for editing in other applications, just to say for game engine exports this is what often happens since this results in less processing when loading models into the graphics card.

What a useless reply to one of the few useful Endi posts. He’s almost entirely factually correct about all the things that aren’t subjective. Vertices need to be duplicated if even one of their attributes (such as color,UV) is not shared. How that is handled at the user-level is application dependent, so it’s bound to cause discrepancies between applications. I don’t see it as a problem unless you want to edit models in multiple applications before sending them to your game engine.


Cheers @|MM|, for concise reply.
I’ll take a look at adding smoothgroup support to FBX this week - shouldn’t take more then a few hrs.


It would be great if both OBJ and FBX could preserve hard/soft edges on import/export. But I will take any improvements over nothing.

Thanks IMMI
Should I add here…
Well, internally, blender can rebuild subdivisions after applying a multires modifier. Just keep a duplicate of the low poly mesh, subdivide it and use reshape under multires modifier. Irrelevant to you needs but in many cases it’s a solution on multires sculpting performance issues. (base retopo cage >10k)
This workaround won’t work if we have the idea to import for instance a hires and the low base from zbrush. Explode is what we get. Because there is a different data of vertices? I’m ignorant on such matters. What about rebuilding subdivisions from a hires mesh (coming after subdivisions on other apps or in blender without the use of reshape etc?)
After all, if you have lot of RAM installed and (wait a few mins!? ) you can import very dense obj meshes.

@ideasman
IMMI mentioned the hi to low poly baking issue. Not in the first subd level. This is an important issue, another among other related to the multires modifier.
I’ll keep repeating it until someone notices it. No, I mean until most of the blender users notice it.
We’re talking on the compatibility issues with other apps on game assets modeling. Without having a stable, productive, multires system. Maintaining excellent performance.
But we have a nice (so and so) dyntopo… well, this is only a first step.

I’m sure that lot of blender users have a clear idea on the appropriate workaround for building “professional” assets.
But, I still don’t see any roadmap that devs may follow.
Bad english sorry.

Michalis, multires base meshes have fundamentally different characteristics than what you’d want for an in-game model. Baking to them works well for offline rendering, and maybe once the next generation of consoles comes in they’ll be good enough for realtime too. I don’t think very many Blender users are going to be targeting the PS4 for the moment though, so right now meshes for realtime engines need to be be much better optimized - you have to make them by hand and save every vertex and fine-tune every normal where you can. So as far as games are concerned baking from multires is pretty irrelevant.

@|MM|, oki - Ill do generic hard-edge --> smooth-group function and share between exporters.


That’s what the actual problem is. Basically freelance game artists have a difficult time producing models for clients. The client is almost certainly going to be using Maya or Max. If you’re sending them a model created in Blender you can’t retain smoothing groups/edge splits.

Quoted for the truth. If this indeed will get improved, I`m sticking with Blender all the way.

EDIT: @xrg, I quoted you on my opening post for clarification of the problem.

I believe Jibberish is currently working on the FBX side of things because tangents and bi-normal aren’t being exported as well.

Awesome. Three cheers for Campbell!

@ideasman

your effort is highly appreciated. I am not a coder so I am kinda useless in that regards.
Do you think it will be difficult to prevent Blender to recalculate normals of any imported model
and instead use the the vertex normal shading provided inside the OBJ file?

That not for the game designers but for the architect and product designers here will extremely
help with Blender and rendering.

With BMesh and Cycles we got so close to comercial application - it seems this vertex shading
is the last battelground.

@cekuhnen It’s now a candidate target for 2.68! :slight_smile:

Campbell your awesome! Obj and fbx I/O support of vertex normals and smoothing groups is a HUGE deal and I can’t wait to try it out! Thanks so much for your efforts!

How do you see this working in practice? Since blender’s mesh format doesn’t internally support these things? Will a model with smoothing groups get converted to a model with an edge split modifier in blender? On the flip side, the exporter will recognize an attached edge split modifier and export it as a smoothing group?

An obj import from MOI seems like it will be even more difficult to represent in blender, since the way Moi bends vertex normals to avoid shading artifacts seems like voodoo magic to me. :slight_smile:

Also, I’ve had problems exporting multiple meshes at once as an obj and having it come in as one single object in maya. Is this a limitation of the obj exporter or am I just doing it wrong? :slight_smile:

Editable vertex normals is useful for games too actually. Bunch of examples here on using it for foliage for instance. There was an add-on to edit them already, but since Blender recalculate them it kind of limited it’s practical usefulness.

Anyhow, looks like it’s a target for 2.68. :slight_smile: Edit: Bah, didn’t even see MadMinstrel’s post :stuck_out_tongue: