ResidualVM logo Forum Index - ResidualVM website - Contact us - Rules Login    Register     Search curved edge
It is currently Thu Jun 20, 2019 1:13 pm

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 ... 27, 28, 29, 30, 31, 32, 33 ... 38  Next
Author Message
 Post subject:
PostPosted: Tue Jun 26, 2012 7:33 pm 
Offline
User avatar

Joined: Tue Jul 19, 2011 2:51 am
Posts: 324
Location: aka ThunderPeel2001
Woot! Very exciting indeed! I'll start playing around with this soon. Nice going, Nitrus!

PS - "Grim Ripper" is quite a clever name if you ask me ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 1:34 am 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
JohnnyWalker2001 wrote:
PS - "Grim Ripper" is quite a clever name if you ask me ;)


It is, isn't it...? Oh well, what's done is done.

Now it seems we have a different problem: I tried to export-import a 3D model with 4 times the material sizes, and it came out wrong. I'm not doing something right, it's like the textures are tiled and multiplied a million times! Could any of you tell me what to do with the object in my 3D application? Should I export the materials or not? The tool (obj3do) is giving me all sorts of errors. A little guide would be most helpful.

But the problem is this: Even with my garbled model I could see facial animations still missing, even though they exist in the *.MAT. That probably means that another Multi/Sub material is needed in the 3D model, and it's not a *.MAT thing...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 12:09 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 323
I seem to remember the tex-coords in the 3DO-files being the inverse of what OpenGL expects (i.e. absolute coordinates, not relative). How are you calcing the new coords?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 2:34 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
I'm converting the models with the tools I found in this thread,3doobj and obj3do, I have no idea how that works, I don't know how it reads nor how it writes. I only made the *.MAT exporter proggy above, which has no connection with the missing facial expressions. I _think_ that there's at least another sub-level of the material within the 3DO which needs to be exported. For example, I use 3Ds MAX, and within each of the materials there's another material (Multi/Sub), a container, which can contain more than one texture. And for example, the material for Manny's jaw is contained in one of these Multi/Subs, but in my opinion it should be a Multi/Sub itself, for containing the rest of the 10 textures, and not just the first one.
I tried with Blender, but didn't have much success either, but on the other hand, I'm not very experienced with Blender.

I don't know if I understood your question correctly, but I think the Wavefront OBJ exporter in 3DS Max exports in absolute too.

I wanted to make another 3DO to OBJ converter (and vice-versa), but I can't seem to find much information on how the stuff is stored in 3DO, and I can't find information on it's header either....


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 8:08 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 323
Well, there is code for loading it in residualvm, if you want to read through that. The format is proprietary lucasarts, and not the exact same as in Jedi Knight.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 8:21 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
Hmmm, I might just try that. Is it included in the regular source? (The one I could get from git)

UPDATE: I looked in engines/grim/model.cpp, and it's a bit tough to pinpoint the class/classes I would need to look at most. Could you help me out a bit?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 11:10 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 323
I did some attempts at fixing such a tool myself a while ago, my last attempt at fixing it is here, I'm not at all sure in what state it is:
https://github.com/somaen/residual-tool ... ools/tools

It's been a while since I looked into the files, but from what I remember model.cpp contains all (or atleast most of the logic) behind the loading of 3DOs. You can ignore the text-stuff, as that is only used in the demo I think. (You may however use that as output-format if you like.

A quick look-through says that the binary-format looks a bit like this (I seem to remember there being a semi-usable spec for the Jedi Knight format that is a bit more detailed, but that won't be completely usable since there are differencies):
4 bytes - signature "MODL"
Num_materials (4 bytes)
Material-list: Num_materials * 32 bytes (material-names with fixed length)
36 bytes of skipped data
_numGeosets - 4 bytes
GeoSet-list:
{
each geoset has:
_numMeshes: 4 bytes
Mesh-list:
{
a bit lengthy to describe here, look at Mesh::loadBinary(Common::SeekableReadStream *data, Material *materials[]) in model.cpp for details
}
}
4 bytes are skipped
_numHierNodes - 4 bytes
_hiernode-list:
{
ModelNode::loadBinary(Common::SeekableReadStream *data, ModelNode *hierNodes, const Model::Geoset *g) in model.cpp
}
_radius - 4 bytes (float)
skip 36 bytes
one vector (3 * 4 bytes) (float)


Not the cleanest description, but it should at least get you started, maybe the tool-makers in this thread could give out their sources to save you some time.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 27, 2012 11:35 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
Woot! Thank you! As soon as I have some more free time, I'll have a serious sit-down.

P.S: Compiled and ran your tool, and as you said, it's very WIP, but it's more than I could have asked for. There are no materials supported, but as long as you import it as single mesh, it works, it just doesn't position the object correctly. No matter, it's more than a jumpstart, but the thing is, I haven't worked with C++ in a looooong time, I guess when it comes to object-oriented languages, I've worked more with C# (or C-Crap as I like to call it) and Java...
I think I can get this to work (maybe not), but it could take a long time, since I'm not accustomed to C++. I'll do my best, but I'm not promising anything... :?

P.P.S.: While I still have you here, I can't seem to manage to get the textures (without modifying the 3DO) to display at the correct size. How did you guys manage that? For example, If I get a 512x512 image into the *.MAT it looks like this:

Image

The correct dimensions are correct in the MAT too: 0x 00 02 00 00 (512 decimal) :? :?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2012 9:51 am 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 323
Well, you can't without modifying the 3DO, the texture-coordinates are absolutes like I said, which means that positiion (10,20) in a 256x256 will differ from position (10,20) in an upscaled 512x512-version of the same texture.

Relative coordinates would have worked in both cases, as 10% into the texture will be the same position in a big texture as well as a small one.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2012 12:01 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
I know, I just thought that you had figured out a way, because of this post:
http://forums.residualvm.org/viewtopic.php?p=849#849

It's only on the second page of this thread, so I thought that no 3DO work had been done at that point. :wink:


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2012 1:00 pm 
Offline

Joined: Tue Aug 23, 2011 9:05 pm
Posts: 15
Location: Iran
I thought I saw something about that in the early days... Was not sure enough to tell you...
Anyway, great job Nitrus! Keep up the nice work!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2012 10:32 pm 
Offline
ResidualVM Developer
User avatar

Joined: Wed Nov 24, 2010 2:44 am
Posts: 323
Well, the other solution is to compile ResidualVM with a hardcoded multiplication on the tex-coords. I don't remember if it was that or the patched 3DOs we used there.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 28, 2012 11:45 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
I _think_ I _may_ have gotten it to work, without coding anything. Blender plays hell with the normals though. Will keep you posted if I have any notable success.

UPDATE: I managed to get facial animations and everything else to work with the existing tools (obj3do / 3doobj), but I managed to do that only if I use same size materials. How did you manage to use bigger sized(dimension) materials? What did you do with the model in order to allow that?

UPDATE: OK, I managed to do everything, but it's a CRAP process:

Use the tools to create an OBJ file, then edit the *.mtl file to contain the missing images (not MATs but TGAs or something similar (BMP didnt't work with Blender on my end) ).
Then import to blender (to coordinate with the textures, in 3DSMax you'd have to do it manually), then export to 3DSMax, then scale the UV's four times (yes, scale the UV's, which makes it impossible to see how it will look like ingame), I do this with a script in MAX, since manually it's virtually imposssible to be precise. Then export back to Blender (I couldn't get the exported file from MAX to compile with the tools, I always got a NORMAL NOT UPDATED error), and resave as an OBJ, and finally use the tools to make a 3DO... Oh and yeah, Blender does a terrible job with normals and smoothing groups.

Please tell me you had a better way :D

Here's a test with a 512x512 chest (nothing improved just a resized image):

Image

P.S.: a quote from Wiki:

Quote:
Relative and absolute indices

OBJ files, due to their list structure, are able to reference vertices, normals, etc. either by their absolute (1-indexed) list position, or relatively by using negative indices and counting backwards. However, not all software supports the latter approach, and conversely some software inherently writes only the latter form (due to the convenience of appending elements without needing to recalculate vertex offsets, etc.), leading to occasional incompatibilities.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 30, 2012 3:44 pm 
Offline
User avatar

Joined: Thu Jun 21, 2012 3:00 pm
Posts: 143
All right, I worked it out. I downloaded the enhanced 3D verison of Manny that blacksad made, and worked on it a bit.
Enhanced Manny is fixed, complete with facial expressions.

Here's a preview, although YouTube compressed it quite a bit (looks a lot better in-game):
See Handsome Manny!

And here's the datausr.lab with everything in working order:
Download Handsome Manny!

Let's get to it then... 8)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jun 30, 2012 3:50 pm 
Offline

Joined: Thu Sep 01, 2011 1:45 pm
Posts: 6
You made my day. Thanks !

I believe the next step is to make the same with the others costumes of Manny, right ?

You guys are awesome !


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 ... 27, 28, 29, 30, 31, 32, 33 ... 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