D
Deleted User
Guest
Well right now I am trying to decide to release a tutorial on a manual, long process for incorporating simple edits or making an application that applies my research to allow almost completely new models.
The thing that is forcing my laziness upon me is the fact that that you would only be able to use the same amount of vertices as the original model and you need to make your new model by changing the positions from the original model, so no importing external models.
Ever since my computer was formatted I lost my big files of model research
This is all I have had time to recreate:
Code:
vn:
01 = 0.007874016
02 = 0.01574803
03 = 0.02362205
04 = 0.0314906
05 = 0.03937008
06 = 0.04724409
07 = 0.05511811
08 = 0.06299213
09 = 0.07086614
0A = 0.07874016
0B = 0.08661418
0C = 0.09448819
0D = 0.1023622
0E = 0.1102362
0F = 0.1181102
10 = 0.1259843
11 = 0.1338583
12 = 0.1417323
Last edited by ,
D
Deleted User
Guest
I am going to leave this here because it isn't worth making a thread about.
BLUE: What seems like the header for each set of V (Vertex), VN (Vertex Normal), and VT (Vertex Texture)
RED: The vertex (it's split into 3 sections [X, Y, Z] in that order) 00 00 (X) | 00 00 (Y) | 00 00 (Z)
One increment (01) in the first half of a segment (01 00) is equal to 0.0003045535.
One increment (01) in the second half of a segment (00 01) is equal to 0.07796571.
One increment (01) on both halves of a segment (01 01) is equal to 0.07827026.
Notice that 01 01 equals 0.00030455 (0.0003045535 rounded to the nearest 100 millionth) plus 0.0779571.
Also note that the numbers aren't always rounded at the 100 millionth mark. They are rounded at the place that ends 00 XX. For example: 34 36 is 4.225985 (goes to 1 millionth place). 34 00 is 0.01583678 (goes to the 100 millionth place). 00 36 is 4.210148 (goes to the 1 millionth place). 0.01583678 rounded to the nearest millionth is 0.015837. 0.015837 + 4.210148 = 4.225985. Still researching the exact equation to find a number based just on the Bytes.
GREEN: The vertex normal (split into three sections [X, Y, Z] in that order)
One increment (01) is 0.007874016. Since there is only one segment per axis you would expect it to be easier to just multiply 0.007874016 by the decimal value of the byte, well that is not the case as results from Ohana3dsRebirth vary. 0.007874016 * 2 = 0.015748032. However Ohana3ds rounds it up one, but the places vary per exportation.
GREY: No idea what this is. Doesn't have a visible effect from what I can see but is probably something like a bone position because those do not show up in OBJ files. Now that I think about it, this is most likely a bone.
PURPLE: The vertex texture (split into two sections [U, V] in that order (u and v are coordinates for 2d textures to be mapped on a 3d model))
One increment (01) in the first half of the segment is equal to 3.020859E-05 (0.00003020859)
One increment (01) in the second half of the segment is equal to 0.007733399
One increment (01) on both halves of the segment is equal to 0.007763607
Not sure about the way to find the decimal value on these yet either.
If anybody is curious, the most productive way to design a model importer (from my eyes) would be to do the following:
- Create a list of all possible Vertices, Vertex Normals, and Vertex Textures
- Create a pointer file system where the user would export a model from Ohana3dsRebirth, put it into a different modeling software (such as blender) and then export it to a different file from there (creating the Ohana version of a OBJ and the original Wavefront version of a OBJ) and find the exact same vertices, vertex normals, and vertex textures from the same object in each file and create a pointer file telling the system where the vertex from blender belongs in the file from Ohana
- After making the pointer file, edit the model (not adding nor subtracting vertices) in the same software used to make the new OBJ file used for the pointer and replace the OBJ used for the pointer with the edited version (leaving the pointer file to show where the edited vertices come into play)
- A: Try and import this new model (after replacing the Ohana version with the new vertices thanks to the pointer file) and plug it into smash since it will have all of the same object names
B: If A doesn't work, you will need a tool to create a pointer file for the original exported Ohana obj to the MBN file that converts the vertices to bytes and finds their location in the MBN and creates the pointer. Then you can use the tool to move the edited vertices into the MBN manually and it then allows the model to be played in game.
EDIT: If anything is made or developed using this information, please, cite me. I know it probably common knowledge from anybody who has fucked around in the models and stuff so please, just cite me if u use this.
EDIT: I forgot to mention that these small little edits do work in game, I have no idea how a full model override would be handled, especially since I haven't worked on animations yet
EDIT: This method only works for the c0X models. The h0X models have a different format.
Last edited by ,
Nice guide and, about a month ago I was hex editing Link's mbn and on one of my tests I ended up stretching out his leg xD
I am going to leave this here because it isn't worth making a thread about.
BLUE: What seems like the header for each set of V (Vertex), VN (Vertex Normal), and VT (Vertex Texture)
RED: The vertex (it's split into 3 sections [X, Y, Z] in that order) 00 00 (X) | 00 00 (Y) | 00 00 (Z)
One increment (01) in the first half of a segment (01 00) is equal to 0.0003045535.
One increment (01) in the second half of a segment (00 01) is equal to 0.07796571.
One increment (01) on both halves of a segment (01 01) is equal to 0.07827026.
Notice that 01 01 equals 0.00030455 (0.0003045535 rounded to the nearest 100 millionth) plus 0.0779571.
Also note that the numbers aren't always rounded at the 100 millionth mark. They are rounded at the place that ends 00 XX. For example: 34 36 is 4.225985 (goes to 1 millionth place). 34 00 is 0.01583678 (goes to the 100 millionth place). 00 36 is 4.210148 (goes to the 1 millionth place). 0.01583678 rounded to the nearest millionth is 0.015837. 0.015837 + 4.210148 = 4.225985. Still researching the exact equation to find a number based just on the Bytes.
GREEN: The vertex normal (split into three sections [X, Y, Z] in that order)
One increment (01) is 0.007874016. Since there is only one segment per axis you would expect it to be easier to just multiply 0.007874016 by the decimal value of the byte, well that is not the case as results from Ohana3dsRebirth vary. 0.007874016 * 2 = 0.015748032. However Ohana3ds rounds it up one, but the places vary per exportation.
GREY: No idea what this is. Doesn't have a visible effect from what I can see but is probably something like a bone position because those do not show up in OBJ files. Now that I think about it, this is most likely a bone.
PURPLE: The vertex texture (split into two sections [U, V] in that order (u and v are coordinates for 2d textures to be mapped on a 3d model))
One increment (01) in the first half of the segment is equal to 3.020859E-05 (0.00003020859)
One increment (01) in the second half of the segment is equal to 0.007733399
One increment (01) on both halves of the segment is equal to 0.007763607
Not sure about the way to find the decimal value on these yet either.
If anybody is curious, the most productive way to design a model importer (from my eyes) would be to do the following:
If anybody can and wants to check my info, please do. I do not want to be spreading false information. Oh, and by editing the vertex textures you can create more user friendly texture patterns.
- Create a list of all possible Vertices, Vertex Normals, and Vertex Textures
- Create a pointer file system where the user would export a model from Ohana3dsRebirth, put it into a different modeling software (such as blender) and then export it to a different file from there (creating the Ohana version of a OBJ and the original Wavefront version of a OBJ) and find the exact same vertices, vertex normals, and vertex textures from the same object in each file and create a pointer file telling the system where the vertex from blender belongs in the file from Ohana
- After making the pointer file, edit the model (not adding nor subtracting vertices) in the same software used to make the new OBJ file used for the pointer and replace the OBJ used for the pointer with the edited version (leaving the pointer file to show where the edited vertices come into play)
- A: Try and import this new model (after replacing the Ohana version with the new vertices thanks to the pointer file) and plug it into smash since it will have all of the same object names
B: If A doesn't work, you will need a tool to create a pointer file for the original exported Ohana obj to the MBN file that converts the vertices to bytes and finds their location in the MBN and creates the pointer. Then you can use the tool to move the edited vertices into the MBN manually and it then allows the model to be played in game.
EDIT: If anything is made or developed using this information, please, cite me. I know it probably common knowledge from anybody who has fucked around in the models and stuff so please, just cite me if u use this.
EDIT: I forgot to mention that these small little edits do work in game, I have no idea how a full model override would be handled, especially since I haven't worked on animations yet
D
Deleted User
Guest
sounds like something i would do. And when I was originally modding the Kirby model I manipulated the model to give him a hole in the back of his (body?) and gave him a unicorn horn
depending on what do you want to download but for texture mods is really fast
before i forgot i still making the corrin pack, but i need a bigger pic to make the csp, @edd323, do yo have a better pic
Mods take a while to load. Be patient
--------------------- MERGED ---------------------------
Use smash selector and make one smash game with your favorite Corrins and make a smash2 with the others.
Similar threads
- No one is chatting at the moment.
-
@
Psionic Roshambo:
I wonder if I could recommend that to some emulation devs that perhaps the sound could use some smoothing out to simulate those old TVs -
@
Psionic Roshambo:
I think a few of the early systems could benefit from that, at least up to the 8 bit generation, by the 16 bit generation I think TVs had gotten a lot better in almost every way
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
it says it only works for the original R4, R4i Gold (r4ids.cn), R4iDSN (r4idsn.com) and Acekard R.P.G. -
-
-
-
-
-
@
Psionic Roshambo:
Just give it a try, but honestly if you have a 3DS you can play DS games without a card just off the internal SD card
-
-
-
-
-
-
-
