GUI Actions seem to be working alright now, they can be called from pretty much anywhere and don't require much work to change etc. Non-generic toolbars such as the one in the screenshot below affect each separate opened file, so if you say want on Model file to display wireframe, it will only set wireframe for the currently selected window. Also toolbars that aren't used by the window type are hidden every time you switch windows, so it should help keep stuff neat and tidy
I've fixed a bunch of bugs in the file browser, which actually was loading a folder several times every time it was refreshed -_-
The archive window is now fully working, and loads inner archives really really fast since all the file scanning is only done once each time the source file if opened.
My main focus at the moment is coming up with a decent model structure class that I can use across as many different formats as possible like I've been doing with image formats. The trouble is there is quite a bit of variation in how people like to store their 3d models and stuff, which means I have to study them more to get a better understanding
So I've been looking at Autodesk's 3DS format, which I have a Zelda TP pack for to experiment on. With that, basic support for TGA images has been added too
I've come up with a fairly generic Model Data Structure which is based on how gamecube models are packed. Basically in terms for NDS models, the polygon data is broken into four levels...
- shape (ie quad, quadstrip, triangles, etc)
- vertices (just a group name for the attributes below)
- attributes (ie position, normals, scale, restoreId, color, etc)
Not all vertices will have every type of attribute, which can be easily checked upon rendering using struct styled classes (this is java after all).
Each time I reimplement my NDS Model code, it always seems to be a little different from the last time >_<
The above was one particular model that really hated me in all my older implementations, and now it just works...A lot of other funky models now also display properly too however some of the ones I had gotten perfect now have some spastic vertices.
Found the problem. VTX_DIFF wasn't being added to the vertex list.
I am now able to get nearly every single NSMB character model displaying properly now! Models with Joint Scaling and Rotation, or funky stack IDs are the only ones that don't display properly, which covers pretty much all Zelda game models -_-
Gamecube models have also been updated to the new format structure, however they still require a lot of work.
The Model GUI has gone through a bunch of improvements, including basic lighting (or at least what is supposed to be lighting) and Perspective Transformations using the mouse buttons (ROTATE, MOVE, SCALE). Toggles for most of the interface have been added too.
A preliminary Key Listener has been added as well to allow for shortcuts etc in the future
NDS Roms are back and files can be exported from archives.
Fixed a bug that caused multiple reads per file while checking for compression, folders load quicker now.
I still need to build some properties windows to display stuff and create a resource manager so files can be linked with external files, such as external textures. Currently it will load the last texture selected by default if no texture is found within the model file.
While trying to figure out joint rotation in NDS models, I decided to have a go at drawing the joints on screen to help with debugging. I was kind of surprised at how easy it was to do and so now the model viewer is one step closer to total awesomeness
The joint rotation data is made up of 8 signed decimal values, which I figure sit in top right hand corner of the 4x4 matrix stack. Looking at "bomb_menbo", I've managed to get his left legs looking kinda right, but I'll have to do more trial and error to figure out how exactly these values are stored...
Although I haven't looked at them yet, the joint scaling is made up of 6 signed decimal values, however I have seen some impossible data (ie really really big values) pop up in these slots so I'm not completely sure on them yet...
I figured it out!!! Each joint had an used word which turns out to be a type of scaling factor. I only figured this out because I came across a model in NSBMD where the bird's wings had been obviously flipped in the model editor and hadn't had their transformations reset (for those not familiar with modelling...sorry). Each wing had an inverse scale factor so when I inputted that into the Rotation matrix...It displays properly
So in simple terms the 8 rotation values + the scaling factor are put into a 4x4 matrix like so...Note that for whatever reason when people represent a 4x4 matrix it is shown as top-bottom, left-right.
s = scale factor (signed)
r = rotation
[ s, r, r, 0]
[ r, r, r, 0]
[ r, r, r, 0]
[ 0, 0, 0, 1]
I'll assume that this scaling factor affects all joint data, hence why alot of models aren't sitting in their bounding boxes. Going to test that assumption out now...
Since figuring out how joint rotation data is stored, a very large number of models now display properly. The above is a Ben 10 model, which I've also pasted what comes up in KiwiDS's NSBMD model viewer so you can see the difference in accuracy
I haven't figured out how the joint scaling data is used. It's made up of 6 values, which is twice as many as any typical scaling (aka one for each axis)...however it seems to have little visual impact on how accurate the models look so I'm not that worried.
Pretty much all issues remaining lie in the bones data...There's still a few commands that aren't properly implemented if at all, plus there's still the issue with objects overwriting used stack locations due to wacky stack IDs...The funny thing is that KiwiDS's model viewer doesn't seem to face this problem and yet I've gone over his source code and cannot see how he implemented it so I'm guessing I have an older version of the code or something :/
Lol this is turning into a long post...Anyways figured out how to get models with wacky stack ids to display right. You keep a copy of each joint matrix in a separate stack and when each polygon is loaded you "restore" that joint matrix to the main stack, thus allowing multiple joints to use the same area in the stack...It was kind of obvious now that I think about it, however the fact was that all restore calls from vertices reference to the main stack and not the joints themselves. Zelda models now display well too now, though ironically Link is among the few that DON'T display properly yet -_-