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 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...
Grim Fandango Deluxe - Original Thread [Locked]
Moderator: ScummVM Team
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...
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...
-
JohnnyWalker2001
- Posts: 405
- Joined: Mon Oct 16, 2006 1:27 pm
- Location: London, UK
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.
I'll post some pics here once I figure it out.
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.
"High-Poly" Glottis model plus Head models ready for testing. Have fun 
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.
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.
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:
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.
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:
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.
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.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 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.
Why reinvent the wheel? Version control systems already are a dime a dozen, and GitHub/SourceForge/BitBucket are all easily accessible for no charge.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.
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).
-
YakBizzarro
- Posts: 37
- Joined: Wed May 18, 2011 8:10 am
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.
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.
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.
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.
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...YakBizzarro wrote:the best solution would be a private one, with a buildbot that periodically generates public snapshots with PatchR from plain files
-
YakBizzarro
- Posts: 37
- Joined: Wed May 18, 2011 8:10 am
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
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
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.
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.