ResidualVM logo Forum Index - ResidualVM website - Contact us - Rules Login    Register     Search curved edge
It is currently Fri Oct 20, 2017 3:28 am

All times are UTC




Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 559 posts ]  Go to page Previous  1 ... 31, 32, 33, 34, 35, 36, 37, 38  Next
Author Message
 Post subject:
PostPosted: Fri Jul 20, 2012 9:48 am 
Offline
ResidualVM Developer
User avatar

Joined: Mon Mar 21, 2011 9:20 am
Posts: 139
Location: Belluno, Italy
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 20, 2012 12:26 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
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...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 26, 2012 10:23 am 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
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!


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2012 5:14 pm 
Offline

Joined: Fri Apr 06, 2012 10:33 pm
Posts: 4
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 29, 2012 1:36 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
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.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jul 29, 2012 11:10 pm 
Offline
User avatar

Joined: Sun Feb 12, 2012 11:02 pm
Posts: 30
"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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 30, 2012 2:37 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 30, 2012 3:07 pm 
Offline

Joined: Fri Apr 06, 2012 10:33 pm
Posts: 4
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 30, 2012 4:56 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
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 Nitrus on Mon Jul 30, 2012 9:00 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 30, 2012 8:54 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 322
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).


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 30, 2012 8:58 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
Point taken.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 02, 2012 7:09 am 
Offline
User avatar

Joined: Wed May 18, 2011 8:10 am
Posts: 37
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 02, 2012 10:03 am 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 130
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...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 02, 2012 11:24 am 
Offline
User avatar

Joined: Wed May 18, 2011 8:10 am
Posts: 37
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 :)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 02, 2012 6:29 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 322
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 559 posts ]  Go to page Previous  1 ... 31, 32, 33, 34, 35, 36, 37, 38  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Forum design by ScummVM team, icons by raina, adopted for ResidualVM
curved edge   curved edge