[WIP] Almagest. Strict Import for SH5. - Page 8

kapuhy · 01-19-22, 06:33 AM

Quote:

Originally Posted by gap

Why don't you bake your AO textures in Mod Tools (i.e. the free version of Autodesk Softimage)?

Never knew such a thing existed

Thanks for heads up, will check it out.

gap · 01-19-22, 06:45 AM

Quote:

Originally Posted by kapuhy

Never knew such a thing existed

Thanks for heads up, will check it out.

My pleasure. Let me know if you need any help with it. If you want I can also tell you my favourite settings. Depending on model complexity and final pixel resolution a good bake might take 20 to 40 minutes, but if you have a more modern computer it might take even lesser

Mister_M · 01-19-22, 01:13 PM

So, finally, where does the glitch I'm experiencing come from ? Only a difference in the order of vertices between main and AO objects ?

Quote:

Originally Posted by kapuhy

Mister_M, if you'd like to make some changes to model in Blender I can send you .blend files so there's less importing/exporting.

Quote:

Originally Posted by gap

My suggestion is to switch to Blender for final model editing. This program supports object multi-mapping, i.e. the assignation of multiple UV maps on the same object. You can even import an UV map from one object to another identical object, so whatever changes you do to the model, you are sure that the two exported obj files will be identical in vertex/face structure.

I don't have Blender installed, and don't know how to use it.

Quote:

Originally Posted by gap

Else, if you want to stick to Wings3D, be more careful. You want to ungroup the main model? Immediately after, ungroup the AO model too. You want to regroup a group of sub models? Make sure that you regroup exactly the same objects for both models. Your actions on each model should be specular and you should perform them exactly in the same order for having a chance of success.

gap · 01-19-22, 02:40 PM

Quote:

Originally Posted by Mister_M

So, finally, where does the glitch I'm experiencing come from ? Only a difference in the order of vertices between main and AO objects ?

Yes, at this point we can conclude that this is the main, and probably the one problem

Quote:

Originally Posted by Mister_M

I don't have Blender installed, and don't know how to use it.

I think no one knew how to use Blender before installing it and starting to mess with it

At the beginning the learning curve can be step, but on the internet there are a lot of guides and video-tutorials covering even the most advanced of its functionalities. I myself am still learning them. I think I will stick to Wings3D as my main modelling tool because I feel more proficient with it, but there are a lot of cool things you simply can't do in Wings and you can do in Blender. Why giving them up?

Jeff-Groves · 01-19-22, 02:58 PM

Quote:

Originally Posted by Mister_M

So, finally, where does the glitch I'm experiencing come from ? Only a difference in the order of vertices between main and AO objects ?

Yes. And there is a VERY easy way to see this in Wings3D, Blender, 3DS Max, or any other 3D program.

Copy the Faces section in the AO obj file.
(Obj files are just text files!)

Paste that over the faces section of the main obj file then open it!

If it looks like garbage? It is Garbage!

For GR2 strict import? We need to sort the faces and texture coords.
For SH3/4? The faces and textures are stored in a different TMAP section!

Mister_M · 01-19-22, 03:56 PM

So, in short, it's impossible to realise (unless checking everything with your trick) that AO objects are incorrect before seeing it in game... because S3D only checks if there are the same number of vertices between main and AO obj...

Quote:

Originally Posted by gap

I think no one knew how to use Blender before installing it and starting to mess with it

I was sure you were about to say something like that...

Jeff-Groves · 01-19-22, 04:01 PM

Quote:

Originally Posted by Mister_M

So, in short, it's impossible to realise (unless checking everything with your trick) that AO objects are incorrect before seeing it in game... because S3D only checks if there are the same number of vertices between main and AO obj...

Correct!
But you can just look at the first few lines of verts in each file and see that you have a problem.

gap · 01-21-22, 09:12 AM

Quote:

Originally Posted by Mister_M

I was sure you were about to say something like that...

Hahahah, I am predictable and you know me well. My point still stands though

Jeff-Groves · 01-21-22, 01:15 PM

I had to do some research but I'll explain how a 3D model is stored in a dat file.
I'd figured this out long ago but just some details I had forgotten.

I have a Template for 010 that I'd forgotten about so I used it to refresh my memory. I guess I'm getting old!

Anyway! Here's how a dat stores the information and how I figured it out.

All verts are stored in a chunk of information easy to follow with my Template.
As are Faces and texture coords. And here's where it gets tricky!
Any extra texture coords, for say the AO mapping, get stored right along with the Main objects coords in one chunk of data.

That's where the TMAP sections come in! They point to the Verts and the texture coords in the main chunk of data! So they are nothing more then faces calling the proper lines from the main chunk of data.

S3D just puts out a proper obj file on export then on import?
Just stacks everything in it's proper place.

How I do it is to export a 3D model as a rawchunk with S3D then run my Template. It takes a few minutes to look at things and see that texture coords are GREATER then the same obj files exported by S3D.

Should anyone want to see the Template and the files I worked with let me know.

SH5 does it a bit differently.

Jeff-Groves · 01-21-22, 01:57 PM

Now! back to the dat information!

There's one more small bit of information to know on reading the textures in hex!

Say I have this in the obj file.....
vt 2.548912764 0.04277324677

But my Template shows this!
float U_coord 2.548913
float V_coord 0.9572268

Don't make sense? yes it does! Subtract the float V_coord from 1!

I'll have to edit my Template to get the proper read out.

I also have to Credit my Friend Anvart (Alex) for most of the Template.

Jeff-Groves · 01-22-22, 05:38 PM

Like I said before. I'd forgotten more then most even know.
Going over the information in a dat file I remembered even more!
I'm working on fixing the Template to show EXACTLY what you'd see when exported with S3D.

One area is the faces and how they are stored in a dat file.
One needs to read the first part then read the second.

It's kind of crazy but here's what you see.
We read 3 Verts THEN read the 3 Textures!
So if a Face is 3/1 2/3 5/4?
You will read 3 2 5 in Hex THEN 1 3 4!

Now I know most don't give a crap about that kind of stuff. But I do for a reason!
I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game!
There is NOTHING that does that!

vickers03 · 01-22-22, 06:44 PM

Quote:

Originally Posted by Jeff-Groves

I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game!

that would be awesome

tonschk · 01-22-22, 11:24 PM

Quote:

Originally Posted by Jeff-Groves

I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game!
There is NOTHING that does that!

Amazing, thank you Jeff-Groves

gap · 01-23-22, 10:51 AM

Quote:

Originally Posted by Jeff-Groves

I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game!
There is NOTHING that does that!

That would be nice

Indeed, one can arrange model parts in their desired position by manually adding/subtracting node translation/rotation values, but performing this task on model of a certain complexity is a PITA because nested objects inherit position/rotation from their parent objects

01-21-22, 01:57 PM	#115
Jeff-Groves GLOBAL MODDING TERRORIST Join Date: Sep 2014 Posts: 5,654 Downloads: 137 Uploads: 0	Now! back to the dat information! There's one more small bit of information to know on reading the textures in hex! Say I have this in the obj file..... vt 2.548912764 0.04277324677 But my Template shows this! float U_coord 2.548913 float V_coord 0.9572268 Don't make sense? yes it does! Subtract the float V_coord from 1! I'll have to edit my Template to get the proper read out. I also have to Credit my Friend Anvart (Alex) for most of the Template. Last edited by Jeff-Groves; 01-21-22 at 05:06 PM.

01-22-22, 05:38 PM	#116
Jeff-Groves GLOBAL MODDING TERRORIST Join Date: Sep 2014 Posts: 5,654 Downloads: 137 Uploads: 0	Like I said before. I'd forgotten more then most even know. Going over the information in a dat file I remembered even more! I'm working on fixing the Template to show EXACTLY what you'd see when exported with S3D. One area is the faces and how they are stored in a dat file. One needs to read the first part then read the second. It's kind of crazy but here's what you see. We read 3 Verts THEN read the 3 Textures! So if a Face is 3/1 2/3 5/4? You will read 3 2 5 in Hex THEN 1 3 4! Now I know most don't give a crap about that kind of stuff. But I do for a reason! I am working on an Exporter to rip 3D models from SH3/4 that ACTUALLY places the parts in their positions just as you see them in S3D or in Game! There is NOTHING that does that! Last edited by Jeff-Groves; 01-22-22 at 05:56 PM.

01-21-22, 01:15 PM	#114
Jeff-Groves GLOBAL MODDING TERRORIST Join Date: Sep 2014 Posts: 5,654 Downloads: 137 Uploads: 0	I had to do some research but I'll explain how a 3D model is stored in a dat file. I'd figured this out long ago but just some details I had forgotten. I have a Template for 010 that I'd forgotten about so I used it to refresh my memory. I guess I'm getting old! Anyway! Here's how a dat stores the information and how I figured it out. All verts are stored in a chunk of information easy to follow with my Template. As are Faces and texture coords. And here's where it gets tricky! Any extra texture coords, for say the AO mapping, get stored right along with the Main objects coords in one chunk of data. That's where the TMAP sections come in! They point to the Verts and the texture coords in the main chunk of data! So they are nothing more then faces calling the proper lines from the main chunk of data. S3D just puts out a proper obj file on export then on import? Just stacks everything in it's proper place. How I do it is to export a 3D model as a rawchunk with S3D then run my Template. It takes a few minutes to look at things and see that texture coords are GREATER then the same obj files exported by S3D. Should anyone want to see the Template and the files I worked with let me know. SH5 does it a bit differently.