Converter tools. Unnormalized normal errors in current git download

[Frame]

Unnormalized normal errors

Making a model and just exporting it in 3dmax 9 as an obj file
gives me those errors... I have ticked normals in the export
and it did'nt used to be a problem with the more older tools
that did however generate erros.

Im using the Obj2DatTexNorm.py found here

https://github.com/OoliteProject/oolite-mesh-converters

What is the main reason getting such an error. ? Isolated vertex, open edges ?

This is what im getting after editing the python file to not show a gazillion warnings and learning
about pythons 4 space vs 1 tab feature... nice stupidity right there on the design of python.

Anyway here is the output

Code: Select all

Frame_STG19R.obj -> frame_stg19r.dat
  Material library file: C:\Users\Dennis\Documents\3dsmax\export\B5universe\./Frame_STG19R.mtl
  Material Material__67 -> StripePainting.png
  Material Material__2088 -> GenHull_FrameDarkf.png
  Material 04_-_Default -> Centrifuge_Detail3_Polaris_Frame.jpg
  Material Material__2089 -> GenHull_FrameBluef.png
Warning: read unnormalized normal -0 0 -0
Traceback (most recent call last):
  File "E:\Projects\OoliteModelTools\oolite-mesh-converters-master\DTPObj2DatTexNorm.py", line 452, in <module>
    normal.append(vector_normalize((x, y, z)))
  File "E:\Projects\OoliteModelTools\oolite-mesh-converters-master\DTPObj2DatTexNorm.py", line 73, in vector_normalize
    return vector_scale(v, 1.0 / vector_magnitude(v))
ZeroDivisionError: float division by zero

[kanthoney]

You've got a zero length normal in your data somewhere, which isn't normal (sorry.) I've just pushed a version of Obj2DatTexNorm.py which should cope with this - it's on the zero-normals branch on the github repo and should work if you use the --accept-zero-normals flag.

Let me know if it works so I can push out the change to the master version.

[Frame]

You've got a zero length normal in your data somewhere, which isn't normal (sorry.) I've just pushed a version of Obj2DatTexNorm.py which should cope with this - it's on the zero-normals branch on the github repo and should work if you use the --accept-zero-normals flag.

Let me know if it works so I can push out the change to the master version.

Seems to be working. At least i got it converted. I dont have it ready for ingame yet, but a quick glance of the dat file looks promising.

On a side note, I got some 668 warnings regarding this in the model file.
That amount of warnings exeeds the command prompt screen buffer window and
hides any other useful information. A 1 line warning regarding this should be sufficient.

[kanthoney]

668 warnings?!? I suspect something's gone awry with the normal generation when exporting the model.

[Cody]

668? The neighbour of the Beast?

[Frame]

668 warnings?!? I suspect something's gone awry with the normal generation when exporting the model.

Well it is a 16K poly model .

but i narrowed it down to, that it only happens when i have smooth groups on the model, and it happens
each time. I did however create a sphere to counter-test and that exports just fine, allthough be it with 1 smoothgroup. Gotta test with more later.

https://knowledge.autodesk.com/support/ ... B-htm.html

I got the model in game now using obj2DatTexNorm.py, and there are holes in it at places that does not seem to be "difficult". Some are either 90 degree pointing directly up
or 90 degree pointing to the right/left or forward.

I can fix it however by detaching the areas in question to elements of the model. thus severing it from the rest of the model and giving it vertexes of its own.

[Frame]

here is a video of the model among other things.

https://youtu.be/BTscgsXdzGQ

[Frame]

To expand on this.

I found out that the

Code: Select all

"warning: read unnormalized normal -1.28564 -4.18861 0.82095"

only happens when i got smooth groups on the model.

Look here for explanation.

https://knowledge.autodesk.com/support/ ... B-htm.html

removing them remedies the first problem, and when exporting vertex normals, they are not really needed. I discovered this purely by accident when exporting another model that used to work fine, but suddenly started to give me those errors and then backtraced the to the origin of the problem.

The second problem that is holes in the models are due to the converter tools automatic winding of the faces. Sometimes it gets confused and it especially gets confused around what i can describe as "trenches" in the model. in any direction. For example and inward extrusion around windows. To clarify: i predict a model of the Star Wars Deathstar Trenches would cause problems with the 2 setting.

Setting the winding to 0 thus preserving the original winding also cures this problem. I found some other trouble spots that i cant explain other than they partially goes in the oppersite direction than most of the rest of the model is.

I wonder why this was set to 2 in the first place.

An explanation of available modes are in the file luckily.

Code: Select all

Available modes:
  0: maintain the OBJ file's original winding.
  1: reverse the OBJ file's winding.
  2: select winding automatically for each face based on normals.
  3: select winding automatically for each face, but buggily (the same
     behaviour as Oolite for old-style model files). You probably don't
     want this."""
        parser.exit()

[KaiserZandrich]

668? The neighbour of the Beast?

You make browsing any of these forums worthwhile.