New utility: S3O Normalizer

[FLOZi]

As is well known to most people who use it, Upspring messes up the normals of your model when you scale an object in it. It has its own inbuilt functions to deal with that, but they also have the effect of changing how vertices are welded (smoothing), which may not be desired.


fig 1. Old 'n' Busted vs. New Hotness

I've written a small Python program to batch (or individually) fix s3os with rescaled normals. All this program does is scale normals back to their correct unit length.


fig 2. Scaled objects with scaled normals vs. uniform, unit length normals

S3ONorm is pretty easy to use, here's the usage text:

Code: Select all

S3O Normalizer v0.15 - by FLOZi

usage: s3onorm.py [options] [infile]

Options:

 -s --silent     Silent mode, no written output (overrides -v)
 -v --verbose    Print out all s3o vertex info and list of changes
 -a --auto       Auto scan for all s3os in directory and fix (default mode)
 -b --backup     Copy original files to /backup subdir
 -f --force      Force all normals to be recalculated
 -h --help       Print this usage summary!

But if you just run the program without any options or filename (.py should be associated with Python on install with windows, so you can just put it in the folder with your s3os and double click) it will prompt you to run auto mode and ask if it should run silently.

I make no extraneous claims about the safety of this program. I can't guarantee that it won't murder your neighbours, run off with your fianc├®e or eat your children.

Even worse it could tamper with your s3os so do be careful if you have no version control or safe copies, and if you don't trust it/me, , for crying out loud use --backup mode or just don't use it at all.



Let me know about any problems or issues and maybe I will look into it. No, I will not fix Upspring to have this option

Enjoy!

p.s. To any Python (or general) programmers, forgive me my sins for they are undoubtedly many.

edit: Updated to v0.15

• fixes an issue with pieces whose number of vertices doesn't match the size of the vertex table reading past the end of the file.
• fixes an issue with auto processing files where the data to written was not cleared from the previous file
• Adds -f --force option, forces all normals to be recalculated

edit: Updated to v0.16

• Fixes a crash when a NaN is found
• Fixed a possible problem with 0 vertex pieces

[MidKnight]

What version of py does this use? I can't get it to run.

Code: Select all

HexToInt
    return int(hexstr, 16)
ValueError: invalid literal for int() with base 16: ''

[FLOZi]

It should run fine in 2.4 at least if not earlier than that. Can I take a look at the s3o you are trying to use?

[FLOZi]

Found the issue , first post updated with v0.15. Many apologies to anyone who already downloaded it, you should update.

edit: v0.16 seems pretty solid now. It is *slow* though, because of the way it reads through files instead of reading the whole thing into memory. It'll take me a while to rewrite, but it should work as is decently for now.

[FLOZi]

Nevermind, this is now totally useless. Lock or delete thread.

[Pxtl]

Nevermind, this is now totally useless. Lock or delete thread.

Not wanting to crawl through the code, what does the linked change do? The Spring rendering code now re-normalizes the normals down to unit-vectors so the scale of the normals is no longer relevent?

[jK]

Correct the scale isn't relevant anymore, but their facing still is and not all scalings preserve the facing.
Only scalar ones do (= all 3 axis are scaled by the exact same amount) like making a model twice as large, but making a tank wider/lower/thinner will change the facing of the normals and they need to be recomputed.

[bobthedinosaur]

would flozi's normalize work on thinned/widened parts?

[FLOZi]

would flozi's normalize work on thinned/widened parts?

Mine just does exactly what kloots 1 line engine patch does, only much slower.

[Pxtl]

Correct the scale isn't relevant anymore, but their facing still is and not all scalings preserve the facing.
Only scalar ones do (= all 3 axis are scaled by the exact same amount) like making a model twice as large, but making a tank wider/lower/thinner will change the facing of the normals and they need to be recomputed.

Good to know. I'd wager only 1% of resizings are stretch operations - that kind of modelling would be done in the modelling app. Upspring's rescaling is more useful when you're adjusting the size of stuff as they appear in-game.

So, in other words, the scaling bug is all-but-gone. Can we get a Cob/Lua command to resize a part now?

[Neddie]

So, would you still like this thread closed?

[FLOZi]

May as well.