Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
- JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
It is, isn't it...? Oh well, what's done is done.JohnnyWalker2001 wrote: PS - "Grim Ripper" is quite a clever name if you ask me
Now it seems we have a different problem: I tried to export-import a 3D model with 4 times the material sizes, and it came out wrong. I'm not doing something right, it's like the textures are tiled and multiplied a million times! Could any of you tell me what to do with the object in my 3D application? Should I export the materials or not? The tool (obj3do) is giving me all sorts of errors. A little guide would be most helpful.
But the problem is this: Even with my garbled model I could see facial animations still missing, even though they exist in the *.MAT. That probably means that another Multi/Sub material is needed in the 3D model, and it's not a *.MAT thing...
I'm converting the models with the tools I found in this thread,3doobj and obj3do, I have no idea how that works, I don't know how it reads nor how it writes. I only made the *.MAT exporter proggy above, which has no connection with the missing facial expressions. I _think_ that there's at least another sub-level of the material within the 3DO which needs to be exported. For example, I use 3Ds MAX, and within each of the materials there's another material (Multi/Sub), a container, which can contain more than one texture. And for example, the material for Manny's jaw is contained in one of these Multi/Subs, but in my opinion it should be a Multi/Sub itself, for containing the rest of the 10 textures, and not just the first one.
I tried with Blender, but didn't have much success either, but on the other hand, I'm not very experienced with Blender.
I don't know if I understood your question correctly, but I think the Wavefront OBJ exporter in 3DS Max exports in absolute too.
I wanted to make another 3DO to OBJ converter (and vice-versa), but I can't seem to find much information on how the stuff is stored in 3DO, and I can't find information on it's header either....
I tried with Blender, but didn't have much success either, but on the other hand, I'm not very experienced with Blender.
I don't know if I understood your question correctly, but I think the Wavefront OBJ exporter in 3DS Max exports in absolute too.
I wanted to make another 3DO to OBJ converter (and vice-versa), but I can't seem to find much information on how the stuff is stored in 3DO, and I can't find information on it's header either....
I did some attempts at fixing such a tool myself a while ago, my last attempt at fixing it is here, I'm not at all sure in what state it is:
https://github.com/somaen/residual-tool ... ools/tools
It's been a while since I looked into the files, but from what I remember model.cpp contains all (or atleast most of the logic) behind the loading of 3DOs. You can ignore the text-stuff, as that is only used in the demo I think. (You may however use that as output-format if you like.
A quick look-through says that the binary-format looks a bit like this (I seem to remember there being a semi-usable spec for the Jedi Knight format that is a bit more detailed, but that won't be completely usable since there are differencies):
4 bytes - signature "MODL"
Num_materials (4 bytes)
Material-list: Num_materials * 32 bytes (material-names with fixed length)
36 bytes of skipped data
_numGeosets - 4 bytes
GeoSet-list:
{
each geoset has:
_numMeshes: 4 bytes
Mesh-list:
{
a bit lengthy to describe here, look at Mesh::loadBinary(Common::SeekableReadStream *data, Material *materials[]) in model.cpp for details
}
}
4 bytes are skipped
_numHierNodes - 4 bytes
_hiernode-list:
{
ModelNode::loadBinary(Common::SeekableReadStream *data, ModelNode *hierNodes, const Model::Geoset *g) in model.cpp
}
_radius - 4 bytes (float)
skip 36 bytes
one vector (3 * 4 bytes) (float)
Not the cleanest description, but it should at least get you started, maybe the tool-makers in this thread could give out their sources to save you some time.
https://github.com/somaen/residual-tool ... ools/tools
It's been a while since I looked into the files, but from what I remember model.cpp contains all (or atleast most of the logic) behind the loading of 3DOs. You can ignore the text-stuff, as that is only used in the demo I think. (You may however use that as output-format if you like.
A quick look-through says that the binary-format looks a bit like this (I seem to remember there being a semi-usable spec for the Jedi Knight format that is a bit more detailed, but that won't be completely usable since there are differencies):
4 bytes - signature "MODL"
Num_materials (4 bytes)
Material-list: Num_materials * 32 bytes (material-names with fixed length)
36 bytes of skipped data
_numGeosets - 4 bytes
GeoSet-list:
{
each geoset has:
_numMeshes: 4 bytes
Mesh-list:
{
a bit lengthy to describe here, look at Mesh::loadBinary(Common::SeekableReadStream *data, Material *materials[]) in model.cpp for details
}
}
4 bytes are skipped
_numHierNodes - 4 bytes
_hiernode-list:
{
ModelNode::loadBinary(Common::SeekableReadStream *data, ModelNode *hierNodes, const Model::Geoset *g) in model.cpp
}
_radius - 4 bytes (float)
skip 36 bytes
one vector (3 * 4 bytes) (float)
Not the cleanest description, but it should at least get you started, maybe the tool-makers in this thread could give out their sources to save you some time.
Woot! Thank you! As soon as I have some more free time, I'll have a serious sit-down.
P.S: Compiled and ran your tool, and as you said, it's very WIP, but it's more than I could have asked for. There are no materials supported, but as long as you import it as single mesh, it works, it just doesn't position the object correctly. No matter, it's more than a jumpstart, but the thing is, I haven't worked with C++ in a looooong time, I guess when it comes to object-oriented languages, I've worked more with C# (or C-Crap as I like to call it) and Java...
I think I can get this to work (maybe not), but it could take a long time, since I'm not accustomed to C++. I'll do my best, but I'm not promising anything...
P.P.S.: While I still have you here, I can't seem to manage to get the textures (without modifying the 3DO) to display at the correct size. How did you guys manage that? For example, If I get a 512x512 image into the *.MAT it looks like this:
The correct dimensions are correct in the MAT too: 0x 00 02 00 00 (512 decimal)
P.S: Compiled and ran your tool, and as you said, it's very WIP, but it's more than I could have asked for. There are no materials supported, but as long as you import it as single mesh, it works, it just doesn't position the object correctly. No matter, it's more than a jumpstart, but the thing is, I haven't worked with C++ in a looooong time, I guess when it comes to object-oriented languages, I've worked more with C# (or C-Crap as I like to call it) and Java...
I think I can get this to work (maybe not), but it could take a long time, since I'm not accustomed to C++. I'll do my best, but I'm not promising anything...
P.P.S.: While I still have you here, I can't seem to manage to get the textures (without modifying the 3DO) to display at the correct size. How did you guys manage that? For example, If I get a 512x512 image into the *.MAT it looks like this:
The correct dimensions are correct in the MAT too: 0x 00 02 00 00 (512 decimal)
Well, you can't without modifying the 3DO, the texture-coordinates are absolutes like I said, which means that positiion (10,20) in a 256x256 will differ from position (10,20) in an upscaled 512x512-version of the same texture.
Relative coordinates would have worked in both cases, as 10% into the texture will be the same position in a big texture as well as a small one.
Relative coordinates would have worked in both cases, as 10% into the texture will be the same position in a big texture as well as a small one.
I know, I just thought that you had figured out a way, because of this post:
http://forums.residualvm.org/viewtopic.php?p=849#849
It's only on the second page of this thread, so I thought that no 3DO work had been done at that point.
http://forums.residualvm.org/viewtopic.php?p=849#849
It's only on the second page of this thread, so I thought that no 3DO work had been done at that point.
I _think_ I _may_ have gotten it to work, without coding anything. Blender plays hell with the normals though. Will keep you posted if I have any notable success.
UPDATE: I managed to get facial animations and everything else to work with the existing tools (obj3do / 3doobj), but I managed to do that only if I use same size materials. How did you manage to use bigger sized(dimension) materials? What did you do with the model in order to allow that?
UPDATE: OK, I managed to do everything, but it's a CRAP process:
Use the tools to create an OBJ file, then edit the *.mtl file to contain the missing images (not MATs but TGAs or something similar (BMP didnt't work with Blender on my end) ).
Then import to blender (to coordinate with the textures, in 3DSMax you'd have to do it manually), then export to 3DSMax, then scale the UV's four times (yes, scale the UV's, which makes it impossible to see how it will look like ingame), I do this with a script in MAX, since manually it's virtually imposssible to be precise. Then export back to Blender (I couldn't get the exported file from MAX to compile with the tools, I always got a NORMAL NOT UPDATED error), and resave as an OBJ, and finally use the tools to make a 3DO... Oh and yeah, Blender does a terrible job with normals and smoothing groups.
Please tell me you had a better way
Here's a test with a 512x512 chest (nothing improved just a resized image):
P.S.: a quote from Wiki:
UPDATE: I managed to get facial animations and everything else to work with the existing tools (obj3do / 3doobj), but I managed to do that only if I use same size materials. How did you manage to use bigger sized(dimension) materials? What did you do with the model in order to allow that?
UPDATE: OK, I managed to do everything, but it's a CRAP process:
Use the tools to create an OBJ file, then edit the *.mtl file to contain the missing images (not MATs but TGAs or something similar (BMP didnt't work with Blender on my end) ).
Then import to blender (to coordinate with the textures, in 3DSMax you'd have to do it manually), then export to 3DSMax, then scale the UV's four times (yes, scale the UV's, which makes it impossible to see how it will look like ingame), I do this with a script in MAX, since manually it's virtually imposssible to be precise. Then export back to Blender (I couldn't get the exported file from MAX to compile with the tools, I always got a NORMAL NOT UPDATED error), and resave as an OBJ, and finally use the tools to make a 3DO... Oh and yeah, Blender does a terrible job with normals and smoothing groups.
Please tell me you had a better way
Here's a test with a 512x512 chest (nothing improved just a resized image):
P.S.: a quote from Wiki:
Relative and absolute indices
OBJ files, due to their list structure, are able to reference vertices, normals, etc. either by their absolute (1-indexed) list position, or relatively by using negative indices and counting backwards. However, not all software supports the latter approach, and conversely some software inherently writes only the latter form (due to the convenience of appending elements without needing to recalculate vertex offsets, etc.), leading to occasional incompatibilities.
All right, I worked it out. I downloaded the enhanced 3D verison of Manny that blacksad made, and worked on it a bit.
Enhanced Manny is fixed, complete with facial expressions.
Here's a preview, although YouTube compressed it quite a bit (looks a lot better in-game):
See Handsome Manny!
And here's the datausr.lab with everything in working order:
Download Handsome Manny!
Let's get to it then...
Enhanced Manny is fixed, complete with facial expressions.
Here's a preview, although YouTube compressed it quite a bit (looks a lot better in-game):
See Handsome Manny!
And here's the datausr.lab with everything in working order:
Download Handsome Manny!
Let's get to it then...