GR2 Editor/Viewer/Extractor/Importer

[TheDarkWraith]

Originally Posted by gap

Have you looked into why, once imported with your application, the baloon gets so many 'redundand' vertices? Looking in its UV map, I have spotted a few unwelded vertices which can be optimized before importing, but they evidently can't be the one reason for the many tangents/binormals displayed by your application for each vertex.

P.S: what is the exact meaning of the 'calculate' button in the meshes tab? IIRC, it says something about normals, but clicking on it does nothing apparently...

I explained the redundant vertices many posts ago. The Granny way needs a vertex for every set of unique uvs. That's not necessarily a Granny thing either as DirectX needs the same.

OBJ files are 'compressed' by listing all of the common vertices in the v section, the common normals in the vn section, and the common uvs in the vt section. The faces (f) section then links all of these together to create vertices. There is hardly ever a 1:1 ratio between all of these (3DS Max can export to a 1:1 ratio).

In your 3D modeling program you have a geometry visible on the screen. Each vertice that you see on the screen may actually be multiple vertices. Why multiple vertices? Might have 2 or more textures at that same point (thus needing 2+ unique sets of uvs). When you export this geometry that's visible the app will see that their are vertices that have the same positional data but different uv data. The app will export just one vertice (v) but 2 uvs (vt). If the normals are different between those vertices then it will export 2 normals (vn). Here is why I said OBJ files are 'compressed' earlier.

My app is now smart enough when reading in OBJ files to see that their are 2+ uvs (vt) referencing the same vertice (v) and thus will create clone(s) of the vertice (v) to properly render the geometry.

Clicking the Calculate button will have the app recompute the binormals and tangents of the currently selected mesh (if it has either/both). It appears to do nothing but it does do something

[gap]

Originally Posted by TheDarkWraith

In your 3D modeling program you have a geometry visible on the screen. Each vertice that you see on the screen may actually be multiple vertices. Why multiple vertices? Might have 2 or more textures at that same point (thus needing 2+ unique sets of uvs). When you export this geometry that's visible the app will see that their are vertices that have the same positional data but different uv data. The app will export just one vertice (v) but 2 uvs (vt). If the normals are different between those vertices then it will export 2 normals (vn). Here is why I said OBJ files are 'compressed' earlier.

That is clear. What I don't get, is why one vertex at the center of a 'continuous' UV region (as I undesrtand it, that shoul be equal to 'same UV data'), is split in two or more vertices. Currently, it looks like -after porting from obj to granny format- every vertex is repeated as many times as the number of polygons sharing it. In other words, every polygon is handled as a distinct geometry, no matter if it got the same UV data as adjacet polygons or not.

Originally Posted by TheDarkWraith

Clicking the Calculate button will have the app recompute the binormals and tangents of the currently selected mesh (if it has either/both). It appears to do nothing but it does do something

Aren't tangents and binormals calculated automatically each time a new mesh is imported? What is the use of caalculating them again?

[TheDarkWraith]

Originally Posted by gap

That is clear. What I don't get, is why one vertex at the center of a 'continuous' UV region (as I undesrtand it, that shoul be equal to 'same UV data'), is split in two or more vertices. Currently, it looks like -after porting from obj to granny format- every vertex is repeated as many times as the number of polygons sharing it. In other words, every polygon is handled as a distinct geometry, no matter if it got the same UV data as adjacet polygons or not.



Aren't tangents and binormals calculated automatically each time a new mesh is imported? What is the use of caalculating them again?

Couldn't tell you why the 3D app you used had multiple vertices with different UV data. I just read the OBJ file and react accordingly. It's something with the way the object was exported with the 3D modeling app and/or how it's UV mapping was done.

Yes tangents and binormals are calculated automatically each time a new mesh is imported (if they are in the vertex declaration). That button is there to force the calculation (such as on SH5's GR2s).

I haven't finished this feature yet but I'm coding in the ability to modify a vertex's normal with the app (using the mouse). You select the vertex and turn on display normals. Then if you grab the end of the normal you can move it with the mouse. This will allow fine tuning of the normals Then after you modify the normal the app will have to calculate the new binormal and tangent since they are based on the normal.

[gap]

Originally Posted by TheDarkWraith

Couldn't tell you why the 3D app you used had multiple vertices with different UV data. I just read the OBJ file and react accordingly. It's something with the way the object was exported with the 3D modeling app and/or how it's UV mapping was done.

Okay, I will mess with different applications and inform you in case I find anything interesting about UV coordinates.

Originally Posted by TheDarkWraith

Yes tangents and binormals are calculated automatically each time a new mesh is imported (if they are in the vertex declaration). That button is there to force the calculation (such as on SH5's GR2s).

I haven't finished this feature yet but I'm coding in the ability to modify a vertex's normal with the app (using the mouse). You select the vertex and turn on display normals. Then if you grab the end of the normal you can move it with the mouse. This will allow fine tuning of the normals Then after you modify the normal the app will have to calculate the new binormal and tangent since they are based on the normal.

[TheDarkWraith]

v1.1.434.1 released. See post #1

- Fixed memory leaks found
- More optimizations done to decrease loading/save time
- everything else mentioned in the previous posts since last version was released

[gap]

Originally Posted by TheDarkWraith

v1.1.434.1 released. See post #1

- Fixed memory leaks found
- More optimizations done to decrease loading/save time
- everything else mentioned in the previous posts since last version was released

Thank you TDW

[tonschk]

Amazing Thank you

Originally Posted by TheDarkWraith

v1.1.434.1 released. See post #1

- Fixed memory leaks found
- More optimizations done to decrease loading/save time
- everything else mentioned in the previous posts since last version was released

[TheDarkWraith]

Originally Posted by tonschk

Amazing Thank you

Long time ago I tried to make the app multi-threaded but had many problems with it. I finally figured out my multi-threading issues

Before I would read everything sequentially and in sequential order. For instance: read all Textures and read each texture of those Textures one at a time. When done reading Textures then read all Materials reading each one at a time. That worked ok but loading times were really lousy.

Now I still read everything sequentially (Textures then Materials then ...) but in each section (Textures, Materials, etc.) I spawn off additional threads equal to the number of items in the section thus achieving a parallel read of all the items of the section.

I did this for the PrimaryVertexData and the Meshes so far and the results are excellent Loading the Bunker.GR2 on my home system takes ~11.3 seconds using the old method. Using the multi-threaded method reduced the loading time to ~8.0 seconds. That's a 30% reduction in loading time I have an 8 core AMD processor so the total number of concurrent threads (that's ALL threads currently defined in the OS) that can be running at any time is 8 (even though 40 threads are spawned when the PrimaryVertexData is read in a max of 8 will be 'running' at any time.) . The more CPUs and the more cores each CPU has then the lower the loading time will be. Intel processors will have a much faster loading time due to their hyper-threading (they can run more than 1 thread per core on each processor and they have a higher IPC than AMD).

Now I haven't even done any optimizations on the multi-threading yet (like having the PrimaryVertexData spawn additional threads for the vertices). This was just a trial run to see if I finally fixed the multi-threaded problem I was having a long time ago.

[tonschk]

increasing the performance of the GR2 Editor Very good

Originally Posted by TheDarkWraith

Loading the Bunker.GR2 on my home system takes ~11.3 seconds using the old method. Using the multi-threaded method reduced the loading time to ~8.0 seconds. That's a 30% reduction in loading time

[tonschk]

Hi there, please can you tell me how to zoom this mesh/texture view of the tower ?, thank you

[TheDarkWraith]

Originally Posted by tonschk

Hi there, please can you tell me how to zoom this mesh/texture view of the tower ?, thank you

press H to bring up the help menu. Then press M to view the mouse commands.

You'll see that if you right click and hold and move the mouse forward/backward you can zoom.

You can also use the arrows on the numpad to 'walk' fwd/bckwd/left/right.

[gap]

Hi TDW,

how hard would be the (temporary) merging of two GR2 files in your application? I make myself clear: one of the major differences among SHIII-IV sea units and SH5 ones, is that most general effects are linked to the bones of a second GR2 file (*_FX.GR2) which gets "overlayed" in game to the main GR2 file. By looking into several *_FX.GR2 files, I have noticed that their bones follow roughly the profile of the model they apply to. Should we create a new GR2 ship, we would be forced to move her FX nodes blindly though. The task would be much easier if we could preview the 3d model (of the main GR2 file) over the nodes (of her FX GR2).

[TheDarkWraith]

Originally Posted by gap

Hi TDW,

how hard would be the (temporary) merging of two GR2 files in your application? I make myself clear: one of the major differences among SHIII-IV sea units and SH5 ones, is that most general effects are linked to the bones of a second GR2 file (*_FX.GR2) which gets "overlayed" in game to the main GR2 file. By looking into several *_FX.GR2 files, I have noticed that their bones follow roughly the profile of the model they apply to. Should we create a new GR2 ship, we would be forced to move her FX nodes blindly though. The task would be much easier if we could preview the 3d model (of the main GR2 file) over the nodes (of her FX GR2).

The app supports LNK entries and prt files. If the app needs to load additional files in it will as long as the options are set to do this.

You can see this effect when loading any player's sub (if the options are set to do it)

[gap]

Originally Posted by TheDarkWraith

The app supports LNK entries and prt files. If the app needs to load additional files in it will as long as the options are set to do this.

You can see this effect when loading any player's sub (if the options are set to do it)

Yep, I know it, but how can I preview a ship model while I am editing its FX.GR2 file?

[TheDarkWraith]

Originally Posted by gap

Yep, I know it, but how can I preview a ship model while I am editing its FX.GR2 file?

Open both of them up with the app at the same time. The app does allow you to open multiple GR2 files at once.