Grim Fandango Deluxe - Original Thread [Locked]

JohnnyWalker2001 · Post by **JohnnyWalker2001** » Tue Jun 26, 2012 7:33 pm

Woot! Very exciting indeed! I'll start playing around with this soon. Nice going, Nitrus!

PS - "Grim Ripper" is quite a clever name if you ask me

Nitrus · Post by **Nitrus** » Wed Jun 27, 2012 1:34 am

JohnnyWalker2001 wrote: PS - "Grim Ripper" is quite a clever name if you ask me

It is, isn't it...? Oh well, what's done is done.

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...

somaen · Post by **somaen** » Wed Jun 27, 2012 12:09 pm

I seem to remember the tex-coords in the 3DO-files being the inverse of what OpenGL expects (i.e. absolute coordinates, not relative). How are you calcing the new coords?

Nitrus · Post by **Nitrus** » Wed Jun 27, 2012 2:34 pm

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....

somaen · Post by **somaen** » Wed Jun 27, 2012 8:08 pm

Well, there is code for loading it in residualvm, if you want to read through that. The format is proprietary lucasarts, and not the exact same as in Jedi Knight.

Nitrus · Post by **Nitrus** » Wed Jun 27, 2012 8:21 pm

Hmmm, I might just try that. Is it included in the regular source? (The one I could get from git)

UPDATE: I looked in engines/grim/model.cpp, and it's a bit tough to pinpoint the class/classes I would need to look at most. Could you help me out a bit?

somaen · Post by **somaen** » Wed Jun 27, 2012 11:10 pm

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.

Nitrus · Post by **Nitrus** » Wed Jun 27, 2012 11:35 pm

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)

somaen · Post by **somaen** » Thu Jun 28, 2012 9:51 am

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.

Nitrus · Post by **Nitrus** » Thu Jun 28, 2012 12:01 pm

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.

Jon N/A · Post by **Jon N/A** » Thu Jun 28, 2012 1:00 pm

I thought I saw something about that in the early days... Was not sure enough to tell you...
Anyway, great job Nitrus! Keep up the nice work!

somaen · Post by **somaen** » Thu Jun 28, 2012 10:32 pm

Well, the other solution is to compile ResidualVM with a hardcoded multiplication on the tex-coords. I don't remember if it was that or the patched 3DOs we used there.

Nitrus · Post by **Nitrus** » Thu Jun 28, 2012 11:45 pm

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:

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.

Nitrus · Post by **Nitrus** » Sat Jun 30, 2012 3:44 pm

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...

pokito · Post by **pokito** » Sat Jun 30, 2012 3:50 pm

You made my day. Thanks !

I believe the next step is to make the same with the others costumes of Manny, right ?

You guys are awesome !