0
$\begingroup$

For some reason when I export my model as OBJ file, it contains some NaN values instead of floats (in normals section, like "vn NaN NaN NaN").

Can anyone tell me why is that or how to avoid/fix this, please?

HINT: in the example file below, only that enabled object is considered for OBJ export (actually it is an export of the src folder in there - I have reasons for doing this, cos I want still having my source files and yet I need it as one merged file when exported to OBJ, that's why).

BTW: I am using Blender v2.92.0 cos I am on Win7

EDIT [solved...kind of]: Although not a solution as such, but I "solved" it by simply changing the exported file type from OBJ to Collada DAE - all is solved for me now although I have no clue how it was possible, but that is how it is, simply export to DAE instead of OBJ....case closed.

$\endgroup$
7
  • $\begingroup$ Would need to see the blend file, or at least more information about your geometry nodes, like at least a legible screen shot to be able to help. (How to add a blend file) $\endgroup$ Mar 20, 2022 at 19:21
  • $\begingroup$ If in the normals section, I'd suspect you have some zero-area faces. $\endgroup$
    – Nathan
    Mar 20, 2022 at 19:22
  • $\begingroup$ @Nathan What that means? How to avoid or fix that? $\endgroup$
    – qraqatit
    Mar 20, 2022 at 19:31
  • $\begingroup$ It's just a suspicion, and if you want more details, you should consider uploading your file so people can check that before wasting time. $\endgroup$
    – Nathan
    Mar 20, 2022 at 20:08
  • $\begingroup$ Example file added... $\endgroup$
    – qraqatit
    Mar 20, 2022 at 21:58

1 Answer 1

1
$\begingroup$

While I'm not going to download 2.92 to double check, when we look at your mesh, we can see some obvious problems with it, that could conceivably lead to miscalculation of normals, and that need to be fixed even if they're not responsible for your problem.

Start by enabling "face orientation" in your 3D viewport's overlays dropdown. We can see that some of our faces' normals are pointing the wrong way:

enter image description here

Where it's blue, the normals are facing more or less toward the viewport "camera"; where they are red, they are facing more or less away from it. Everything should be blue. Where it transitions from blue to red, you have the potential for a zero-length normal, which might turn into NaN (which is generally something you get when you divide by zero.)

Now, let's use a "select non manifold" operation, and then in the operator box, disable boundaries. After hiding some stuff so we can see, we're left with the following selection:

enter image description here

What's happening there? The ring of selected edges are edges that connect three different faces: the tube running through this plane is welded to the plane. This is another case where there is no reasonable way to calculate vertex normals, and where we're likely to run into issues with division by zero. For reasonable normals, you need a manifold mesh, and the main characteristic of that is that each edge connects two and only two faces.

Let's look at one more place, someplace that looks like a plane, but apparently has a bunch of overlapping geometry. That looks suspicious to me. Let's select a vert and pull it away:

enter image description here

Huh, it leaves a triangle connecting to its old location. Here we have a triangle with two of its vertices in the exact same location. That means that the face doesn't actually occupy any area: it is a line, not a surface, and because of that, you can't calculate any kind of normal from it-- the normal is a plane, not a vector. This is another situation where we might expect NaN normals.

How do we prevent this? We don't make geometry like that to begin with. We don't have edges that connect three different faces. We don't make zero area faces. You can see that we can use "select non manifold" to identify problem areas, but each of these problem areas require individual attention. You might get some use out of "merge by distance", but it's just as likely that merge by distance will create as many problems as it solves, unless you use it very judiciously.

This particular mesh looks to me like it was probably made in a different application, because it's all triangulated, with ripped edges. If that's the case, I probably couldn't tell you how to get that application to export decent geometry-- both because I don't know what application it is, and because I don't use other applications to make my geometry anyways, so I'm not familiar with them.

$\endgroup$
8
  • $\begingroup$ I already know most of what you said above (except the "select non manifold" operation, that is very good new knowledge for me - thank you for that). But if you would look into the src folder which produced that object/mesh, you would see that IT IS BLENDER EXPORTING TEXT TO OBJ LIKE THAT, not me doing anything. So I still think there is something wrong with the Blender OBJ export - that text part is normal editable 3D text in that src folder. Try to export that src folder as obj (export only all visible meshes tho!) and then reimport it back to Blender, you'll get what you see now. $\endgroup$
    – qraqatit
    Mar 21, 2022 at 9:57
  • $\begingroup$ Also, all those overlapping faces and open lines/points are created only after applying modifiers. I would think as it is internal Blender process/method, it should be done correctly without these artifacts, right? Like if I use modifier "Boolean" on that main brick mesh and select "Difference" I would think Blender would make the new mesh correctly without overlapping new faces and opened/broken ones, right? But that is not the case, it is exact opposite...so...??? $\endgroup$
    – qraqatit
    Mar 21, 2022 at 10:08
  • $\begingroup$ + yes, that main brick mesh is a export from another program - it is not me manually creating it so I have what I got from there. Basically what I am doing with it is that I take that very simple model and trying to update its mesh with elements according to real LEGO brick I am comparing it to, like those numbers and words + those additional holes in the bottom side of the brick, and then exporting it once again as final OBJ file. $\endgroup$
    – qraqatit
    Mar 21, 2022 at 10:14
  • $\begingroup$ + and strangely enough, for some reason now when I export it as OBJ there is no more any NaN value in normals section (and I really did not change anything at all, just reopened the same blend file I created the obj before from, tho it might be that I upgraded overtime my Blender, so its version is not the same as the one causing those NaN values), BUT now I am dealing exactly with those strange faces overlaps and stuff producing ugly renders caused by those overlaps and opened lines, thus I do not know if I should open new question or change this one instead? $\endgroup$
    – qraqatit
    Mar 21, 2022 at 10:21
  • $\begingroup$ The link in your comment provides a single file, a .blend. There is no folder that comes with it. If that's not what you're exporting, people need to see what you're exporting instead. Yes, if your process is generating non-manifold geo, you should figure out which part of the process is doing that, and if you don't understand why, then ask about that specific part of the process-- we cannot see what steps you took to make a particular mesh. $\endgroup$
    – Nathan
    Mar 21, 2022 at 15:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .