I have a problem concerning outfits/armors. I have so many armors from different people that I’ve had to edit the numbers a bit (since sometimes two different creators use the same numbers). Since I know next to nothing about modelling, what I still learned sometime during the last two years, was that I could edit things with MDBConfig. The way I’ve done things is to open the mdb file in MDBConfig, and there I’ve changed the packet name (or rather the number at the end) and then copied this new packet name and saved the new mdb file under that name. It sort of works, but recently I discovered that when opening and testing the armor in the toolset, the tinting (I think it’s called) of the colors have gone wrong. Maybe I’m doing stuff the wrong way? Maybe you actually can’t change numbers this way? Maybe someone here could help me?
Edit: Maybe it has something to do with the UTI files or the dds, tga files somehow pointing to the wrong thing when I change the numbers in the packet and file name?
As I said, I’ve only changed the packet name and then the copied that new name and named the whole file after that name.
I investigated some more and as it turns out, as far as I can see, two of the outfits I changed the numbers for actually look identical when switching between the changed file and the unchanged file (difficult to explain but I remove and add the unchanged and the changed in the override folder) and those two outfits are the important ones. Another outfit however looks weird with the tint map and I haven’t changed the tint map name at all.
I’m now guessing maybe I have some conflict in my override folder or something, even though it doesn’t seem that way…
The one issue I know about is that Java doesn’t handle the floating point precision on a tiny Specular value well. I meant to look for a solution but never got to it. The mesh should pass through untouched.
Thanks for the answers guys! Exactly as you say, Rashi, the armor looks faded almost all the time as soon as I’ve used MDBConfig and changed numbers. Sometimes I’ve just ignored it, but when it comes to important NPCs, like companions, I want it to look as good as possible (and to not take away from Rashi’s, in this particular case, hard work).
I’ll look into MDBCloner tomorrow. Is it hard to use? Does it work in the same way as MDBConfig? It’s late where I live and I need to sleep now.
Apparently, MDBConfig doesn’t take into account the glossiness value (according to the 3ds max screenshots by Rashi: Before MDBConfig
After MDBConfig)
3ds max allows the maximum values here below:
So maybe the “Specular power” of 0.2999999 in MDBConfig should be 0.03 by the way?
My understanding of “specular” and “glossiness” is the following:
for 3DS max, the specular level is how shiny the object is, on a scale from 0 to 999 (the higher the shinier)
glossiness corresponds to the size of the cercle of reflexion of light on the object, with a scale from 0 to 1, the larger the value the smaller the circle.
My understanding is that glossiness comes from the Specular power, in combination with the transparency level in the normal map. I’m not sure where else that could be stored.
The value in the Specular power field is just what came from the file. I wonder though if there is some hidden encoding in the data we’re not aware of?
Looking at the hex data for the floor RIGD packet of the TL_SI_XXXX_01.mdb time model, I get a value of ffff6f41. In a floating point converter with endianness swapped that translates to 15.0, but in the MDBConfig I get 6.9055E-41 for specular value. So yeah, Java is effing it up for some reason; I’m not sure why just yet. I may need to implement logging so I can see what’s going on under the hood.
After looking through the code, my best guess is it is having some issue with the endian bitness flipping. I used some code off the web for that, but perhaps it’s got a bug in the high order bit? Anyway, still investigating.
