Ok, I made some progress here. Code (Text): -------------------------------------- Sonic R models format (WIP). By softman --------------------------------------- struct VERTEX_PART // 16 bytes { word x, y, z // integer part of float byte unknown[10] } struct MDL_PART_TRI // variable size? (16 bytes...) { word a, b, c word ta, tb, tc // texture coordinates. Hopefully... dword null } // consists of 6 points (probably quad split in 2 triangles, // but I'm not sure...) struct MDL_PART_POLY // variable size? (20 bytes...) { word a, b, c, d, e, f word unk1, unk2 dword null } // ========================================= // FILE LAYOUTS // Every chunk (part of the object) begins with dword OBJECT BEGIN dword num_verts [data] // VERTEX_PART*num_verts ... dword num_parts [data] /* MDL_PART_x * num_parts. This is the most confusing part, because there is no way to find out (for now) which part is supposed to go next. So, you can only rip someting by hands (take a look at first three words of the struct). Most of the time the first struct is TRI, but the rest is somewhat strange (many parts of variable size for example) */ ... dword unknown OBJECT END NEXT OBJECT... // ========================================= I used .obj format for testing. Like so: Code (Text): v x1, y1, z1 v x2, y2, z2 ... # n vertices g some_label f a, b, c, d, e, f f a2, b2, c2, d2, e2, f2 ... # n polygons (that is why I named struct as "POLY") I only tested sonic_h.bin model. Here is sonic's body part (partialy correct) Finally, here are offsets (decimal) for every sonic's part in sonic_h.bin Code (Text): 0: body (34 vertices) 1268: head (61 vertices) 3540: left hand (28 vertices) 4180: left boot (40 vertices) 5192: left shoulder (12 vertices) 5456: left leg (12 vertices) 5720: right hand 6360: right boot 7372: right shoulder 7636: right leg 7900: tail (6 vertices) You can test this by zeroing entire object (except for the first dword of structs) as well as to try a different model. I'll try to find out more on this, but do not expect anything real very soon. But sure, any help would be appreciated
Forgive my ignorance, but would a glidewrapper be able to work for Sonic R (either zeckensack's Glide wrapper, or nGlide)? It'd make it look better than in 640x480.
I imagine if you created a DLL with the same name, etc. and rewrote all its calls -- you could do whatever you want with the video output.
Binary + source: http://magicstone.de/dzd/random/sonicr/SonicR-1.rar rmodel.c and rmodel.h for details, also some of the "unknowns" in the vertex struct are normals, I haven't changed the naming yet, though. The drawing functions tell you where they are. Camera is controlled via mouse and WASD & TFGH (slower), F9 resets the camera position, numpad +/- select which model part to render (defaults to all). Probably somewhat buggy and all, but hey, it works. Ah, oh yeah, command line is: "SonicR.exe <model file> <texture file>"
Wow, that was surprisingly fast. Thank you! Well, I had some doubts on it, because there were .grd files (which are probably vertex colors or normals).
total: I'm honestly not 100% sure either, but it sure looks like they're normals. Will look into those .grd files some more. MainMemory: I suck when it comes to making editors for 3D games, so you shouldn't count on me here. I guess I'll try - maybe in C#, which I'm "learning" at the moment -, but it's probably gonna end in failure :P
Wow, that was quick :D I may try to port some of these to SADX. If you get an export function working :P
Exporting the individual body parts shouldn't be much of a problem, proper animations and all are something else entirely. Well, I am looking into the limb structures and animation currently - the, in Sonic's case, san*.bin files - but limb rotations are giving me a headache... they come out backwards or something? (Also, disregard the lighting, it's junk. And this is san5.bin, btw, Sonic's standing pose ex. from the character select)
hey, I also looked in them :P That is what I figured out: Code (Text): struct keyframe // obj_transform*num_objects? { obj_transform model[num_objects] } struct obj_transform // 24? { dword unknown[3] // more likely positions, but nothing happens if changed...maybe dword rot_x, rot_y, rot_z } As for rotations, have you tried this? And here are some macros Code (Text): /*----------------------------------------------------------------------------------*/ #define M_PI 3.1415926535897932 #define toFIXED(a) ((FIXED)(65536.0 * (a))) #define POStoFIXED(x,y,z) {toFIXED(x),toFIXED(y),toFIXED(z)} #define ATTRIBUTE(f,s,t,c,g,a,d,o) {f,(s)|(((d)>>16)&0x1c)|(o),t,(a)|(((d)>>24)&0xc0),c,g,(d)&0x3f} #define SPR_ATTRIBUTE(t,c,g,a,d) {t,(a)|(((d)>>24)&0xc0),c,g,(d)&0x0f3f} #define DEGtoANG(d) ((ANGLE)((65536.0 * (d)) / 360.0)) #define RADtoANG(d) ((ANGLE)((65536.0 * (d)) / (2*M_PI))) #define RGB(r,g,b) (0x8000|((b)<<10)|((g)<<5)|(r)) #define DGTtoRGB(c) (0x8000|(((c)&0x0f00)<<3)|(((c)&0x4000)>>4)|(((c)&0x00f0)<<2)|(((c)&0x2000)>>8)|(((c)&0x000f)<<1)|(((c)&0x1000)>>12)) Also, the last dword in the file is somehow related to other animations...
So, grd files are vertices "colors" (let's name it "shading factor"). Every value (one per vertex) varies from 0x0000 (darkest\black) to 0xFFFF (brightest\white) Code (Text): // repeats 48 times struct light_data // num_verts*sizeof(word) { word verts_shading[num_verts] } -------- looking forward for v0.2 of model viewer, xdaniel PS: I'll make bin2obj soon...maybe
oh snap, this is what I get for not paying attention. This is QUITE awesome, though how do you display full models like that Sonic there (unless it can't be done in this build)
Just tested it out. On Sonic's model, there are UV errors on all of his body parts, yet when you look at them in the uv editor, they look fine.
Download v0.2: http://magicstone.de/dzd/random/sonicr/SonicR-2.rar Honestly haven't worked on it at all the last few days (only rebuild it earlier), so no new screenshot; limb rotations are still wrong. If anyone wants to try and mess with them, check rm_PositionModel in rmodel.c for how I interpret them currently. It's most likely quite off :P In addition to the controls from v0.1, you can now select the animation frame to use by pressing F1 and F2 to go through them. Also, the command line changed: "SonicR.exe <model file> <animation file> <texture file>", so ex. "SonicR.exe sonic_h.bin san5.bin player00.raw". Will look into it again over the weekend, maybe.
why not use BinaryReader instead? --- And for those, who interested (anyone?), I'm no longer working on sr_bin2obj, because .obj is crap. I like maxscript+custom_binary_format better. ps: and seriously, since there is almost no interest in this, should I bother writing anything here?
