Importing Normals

Are normals actually imported?. Seems that what's supposed to happen is that if you disable 'Calculate Normals' then Unity is supposed to import the normals along with the mesh. Yet no matter what I do my mesh always seems to be imported with the same smoothing angle. To make sure I set the smoothing angle to a low value so the mesh looks faceted in my modeler but it always comes into Unity smoothed.

I've tried exporting from Modo in both .obj and .fbx format (including the 2006 fbx format). I've also tried 3D Coat's .obj format.

ps - I'm using Unity 2.6 Pro.

 

Smoothing angle and normals are different things. In order to get hard edges you need to split vertices. You can do that manually, or in Blender for example you can mark edges as sharp and use the edge split modifier.

--Eric

 

Hi Eric,

Well my point is that we can transfer a model from one program to another and the shading is usually preserved. We don't have to go and split edges in Blender to do this.

You're saying that Unity can't import whatever it is that other programs import in order to maintain the original shading?

 

"whatever it is" is normals. Unity does it fine, otherwise what Eric mentioned with Blender, as an example, wouldn't work. The Edge Split modifier just splits vertices at edges and uses non-averaged normals for each. The modifier is baked into the actual normals upon export.

 

Unity would do it even finer if it wasn't necessary to manually split the edges beforehand.

But I get the message.. Thanks for your replies, guys!

 

Are you saying Unity doesn't import normals or tweaking split angle doesn't work?

My recommendation is to try Unity 3.0 and see if that works any better.

 

What are you talking about? That's how modeling works. Either vertices/normals are split based on angle, or they are all combined or all split. If you want a combination of "smooth" and "hard", you model it.

 

As an example - if I set a smoothing angle of just 1 in my modeling application then all the polygons will obviously look faceted. I can then export that model into another program and the model will look exactly the same. But if I import the model into Unity then it seems Unity is ignoring my normals and is instead generating its own. Obviously I can still use 'Calculate Normals' within Unity to make the model look correct (faceted) again.

But it becomes a real problem when I have a model that has been split into several parts as each parts shading isn't imported. Yet I can import a split model into another program without any problems at all.

 

I'm going to guess that it's coincidence that the normals seem to be altered by whatever you're doing, and you're not actually doing anything that exports. In Blender, for example, you can have a model be "smooth" or "solid", which obviously affects normals in Blender itself, but that won't export. The EdgeSplit modifier is the only way to actually change the normals inter-app. You need to find a method that does the same for your own tools.

What does that mean, "split" / "part"? Separate meshes? Why don't you try actually making hard edges inside of smooth areas in one mesh? If that doesn't export, then you actually have a problem.

In fact, I'll do it for you. Tell us what happens when you import it into your various apps. It's a low-poly subdiv-type sphere with split normals at the equator. Here's what it looks like in Unity 3.1 when I Import Normals:

 

Blender's Smooth or Solid setting won't export, but the normals probably will. The problem seems to be with Unity not importing those normals. Instead Unity seems to be recalculating its own normals on import despite 'Calculate Normals' being disabled.

 

I never had that problem with any version of Unity. All you're saying is useless conjecture without test results. I just gave you something ridiculously easy to test with. No point in continuing unless you test it or something like it.

 

Sorry, Jessy. I just needed to know whether Unity imports normals or not. I do appreciate your time.

 

Yes, Unity imports normals. As I said, you need to split edges if you want them to be hard. Actually, Blender's smooth/solid faces are in fact baked properly if exporting to .obj, so the edges are automatically split correctly. If using .fbx/.blend, you need to use the edge split modifier, or split edges manually. In any case, this is a matter of what the 3D app is doing when exporting, nothing to do with Unity.

--Eric

 

Strange..

I just tried exporting a solid sphere from Blender using the obj format. The sphere comes into Unity smoothed. I inspected the .obj file and it contains no normals. So no wonder..

 

I see!

So it's not the normals that are important but rather it's the split edges. Which is what you've all been trying to tell me all along!

This is what I've got so far:

Unity ignores the split edges when importing an .obj file and the mesh will always be imported looking smooth (by default). But it will keep the split edges of an .fbx file provided those edges were manually split. It won't import the split edges of an .fbx that have been derived from Modo's Smoothing Angle. Yet for some reason 3D Coat will import those split edges in an .obj file, but crashes when I import an .fbx file.

..and my head hurts

 

You have to click on the "Normals" button when exporting an .obj in order for the normals to be included.

As long as you export normals with .obj files, you can use smooth/solid faces, as I mentioned.

Welcome to the wonderful world of 3d app (non) interoperability....

--Eric

 

You're really overcomplicating this. As I described before, "split edges" are just edges between duplicated vertices that are in the same place. The duplication is necessary, because a vertex can only have one normal, but at these edges, you need different shading on each side, requiring two normals. Hard edges, aka "solid shading", therefore increases vertex count.

Neither FBX nor OBJ have any problems storing the correct data. It's all about what your exporters do, as Eric said.

 

It's also about the importers too. An exporter can store all the correct information but if the importer in your target program isn't so flexible then you're obviously gonna have problems.

The .obj file format can be surprisingly varied from one application to the next, so it's no wonder applications struggle to import files from other sources.