ResidualVM logo Forum Index - ResidualVM website - Contact us - Rules Login    Register     Search curved edge
It is currently Wed Sep 19, 2018 11:05 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, 2, 3, 4, 5 ... 38  Next
Author Message
PostPosted: Thu Jul 28, 2011 4:35 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
giucam wrote:
JohnnyWalker2001 wrote:
Thanks, I'm getting to understanding what's going on now, although I'm still not sure which *file* the offset is being read from. (Edit: I see you're saying it's in the .mat files?)

Yes, in the .mat files.


Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 28, 2011 4:45 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
somaen wrote:
Sure, or OBJ for that matter, as long as it's a documented format, it shouldn't be that hard to add, the main issue would be detecting that the files are non-standard I guess.


This is very exciting news!


Top
 Profile  
 
PostPosted: Thu Jul 28, 2011 5:05 pm 
Offline
ResidualVM Developer
User avatar

Joined: Mon Mar 21, 2011 9:20 am
Posts: 139
Location: Belluno, Italy
JohnnyWalker2001 wrote:
Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*


How are you looking in the file? Are you sure you are looking a it encoded in decimal?


Top
 Profile  
 
PostPosted: Mon Aug 01, 2011 10:56 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
giucam wrote:
JohnnyWalker2001 wrote:
Huh. Well it's seriously confusing because the size (128) doesn't seem to be stored anywhere in the .mat files, at any offset. *scratches head*


How are you looking in the file? Are you sure you are looking a it encoded in decimal?


No, I was looking for 80 in hex... but thinking about it I think I may have been looking in my new .mat 256 file. I guess was hoping that it was causing the problem, but Aquadran has made me question if it's actually a fundamental limitation in Grim.

My computer is out of action until tomorrow, so I'll try again then.

I guess it's going to be new models and textures!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 03, 2011 1:37 pm 
Offline

Joined: Mon Aug 01, 2011 9:34 pm
Posts: 14
Conversion to a more generic format is certainly doable. As proof of concept here's a quick converted model to .obj.

Its the coral item, although it looks like I messed up somewhere because the textures arent applied correctly (the base is wrong).


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 03, 2011 1:52 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
Excellent! How did you convert it?

In other news: It seems that the .mat files aren't to blame after all, and in fact are storing the correct texture size. Grim/ResidualVM is just ignoring it, though. (Or so it seems.)

In the original files it says 128 (80 00 00 00), but in my modified file it says 256 (00 01 00 00). So there's definitely a limitation in Grim/ResidualVM that doesn't take into account texture sizes bigger than 128 x 128.

So remodelling is looking like the way to go!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 03, 2011 1:58 pm 
Offline

Joined: Mon Aug 01, 2011 9:34 pm
Posts: 14
I did it by hand just because it was a quick test. For speed I used the text 3do from the demo rather than the binary one from the full game.

For a project like this to work, you'd need:
  • A decision on the best/most suitable format to convert the 3do models to.
  • Someone to add code to make residual support the loading of external/alternate models
  • Someone to make a convertor for the models to the new format
  • And finally people to create enhanced models and textures.

Its a big job.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 03, 2011 2:03 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
Yep, it's a big job :)

I'm happy to try and take care of Step 4, but the first three steps are beyond me.

Step1: People seem to think that Cal3D or OBJ are the most likely formats.

Step2: I think Aquadran will be needed for this.

Step3: Not sure who has the skills to convert the old formats to a new one. Could you write an app that could do this if you were given all the specifications, BG?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 03, 2011 5:37 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 322
Are there any limitations in the model-format that is used in Grim originally that are problematic, or couldn't that simply be used, instead of adding additional complexity to ResidualVM?

If the existing format is workable (or workable with minor adjustments), then all that is needed would be converting to obj/cal3d and back. (i.e. no actual changes necessary in the ResidualVM-codebase).


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 1:32 am 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
somaen wrote:
Are there any limitations in the model-format that is used in Grim originally that are problematic, or couldn't that simply be used, instead of adding additional complexity to ResidualVM?

If the existing format is workable (or workable with minor adjustments), then all that is needed would be converting to obj/cal3d and back. (i.e. no actual changes necessary in the ResidualVM-codebase).


A good question. Someone more technically involved with ResidualVM will have to explain further, but other than the texture dimension problems, I'm not sure what other problems there might be with the existing format.

Based on what people (like Ender) have said, though, adding a new format would be just as easy?

More information is needed, obviously :(


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 8:40 am 
Offline
ResidualVM Developer
User avatar

Joined: Mon Mar 21, 2011 9:20 am
Posts: 139
Location: Belluno, Italy
Adding a new format may be easy, but it would however mean adding new code and complexity, which it's better not to do.
I don't know any other model format aside .3do, but i don't see any limitation with it.
As regards the materials, ResidualVM does use the texture size. If your bigger texture is not working right, that's likely to be a simple bug in the code.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 7:51 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
Result! We have a hires Manny! (Thanks to Somaen and Guicam for the help!) It's just the beginning, but yes, it's possible...

Image


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 9:19 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
So after some messing I around, I can already start to see some limitations.

For a start, the increase texture resolution is only really visible when Manny is REALLY close to the camera (see below). Secondly, being only able to use the 256 colour palette of the game is very restrictive (see Manny's tie, below). Thirdly, GF is very stylized, so it's not entirely clear how and where the extra detail should be placed (although this could be figured out).

It seems to me that, at the very least, we need a way of adding more colours to the palette. Without it means it's only worth adding bigger textures to a very small collection of items in the game (those that are seen close-up).

This might be worth doing in the meantime (it IS nice that Manny's face doesn't pixelate so), I don't know of a way on doing it on a per-model basis... it's every texture in the game or no textures at the moment.

Any ideas?

The way I see it, we have three options:

1. Add high-quality textures to a small amount of items in the game (i.e. the things that are seen close-up).

Problem: Need to be able to remap the textures on a per model basis.
Pros: Very quick and easy way to make Grim Fandango look nicer to modern eyes.

2. Make more colours available to textures in an attempt to be able to add more detail that way (think shading).

Problem: Adding more colours to textures is quite a big job (from what I gather).
Pros: It might allow use to add a little more detail to textures -- although I expect not much.

3. Remodel the characters and use an increase polygon count to improve the visuals of the game.

Problem: We need a way of converting .3do files to .obj and back again. Also, very time consuming.
Pros: We could end up with a very beautiful version of Grim Fandango.

Image


Last edited by JohnnyWalker2001 on Thu Aug 04, 2011 11:56 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 10:22 pm 
Offline

Joined: Mon May 04, 2009 8:06 am
Posts: 66
Nice!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 04, 2011 11:56 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
Cool, isn't it? :)


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, 2, 3, 4, 5 ... 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:  
Powered by phpBB® Forum Software © phpBB Group
Forum design by ScummVM team, icons by raina, adopted for ResidualVM
curved edge   curved edge