Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
How close are we to a 3do exportor or converter from OBJ?
I used to do a lot of 3d modelling, texturing, etc and this project sounds awesome. The progress so far is awesome...
Couple of things: If you're updating the file resolution of images but sticking with the original models - the UV maps shouldn't need altering as they fit the image they are applied to.
If we could get a working converter, I could try and get a prototype of an updated manny out..
Out of interest.. where are the animations stored? Within the 3do itself?
I used to do a lot of 3d modelling, texturing, etc and this project sounds awesome. The progress so far is awesome...
Couple of things: If you're updating the file resolution of images but sticking with the original models - the UV maps shouldn't need altering as they fit the image they are applied to.
If we could get a working converter, I could try and get a prototype of an updated manny out..
Out of interest.. where are the animations stored? Within the 3do itself?
http://imageshack.us/photo/my-images/15 ... fthee.jpg/
I've also made manny in the traditional 3d sense, too
I've also made manny in the traditional 3d sense, too
Guys,
I've just had a nosey through the files. Here's my thoughts:
- If models are going to be changed, this should be done at the start as the UV Mapping / Textures / Colour Maps will all need changing. Maybe a two phase approach would work here where textures are made a higher resolution until that model is replaced, using the existing palette (cmp) files.
- Having looked at the .cmp files - they don't seem to be a standard file format used within Photoshop. Tried importing it to no avail. This format must have been broken down somewhat as Scumm Revisited (2.0) is able to view the palette, no problem. I think the ability to create this is of big importance.
- The big question is regarding 16-bit. If 16-bit can't be achieved; the textures need to be split to maximise the colour variance (should they be re-modelled).
I've just had a nosey through the files. Here's my thoughts:
- If models are going to be changed, this should be done at the start as the UV Mapping / Textures / Colour Maps will all need changing. Maybe a two phase approach would work here where textures are made a higher resolution until that model is replaced, using the existing palette (cmp) files.
- Having looked at the .cmp files - they don't seem to be a standard file format used within Photoshop. Tried importing it to no avail. This format must have been broken down somewhat as Scumm Revisited (2.0) is able to view the palette, no problem. I think the ability to create this is of big importance.
- The big question is regarding 16-bit. If 16-bit can't be achieved; the textures need to be split to maximise the colour variance (should they be re-modelled).
As I've hinted about before, EFMI uses 32-bit textures, and 32-bit backgrounds, which will be supported eventually, I don't see any reason why this support kept open for Grim Fandango too, whenever we get around to adding it.
So, yes there might come 32-bit support down the line, No it won't happen today (the Software Renderer needs to support 32-bit graphics before that happens, and EFMI needs a bit more work first). So, please go ahead and work in higher bitdepths, shouldn't be a problem to EVENTUALLY adapt it. (BTW, EFMI doesn't use colourmaps).
So, yes there might come 32-bit support down the line, No it won't happen today (the Software Renderer needs to support 32-bit graphics before that happens, and EFMI needs a bit more work first). So, please go ahead and work in higher bitdepths, shouldn't be a problem to EVENTUALLY adapt it. (BTW, EFMI doesn't use colourmaps).
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
Hey! Thanks for offering your skills to the project. Yes, there are converters, and they seem to be working just fine at the moment.thnom wrote:Guys,
I've just had a nosey through the files. Here's my thoughts:
- If models are going to be changed, this should be done at the start as the UV Mapping / Textures / Colour Maps will all need changing. Maybe a two phase approach would work here where textures are made a higher resolution until that model is replaced, using the existing palette (cmp) files.
- Having looked at the .cmp files - they don't seem to be a standard file format used within Photoshop. Tried importing it to no avail. This format must have been broken down somewhat as Scumm Revisited (2.0) is able to view the palette, no problem. I think the ability to create this is of big importance.
- The big question is regarding 16-bit. If 16-bit can't be achieved; the textures need to be split to maximise the colour variance (should they be re-modelled).
You can grab an .OBJ version of Manny here:
http://www.mediafire.com/download.php?i5vkh7jd4axpv08
Please model away!
As for the .CMP files, they can be extracted as .ACT files, I believe, by MatMaster or Mat16 (I forget which), so they can be used by Photoshop. (Indeed, that's how I did the hires version of Manny.)
Looking forward to seeing your 3D model!
I will post updates!
http://imageshack.us/photo/my-images/856/mannymax.jpg/ - Just managed to import Manny into 3ds max (ty Autodesk for the free Student edition)
Now to start..
http://imageshack.us/photo/my-images/856/mannymax.jpg/ - Just managed to import Manny into 3ds max (ty Autodesk for the free Student edition)
Now to start..
-
cplhenshaw
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
Blender is the only program I have tried it with, that's the only reason I suggest so, but theoretically any program which can handle .obj files should be okay to use. There are however some rules that should be kept to to guarantee the reverse journey to .3do is a smooth one.
The reverse program (obj -> 3do) doesn't turn any obj file into a 3do, it basically "updates" a given 3do using an obj file. So for every piece in the obj file it checks if there is a piece with the same name in the 3do file and overwrites it.
Thus:
Be sure not to change the names of any pieces. I know Blender leaves them alone, but it's possible some other programs might alter them ?
Edit each piece "in place", and do not adjust the dimensions of each piece. i.e do not stretch arms to be longer etc The animations have all been done for the original models, and changes like these will probably make them look strange.
You need to ensure that the program exports obj files with uv data and normals. These will be required. Again, in Blender the default does not export normals but other programs may be different.
These are the main things to keep in mind and I'm sure there will be other issues that pop up as we go along.
The reverse program (obj -> 3do) doesn't turn any obj file into a 3do, it basically "updates" a given 3do using an obj file. So for every piece in the obj file it checks if there is a piece with the same name in the 3do file and overwrites it.
Thus:
Be sure not to change the names of any pieces. I know Blender leaves them alone, but it's possible some other programs might alter them ?
Edit each piece "in place", and do not adjust the dimensions of each piece. i.e do not stretch arms to be longer etc The animations have all been done for the original models, and changes like these will probably make them look strange.
You need to ensure that the program exports obj files with uv data and normals. These will be required. Again, in Blender the default does not export normals but other programs may be different.
These are the main things to keep in mind and I'm sure there will be other issues that pop up as we go along.
Henshaw,
To update the models you need to introduce more vertices and faces. Any additions will surely not get animated and/or have any UV mapping applied.
If we can't move any existing vertices then creating from scratch is a no I'd presume? If we have stick to these constraints I don't think we can dramatically improve the models..
To update the models you need to introduce more vertices and faces. Any additions will surely not get animated and/or have any UV mapping applied.
If we can't move any existing vertices then creating from scratch is a no I'd presume? If we have stick to these constraints I don't think we can dramatically improve the models..
-
cplhenshaw
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
More vertices and faces are fine, and uv mappings done in the modelling program will be reflected in the update 3do.
The animations are done at the level of the pieces i.e the entire piece is rotated / shifted. Thus by updating the pieces rather than from scratch we do not need to change any animations.
I suppose one approach would be to subdivide all the faces, and then adjust the new vertices to give a more rounded form (or whatever improvements are desired).
That said you could also create a new detailed piece over the top of the old one, using it as a template for position and scale, and then replace the old with the new one.
Does that make sense?
The animations are done at the level of the pieces i.e the entire piece is rotated / shifted. Thus by updating the pieces rather than from scratch we do not need to change any animations.
I suppose one approach would be to subdivide all the faces, and then adjust the new vertices to give a more rounded form (or whatever improvements are desired).
That said you could also create a new detailed piece over the top of the old one, using it as a template for position and scale, and then replace the old with the new one.
Does that make sense?
Animations done on an entire piece within the files would imply thats its purely based on the selection of the groupings.. would that be right.. or is it on a vertex level?
Subdivided faces could be done but its a hell of a lot of sub-dividing, avoided this due to the model breakup. For example in manny his blazer is separated into the torso, shoulders, upper arm, lower arm, etc. Modelling today doesn't take that split setup (it was similar in N64 games - check WWF No Mercy (http://ui30.gamefaqs.com/1341/gfs_40676_2_3.jpg).
If we're saying the models need to remain in those groups, the improvements per model are going to be minimum and attention should be concentrated on the textures.
Subdivided faces could be done but its a hell of a lot of sub-dividing, avoided this due to the model breakup. For example in manny his blazer is separated into the torso, shoulders, upper arm, lower arm, etc. Modelling today doesn't take that split setup (it was similar in N64 games - check WWF No Mercy (http://ui30.gamefaqs.com/1341/gfs_40676_2_3.jpg).
If we're saying the models need to remain in those groups, the improvements per model are going to be minimum and attention should be concentrated on the textures.
-
cplhenshaw
- Posts: 54
- Joined: Wed Aug 10, 2011 9:17 pm
Yes, each piece is "solid" and moves as a whole, individual vertices are not animated individually.
I think the models do need to stay in these groupings, otherwise we need to redo all animations (and implement a new system to perform the new style of animations) which is infeasible.
So any improvements will not bring the game up to modern graphics standards, but there should be a certain level of improvement achievable (3d fingers, rounder arms etc)
I think the models do need to stay in these groupings, otherwise we need to redo all animations (and implement a new system to perform the new style of animations) which is infeasible.
So any improvements will not bring the game up to modern graphics standards, but there should be a certain level of improvement achievable (3d fingers, rounder arms etc)