GR2 Editor/Viewer/Extractor/Importer

[TheDarkWraith]

Originally Posted by gap

It makes perfect sense, but why 3ds max exports of the same ballon model, whose vertices are also optimized, are imported correctly by GR2 Editor?

Please have a look to the obj files below (kindly provided by Targor Avelany) to know what I mean:

https://www.mediafire.com/?2l6uew8aqxebk2y

Look at the OBJ files produced by 3DS Max and compare them to the ones made by Wings 3D. It's really easy to spot why the 3DS Max ones work correctly. Here is an excerpt from the 3DS Max one:

g balloon_Balloon
usemtl _balloon_MkVII_4Balloon
s 1
f 1/1/1 2/2/2 3/3/3
f 1/1/1 4/4/4 5/5/5
f 3/3/3 6/6/6 7/7/7
f 3/3/3 4/4/4 1/1/1
f 3/3/3 8/8/8 4/4/4
f 3/3/3 9/9/9 8/8/8
f 7/7/7 6/6/6 10/10/10
f 7/7/7 9/9/9 3/3/3
f 10/10/10 9/9/9 7/7/7
f 10/10/10 11/11/11 9/9/9
f 5/5/5 2/2/2 1/1/1
f 5/5/5 12/12/12 2/2/2

Look how everything is a 1:1 ratio (vertices are not optimized). This one is ready for import into a GR2 file. Check the Wings3D one and you'll see that there is no 1:1 ratio (it's very evident). It's not Granny friendly. Do you see what I'm talking about?

[gap]

Originally Posted by TheDarkWraith

Look at the OBJ files produced by 3DS Max and compare them to the ones made by Wings 3D. It's really easy to spot why the 3DS Max ones work correctly. Here is an excerpt from the 3DS Max one:

g balloon_Balloon
usemtl _balloon_MkVII_4Balloon
s 1
f 1/1/1 2/2/2 3/3/3
f 1/1/1 4/4/4 5/5/5
f 3/3/3 6/6/6 7/7/7
f 3/3/3 4/4/4 1/1/1
f 3/3/3 8/8/8 4/4/4
f 3/3/3 9/9/9 8/8/8
f 7/7/7 6/6/6 10/10/10
f 7/7/7 9/9/9 3/3/3
f 10/10/10 9/9/9 7/7/7
f 10/10/10 11/11/11 9/9/9
f 5/5/5 2/2/2 1/1/1
f 5/5/5 12/12/12 2/2/2

Look how everything is a 1:1 ratio (vertices are not optimized). Check the Wings3D one and you'll see that there is no 1:1 ratio (it's very evident).

Yep, but when I open the 3ds Max obj file in Wings3d, the duplicated vertices are apparently not there. Moreover, if I re-export those meshes, their UV map is broken again by GR2 Editor.

Maybe Max uses a special format for those vertices which is recognized by Wings, and redundant vertices (for Wings) are merged automatically on importing them?

The same does not apply to S3d/GR2 Editor obj exports. When inported in Wings3d, I can clearly see that meshes have been cut along the perimeter of their UV zones.

[TheDarkWraith]

Originally Posted by gap

Yep, but when I open the 3ds Max obj file in Wings3d, the duplicated vertices are apparently not there. Moreover, if I re-export those meshes, their UV map is broken again by GR2 Editor.

Maybe Max uses a special format for those vertices which is recognized by Wings, and redundant vertices (for Wings) are merged automatically on importing them?

Just looking over the OBJ exports from Wings3D shows that it's doing some kind of optimization on your model. It clearly is removing duplicate vertices either by welding them together or just completely throwing them out.

I don't think 3DS Max is using any kind of special format. It just has no problem with duplicate vertices. It's very Granny friendly

I've used Wings3D in the past and had no problems with importing the OBJ files from it so there is something 'different' with your model. Once I get back home today I'll code in the cloning of duplicate vertice indexes found in the importer and I can almost guarantee it will fix the problem with your model.

[gap]

Originally Posted by TheDarkWraith

Just looking over the OBJ exports from Wings3D shows that it's doing some kind of optimization on your model. It clearly is removing duplicate vertices either by welding them together or just completely throwing them out.

I don't think 3DS Max is using any kind of special format. It just has no problem with duplicate vertices. It's very Granny friendly

I think I know what is happening: Wings3d welds automatically redundant vertices within the same geometry (as it is the case of the Max-exported balloon). On the contrary, it keeps coinciding vertices, if they are located in different geometries combined together (as for S3d/GR2E obj files).
If you are familiar with Wings you know what I mean

Originally Posted by TheDarkWraith

I've used Wings3D in the past and had no problems with importing the OBJ files from it so there is something 'different' with your model.

As far as I can see it all depends on the complexity of the UV mapping. If you set few UV zones, or if the texture one is using is relatively uniform, you won't ever spot the mistakes, if any.

Originally Posted by TheDarkWraith

Once I get back home today I'll code in the cloning of duplicate vertice indexes found in the importer and I can almost guarantee it will fix the problem with your model.

[TheDarkWraith]

Originally Posted by gap

I think I know what is happening: Wings3d welds automatically redundant vertices within the same geometry (as it is the case of the Max-exported balloon). On the contrary, it keeps coinciding vertices, if they are located in different geometries combined together (as for S3d/GR2E obj files).
If you are familiar with Wings you know what I mean



As far as I can see it all depends on the complexity of the UV mapping. If you set few UV zones, or if the texture one is using is relatively uniform, you won't ever spot the mistakes, if any.

Like I said earlier, if I clone vertices that are duplicated in the OBJ file the results speak for themselves:


This was your Wings3D OBJ barrage balloon imported into Iceberg01

[TheDarkWraith]

v1.1.403.1 released. See post #1

This version enhances the loose importer. If an OBJ file has indices that define a vertex more than once then for every indice for that vertex after the first the importer will clone that vertex thus keeping a 1:1 ratio (Granny friendly).

The strict importer will NOT do this. After all it's a strict import and the vertices defined in the OBJ file must equal the number of vertices defined in the mesh.

[gap]

Originally Posted by TheDarkWraith

v1.1.403.1 released. See post #1

This version enhances the loose importer. If an OBJ file has indices that define a vertex more than once then for every indice for that vertex after the first the importer will clone that vertex thus keeping a 1:1 ratio (Granny friendly).

The strict importer will NOT do this. After all it's a strict import and the vertices defined in the OBJ file must equal the number of vertices defined in the mesh.

My Hat's off TDW. The UV map problem had bothered me for the last 3 months

Since we are at it, have you looked into the smoothing groups issue yet? and wath about the other problem I had pointed (see below)?

Originally Posted by gap

another weirdness that should be addressed:

http://www.subsim.com/radioroom/show...&postcount=149
http://www.subsim.com/radioroom/show...&postcount=154

This time I had exported some of the crates from small_generic_01.GR2, edited their height in wings, and imported them back in the same file (strict import, only vertices coordinates imported, keep existing Norma/AO data yes). Their material was getting corrupt. The one cure I was able to find, was setting a new material and discarding the old one.

[TheDarkWraith]

Originally Posted by gap

My Hat's off TDW. The UV map problem had bothered me for the last 3 months

Since we are at it, have you looked into the smoothing groups issue yet? and wath about the other problem I had pointed (see below)?

The loose importer had a problem with smoothing groups. It was fixed in the newest version.

If the importers encounter any 's x' entries in the OBJ files they ignore them (they just skip over them). So shouldn't matter anymore.

The other problem I have to fire up the app in the debugger and see. What files were used and what exactly did you do?

[gap]

Originally Posted by TheDarkWraith

The loose importer had a problem with smoothing groups. It was fixed in the newest version.

If the importers encounter any 's x' entries in the OBJ files they ignore them (they just skip over them). So shouldn't matter anymore.

Originally Posted by TheDarkWraith

The other problem I have to fire up the app in the debugger and see. What files were used and what exactly did you do?

It has been quite a long time since I experienced that problem. All I can remember is:

file name: small_generic_01.GR2

task performed: exported crates mesh (if you look into that GR2 there are some levitating crates at the end of the docks); edited their y coordinate in Wings3d; imported them back in the same GR2.

import method: strict import (only vertex coordinates imported, kept the existing AO/Normal coordinates when prompted about them).

problem experienced: the crate material gor corrupted (over-reflective), but the GR2 was still working in game.

In case they can help, I think i have a back-up of the GR2 file with my updates and of the meshes imported in it.

P.S: have you seen this last suggestion?

Originally Posted by gap

On a side note: TDW, can you make error messages into selectable text fields, for us to quickly copy/paste them on the forum?

[TheDarkWraith]

I'm coding something new into the app that will allow you to 'see' how the vertices for a mesh are 'coded'. This is very important if you are going to use existing GR2s as a base for something new. Vertices can have lots of items defined for them such as:
- position (translation)
- UV1
- UV2
- bone weights
- rotation
- normal
- tangent
- binormal
- etc.

There are many ways to define a vertex. If you try and use a mesh that doesn't have the correct vertex information defined your new mesh may not render correctly. Worse yet a mesh could have vertex information that you don't need and needs to be defined but you don't define it so it renders badly/incorrectly.

Ultimately I'm trying to code in a way to change the vertex declaration for the mesh. Since this is Granny it won't be easy

[gap]

Originally Posted by TheDarkWraith

I'm coding something new into the app that will allow you to 'see' how the vertices for a mesh are 'coded'.

Most useful

[TheDarkWraith]

Originally Posted by gap

It has been quite a long time since I experienced that problem. All I can remember is:

file name: small_generic_01.GR2

task performed: exported crates mesh (if you look into that GR2 there are some levitating crates at the end of the docks); edited their y coordinate in Wings3d; imported them back in the same GR2.

import method: strict import (only vertex coordinates imported, kept the existing AO/Normal coordinates when prompted about them).

problem experienced: the crate material gor corrupted (over-reflective), but the GR2 was still working in game.

In case they can help, I think i have a back-up of the GR2 file with my updates and of the meshes imported in it.

P.S: have you seen this last suggestion?

In regards to that last suggestion click the Status tab in the app. I'm fairly certain that 99% of what's displayed in a dialog box shows up there also. You should also be able to highlight the text in the dialog box and press Ctrl+C to copy it to the clipboard.

Send me the files you have for this small_generic_01.gr2 thing.

[gap]

Originally Posted by TheDarkWraith

In regards to that last suggestion click the Status tab in the app. I'm fairly certain that 99% of what's displayed in a dialog box shows up there also. You should also be able to highlight the text in the dialog box and press Ctrl+C to copy it to the clipboard.

Okay, I will try.

Originally Posted by TheDarkWraith

Send me the files you have for this small_generic_01.gr2 thing.

This is the GR2 file with the broken material:

http://www.mediafire.com/download/5z...20textures.rar

In GR2 Editor everything looks fine, but if you open the file in Goblin (or in game) crates should look like this:



As I said before, the problem is in the material. The one solution I found, was replacing the corrupt material with a new one.

I will look into my hard drive for the meshes whose importing corrupted the material, if you think they can help you in understanding what went on

[TheDarkWraith]

Originally Posted by gap

This is the GR2 file with the broken material:

http://www.mediafire.com/download/5z...20textures.rar

In GR2 Editor everything looks fine, but if you open the file in Goblin (or in game) crates should look like this:

You do know that you can turn lighting on in the app right? This allows you to check the normals and all to verify they are ok. I bet if you turned lighting on and defined some lights you would've seen this in the app also

[gap]

Originally Posted by TheDarkWraith

You do know that you can turn lighting on in the app right? This allows you to check the normals and all to verify they are ok. I bet if you turned lighting on and defined some lights you would've seen this in the app also

No, I'd never noticed this feature