Oolite Bulletins

For information and discussion about Oolite.
It is currently Tue Oct 17, 2017 2:58 pm

All times are UTC




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sun Feb 05, 2017 11:56 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Fri Mar 30, 2007 8:32 am
Posts: 1474
Location: Witchspace
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:
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

_________________
Bounty Scanner
Number 935


Top
   
PostPosted: Mon Feb 06, 2017 12:26 pm 
Offline
Commodore
Commodore
User avatar

Joined: Thu Nov 07, 2013 10:21 pm
Posts: 281
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.


Top
   
PostPosted: Mon Feb 06, 2017 9:35 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Fri Mar 30, 2007 8:32 am
Posts: 1474
Location: Witchspace
Quote:
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.

_________________
Bounty Scanner
Number 935


Top
   
PostPosted: Mon Feb 06, 2017 9:48 pm 
Offline
Commodore
Commodore
User avatar

Joined: Thu Nov 07, 2013 10:21 pm
Posts: 281
668 warnings?!? I suspect something's gone awry with the normal generation when exporting the model.


Top
   
PostPosted: Mon Feb 06, 2017 9:50 pm 
Offline
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
User avatar

Joined: Sat Jul 04, 2009 9:31 pm
Posts: 12837
Location: Corke's Drift
668? The neighbour of the Beast?

_________________
The only good fnord is a dead fnord!


Top
   
PostPosted: Tue Feb 07, 2017 6:51 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Fri Mar 30, 2007 8:32 am
Posts: 1474
Location: Witchspace
Quote:
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.

_________________
Bounty Scanner
Number 935


Top
   
PostPosted: Tue Feb 07, 2017 11:38 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Fri Mar 30, 2007 8:32 am
Posts: 1474
Location: Witchspace
here is a video of the model among other things.

https://youtu.be/BTscgsXdzGQ

_________________
Bounty Scanner
Number 935


Top
   
PostPosted: Wed Mar 01, 2017 4:30 pm 
Offline
---- E L I T E ----
---- E L I T E ----
User avatar

Joined: Fri Mar 30, 2007 8:32 am
Posts: 1474
Location: Witchspace
To expand on this.

I found out that the
Code:
"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:
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()

_________________
Bounty Scanner
Number 935


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited