SUBSIM Radio Room Forums - Exporting 3D models from GR2

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)

- SH5 Mods Workshop (https://www.subsim.com/radioroom/forumdisplay.php?f=249)

- - Exporting 3D models from GR2 (https://www.subsim.com/radioroom/showthread.php?t=173092)

Quote:

Originally Posted by urfisch (Post 1587458)

hey anvart. great work! seems, as if we might finally get new crew models in sh3?

May be... but after degradation of meshes and textures... i think :D
and creation of all vertixes animations too...

k...

lets get the export/import thing in sh5 done first...i think

:up:

This looks really good, thanks privateer.

So it will soon be possible to add new 3D data to the game, will it also be possible to add new equipment to the sub later on? Does the game logic allow for such changes? I wonder this, as I have seen that there is progress done in extending the campaign after 43. It would be cool to upgrade your sub with post 43 tech, or even new classes as IX, or XI boats.

Quote:

Originally Posted by Anvart (Post 1587291)

Version 13011.7z.
Body parts are exported from CharacterBodyParts.GR2 ...
In 3ds Max, DE, S3D and in game (SH3) UV maps looks normally...
Look 3-d picture:
Specular (a-channel) as is ...
Bump as is ...
not adjusted.

@Anvart,

Can you give me a link to the imported Man you created?
I'd like to see why one side is faded like the last image.

Nice work!! Good progress here!

Quote:

Originally Posted by privateer (Post 1587519)

Here's a quick fix of the type 7C exported.

Never mind the secret stuff in the dat.
It's a test dat where I dump a lot of tests of the exporter.
:03:

I took the UV's for the bottom Hull, shrunk them and positioned them.
took the 1024 x 512 texture and made a 1024 x 1024 texture.
placed them in the dump dat and got what you see above.

Well, I can tell you, S3D definately does not care. All that S3D does is push the raw (directly from DAT) vertex data, uv data and textures to the DirectX-device. If textures are warped or squashed, then the data is incorrect. Plain and simple ;)

As such, remember that UV's are normalized [0-1], so a value of 0,0 or 0,1 or 1,0 or 1,1, they all represent the same corner on any texture, whether it is 1024x512, 1024x1024, or 123x873945 pixels.
Therefor, the problem is more likely a UV-scaling matrix you are 'missing' to multiply with the UV's, which probably is stored in some global variable section in the GR2 and granny IS handling when rendering. This may explain the difference. I have no other explanation for it.
In 3dsMax there's similar options in the materials-section for flipping UV's or even multiplying them by some arbitrary value. So perhaps you should hunt for that value in the GR2 file for a more stable and future proof export. My guess is it's there somewhere ;)

Now if I'm told I'm wrong, well... ok then I guess :]

Note: I do not claim either SH3 or SH4 itself has no issues with non-square textures though.

Hi Skwasjer,

Found the problem.
The Hull UV's are mapped above the usual plane.
So they are not tileing as they should.
Once I place them in the correct plane all is well.
(At lest as seen in S3D. Don't know about in Game.)

I could just check for anything over 1 and subtract 1 to drop them in place.

So far (That I've found) only the ship Hulls and Sub Hulls are Mapped like this.
Guess it'll be another round of extracting every GR2 file in SH5 to be sure
there's not something else that may get whacked.
:haha:

Quote:

I could just check for anything over 1 and subtract 1 to drop them in place.

This seems rather dangerous, because you can have stretched textures with values that exceed >2, or <1, <2 etc. In more advanced 3D computing the uvmap data can be offset using a premultiplied value (for U, V, W seperately), which is defined at the material. (as I said this is also possible in Max). SH3/4 do not have this ability, but SH5 may (because obviously GR2 is way more advanced). The benefit is obvious, less uv data needs stored, only when rendering is the uv data correctly calculated. If this is the case for SH5/GR2, you will have to facilitate this in your export code and transform the uv map data correctly by these offsets (which again, may be material specific), since OBJ/DAT, and thus, S3D and SH3/4 do not support this. You would do nothing more than store incorrect data in OBJ from the start, which is why S3D and other OBJ-viewers would not show correctly.

Hello Privateer

Please forgive me if what I say below had nothing to do with the UVs problem you are discussing here. I've only taken a quick look at the above posts and I have only quickly tested the first version of your program (although I have recommended your work in a job that I posted in the forum recently).

I noticed the shifting of UVs, but, If I'd want to let OK the UVs produced by your program (the first version, remember) in 3DS Max, I would not flip the UVs and then would displace them, but instead, for each UV vertex I would change the sign of its Y coordinate.

As an example, if I select the ship's hull and then run this script, all the UVs left OK, without having to flip and move them.

Code:

oMesh=selection[1]



for idx = 1 to oMesh.numTVerts do (

    oTVert = getTVert oMesh idx

    setTVert oMesh idx [oTVert.x, -oTVert.y, 0]

)

update oMesh

##### EDITED/ADDED ##########
What I mean is that in this way the UVs don't become shifted. I don't know if you have already noticed and fixed it in the last version. I believe it also makes sense that when you export them, for SH5, you only must change again the sign of the UV's Y coordinate.
##########################

Please again, excuse me if this had nothing to do with the problem discussed above.
(sorry too for my insufficient English)

toniloCoyote

Spot on, exactly what I was talking about! But the inversion of the sign must be defined somewhere in GR2, instead of assuming by default, unless this can be tested/verified for all models, because it 'can' be different on a per model basis...

Well, I think this is a specification of GR2 format and is not a per Ship issue. It depends on what the renderer engine understands by up and down.

As I said, I believe you must do this inversion for every GR2 model, and not only for SH5's ones (at least if you want 3DS Max to understand them), but I'm not completely sure of it. I agree with you that It's better to test all the ships.

Regards.

Ok, to prove the point further...

I don't have 3dsmax so I looked online for an example, but see here:

http://graphicstutorials.org/wp-cont...-Tutorial3.jpg

Notice the U/V offset and tiling values, and the mirror and tile checkboxes (and even a rotation option). These are uv transform settings, defined 'per material'. If you flip a 'sign' like you have, you essentially tick the mirror checkbox iirc (or whatever, too long ago). Since GR2 is a fairly advanced format, I wouldn't be amazed if it supports similar functionality. I don't say it does, but if it does, it can be different per model (and per material even) and depends more on how consistent the devs have been, so it's worth checking out. If GR2 isn't that sofisticated, then yes, flipping the sign is an easy fix.

Tiling in the GR2s in SH5 is set at 3.
But in 3DS Max, Deep X, and several other Viewers?
Everything shows fine for the textures and UV stuff.
I exported the exact settings as can be seen in the Granny Viewer.
Flipped the dds texture as the GR2 files are set to invert things to SH3/4 standards.
I'm workikng up images and the pack of files I worked with to
explain what is going on better.

I'll have screen shots of Deep X, 3DS Max 2008, S3D, and in Game SH4.
All will use the same files as exported exactly as the GR2 is listed in the GrannyViewer.

@skwasjer:

Excuse me if I have not expressed myself correctly in my previous posts. I do not know what is causing the problem you are discussing here. I only know which is the cause of an issue that is happening when importing into 3DS Max from the first version of Privateer GR2Exporter. Due that this defect looked like the problem that you are discussing here, I mentioned it just in case it could be the same issue.

People who work with 3DS max we are used to suffer these problems due to the differences in the coordinates between other packages and 3DS Max. Because the origin of 3DS Max as a CAD application, these differences occur with many other packages and, for us, it is normal to have to reverse or to exchange coordinates. Very rarely it does not happen.

However, this also happens between GR2 and 3DS Max; GR2 uses by default a coordinates system in which, to import its models into 3DS Max, you must swap the YZ coordinates of geometry, and must reverse the Y coordinates of UVs, and Privateer did not do any of those things (at least in the first version of GR2Exporter). Because he is developing an importer / exporter for 3DS Max, I remembered this to him.
As an example you can see the source code of "GR2 Decoder" converter (from its web), which converts files into scripts for 3DS Max. There, the developer reverses the sign of the Y coordinates of the UVs, and this converter is not made for SH5.

As for the "Mirror" checkbox in the material editor of 3DS Max, all who use this program we know it and use it often, but this is not the problem nor the solution. You must not reverse the UVs as a whole (flip it around its local center), which is what this checbox does, what you need to do is to reverse the sign of the UVs Y coordinates (flip it around global 0). If you do otherwise (for example, if you use the checkbox) the textures will appear displaced.

This checkbox is not the only place where you can change the orientation of the UVs; even the original SDK exporter of Rad Game Tools gives you the option of reversing the UVs.
The effect of both options is reflected in the final structure of the GR2 file, in the per material struct fields:

UVWTransform (granny_real32)
mirrorU (granny_int32)
mirrorV (granny_int32)

These are the places where, as you well say, one should look to see if there has been a change in the UVs, made by using the methods described above. But if you look at these fields (i.e. in Granny Viewer) you will see that SH5 vessels show no change in these fields and, even then, the Y coordinates of their UVs should be reversed (changed in sign) for 3DS Max understands it.

I'm just saying what needs to be done in order to successfully import a SH5 ship into 3DS Max, I do not know if this has anything to do with the problem you are discussing here. Forgive me if this has nothing to do. I never wanted to say you're wrong, indeed I agree with you. I only say that GR2 uses a different UVs coordinate system than 3DS Max.

Best regards.

@Privateer

You have a couple of outstanding PM's

Here's the start of the TexCoords Chain.
The Export is a direct write of the Values in the file NBB_QE.GR2
This shot shows the values in GRViewer, the matching values in the obj file, and how they look in 3DS Max 2008.
http://i108.photobucket.com/albums/n...ords_Chain.jpg
The only thing done was to flip the dds files so the Textures would render in place in all shots to follow.

First is Goblin with the original GR2 file.http://i108.photobucket.com/albums/n...E_Hull_SH5.jpg

Now Rendered in Deep X useing the Exported Hull obj file.
http://i108.photobucket.com/albums/n...QE_Hull_DX.jpg

So a direct export seems to be working so far.