Grim Fandango Deluxe - Original Thread [Locked]

Discussions regarding the development of the mod "Grim Fandango Deluxe"

Moderator: ScummVM Team

Locked
User avatar
giucam
Posts: 139
Joined: Mon Mar 21, 2011 9:20 am

Post by giucam »

Nitrus wrote: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...
Actually no, the things that manage the visibility of the 3do are the chores and components (Mesh and Model/MainModel), defined in the costume files (.cos). The .key files set only the translation and rotation of the nodes, but they don't know which nodes are. Indeed, the nodes they work with are fed by the costume every time.
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

Oh right, thanks. I remembered looking at ascii orders somewhere but I got mixed up with the *.keys...
Actually now that I think about it, it might not be that hard to introduce some new lines about new meshes in the *.cos, which will use the same keyframes (or keys) as the previous heads. It's going to be a bit tough to coordinate what's what though...
User avatar
JohnnyWalker2001
Posts: 405
Joined: Mon Oct 16, 2006 1:27 pm
Location: London, UK

Post by JohnnyWalker2001 »

Holy cow! Great stuff, guys! If only I wasn't so busy in my work at the moment.

I will try and take a crack at the textures of Revolutionary Manny and Glottis. Both models look SWEET right now!
iceberg
Posts: 4
Joined: Fri Apr 06, 2012 10:33 pm

Post by iceberg »

I just got a MakerBot Replicator and wanted to test it out.... anyone have a Manny or Glottis object for me to "print"? The input files it takes are STL files.

I'll post some pics here once I figure it out.
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

I took a quick look at MakerBot's site, and I think that the models we're working with aren't suitable for printing. They are consisted of many parts, with no holding mechanism between them, so a lot of tweaks will be necessary to make them functional, or it needs to be a one-part model. Plus as they are, I think they'd come up as a full core models, instead of hollow ones, to save printing material (Except if the printing software doesn't have a solution for that). A lot of the details are textures instead of modeled, because we're working with game optimized models, that use fewer polygons, this means no imprinted or extruded eyes, teeth, noses etcetera, and you'd have to paint them all by hand.
User avatar
Blacksad
Posts: 30
Joined: Sun Feb 12, 2012 11:02 pm

Post by Blacksad »

"High-Poly" Glottis model plus Head models ready for testing. Have fun :D

datausr.lab

edit
There is one thing, i don't understand. I made a rough upscaled texture of gl_eye to get a more detailed hair texture to make uv-mapping a little easier. I replaced it in the blend-file and it maped the new texture automatically in the correct scale. While exporting to obj i forgot to replace it with the original, so i got uv-coordinates for the hi-res texture. But this makes no difference ingame. It places the old texture correctly on the new head-model. Why does this happen? I thought it would be messed up but it isn't.

edit2
In this new datausr.lab is just the new glottis model, so i thought it would be handy, if we make a shared webspace available, where we could put in the 3do's and mat's. so everytime someone has finished something he can make a complete datausr.lab and link it here. I thought about a shared folder in dropbox, or something similar.
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

Sorry for the late reply, had to set everything up after a format.

Glottis is lookin' good!
Yeah, we could make a joined Dropbox or something, to have it all in one place. Although every change would need to be revisioned, because for example, someone decides to make modifications on your Glottis model, and overwrites yours. In the meantime, you've made further modifications and overwrite that one etc... Maybe if we save them with a filename extension, like gl_head1_REV1.3do or something like that.

On the texture bit, it seems your upscaled UV's didn't take. For example, I made the first image from gl_eye.mat 512x256 (128x64 x 4), and compiled it in the datausr.lab.

This is what I got:
Image

It seems to me that Blender downscales the Image to make it correspond to the UV's space, but does not upscale the UV's to match the image size. I could be wrong.
iceberg
Posts: 4
Joined: Fri Apr 06, 2012 10:33 pm

Post by iceberg »

Nitrus wrote:I took a quick look at MakerBot's site, and I think that the models we're working with aren't suitable for printing. They are consisted of many parts, with no holding mechanism between them, so a lot of tweaks will be necessary to make them functional, or it needs to be a one-part model. Plus as they are, I think they'd come up as a full core models, instead of hollow ones, to save printing material (Except if the printing software doesn't have a solution for that). A lot of the details are textures instead of modeled, because we're working with game optimized models, that use fewer polygons, this means no imprinted or extruded eyes, teeth, noses etcetera, and you'd have to paint them all by hand.
The rendering engine ("Skeinforge" in the default one, but there are a few others) that translates the STL objects into motor commands can be customized to control the amount of "infill" that will be built inside the object.

The default infill is "1", and I think it scales to "100" for 100% infill. If you input 0, it will only attempt to build the outer shell of the object, and not necessarily successfully.

If the object model wasn't designed with 3D printing in mind, I would probably shoot for 10% infill, and the rendering engine will then add interior struts approximating 10% to the hollow of the model that would be "printed".

Typically the models that are shared on Makerbot's website were designed to be printed as-is, with sufficient interior structure so that typical users won't need to tweak those values.
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

I took down the link.
You should be able to convert some of the models with the tools on this thread.


Image
Last edited by Guest on Mon Jul 30, 2012 9:00 pm, edited 2 times in total.
User avatar
somaen
ScummVM Developer
Posts: 376
Joined: Thu Apr 21, 2011 7:31 pm
Location: Trondheim, NO

Post by somaen »

Nitrus wrote:Yeah, we could make a joined Dropbox or something, to have it all in one place. Although every change would need to be revisioned, because for example, someone decides to make modifications on your Glottis model, and overwrites yours. In the meantime, you've made further modifications and overwrite that one etc... Maybe if we save them with a filename extension, like gl_head1_REV1.3do or something like that.
Why reinvent the wheel? Version control systems already are a dime a dozen, and GitHub/SourceForge/BitBucket are all easily accessible for no charge.

Just be carefull what you put up on the 'net though, as you ARE working with copyrighted material here. (So, please don't share any original game data).
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

Point taken.
User avatar
YakBizzarro
Posts: 37
Joined: Wed May 18, 2011 8:10 am

Post by YakBizzarro »

About the copyright issues, you could use PatchR. It's used internally by ResidualVM to patch bugged lua scripts (see here). It's like the ordinary diff/patch, but it even works with binary files. So, instead of providing the plain version of resources files, you could just distribute the relative .patchr file that transform the old file in to the new version, avoiding all copyright issues. It even reduces the size of resulting files, since it reuses the original file as much as possible and it's compressed. Here there is a proof of concepts: it's basically the last datausr.lab made by Nitrus, but made with the use of PatchR (except for action_manny.mat and manny_deathrobe.mat, since i haven't found them in my original game datafiles). It works only with the last development version of ResidualVM, since it contains some critical fixes. If it crashes with a "Corrupted patchfile" error you probably have to update it.
At a first look the performances seem good, but some more scientific tests are needed.
The diffr/patchr tools could be found in the residualvm-tools repository. Here their documentation.
Imho you definitely need a version control system; the best solution would be a private one, with a buildbot that periodically generates public snapshots with PatchR from plain files, but this would cost money. A decent free solution would be also a free public hosting, but with only the patches instead of plain file.
Nitrus
Posts: 177
Joined: Wed May 18, 2011 9:49 am

Post by Nitrus »

Hmmm this is some really useful stuff! I didn't know that this method, or similar ones circumvent copyright issues. But in any case I don't think this is going to be a real issue, since the idea is that we only upload modified files for community use (modified textures/models), not the original ones, because everybody is supposed to already have those, right? So the uploaded files are already different, both in content, size, CRC and what not. When we create a new model or a new texture, and upload it, isn't that enough for avoiding copyright breaches? Or am I missing something here?

PatchR could be used to modify the original DAT###.LAB files so one could save space, but I rather like the datausr.lab method, since it lets you switch between the original game files, and the modified ones at your leisure. If we were to patch the originals and use them, then that's all we have, and going back would mean replacing with the files from the CDs. Although, PatchR might be useful for using on a template datusr.lab...

Yeah, I was looking at some free repository solutions, and I think BitBucket is alright, but offers only 5 users to their free plan. Although the best choice might turn out to be GitHub, which offers unlimited users, if you don't mind the repository being public. Which I personally don't since there is nothing private about this one, and the more people the better.
YakBizzarro wrote:the best solution would be a private one, with a buildbot that periodically generates public snapshots with PatchR from plain files
I don't have much experience with version control systems, so could you please explain why do you think a private one is better than a public one? In our case of course...
User avatar
YakBizzarro
Posts: 37
Joined: Wed May 18, 2011 8:10 am

Post by YakBizzarro »

I'm not an expert of copyright law, but I think that even if the models/textures/whatever are made from scratch, they are considered a derived work, like a cover song. But it's only my opinion.

I have not explained well, PatchR in ResidualVM (not the homonym tool in ResidualVM-tool repository) does all the modifications to data in ram every time that a file is requested by the game. No data are saved on the hard-disk. .patchr files need to be inside datausr.lab, like how is now with plain files.

About private vs. public, my only concern was the copyright issue, without this problem I obviously prefer a public repository :)
User avatar
somaen
ScummVM Developer
Posts: 376
Joined: Thu Apr 21, 2011 7:31 pm
Location: Trondheim, NO

Post by somaen »

Following up on what YakBizarro said, I personally think that some proper ground rules for how the distribution should be handled, I know a similar thing has been going on over at the ScummVM boards with the "MI1 - Talkie Edition"-thing, so it's not unheard of, but then again, we have to keep a rather hard line on distribution of the game data files.

This is why I came in rather early in this thread saying that you should atleast stick to sharing it only as patches, and preferably developed quite separately from ResidualVM.

That being said, I really like what you are working with here, I just don't want ResidualVM to end up in any kind of trouble for this.
Locked