Well the global rotation of the model itself is no problem, I mean, it's easy to just rotate the model by 90 degrees on two of the axes in Blender, and then back again when you're done.
And if the model is even slightly recognizable (like the case with Meche up there), then that's no problem. All we do is model new pieces on top of the old ones, for example, we could model a hand or fingers, and then just position them in the way they are with the imported model.
Which leads to my next question: When you update your modified model (convert back to 3DO), will it come out OK in-game? I mean, if we positioned the new pieces in the same way as they were when imported, the rotations you talked about are going to stay the same right?
By the way, I got myself familiar a bit with the 3do MODL, do you remember where these rotations are kept exactly? Because if it's different for every model (I mean if you manually need to insert rotation code for each and every 3do), then it's not worth bothering with.
Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
-
cplhenshaw
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
There is a very useful writeup of the MODL format here.
http://wiki.multimedia.cx/index.php?title=MODL
After all the definitions of the pieces of the model there's a hierarchy of "Nodes" which tell you how the pieces are parented to each other, and for each piece gives the offset from it's parent and well as a pitch, yaw and roll to orient the piece.
When Meche comes out sitting in a pose, these are not the rotations I'm talking about, that's just the default orientation of the pieces. Some of the later models are in very bizarre positions (legs folded back inside the chest, all ontop of itself etc), and you have to apply these extra rotations to get the model to it's default pose. I'm not really sure what the purpose of it is, but I'm assuming it would be quite difficult to remodel each piece without seeing it's proper position in the whole.
http://wiki.multimedia.cx/index.php?title=MODL
After all the definitions of the pieces of the model there's a hierarchy of "Nodes" which tell you how the pieces are parented to each other, and for each piece gives the offset from it's parent and well as a pitch, yaw and roll to orient the piece.
When Meche comes out sitting in a pose, these are not the rotations I'm talking about, that's just the default orientation of the pieces. Some of the later models are in very bizarre positions (legs folded back inside the chest, all ontop of itself etc), and you have to apply these extra rotations to get the model to it's default pose. I'm not really sure what the purpose of it is, but I'm assuming it would be quite difficult to remodel each piece without seeing it's proper position in the whole.
Could you give an example as to one of the models (with it's 3do name if possible) that does that? I'd like to take a look, and see if I can figure something out, although I doubt that I could be of help with this one...
EDIT: OK, I can see it with gatekeeper.3do from DATA004.LAB.
EDIT: OK yet again, I can see the data for each node:
12 bytes pivot
12 bytes position
4 bytes pitch
4 bytes yaw
4 bytes roll
If I understood you correctly, you ignore the pitch, yaw and roll? Or I misunderstood?
If that's the case, then I think that it's not that hard, considering ResidualVM developers already did the work.
For example, in Grim Fandango:
Pitch is rotation around X
Yaw is rotation around Z
Roll is rotation around Y
The values should be grabbed as radian angles, and then the math can be applied on the vertex coordinates (relative to the pivot or parent of the object (this is an assumption from experience) ).
Take a look at math/rotation3d.h in residual's source, or you could take a look in somaen's tools here, which he pointed out to me in a previous post.
I think it would get clearer once you do this. I'd love to work on this a bit myself, but I'm afraid I haven't got any time, I'm working under a deadline
P.S.: 48 bytes are unknown after this
EDIT: OK, I can see it with gatekeeper.3do from DATA004.LAB.
EDIT: OK yet again, I can see the data for each node:
12 bytes pivot
12 bytes position
4 bytes pitch
4 bytes yaw
4 bytes roll
If I understood you correctly, you ignore the pitch, yaw and roll? Or I misunderstood?
If that's the case, then I think that it's not that hard, considering ResidualVM developers already did the work.
For example, in Grim Fandango:
Pitch is rotation around X
Yaw is rotation around Z
Roll is rotation around Y
The values should be grabbed as radian angles, and then the math can be applied on the vertex coordinates (relative to the pivot or parent of the object (this is an assumption from experience) ).
Take a look at math/rotation3d.h in residual's source, or you could take a look in somaen's tools here, which he pointed out to me in a previous post.
I think it would get clearer once you do this. I'd love to work on this a bit myself, but I'm afraid I haven't got any time, I'm working under a deadline
P.S.: 48 bytes are unknown after this
-
cplhenshaw
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
That's understandable, and I'm thrilled that you decided to give it a go. Don't worry, take your time. Could you also make it ignore case while reading, and when updating back the 3do? This has nothing to do with the actual 3D model itself, but with the materials, so they can be read properly. It can easily be done with strcasecmp from #string.h, for example:
if (strcasecmp (string_from_matnames.h, string_from_3do_file) == 0) {
//Do everything else
}
This will compare the strings, and ignore their case, making lowercase or uppercase not important anymore.
Don't know why I didn't do this, I made every string being read tolower(), which creates problems afterwards.
if (strcasecmp (string_from_matnames.h, string_from_3do_file) == 0) {
//Do everything else
}
This will compare the strings, and ignore their case, making lowercase or uppercase not important anymore.
Don't know why I didn't do this, I made every string being read tolower(), which creates problems afterwards.
-
ezekiel000
- Posts: 443
- Joined: Mon Aug 25, 2008 5:17 pm
- Location: Surrey, England
I have thought about 3d eye geometry and face animation, and ended up with the following concept.
At first the original concept. It uses different Textures for the upper head including the eyes and hair. The whole lower part of the texture is used for the eyes and varies wile animation.
The new concept uses for each eye expression a different area on the textures, while all other areas which are used for eyes are marked as transparent. This way we can model 3d-geometry for each expression and lay them on top of each other. By switching from one texture to another, it makes always just one of the 3d-eyes visible, wile the others are transparent.
I hope i made myself understandable
I think this way, it could work. What do you think about it?.
I'm afraid this method would take a large amount of work and i don't know if its worth the effort. (And if we do this on glottis, should we do this on other characters to? Or would it destroy the reduced comic-like look of the characters)
At first the original concept. It uses different Textures for the upper head including the eyes and hair. The whole lower part of the texture is used for the eyes and varies wile animation.
The new concept uses for each eye expression a different area on the textures, while all other areas which are used for eyes are marked as transparent. This way we can model 3d-geometry for each expression and lay them on top of each other. By switching from one texture to another, it makes always just one of the 3d-eyes visible, wile the others are transparent.
I hope i made myself understandable
I think this way, it could work. What do you think about it?.
I'm afraid this method would take a large amount of work and i don't know if its worth the effort. (And if we do this on glottis, should we do this on other characters to? Or would it destroy the reduced comic-like look of the characters)
-
ezekiel000
- Posts: 443
- Joined: Mon Aug 25, 2008 5:17 pm
- Location: Surrey, England
That's a really good idea.
I don't think doing this for glotis means it has to be done for everyone only where it is needed. Maybe the other demons would need is but as they are all organic where as most other characters are bone and so ridged. But then the other demons don't have multiple expressions do they?
I don't think doing this for glotis means it has to be done for everyone only where it is needed. Maybe the other demons would need is but as they are all organic where as most other characters are bone and so ridged. But then the other demons don't have multiple expressions do they?
Yeah, this is a point which displeases me since I've played some hours wit the high-poly manny.Longcat wrote:...3d eyes would deviate too much from the cutscenes...
Well, maybe we have a solution for this in the very far future (there are some ideas traveling through my brain), but this is also connected with a lot of work (character rigging, reanimating by rotoscopy (or how its named) and copying the animation on top of the existing(recalculated in hi resolution) cutscene and hoping that it looks good)....
and then i woke up...
Yeah I've thought about that too, and I've come to the conclusion that it might even be harder to do than it was to make the original videos. The rigginng would not be that complicated, since it's Rigid all the way, there's a piece for every limb, but tweaking it (keyframing it) to look just like the original would require a lot of work. Plus, for example, Manny has more facial-expressions in the videos than in-game. I'm guessing that goes for the other characters too. And that's not the most concerning part of it if you ask me. I think matching the lighting, environment and camera angles would be a devastating move
It's doable, but it would require A LOT of time, and more people, so the ones already working on it can take a break so they wouldn't lose their minds
BTW, that's real good logic that you've come up with concerning the eyes, although I'm not sure if it would work. Introducing new geometry for the game, means we'd probably have to edit the keyframes for the existing one (or maybe I'm wrong?). For example when Glottis is mad he uses glottis_head3.3do (not sure, just paraphrasing). Now we'd have to change that to something else, the new head that we've made. This information is kept in the *.key files if I remember correctly...
EDIT: Argh, my posts always end up on a new page.
It's doable, but it would require A LOT of time, and more people, so the ones already working on it can take a break so they wouldn't lose their minds
BTW, that's real good logic that you've come up with concerning the eyes, although I'm not sure if it would work. Introducing new geometry for the game, means we'd probably have to edit the keyframes for the existing one (or maybe I'm wrong?). For example when Glottis is mad he uses glottis_head3.3do (not sure, just paraphrasing). Now we'd have to change that to something else, the new head that we've made. This information is kept in the *.key files if I remember correctly...
EDIT: Argh, my posts always end up on a new page.
Well I was thinking of remodeling everything, and almost all of the models are simple with simple textures, mostly just one color (except for carpets, and the ones that look like this, and those would need work). The static scenery shouldn't be that hard to recreate in 3D, since there's more freedom there, you don't have to restrain yourself on the details and polycount since the final product is Video after all, and not something to be rendered real-time.
I think this would be a posibbility in the far future, as Blacksad said, but I think it'd be best if we went one step at a time. Not enough people yet to multitask to that extent...
I think this would be a posibbility in the far future, as Blacksad said, but I think it'd be best if we went one step at a time. Not enough people yet to multitask to that extent...