GR2 Editor/Viewer/Extractor/Importer [Archive] - Page 9

TheDarkWraith

06-08-13, 09:38 AM

There are a couple problems with the above code. One, the header files used most likely are from RAD games tools SDK (or were based off of them) and thus are copy protected. It would be very hard to prove that you somehow magically were able to make these header files. Two, being able to read the file is nice but if you can't change it and write it back it's useless.

My app uses nothing from RAD games tools. It can also read, manipulate, and write GR2s. Granted I cannot manipulate everything contained in them (animations for example) but I can at least read the existing data for them and write it back.

Ekmek

06-10-13, 12:22 PM

DarkWraith,

Over in civ5 land we now have a tool (http://forums.civfanatics.com/showthread.php?t=496855) that lets us export our gr2s including the leaders you were working on then import them into blender to modify. I know you put in a lot of hardwork on those and I appreciate it. If you hit a wall on them, then I'm fine if you move on to something more SH5 specific.

Thank you for all your work on this!

gap

06-10-13, 03:11 PM

Over in civ5 land we now have a tool (http://forums.civfanatics.com/showthread.php?t=496855) that lets us export our gr2s including the leaders you were working on then import them into blender to modify.

:yeah:

machiavelli

06-26-13, 10:53 AM

Could someone please re-up this tool the link is dead.

Thanks.

machiavelli

06-26-13, 10:55 AM

OK, its been disabled for download.

machiavelli

06-26-13, 10:55 AM

Any other alternatives in order to export .gr2 to .obj ?

machiavelli

06-26-13, 10:57 AM

Will this method work for sh5 .gr2 files?

http://forums.civfanatics.com/showthread.php?t=496855

machiavelli

06-26-13, 12:04 PM

I'd like a version of this program specifically for gr2 to .obj conversion. CAn someone pass it along to me? PM, whatever. Thanks.

Vanilla

06-27-13, 04:48 AM

Will this method work for sh5 .gr2 files?

http://forums.civfanatics.com/showthread.php?t=496855

At least 'out of the box' it silently crashes for me upon trying to open a SH5 .gr2 My guess it is not generic enough as opposed to TDWs EVE.

Madox58

06-27-13, 01:42 PM

The source code for NexusBuddy 2 is available.
Download it and adjust it to work with SH5 GR2 files.
And NO. I don't give out my exporters any longer.
Especially to people I don't like.

Anvart

07-05-13, 02:11 AM

...
I don't give out my exporters any longer.
Especially to people I don't like.
... and not only for the above mentioned persons. :haha:
If you do not give anyone your exporter the phrase "Especially to people ..." looks incorrect.
..., the header files used most likely are from RAD games tools SDK (or were based off of them) and thus are copy protected. ...
??? ... or you do not know what are hacking and reverse engineering?
... the frequent repetition of written by you leads to some suspicion. :haha:

gap

08-23-13, 05:20 PM

Looks like I finally figured out what's going on with Goblin/SH5. You can only define 2 materials for each mesh. The third material (if defined) is an opacity or something else map (not quite sure but if you define a third material that has a texture Goblin/SH5 crashes). If a third material is defined it has to have no texture and no maps.

No matter how many subsets are defined each mesh can only contain 2 materials (that have maps defined). Not exactly limiting but not exactly freedom either.

Late reply :03:

...it seems I have just stumbled upon an exception to the above statements by TDW:

http://img826.imageshack.us/img826/1945/a9a3.jpg

Do you see what I mean?

same mesh, 3 subsets, 3 different materials assigned, each with its own diffuse and self-illumination maps :hmm2:

PS: the GR2 file doesn't hang Goblin up. I cannot check if it renders the file corretly, because its meshes have a huge offset from the enter of the scene, and locating them in the scene preview window is a bit hard.

oakdesign

08-24-13, 03:05 AM

PS: the GR2 file doesn't hang Goblin up. I cannot check if it renders the file corretly, because its meshes have a huge offset from the enter of the scene, and locating them in the scene preview window is a bit hard.

Do you mean the SH5 Goblin or TDW Goblin

In SH5 Goblin I can center object with huge offset by selecting them in the scene tree and then select "ctrl + Q" or the "Center on selection" command from the View menu

gap

08-24-13, 03:39 AM

Do you mean the SH5 Goblin or TDW Goblin

In SH5 Goblin I can center object with huge offset by selecting them in the scene tree and then select "ctrl + Q" or the "Center on selection" command from the View menu

LOL after much messing with Goblin I had not realized it yet :doh:

Thank you for the tip mate :salute:

Anvart

08-24-13, 06:47 AM

Where is our "whipping boy"... (lol)
or Rad Game "finished off" him?

oakdesign

08-24-13, 07:34 AM

Where is our "whipping boy"... (lol)
or Rad Game "finished off" him?

I think last sign of life was from a small island somewhere in the southern pacific:hmm2:

gap

08-24-13, 10:48 AM

I think last sign of life was from a small island somewhere in the southern pacific:hmm2:

...where he probably was airdropped by the CIA together with his laptop and a basic survival kit :O:

gap

09-01-13, 02:45 AM

The last day I found the following interesting resources about:

.obj format (http://paulbourke.net/dataformats/obj/);
.mtl format (http://paulbourke.net/dataformats/mtl/).

I am sharing them just in case TDW or someone else will need for them in future. :)

Anvart

09-03-13, 05:18 AM

TDW knows about it. :woot:

tonschk

09-03-13, 06:25 AM

The last day I found the following interesting resources about:.obj format (http://paulbourke.net/dataformats/obj/);
.mtl format (http://paulbourke.net/dataformats/mtl/).

I am sharing them just in case TDW or someone else will need for them in future. :)
Thank you :salute: Gap :yeah:

CPF

09-17-13, 10:33 AM

Madox58

09-17-13, 10:36 AM

You skip the first 104 bytes.
I still have the script for 010 that corrects checksums in the GR2 files if you want it.

CPF

09-17-13, 10:49 AM

You skip the first 104 bytes.
I still have the script for 010 that corrects checksums in the GR2 files if you want it.

Sure! That would be great.

Madox58

09-17-13, 11:04 AM

http://www.mediafire.com/download/5zz4g0v0mdv3369/GR2checksum.7z

:salute:

CPF

09-17-13, 11:09 AM

awesome! :salute:

kangcliff

10-06-13, 01:18 AM

I've been looking for a tool that changes the texture paths in previous gr2 versions.

The version I'm using is 2.5.0.1.

Thanks.

Anvart

10-06-13, 03:11 AM

Hi Anvart,

A while back in this thread you posted a screen capture of 010 Editor, showing the CRC for NBB_King_GeorgeV.GR2. What range are you excluding to get the correct CRC to show in Checksum/Digest?
Hi, CPF.
I rarely visit the forum.
Link to the original script for 010 Editor (for publish) is in this thread.
If you are not can to find it:
http://www.mediafire.com/download/9qa0sfsny4yxj17/GR2checksum.1sc

CPF

10-06-13, 09:15 AM

Hi, CPF.
I rarely visit the forum.
Link to the original script for 010 Editor is in this thread.
If you are not can to find it:
http://www.mediafire.com/download/9qa0sfsny4yxj17/GR2checksum.1sc

Thanks Anvart !

Privateer provided a link for that script for 010, which I am using now.
:up:

Madox58

10-06-13, 10:10 AM

I've been looking for a tool that changes the texture paths in previous gr2 versions.

The version I'm using is 2.5.0.1.

Thanks.

Can you provide one of the GR2 files to check?

kangcliff

10-07-13, 04:20 AM

This one is an uncompressed gr2 file.
http://www.mediafire.com/download/vwp4fhxpd1rd51m/cuirassier_age1_horse.gr2

Other gr2 files are here.
http://www.mediafire.com/download/m2r8137jv6ua7ls/med_fort.gr2
http://www.mediafire.com/download/i3ve8rp4b26x3li/ironclad.gr2
http://www.mediafire.com/download/vyqiru44l56fw3h/pikeman_1age.gr2

Thanks a lot,Privateer.:)

Madox58

10-07-13, 04:20 PM

PM sent Mate.

Madox58

10-15-13, 05:42 PM

To the AOE3 Guys.
The GR2 files are different from the SH5 files.
I'm looking at them as time permits so PM me for contact info and information.

Rongel

10-16-13, 11:38 AM

Help! :wah:

I want to fix the floating crates in Memel harbour. So located the right file (small_generic_01.GR2), opened it in the TDW's GR2 editor (i'm using v.1.1.272.1), and exported the mesh using default settings.

Then I open Blender, import the .obj file, correct the crates and try import the file back to GR2 editor. And it never works! I try the strict and loose import but the result is always "No verticies found in..."

So what I am doing wrong during importing/exporting? I don't know much about 3d stuff, but I thought I could fix this hovering crate annoyance myself.

I tried to find a post concerning importing/exporting meshes but couldn't find one so if somebody could point me in the right direction with this, I would be really happy!

Targor Avelany

10-16-13, 12:08 PM

Rongel

10-16-13, 12:38 PM

try switching the settings for using regional settings. I've had that problem and it relates on how the decimals are split out: with coma or a period. Depending on what is used between GR2 editor and your 3d editor you get this result.

Thanks for the tip! I tried changing the regional setting but still the same result... Must try harder... It bothers me also that the exported file from GR2 editor is bigger in size than the one from blender, am I missing some data here?

CPF

10-16-13, 01:08 PM

Thanks for the tip! I tried changing the regional setting but still the same result... Must try harder... It bothers me also that the exported file from GR2 editor is bigger in size than the one from blender, am I missing some data here?

@Rongel,

Is the file you are looking at in data\Terrain\Locations\CustomAreas\Small_generic ? It has 10s of thousands of vertices. I have the same version of TDWs Editor and it doesn't seem to like this file, asking questions about essential strings. Looks like there is also AO rendering as well. The file sizes not being close to the same indicates a lot of data is missing, the GR2 editor may only be exporting a small part of the GR2.

Targor Avelany

10-16-13, 01:19 PM

Thanks for the tip! I tried changing the regional setting but still the same result... Must try harder... It bothers me also that the exported file from GR2 editor is bigger in size than the one from blender, am I missing some data here?

oops. misread something in your original post.
so it works from GR2 to Blender, but not the other way around.

Send me a link w/ both exported files and if you want to take a screenie on how exactly are you exporting from blender.

Rongel

10-16-13, 01:20 PM

Is the file you are looking at in data\Terrain\Locations\CustomAreas\Small_generic ?No, the file is in the same location but is called "small_generic_01.GR2"

Editor opens the file without problems for me. Then I select the "Object13 (Mesh)" from the meshes tab and export it using default settings. No problems so far. I get several files and the Object13.obj is 335 kb. I can import it to blender, make the fixes, and export it again, but the file size is much lower and GR2 editor gives me error importing it. I really don't know much about the export/import settings so the problem can be there also (or then it's connected to the regional settings). Maybe somebody has time to make a quick test, import the crates, open in blender and export back to the editor???

Rongel

10-16-13, 01:38 PM

Send me a link w/ both exported files and if you want to take a screenie on how exactly are you exporting from blender.

PM sent! :salute:

CPF

10-16-13, 01:41 PM

No, the file is in the same location but is called "small_generic_01.GR2"

Editor opens the file without problems for me. Then I select the "Object13 (Mesh)" from the meshes tab and export it using default settings. No problems so far. I get several files and the Object13.obj is 335 kb. I can import it to blender, make the fixes, and export it again, but the file size is much lower and GR2 editor gives me error importing it. I really don't know much about the export/import settings so the problem can be there also (or then it's connected to the regional settings). Maybe somebody has time to make a quick test, import the crates, open in blender and export back to the editor???

Sorry, that's the file I meant. You are only exporting 1 mesh, so the file size will never match the GR2. That mesh has no AO, but the document Privateer posted includes the steps for diffuse and AO. I don't work much with Blender, so not sure how well it does the import of object files. I don't know if TDW will give his editor the ability to easily export complete GR2 files to obj. That is the part I am missing as well, the exporters I have found at other sites don't do a very good job either, like "evegr2toobj" (exports only the first mesh). Lots of problems can be created doing the export/import, Check Privateer's comments elsewhere in this thread.

CPF

10-16-13, 02:04 PM

Thanks for the tip! I tried changing the regional setting but still the same result... Must try harder... It bothers me also that the exported file from GR2 editor is bigger in size than the one from blender, am I missing some data here?

I get the same results as you, using Blender. The file size after export from GR2 Editor is 335kb. Import to blender, and export without making changes, file size is 109kb. I tried the same file using XSI Softimage, the file size is larger (421kb) without changes. There is an AO map created, even though none is listed under materials in GR2 Editor.

Rongel

10-16-13, 02:25 PM

CPF

10-16-13, 02:48 PM

Did you try to import the blender-file back to GR2 editor, really interested to hear what the editor says in your case!

Yes, same error as you.. "no vertices found". I also did not fix the AO file which remained the same 335kb size, so there would be other problems even if it could import it.

You can see significant differences in the files just using notepad, both the obj and mtl.

Rongel

10-16-13, 03:00 PM

Ok! Thanks for the clarification, good to know it's not something I did! :salute:

And I thought that was a easy fix...

CPF

10-16-13, 03:04 PM

Ok! Thanks for the clarification, good to know it's not something I did! :salute:

And I thought that was a easy fix...

Was it not something to do with the low sea level in that port causing collision problems? Or you are working on something else entirely?

Rongel

10-16-13, 03:25 PM

periunder

10-16-13, 03:32 PM

This tool still unsucessfully extracts SH3 models. It doesn't extract the shader layer correctly.

gap

10-16-13, 05:41 PM

No nothing that important, it was a simple aesthetic issue, when you begin the game, there is couple of crates annoyingly hovering over the harbour and I just wanted to put them down to the ground :D.

Maybe I'll just lower the whole crate pile in GR2 editor...

Rongel, you don't need to edit crate meshes for stopping them from levitating. More simply, you can lower the y position of their binding bone :yep:

gap

10-16-13, 05:42 PM

This tool still unsucessfully extracts SH3 models. It doesn't extract the shader layer correctly.

What do you mean? :huh:

"This tool" has nothing to do with SH3 models. It only handles GR2 files...

Rongel

10-17-13, 01:12 AM

Rongel, you don't need to edit crate meshes for stopping them from levitating. More simply, you can lower the y position of their binding bone :yep:

Oh yes I do if I want to pay attention to details! :D

Because all the crates are at the same level, but the actual harbour height has differencies, so the harbour parts that are lower have levitating crates. If I lower the crates (I cant touch individual crates, they are part of a group), some will sink into the harbour. So that's why I wanted to edit only some of the crates and leave others where they are.

But still this is my plan B!

gap

10-17-13, 02:40 AM

Oh yes I do if I want to pay attention to details! :D

Because all the crates are at the same level, but the actual harbour height has differencies, so the harbour parts that are lower have levitating crates. If I lower the crates (I cant touch individual crates, they are part of a group), some will sink into the harbour. So that's why I wanted to edit only some of the crates and leave others where they are.

But still this is my plan B!

Okay, I will hava a look at the file you are trying to edit, to make myself a better idea of your problem :up:

Rongel

10-17-13, 06:42 AM

Okay, I will hava a look at the file you are trying to edit, to make myself a better idea of your problem :up:

Ok, but don't spend too much of your valuable time on this! :D

I got pretty good results just lowering them all in GR2 editor, probably nobody will notice that there is something fishy going on!

gap

10-17-13, 09:20 AM

Ok, but don't spend too much of your valuable time on this! :D

I got pretty good results just lowering them all in GR2 editor, probably nobody will notice that there is something fishy going on!

No problem, here is the GR2 file that you wanted to edit: :up:

http://www.mediafire.com/?5zxbgy8wd3575su

All the crates were lovered by 10 cm, except for the group at the end of the main dock, which was lowered by about 1 meter. Included in the package slightly improved crate textures:

http://img191.imageshack.us/img191/8261/hwpg.jpg

Rongel

10-17-13, 10:12 AM

No problem, here is the GR2 file that you wanted to edit: :up:

:o

But how?! I need to know! Did you manage to export the crates to some 3D program and edit it there and import it back? Anyway thanks, I'll use this!

gap

10-17-13, 10:30 AM

:o

But how?! I need to know! Did you manage to export the crates to some 3D program and edit it there and import it back? Anyway thanks, I'll use this!

Yes, don't ask me why, but for me it worked. This is what I did, in case you want to try again:

- exported crate meshes from small_generic_01.GR2 (default export options, but I could have selected only vertex coordinates);
- imported/edited/exported them in Wings 3d;
- imported back in GR2 Editor (strict import. Only vertex coordinates were required, but I coud as well import the remainig stuff with no apparent flaws).

What GR2 Editor version are you using? Your problem likely comes from there. If you want, I can send you my edited obj file for you to check if you can import it :salute:

Rongel

10-18-13, 09:11 AM

Yes, don't ask me why, but for me it worked. This is what I did, in case you want to try again:

- exported crate meshes from small_generic_01.GR2 (default export options, but I could have selected only vertex coordinates);
- imported/edited/exported them in Wings 3d;
- imported back in GR2 Editor (strict import. Only vertex coordinates were required, but I coud as well import the remainig stuff with no apparent flaws).

What GR2 Editor version are you using? Your problem likely comes from there. If you want, I can send you my edited obj file for you to check if you can import it :salute:

Ok, thanks, I'll use your file, tested it and it looks good! Probably GR2 editor doesn't like my Blender, or it is a regional thing like Targor suggested. Anyway, I'm happy now, no need to spend more time in this!

gap

10-18-13, 10:54 AM

Ok, thanks, I'll use your file, tested it and it looks good! Probably GR2 editor doesn't like my Blender, or it is a regional thing like Targor suggested. Anyway, I'm happy now, no need to spend more time in this!

Okay, let me know if you find any other flaw which might require a quick GR2 Editor tweak. :salute:

Talking about it, today I had a discussion with Torpedo about the dull appearance of the obs scope beam. Having had a look into its meshes, I realized that retexturing it would require new diffuse and/or AO mapping, and the setting of new texture definitions in Room_CR.GR2.

Tedious task, but probably feasible. How important is the fixing of this flaw to you, guys? Should I spend my time on it?

periunder

10-18-13, 02:26 PM

What do you mean? :huh:

"This tool" has nothing to do with SH3 models. It only handles GR2 files...

I apologize. Let me clarifiy.

I extracted GRf2 files from the interior of the type 7 in SH5, and wanted to insert them into SH3 using s3d. I was successful, with the base model coordinates, but not the shader coordinates. I tested the extracted interior models in several programs and they gave the same results, that the shader coordinates were corrupted. Do you know what the issue is?

I tried this a 6 months ago. Any new versions since?

gap

10-18-13, 07:09 PM

I apologize.

No need for it: no offence taken. I was just trying to put things clear. :)

I extracted GRf2 files from the interior of the type 7 in SH5, and wanted to insert them into SH3 using s3d. I was successful, with the base model coordinates, but not the shader coordinates. I tested the extracted interior models in several programs and they gave the same results, that the shader coordinates were corrupted. Do you know what the issue is?

Do you mean the AO texture mapping? Corrupted like this:

http://www.subsim.com/radioroom/showpost.php?p=2112247&postcount=3770
http://www.subsim.com/radioroom/showthread.php?t=189818&page=7

Those posts refers to the opposite problem (I was trying to import some custom made meshes in a GR2 file), but maybe they could also apply to your case.

Which GR2 file/mesh did you try to export exactly?

I tried this a 6 months ago. Any new versions since?

Unfortunately no :-?

Madox58

10-20-13, 08:41 AM

I get the same results as you, using Blender. The file size after export from GR2 Editor is 335kb. Import to blender, and export without making changes, file size is 109kb. I tried the same file using XSI Softimage, the file size is larger (421kb) without changes. There is an AO map created, even though none is listed under materials in GR2 Editor.
I talked with gap about the file size on export and how RAD has the files stored in the GR2 files.
Don't recall if it was by PM, E-mail, or in a thread here somewhere.
:hmmm:
I refer to it as 'shuffeling' or adding redundant verts to balance file sizes.

Importing the files into most 3D programs gets those thrown out as most programs optimize by default.

gap

10-20-13, 08:53 AM

I talked with gap about the file size on export and how RAD has the files stored in the GR2 files.
Don't recall if it was by PM, E-mail, or in a thread here somewhere.
:hmmm:
I refer to it as 'shuffeling' or adding redundant verts to balance file sizes.

Importing the files into most 3D programs gets those thrown out as most programs optimize by default.

Yes, I remember you saying it, three of maybe four weeks ago. What I don't get is the pupose of the redundant data and if we can discard it with no damage done :88)

Madox58

10-20-13, 09:01 AM

Yes, I remember you saying it, three of maybe four weeks ago. What I don't get is the pupose of the redundant data and if we can discard it with no damage done :88)
I just got called to go work on some ceramic tile job. :/\\!!
I'll post later tonite with details on why GR2 files use the redundant verts info.
You might check past posts in this thread to see if that's where We talked about this. It was when you had problems with the barrage balloon imports.

periunder

10-20-13, 02:16 PM

No need for it: no offence taken. I was just trying to put things clear. :)

Do you mean the AO texture mapping? Corrupted like this:

http://www.subsim.com/radioroom/showpost.php?p=2112247&postcount=3770
http://www.subsim.com/radioroom/showthread.php?t=189818&page=7

Those posts refers to the opposite problem (I was trying to import some custom made meshes in a GR2 file), but maybe they could also apply to your case.

Which GR2 file/mesh did you try to export exactly?

Unfortunately no :-?

Yes the AO texture mapping. I believe it was all of the AO texture mapping that were corrupted in everything I was extracting. I was extracting everything in the aft torpedo room interior.

Madox58

10-20-13, 02:30 PM

Yes the AO texture mapping. I believe it was all of the AO texture mapping that were corrupted in everything I was extracting. I was extracting everything in the aft torpedo room interior.

What were you useing to extract the meshes?
:hmmm:

If you mean the Room_TRF.gr2 I get perfect exports myself.
:03:

periunder

10-20-13, 03:19 PM

If you mean the Room_TRF.gr2 I get perfect exports myself.
:03:

A little heads up for you in the future: "TRF" stands for "torpedo room fore".

Thought you might want to know that, before you start prophesying to everyone that TRF is the aft torpedo room.

Madox58

10-20-13, 03:26 PM

OK. Back to the redundant verts in the GR2 files...........
If you look at the way the verts are coded into the GR2 files you see 2 texture channels.
1 is the main texture the other the AO.
Now both have the same number of verts but different number of texture coords.
They must all go in the same place so a way to match numbers is used.
By adding redundant verts those numbers are made to match.

I'd suspect the granny engine can decide which are just placer verts and discards them on the fly.

On exporting the meshes from the GR2 we see a file size that gets reduced if we use many of the 3D programs to import then export with no changes.
the reason is most programs optimize the obj and dump those extra placer verts.
Some 3D programs even warn that there are extra verts on import.
And then proceed to dump them.

Do you follow me so far?

periunder

10-20-13, 03:29 PM

Madox58

10-20-13, 03:29 PM

A little heads up for you in the future: "TRF" stands for "torpedo room fore".

Thought you might want to know that, before you start prophesying to everyone that TRF is the aft torpedo room.
I didn't prophesize anything. I simply misread the posts.
Fix your own problem then as I'll not offer you help any longer.
:hmph:

Good luck as I can tell you'll need a boat load of it!
:har:

periunder

10-20-13, 03:32 PM

I didn't prophesize anything. I simply misread the posts.
Fix your own problem then as I'll not offer you help any longer.
:hmph:

Good luck as I can tell you'll need a boat load of it!
:har:

At least I can tell the difference between common sh5 files.

It looks like you'll need a submarine of your own, because it seems your in over your head.
:haha::haha::haha::haha:
:rotfl2::rotfl2::rotfl2::rotfl2::rotfl2::rotfl2:
:har::har::har::har::har::har::har:

gap

10-20-13, 03:34 PM

Do you follow me so far?

Thank you privateer, your explanations make perfect sense now. Is there an easy way for matching again diffuse and AO texture coordinates?

Madox58

10-20-13, 05:17 PM

At least I can tell the difference between common sh5 files.

It looks like you'll need a submarine of your own, because it seems your in over your head.
:haha::haha::haha::haha:
:rotfl2::rotfl2::rotfl2::rotfl2::rotfl2::rotfl2:
:har::har::har::har::har::har::har:

I can export and import to SH3 and SH4 which is more then you can do Mate.
So who is in over who's head here?
:har:

Madox58

10-20-13, 05:23 PM

Thank you privateer, your explanations make perfect sense now. Is there an easy way for matching again diffuse and AO texture coordinates?

There is several ways to do so by hand with a few different programs, yes.
Then I get people like the above that make me want to say screw it all, you're on your own.

I can trust many here but will offer no help to the above types.
:shifty:

I offered help, made a mistake in my reading, admited mistake and again was attacked.
Guess it's time to walk away again.

Madox58

10-20-13, 05:42 PM

Yes. Are the extra verticals a problem with exporting into s3d?

Only answer I have for you is, you figure that out.
I know the answer but I'm not in the mood to give it to you Richard.
Then when I look at your responces? I see you may be someone that has used multi accounts in the past.
I'm reporting you for investigation Mate.

Have a nice day.

gap

10-20-13, 06:15 PM

There is several ways to do so by hand with a few different programs, yes.
Then I get people like the above that make me want to say screw it all, you're on your own.

I can trust many here but will offer no help to the above types.
:shifty:

I offered help, made a mistake in my reading, admited mistake and again was attacked.
Guess it's time to walk away again.

:-?

Madox58

10-20-13, 06:23 PM

gap

10-20-13, 06:28 PM

No gap.
I ain't going away that easily.
:D

I do get frustrated at times but I never actually quit.
Besides.
I have an autographed gift from the SH devs waiting for me at home!!!
Sent all the way from Romania!!!
:o
:rock:

:hmmm:
I just hope they didn't put Dracula in there in a secret bid to smuggle him over to the U.S.A.
:har:

:haha:

Okay mate,

let's keep on this discussion in private form if you prefer. I am really eager to add some new goodies to the SH5 campaign... provided that Trevally is still interested into them (I know I must have pissed him off lately :D)

periunder

10-20-13, 06:39 PM

I can export and import to SH3 and SH4 which is more then you can do Mate.
So who is in over who's head here?
:har:

Only answer I have for you is, you figure that out.
I know the answer but I'm not in the mood to give it to you Richard.
Then when I look at your responces? I see you may be someone that has used multi accounts in the past.
I'm reporting you for investigation Mate.

Have a nice day.

What's that?

I couldn't hear you, over the sound of your conceitedness.
:haha::haha::haha::haha::haha::haha::haha::haha::h aha::haha:

periunder

10-20-13, 06:40 PM

No gap.
I ain't going away that easily.
:D

I do get frustrated at times but I never actually quit.

Oh, goodie! Make yourself useful for once.

:har::har::har::har:
:haha::haha::haha::haha::haha:
:rotfl2::rotfl2::rotfl2::rotfl2::rotfl2::rotfl2::r otfl2:

Frustrated anyone?
:k_rofl:

Madox58

10-20-13, 07:25 PM

OK Richard.
Have all the fun you want till you go Bye Bye.
:salute:

You still don't know crap and no one is gonna teach you.

periunder

10-20-13, 07:32 PM

OK Richard.
Have all the fun you want till you go Bye Bye.
:salute:

You still don't know crap and no one is gonna teach you.

Hey Peter the Privateer,

How much are you donating to Subsim so you can troll these forums?
If what you make from your job is any indication, it aint much!

:har::har::har::har:

gap

10-20-13, 08:30 PM

Your recent comments are uncalled for, periunder. Let's not spoil this thred :nope:

Madox58

10-20-13, 08:31 PM

You are so droll.
I'm sure most welcome you wasting time and posts in this thread.
Why not PM me direct with your hate?
Or does that idea scare your pimpled behind?
I'll bet a months wages you don't do it as your just a troll wannabe.
:woot:

What I earn has no bearing on what I donate to Subsim.
What I donate has no bearing on what I can get away with here at Subsim.
I may be the top warning earner here based on my infractions but there's no way I can find that info.
I have been keelhauled but earned my way back into good graces.
That's not something I'm proud of but I stand up and admit my mistakes and try my best to make up for them.

You want to attack me in any way or form? Go for it.
You seem to think you have a power that detracts from goals set by others?
You are sadly mistaken. They have a goal and I help when I can.
I also enjoy laying bait to see you bite cause your a little fishy.

periunder

10-20-13, 08:42 PM

You sure spend alot of time on here for someone you claims to have a job.

:hmmm:

You know, its people like you who exhaust our unemployment benefits while not looking for work, that is taking this country down the crapper.

:har::har::har::har::har::har:

Madox58

10-20-13, 08:51 PM

I don't live in Idiot Land.
How can I exhaust your cookies?
:hmmm:

periunder

10-20-13, 09:05 PM

I don't live in Idiot Land.

That's a lie. :up:

Sailor Steve

10-20-13, 09:07 PM

Okay, this just got childish as well as out of hand. We've been here before, this crap is over, and the next one who continues it will end up taking a time out.

Thank you.

Madox58

10-20-13, 09:10 PM

Still waiing for the PM from you Mate.
:D
(Put me in time out if you see the need Steve)

periunder

10-20-13, 09:17 PM

Well just let him continue his troll run.

Back to topic:

How are standard and AO meshes extract from GR2 and into s3d?

Madox58

10-20-13, 09:24 PM

Mate. If you wish to talk technical? I will do all I can to assist you.
No hard feelings and all that. If you don't want my help? Just say so and I will bow out.

periunder

10-20-13, 09:32 PM

If you don't want my help? Just say so and I will bow out.

After the shamefur dispray today, I don't want your help. Please blow out.

Sailor Steve

10-20-13, 09:35 PM

Okay. Olive branch was offered and rejected. That says something all by itself. Let it end here.

periunder

10-20-13, 09:39 PM

That says something all by itself.

Are you suggesting I should forget everything that just happened?
:hmmm:
I don't think so.

gap

10-20-13, 09:47 PM

Are you suggesting I should forget everything that just happened?
:hmmm:
I don't think so.

self-respect is important, but you have just refused the assistance of the one person who could have helped you, and you did it for futile reasons (honestly: seen from outside your quarrel looks rather naive). Now you better stop putting your questions here: most probably no one else will be able to answer them :yep:

periunder

10-20-13, 09:56 PM

Now you better stop putting your questions here: most probably no one else will be able to answer them :yep:

Thanks gap for the info. But I've already put my questions here, and that's that. If no one answers them, then no one answers them.

Sailor Steve

10-20-13, 09:59 PM

Are you suggesting I should forget everything that just happened?
:hmmm:
I don't think so.
Yes. People do it all the time. I do it all the time. It's called "making peace".

gap

10-20-13, 10:03 PM

Yes. People do it all the time. I do it all the time. It's called "making peace".

...and if even our harshest moderator can do it, why not you? :O:
(I think I am risking the ban myself here :roll:)

Madox58

10-20-13, 10:05 PM

Let it go Mates.
I should not have let this run as it did by reacting as I did.
I stand at fault so let's just let it go.

And Steve is not the harshest moderator by the way.
Wait a minute! I have 2 infractions from him!
:hmmm:
Steve is the harshest moderator!
All hail Steve!
:har:

Sailor Steve

10-20-13, 10:20 PM

(I think I am risking the ban myself here :roll:)
For calling me harsh? Not a chance! I might sit in a corner and cry for awhile, but I always say "If the shoe fits, go barefoot!" :O:

periunder

10-20-13, 11:34 PM

The version I'm using is 1.1.272.1

This isn't the latest version. Is there a download link to the latest version?

Madox58

10-20-13, 11:43 PM

Please blow out
:roll:

Targor Avelany

10-21-13, 09:15 AM

:doh:

Maybe it's my ESL that is acting up, but wtf did I just read for the past 2 pages???

Eh, and that is why a lot of knowledge goes into convoes :(

Madox58

10-22-13, 02:20 PM

I'm sorry that went on as it did.
Mostly for my part in keeping the whole thing going on and on.
I have asked for a different infraction thing though.
I think I may be placed in to protective custody at a later date.
:haha:

CaliEs

10-22-13, 04:17 PM

I am really eager to add some new goodies to the SH5 campaign... provided that Trevally is still interested into them
what could this be?

gap

10-22-13, 05:18 PM

what could this be?

At the moment, this (model by Trevally and me):

http://www.subsim.com/radioroom/showpost.php?p=2109415&postcount=3732

...and this (model by JU_88): ;)

http://www.subsim.com/radioroom/showpost.php?p=2070643&postcount=33

Anvart

01-21-14, 03:09 AM

... current version v1.1.374.1: removed due to major problem in allocating vertices code ...
http://imageshack.com/a/img186/6565/prayan7.gif
Obviously, the theme became lifeless... suddenly.

TheDarkWraith

01-22-14, 01:53 PM

http://imageshack.com/a/img186/6565/prayan7.gif
Obviously, the theme became lifeless... suddenly.

That thing called work gets in the way all the time! :shifty:

While I've been abroad I've worked a little on the app. v1.1.395.1 is available at post #1.

Here are the current changes/additions for this version:
corrected problem of creating new bones (new bone was being deleted right after it was created!).
corrected problem of new bone not having corrected transform (was not being rendered in correct position at times due to not having correct model-world transform).
corrected problem of new bone not having all it's data set correctly (flags, position, rotation, etc. were not being passed onto base class).
corrected problem with renaming embedded strings ('fillers' were not being updated correctly).
corrected problem with deleting bones ('fillers' were not being updated correctly).
corrected problem of missing essential strings window being shown at file load when all required essential strings were found in file.
changed how renaming of embedded strings works. Now when you rename an embedded string and there are items (bones, meshes, skeletons, etc.) that have the same embedded string then all those other items will be updated with the new embedded string.
changed syntax for Sentinel command getchainforsection. Added an optional True that when specified will save the dump to a file also (you can only specify folder location for file). To view the Sentinel command window (if not already visible) press F1. Type h or help to see list of possible commands.
added two new Sentinel commands: doessectioncontainfillers and getsectionswithfillers. These commands should be used when the app tells you the file has errors or broken chains to see where the problems are (you should also use the getchainforsection command with optional True specified for each section reported back with fillers/errors to dump the section to a file for review).
added a new menu entry to File: Verify. Clicking Verify will verify the currently selected GR2 file in use for errors. The errors currently being checked are: broken chains and for 'fillers'. It will display a dialog box denoting all the errors found. This can be done at any time to verify the file after making changes.
added a new menu entry to Edit-->Options-->File: Verify after loading file. If this is checked then when any file is opened it will automatically be verified for errors.

It's been so long since I have worked on this that I've forgotten the reason why I took the link down before (I don't remember what it was in the code that was the problem).

Report all problems and I'll work them out as I have time. I'm doing much travel abroad for work this year so my time is limited.

Make use of the new File-->Verify. After you make a change click File-->Verify to see if there are any problems. If there is then I need to know EXACTLY what you did to cause the error. You can't give me too much information for the exactly part either. The more the better.

gap

01-22-14, 02:23 PM

Thank you Sir :yeah:

:salute:

tonschk

01-22-14, 02:57 PM

This is important, Thank you a Lot :salute::up: TheDarkWraith :yeah::D:up:

Mikemike47

01-22-14, 03:31 PM

TDW is back. :salute::woot:

@TDW, your mailbox is full.

TheDarkWraith

01-22-14, 04:35 PM

v1.1.397.1 available at post #1

Things are slowly coming back to me as to what the problem was before when I took the link down.

This new version fixes problems with deleting materials, textures, and bones. It all has to do with those darn 'fillers' and alignment :shifty:

When I changed the app to work with other GR2s other than SH5's I opened up a HUGE can-of-worms. Slowly putting the lid on it now...

I need you all to try and break the app. I don't have much time at home before I'm shipped off again.

Looking into deleting/adding mesh subsets now. This seems to be where the problem was before when I took the link down...

Mailbox will probably be full for awhile. I don't have time to go through it. If you want to discuss something then post it here and when I have time I'll respond.

TheDarkWraith

01-22-14, 05:28 PM

v1.1.398.1 released. See post #1

Opened up the NLL and clicked File-->Verify. Told me I had errors. This file was unmodified (stock) so I knew I forgot to add something to the verify function.

In certain sections in the GR2 file 'filler' is required to meet the alignment requirements of the section. Everything has to be aligned on the alignment boundary specified by the section. If it's not then there will be problems. Now the verify function will look at the 'fillers' returned (if any) for the sections and see if they are valid or not. If they are all valid and ok then it will tell you they are needed and they are all ok. If there is an error in one of them then it will say error.

The main thing you should watch for in the Verify function is whether it says file is possibly corrupt. If that says Yes then it's more than likely fubar.

TheDarkWraith

01-22-14, 06:47 PM

v1.1.400.1 released. See post #1

This version deals with material bindings. I have changed how you can delete material bindings. If you try to delete a material binding that is bound to a subset you will get an error.

What this does is ensure you can't delete a material binding that's bound to a subset. You have to first give the subset another material binding before you can delete the old one (which means you may have to add more material bindings to the mesh first). This prevents the error of deleting a material binding for a subset and forgetting to set another one for it (Goblin does not like it when you do that!)

TheDarkWraith

01-22-14, 08:11 PM

What I would like is a compilation of problems/bugs/errors that need to be fixed/looked into. I briefly looked over past posts for the time I've been gone and I see people have been able to use the app for making new GR2s. That makes me happy :D What doesn't make me happy is that I also saw that they were having to use many different versions of the app to make those things :shifty: Let's fix this so only one version, the current version, is all that has to be used.

I can't guarantee that I'll be able to fix everything in a short timeframe. I will though work on it as I have time.

With the current version, 1.1.400.1, I've played with mostly everything dealing with textures, materials, bones, and material bindings for meshes. I think I've got the majority of the errors that I remember from ago fixed. I'll be looking into the meshes and items related to meshes from now until I leave for Mexico.

Get me a list so I can work them out :up:

Madox58

01-22-14, 08:18 PM

TheDarkWraith

01-22-14, 08:27 PM

I'd suggest adjusting the way you read the obj files.
I did a simple sorter that allows obj files to be pre-sorted to work with your program.
Also, don't worry about people bit-ching about being away from modding and such.
Real life is takeing it's toll on me also.

Tell me what's wrong with the way I do it. How does the sorter make it 'compatible' with the way I do it? If you can give me files and procedures to follow to expose the problem that would be great.

Being away from modding sucks, I love writing code and making new things. Life and my career always come first though and those are priority. Thank god I'm single too :D

Madox58

01-22-14, 08:32 PM

Tell me what's wrong with the way I do it. How does the sorter make it 'compatible' with the way I do it? If you can give me files and procedures to follow to expose the problem that would be great.

Being away from modding sucks, I love writing code and making new things. Life and my career always come first though and those are priority. Thank god I'm single too :D

I'll get the files to you ASAP. Like you? I travel for my liveing also and am currently in Wilkes-Barre, PA destroying a perfectly good store.
:haha:

It's just the way your reading an obj file for import.
I'd suspect a few lines of code to adjust for universal import from any type obj.

gap

01-22-14, 08:36 PM

What I would like is a compilation of problems/bugs/errors that need to be fixed/looked into.

I'd suggest adjusting the way you read the obj files.

I agree. I didn't get time today for testing the latest versions of GR2 Editor. Will do it tomorrow. Anyway the main limitations of 1.1.374.1 (besides the ones already addressed with v1.1.395.1 and later versions) are:

unabality to clone bones;

unability to import smoothing groups in obj files exported from any 3d application but 3ds max;

after importing, UV coordinates of obj files exported from any 3d application but 3ds max are corrupt (no matter import settings set in GR2 Editor).

I am using Wings 3d as main tool, but objects exported from S3d or Blender show the same problem.

If you need it, I can give you a link to one of my models, for you to look into it. :salute:

Real life is takeing it's toll on me also.

:yep:

TheDarkWraith

01-22-14, 08:48 PM

I agree. I didn't get time today for testing the latest versions of GR2 Editor. Will do it tomorrow. Anyway the main limitations of 1.1.374.1 (besides the ones already addressed with v1.1.395.1 and later versions) are:

unabality to clone bones;
unability to import smoothing groups in obj files exported from any 3d application but 3ds max;
after importing, UV coordinates of obj files exported from any 3d application but 3ds max are corrupt (no matter import settings set in GR2 Editor).

I am using Wings 3d as main tool, but objects exported from S3d or Blender show the same problem.

If you need it, I can give you a link to one of my models, for you to look into it. :salute:

Cloning bones is a problem? Really? Try v1.1.400.1 because there were a lot of problems with the 'fillers' in previous versions. I could add and delete bones without a problem with v1.1.400.1 using my new convention to work with GR2 files other than SH5s. What were the problems when cloning bones? I'll try cloning some bones tonight. Can you give me names of files and bones tried to clone in those files that caused errors?

As far as the importing and smoothing groups you'll need to give me files and detailed directions as to what you did so that I can view the problems myself in the debugger. This beast is getting very complicated now :dead:

I'm not well versed in smoothing groups so that's probably one of the reasons for the errors. If I don't know about it or what it is/does I can't code it. Why the 3DS max smoothing groups work? I must've got lucky :D

gap

01-22-14, 08:54 PM

This is what I and Privateer are talking about:

https://imagizer.imageshack.us/v2/571x364q90/541/3hi8.jpg

http://www.subsim.com/radioroom/showpost.php?p=2112247&postcount=3770

...and here is one of the last version of the barrage balloon recently added to OHII (after import/export in max):

http://www.mediafire.com/download/v9cjtqbx7zh2sn2/barrage_balloon_final_parts.rar

P.S: I will post later a mesh containing smoothing groups

Madox58

01-22-14, 09:00 PM

after importing, UV coordinates of obj files exported from any 3d application but 3ds max are corrupt (no matter import settings set in GR2 Editor).

I am using Wings 3d as main tool, but objects exported from S3d or Blender show the same problem.

If you need it, I can give you a link to one of my models, for you to look into it. :salute:

:yep:

The corrupted UV's seem to be from the way 3D Models are mapped in some programs and then when imported, some numbers are not matched so information is lost resulting in the corrupt UV's.

I know (after hours spent in a hex editor, our favorite tool) what is going on.

GR2's, when exported from a program add a fake kind of insert to make sure numbers match to allow full imports.
Some times it's zeroed, some times it's a repeat of already used info.

Smooth groups seem to have no effect as far as I have been able to detect.
Most 3D models I've been sent only have one smooth group anyway?

I also base that on the original files sent to me by the Dev's that have only one smooth group.

gap

01-22-14, 09:12 PM

Cloning bones is a problem? Really? Try v1.1.400.1 because there were a lot of problems with the 'fillers' in previous versions. I could add and delete bones without a problem with v1.1.400.1 using my new convention to work with GR2 files other than SH5s. What were the problems when cloning bones? I'll try cloning some bones tonight. Can you give me names of files and bones tried to clone in those files that caused errors?

No need for it: using v1.1.400.1 with the stock stuka model I was finally able to clone one of her bones (Junkers_Ju-87B_Stuka_wing_R, for the record). Tried again with v1.1.374.1 and it failed, as expected :up:

As far as the importing and smoothing groups you'll need to give me files and detailed directions as to what you did so that I can view the problems myself in the debugger.

Okay, I am packing a simple model for you to check what I am talking about

Smooth groups seem to have no effect as far as I have been able to detect.
Most 3D models I've been sent only have one smooth group anyway?

If you mean 3d models by me, the reason is that, being aware that GR2 Editor can't import them, I had replaced hard edges with bevelled edges :03:

TheDarkWraith

01-22-14, 09:18 PM

...and here is one of the last version of the barrage balloon recently added to OHII (after import/export in max):

http://www.mediafire.com/download/v9cjtqbx7zh2sn2/barrage_balloon_final_parts.rar

What were you importing this barrage balloon into? Tell me the file(s) and what you were doing (what kind of import, etc.)

No need for it: using v1.1.400.1 with the stock stuka model I was finally able to clone one of her bones (Junkers_Ju-87B_Stuka_wing_R, for the record). Tried again with v1.1.374.1 and it failed, as expected :up:

Good, if the bones are working correctly that means I should be able to fix the meshes problems also since it will use the same fix.

Ensure to use that File-->Verify after making a change. That way when you do something and it fails because there are errors you can tell me what you did and when you did it so I can try and reproduce it.

Madox58

01-22-14, 09:19 PM

If you mean 3d models by me, the reason is that, being aware that GR2 Editor can't import them, I had replaced hard edges with bevelled edges :03:
Your not the only one that sends me 3D models.
:yep:

I've sent 3D models to a few of the original Dev's with more then one smooth group and had the GR2 version sent back and see nothing strange.
:hmm2:

A model with one smooth group really has no smooth groups and can be ignored.

gap

01-22-14, 09:29 PM

What were you importing this barrage balloon into? Tell me the file(s) and what you were doing (what kind of import, etc.)

If memory serves me well, I had tried inporting it in two native GR2's: costal_guns_small.GR2, and one of the icebergs. Loose import. All my import attempts failed -i.e. corrupt UV mapping-, no matter import settings used (options used more commonly: all checked but "import AO coordinates", and when prompted if I wanted to retain existing AO data, I normally answered no but, again, I really tried a lot of other combinations not to avail).

Good, if the bones are working correctly that means I should be able to fix the meshes problems also since it will use the same fix.

Yep, the feature definitely works again with latest version of your program :up:

Ensure to use that File-->Verify after making a change. That way when you do something and it fails because there are errors you can tell me what you did and when you did it so I can try and reproduce it.

Will do that :salute:

gap

01-22-14, 09:45 PM

another weirdness that should be addressed:

http://www.subsim.com/radioroom/showpost.php?p=2134006&postcount=149
http://www.subsim.com/radioroom/showpost.php?p=2134055&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

01-22-14, 10:03 PM

Where are the TGAs/DDSs for the barrage balloon?

gap

01-22-14, 10:05 PM

A model with one smooth group really has no smooth groups and can be ignored.

That is sure. Please see below.

I've sent 3D models to a few of the original Dev's with more then one smooth group and had the GR2 version sent back and see nothing strange.
:hmm2:

Well, it must be a problem with the way Wings writes smoothng groups then, because every time I tried importing an object with GR2 Editor, the program threw an error message even before actually starting the import.

An example? Try importing this object using last GR2E version:

https://www.mediafire.com/?71d3v1du34su3bm

I am importing it in the stuka stock GR2 (loose import, every option checked but 'AO map').

I get this message:

***** the number of vertices defined in (path)\llighthouse for TDW.obj(558) does not match the number of vertices in the mesh (2378) *****

If I set all the edges to smooth before exporting (in wings3d), or if I remove manually all the smoothing groups from the file, the export works flawlessy (except for the usual UV corruption).

In both cases File-->Verify doesn't show any error.

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

gap

01-22-14, 10:08 PM

Where are the TGAs/DDSs for the barrage balloon?

ops... sorry, I forgot about textures. You can get them from here (http://www.mediafire.com/download/072kg5r9bn6tq1e/OPEN%20HORIZONS%20II%20-%20Barrage%20Balloons%20-%20cables%2C%20skins%20%26%20materials%20update.ra r)

TheDarkWraith

01-23-14, 01:37 AM

ops... sorry, I forgot about textures. You can get them from here (http://www.mediafire.com/download/072kg5r9bn6tq1e/OPEN%20HORIZONS%20II%20-%20Barrage%20Balloons%20-%20cables%2C%20skins%20%26%20materials%20update.ra r)

Ok I finally got to the bottom of the problem with the barrage balloon and importing. I found a few very minor errors in the importer but that wouldn't cause the rendering problem.

Granny is a little inefficient (if you want to call it this) in the way it treats vertices. If you export any mesh from any of the SH5 GR2s you'll notice that it has a LOT of vertices defined. Why you may ask? Every vertice in Granny has it's own texture coordinate and might also have a normal defined. If a vertice has the same position data but different texture data then Granny needs another vertice for it.

Your barrage balloon has been optimized in it's vertices. By optimized I mean if two vertices were found to have the same positional data then the 'duplicate' was discarded. This is not good for Granny!

I had the importer track all the indices defined and if a duplicate indice was found then it checked to see if the texture coordinates were different for the two. What I found was what I thought: the indices are defining two vertices (it's actually the same index in the vertices) that have the same positional data but different texture data. My importer is then overwriting the vertices existing texture data (which was previously defined) with new texture data. This makes it appear that texture data is all hosed up.

How to fix? What I have to do is when a duplicate vertice is found (face definition defines a vertex index that has already been used) I have to clone it.

gap

01-23-14, 08:08 AM

Granny is a little inefficient (if you want to call it this) in the way it treats vertices. If you export any mesh from any of the SH5 GR2s you'll notice that it has a LOT of vertices defined. Why you may ask? Every vertice in Granny has it's own texture coordinate and might also have a normal defined. If a vertice has the same position data but different texture data then Granny needs another vertice for it.

Your barrage balloon has been optimized in it's vertices. By optimized I mean if two vertices were found to have the same positional data then the 'duplicate' was discarded. This is not good for Granny!

I had the importer track all the indices defined and if a duplicate indice was found then it checked to see if the texture coordinates were different for the two. What I found was what I thought: the indices are defining two vertices (it's actually the same index in the vertices) that have the same positional data but different texture data. My importer is then overwriting the vertices existing texture data (which was previously defined) with new texture data. This makes it appear that texture data is all hosed up.

How to fix? What I have to do is when a duplicate vertice is found (face definition defines a vertex index that has already been used) I have to clone it.

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? :hmm2:

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

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

TheDarkWraith

01-23-14, 08:38 AM

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? :hmm2:

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

01-23-14, 09:05 AM

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. :yep:

TheDarkWraith

01-23-14, 09:12 AM

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 :yep:

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

01-23-14, 09:25 AM

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 :yep:

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 :up:

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. :yep:

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.

:yeah:

TheDarkWraith

01-23-14, 04:34 PM

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 :up:

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. :yep:
:yeah:

Like I said earlier, if I clone vertices that are duplicated in the OBJ file the results speak for themselves:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7280

This was your Wings3D OBJ barrage balloon imported into Iceberg01
:D

TheDarkWraith

01-23-14, 05:10 PM

gap

01-23-14, 05:29 PM

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 :yeah: :woot:

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)? :D

another weirdness that should be addressed:

http://www.subsim.com/radioroom/showpost.php?p=2134006&postcount=149
http://www.subsim.com/radioroom/showpost.php?p=2134055&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

01-23-14, 05:36 PM

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

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)? :D

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

01-23-14, 05:49 PM

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.

:up:

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. :salute:

P.S: have you seen this last suggestion? ;)

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

01-23-14, 05:50 PM

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 :shifty:

gap

01-23-14, 05:53 PM

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

Most useful :up:

TheDarkWraith

01-23-14, 05:57 PM

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. :salute:

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

01-23-14, 06:08 PM

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.

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/5zxbgy8wd3575su/gap%20-%20Small%20generic%20port%20fix%20%2B%20better%20c rate%20textures.rar

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

http://i1231.photobucket.com/albums/ee503/rongel777/SH5Img2013-10-19_211407.jpg

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 :salute:

TheDarkWraith

01-23-14, 06:14 PM

gap

01-23-14, 06:17 PM

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 :hmmm:

No, I'd never noticed this feature :doh: :oops:

gap

01-23-14, 06:30 PM

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 :salute:

Found them!

https://www.mediafire.com/?mqhk320zi0qw0cd

TheDarkWraith

01-23-14, 06:47 PM

This is the GR2 file with the broken material:

http://www.mediafire.com/download/5zxbgy8wd3575su/gap%20-%20Small%20generic%20port%20fix%20%2B%20better%20c rate%20textures.rar

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

Here's what it looks like rendered in the app with lighting enabled. Ambient light was disabled. I defined 3 lights: a directional (sun), a lightbulb (point), and a searchlight (Spotlight). All were positioned around the boxes.
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7281

You can see that they are washed out so there is a problem with the normals it appears or the specular value of the material is way too high. Could be other parameters of the material that are way too high also.

So there you have it: lighting in the app. You can create some cool scenes using the lighting :D

I found a small problem with the lighting also that I fixed (dealt with when you updated a light). Thus new version coming here very soon.

This also reminds me of something I wanted to add to the lights: a way to 'see' where they are visually in 3D space (along with option to show their defined name). I will add that now.

gap

01-23-14, 07:07 PM

Here's what it looks like rendered in the app with lighting enabled. Ambient light was disabled. I defined 3 lights: a directional (sun), a lightbulb (point), and a searchlight (Spotlight). All were positioned around the boxes.]

Cool! I wonder how I had missed this useful feature before :D

You can see that they are washed out so there is a problem with the normals...

No, normals are okay. How do I know it?

- Wings3d displays the crates correctly.
- If you look closely at the picture at post #2143, the small crates (which I didn't edit) are also washed out, and they use the same material as the big boxes.
- After replacing the corrupt material with a new one, small and big crates looked normal again:

https://imagizer.imageshack.us/v2/821x148q90/191/hwpg.jpg

it appears or the specular value of the material is way too high. Could be other parameters of the material that are way too high also.

Again, no:

- Before noticing the corruption, I didn't mess with material properties in that file;
- After noticing the corruption, I checked that material properties weren't altered somehow, but the tweaked and a clean copy of the same file had exactly the same settings :yep:

I found a small problem with the lighting also that I fixed (dealt with when you updated a light). Thus new version coming here very soon.

This also reminds me of something I wanted to add to the lights: a way to 'see' where they are visually in 3D space (along with option to show their defined name). I will add that now.

Good!

TheDarkWraith

01-23-14, 07:18 PM

v1.1.404.1 released. See post #1
This version just fixes a problem with lighting that I noticed a few posts back

TheDarkWraith

01-23-14, 07:27 PM

TheDarkWraith

01-23-14, 07:33 PM

Found them!

https://www.mediafire.com/?mqhk320zi0qw0cd

I see why your objects 'washed out'. It has to do with your MTL file for the Object13:

# Exported from Wings 3D 1.4.1
newmtl default
Ns 100.0
d 1.0
illum 2
Kd 0.8333333333333334 0.7428571428571428 0.6444444444444445
Ka 0.8333333333333334 0.7428571428571428 0.6444444444444445
Ks 1.0 1.0 1.0
Ke 0.0 0.0 0.0

newmtl harbor_ital_cont2_subset0
Ns 100.0
d 1.0
illum 2
Kd 0.588 0.588 0.588
Ka 0.588 0.588 0.588
Ks 0.9 0.9 0.9
Ke 0.0 0.0 0.0
map_Ka harbor_ital_cont2.Tga
map_Kd harbor_ital_cont2.Tga

Since that mesh only had 1 subset the app used the first newmtl definition it found as the material properties for the mesh when it updated the materials. You have to be careful with Wings3D and materials. That 'default' material will always screw things up!

Once I finish adding the checkbox and code for whether you want the materials updated or not to the import window it will help alleviate this problem of happening when you only want the vertex data updated.

gap

01-23-14, 07:46 PM

You know what I need to add to the import window? Whether you want the materials to be updated or not. Currently the importers always update the materials no matter what. If you only want to change the vertex data and nothing else then there's no reason to update the materials. I'll make that change :up:

I see why your objects 'washed out'. It has to do with your MTL file for the Object13:

...

Since that mesh only had 1 subset the app used the first newmtl definition it found as the material properties for the mesh when it updated the materials. You have to be careful with Wings3D and materials. That 'default' material will always screw things up!

Once I finish adding the checkbox and code for whether you want the materials updated or not to the import window it will help alleviate this problem of happening when you only want the vertex data updated.

Do you mean that your application reads material properties (i.e. Ka, Kd, Ks, d, Ns, illum, etc) directly from mtl files? So far, when needed, I had to set those properties manually. In other words, diffuse, ambient, reflection, etc. properties of the vanilla materials weren't updted apparently. The one thing which was updated automatically, was the number of subset. What did I miss? :hmmm:

TheDarkWraith

01-23-14, 07:53 PM

Do you mean that your application reads material properties (i.e. Ka, Kd, Ks, d, Ns, illum, etc) directly from mtl files? So far, when needed, I had to set those properties manually. In other words, diffuse, ambient, reflection, etc. properties of the vanilla materials weren't updted apparently. The one thing which was updated automatically, was the number of subset. What did I miss? :hmmm:

Try a version of the app > 400. I saw the same thing in versions < 400. In some version < 400 I screwed it up somehow and I don't know which version the screw up started. It should be working correctly now. Let me know if it's not.

gap

01-23-14, 07:53 PM

Since that mesh only had 1 subset the app used the first newmtl definition it found as the material properties for the mesh when it updated the materials.

...and now that I think about it: why did GR2E used the default material, when the one subset had harbor_ital_cont2_subset0 assigned as its material :doh:

TheDarkWraith

01-23-14, 07:56 PM

...and now that I think about it: why did GR2E used the default material, when the one subset had harbor_ital_cont2_subset0 assigned as its material :doh:

That's the way I coded it. When reading the MTL file the newmtl definitions correspond 1:1 to the subsets. If you have more newmtl definitions then subsets then only the first number of subsets newmtl definitions will be used.

gap

01-23-14, 07:56 PM

Try a version of the app > 400. I saw the same thing in versions < 400. In some version < 400 I screwed it up somehow and I don't know which version the screw up started. It should be working correctly now. Let me know if it's not.

Well, until yesterday we had v 1.1.374.1 or lower. I am now testing the latest version. I will inform you whether the feature finally works as supposed or not :up:

gap

01-23-14, 08:01 PM

That's the way I coded it. When reading the MTL file the newmtl definitions correspond 1:1 to the subsets. If you have more newmtl definitions then subsets then only the first number of subsets newmtl definitions will be used.

Okay. In other words, I must always remove manually the 'default' material (from within Wings 3d it is not possible to do it). This would be a minor disturbance :up: but (for the sake of programming cleanness)...

...how hard would be making your application to check actual subset/material linkings instead? :hmm2:

gap

01-23-14, 08:36 PM

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.

Pressing Ctrl in the status tab unselects the text. Right click => Copy did the job though :up:

Try a version of the app > 400. I saw the same thing in versions < 400. In some version < 400 I screwed it up somehow and I don't know which version the screw up started. It should be working correctly now. Let me know if it's not.

Well, just tested the feature with version v_1_1_404_1. Either material properties aren't updated (neither visual nor numeric setting changes), or I am doing something wrong. :hmmm:

Regarding subsets, have you ever seen this post of mine (http://www.subsim.com/radioroom/showpost.php?p=2104858&postcount=2012). I might have found and exception to the "max two (textured) materials per mesh"...

TheDarkWraith

01-23-14, 08:50 PM

Okay. In other words, I must always remove manually the 'default' material (from within Wings 3d it is not possible to do it). This would be a minor disturbance :up: but (for the sake of programming cleanness)...

...how hard would be making your application to check actual subset/material linkings instead? :hmm2:

Fairly complicated. Not something I'm interested in tackling currently. Maybe in the future.

The first thing I do when I work in Wings3D is delete the default material or rename it to the name I need.

Well, just tested the feature with version v_1_1_404_1. Either material properties aren't updated (neither visual nor numeric setting changes), or I am doing something wrong. :hmmm:

Regarding subsets, have you ever seen this post of mine (http://www.subsim.com/radioroom/showpost.php?p=2104858&postcount=2012). I might have found and exception to the "max two (textured) materials per mesh"...

I'll look into the material properties and why they aren't updating tomorrow :up:

I'll check out the exception also tomorrow. I impose no limit as to the number of materials you can define for the mesh. Define away!

v1.1.405.1 released. See post #1
This version adds tooltips to the items in the import/export window and also adds a new checkbox to that window that deals with materials. When importing and the new checkbox is checked then the importer will read the MTL file and update all the mesh's materials. When exporting if the new checkbox is checked then the exporter will write a MTL file and everything else needed for the materials.

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7282

Movie time :D Work will continue tomorrow...

gap

01-23-14, 09:25 PM

Fairly complicated. Not something I'm interested in tackling currently. Maybe in the future.

The first thing I do when I work in Wings3D is delete the default material or rename it to the name I need.

That's just the least problem :up:

I'll look into the material properties and why they aren't updating tomorrow :up:

Okay, I will be online an ready to test any new version. :salute:

On a side note: dunno if it is just a side effect of other fixes or something you made on purpose, but I am pleased to tell you that a bug where inporting a new mesh in costal_guns_small.GR2 messed up its UV map (no matter program used for exporting the new meshes or import settings), is now fixed :sunny:

I'll check out the exception also tomorrow. I impose no limit as to the number of materials you can define for the mesh. Define away!

Who knows, maybe there is something new to learn from those files :hmm2:

v1.1.405.1 released. See post #1
This version adds tooltips to the items in the import/export window and also adds a new checkbox to that window that deals with materials. When importing and the new checkbox is checked then the importer will read the MTL file and update all the mesh's materials. When exporting if the new checkbox is checked then the exporter will write a MTL file and everything else needed for the materials.

I will test this new version tomorrow.

Movie time :D Work will continue tomorrow...

Fair enough: it has been a productive day :)

TheDarkWraith

01-23-14, 09:41 PM

TheDarkWraith

01-24-14, 02:23 AM

v1.1.408.1 released. See post #1

Fixed problem where materials that have been modified not showing (Modified) in the materials tab
Fixed problem of mesh's materials not being updated if the update materials checkbox is checked on an import
The import/export window will now hide after pressing the Import/Export button
Changed how the updating of mesh's materials works during an import with the update materials checkbox checked: importer will try and match up the objects defined and it's usemtl definition to the subsets (now that default material that's always defined in Wings3D MTL files is not an issue). If the importer matches up all that it can and there are some subsets that still don't have materials updated then it will default to using the remaining materials defined to fill in the subsets needing materials updated.
You no longer have to save/reload to see the material changes after an import. All the changes are done immediately and will be visible. This now forces you to plan your subsets/materials before an import. You need to ensure that the subsets have the correct (might need different materials assigned to them) materials assigned before import. Take for instance where a mesh has 2 subsets defined. You are wanting to import an OBJ file that defines 2 subsets with 2 different materials. If the current mesh has the same material defined for both subsets then both mesh's subset's materials will be updated with the last material properties.
If you are importing into a mesh and the import will cause the mesh to gain additional subsets then the importer can't update the materials for those additional subsets because no prior material was defined for them. You will need to assign a material(s) to those additional subsets after the import is complete.
If the importer can't find a texture specified in a material then it will ask you to find it for it (it will show a window where you can navigate to the texture to be used)
If your MTL file defines self-illumination/emissive (Ke) then you need to ensure the emissive/self-illumination is enabled in the material's extendeddata before doing the import. If the emissive/self-illumination is not enabled in the material's extendeddata prior to import then the importer will NOT update the material's emissive/self-illumination data.
There are only two maps the importer supports: map_Kd (diffuse) and map_Bump (or Bump). All other maps (map_Ks for instance) will be ignored. For the occlusion map (AO) define it as map_Kd and the importer will know how to handle it

:|\\

TheDarkWraith

01-24-14, 11:14 AM

v1.1.409.1 released. See post #1
Added the ability to view the vertex declaration for a mesh

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7283

right click on a mesh to view the context menu. You'll notice a new entry: Vertex declaration. If you click that:

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7284

A dialog box will appear showing you how the vertices for that mesh are defined. The number after the component name is the number of items that comprise that component. i.e.: Position has a value of 3. That means 3 items are needed to define position (X, Y, and Z). It also tells you how many bytes each vertex in the mesh occupies memory wise.

I'm currently working on the ability to change the vertex declaration of a mesh (add/remove components)

Targor Avelany

01-24-14, 01:37 PM

TheDarkWraith

01-24-14, 02:50 PM

Welcome back, TDW! :)

Awesome to see you and that you are still working on the editor!!!!

One thing: I have had issues with "mirrired" or "inverted" texture coords.
The example can be seen here: http://www.subsim.com/radioroom/showthread.php?p=2147022#post2147022

I was never able to figure it out, so I have just inverted the textures and it worked fine, but it would be interesting to understand.

Have you tried the newest version to see if the same thing happens? If it does then have you tried setting the double sided property in the mesh's extended data? Did you also try unchecking the invert Y texture coordinates in the importer window?

Targor Avelany

01-24-14, 02:54 PM

Have you tried the newest version to see if the same thing happens? If it does then have you tried setting the double sided property in the mesh's extended data? Did you also try unchecking the invert Y texture coordinates in the importer window?

No on th first question. Yes to the second. I will be trying the new version as soon as I have a smidge of free time at home on computer.

TheDarkWraith

01-24-14, 04:14 PM

Coded in the ability to see the face normals and vertex normals. This could be useful to see if your normals are screwed up or not.

The app calculates the face normal by taking each triangle's 3 vertice's normals and averaging them.

Here is a screenshot of face normals being rendered:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7287

TheDarkWraith

01-24-14, 05:36 PM

It's growing thorns :eek:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7288

No, not really. That would be the rendering of the vertex normals (green), binormals (yellow), and tangents (orange). Of course if the mesh's vertex declaration doesn't define one or more of these then they can't be rendered.

Don't know what binormals and tangents are? Google it :D

Now you can visually verify that these are correct also :up:

THE_MASK

01-24-14, 06:22 PM

While trying to open Silent Hunter 5\data\Terrain\Locations\CustomAreas\navrik.GR2 with GR2EditorViewer_v_1_1_409_1
Comes up with error embedded string failed its alignment check

TheDarkWraith

01-24-14, 07:27 PM

While trying to open Silent Hunter 5\data\Terrain\Locations\CustomAreas\navrik.GR2 with GR2EditorViewer_v_1_1_409_1
Comes up with error embedded string failed its alignment check

The app caught what it was coded to do. Here are some dumps from that GR2 file: https://www.mediafire.com/?wbwrbw0dtnc13qs

I swear when I think I just start to have a clue about the Granny format some GR2 file pops up that blows one of my theories, assumptions, or rules out the window! I don't have many theories, assumptions, or rules for special GR2 files (which this one is - pointers come before data) but previous ones at least followed the alignment or didn't follow the alignment specified for the sections. This one is totally bizarre - only in Section 0 does it break the 'rules'. Sometimes it decides to follow the alignment, then nope, then oh I'll follow it again, nah not anymore, oh ok let's follow alignment again, etc. etc :nope:

TheDarkWraith

01-24-14, 08:26 PM

While trying to open Silent Hunter 5\data\Terrain\Locations\CustomAreas\navrik.GR2 with GR2EditorViewer_v_1_1_409_1
Comes up with error embedded string failed its alignment check

I updated the 'rules' for special GR2 files with the revelation from this GR2 and the app was able to successfully load AND save it :yeah: I hope there aren't too many more of these 'surprises' still. Starting with v1.1.413.1 you'll be able to load and save this file and others like it.

TheDarkWraith

01-24-14, 11:30 PM

rendering tab updated with items needed for the rendering of face normals, vertex normals, vertex binormals, and vertex tangents
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7289

The context menu for the mesh's has been updated with the necessary entries for the rendering of face normals, vertex normals, vertex binormals, and vertex tangents
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7290

v1.1.415.1 released. See post #1

- updated rendering tab and mesh's context menu for rendering of face normals, vertex normals, vertex binormals, and vertex tangents
- changed the code dealing with bounding boxes and bounding spheres to save memory and minimize errors
- updated the 'rules' for the special GR2 files due to something Sober found
- the verify function read a book and gained intelligence. Less false 'is possibly corrupt' now. It has had some new rules added to it.
- Mesh adding/deleting/changing subsets shouldn't cause any problems - people need to verify this though
- a few optimizations were done on the code to minimize memory usage (found some com objects that I wasn't disposing of when I was done with them)
- When you view a mesh's materials you are no longer able to select any
- Started coding in the ability to change a mesh's vertex declaration - about 50% done on it

The app calculates the face normal by taking each triangle's 3 vertice's normals and averaging them.

I've noted that the guns_radars GR2 file will not load with the app due to mixed values being found in Section 0. I'm investigating what these mixed values are.

tonschk

01-25-14, 07:48 AM

:yeah::up::salute::sunny:

Welcome back, TDW! :)

gap

01-25-14, 09:23 AM

Just finished testing the new features with v1.1.415.1

Vertex declarations/Normals, Tangents and Binormals rendering: they seem to work as supposed. :up: I can see 1 Normal and up to 6 Tangents and Binormals coming out of each balloon vertex. Does it mean that each vertex has been split into six during importing, each with slightly different topology?

Material updating: textures/material properties are getting updated now. Everything looks fine within GR2 Editor (lighting enabled) :up: but... no matter what ambient/diffuse/specular/shininess settings I set in Wings3d, the result is always the same in Goblin (i.e. an over reflective model, as for the crates that we discussed before).

An example:

material properties of the imported object:
ambient: 0.5 / diffuse: 0.5 / specular: 0.5 / shininess: 0.5

result:

https://imagizer.imageshack.us/v2/820x311q90/13/y5k3.jpg

left: Goblin; right: GR2 Editor (Lightning Enabled with ambient light and one directional light - light colors and direction: default).

Tried importing in various files, but the result didn't change. I have uploaded the files of my example on mediafire, if you want to have a look into them:

https://www.mediafire.com/?b3e0sibqwt7nhbr

NOTE: the GR2 file included in the above package is reported as 'possibly corrupt' by your verifier. This is because it had been previously edited with various old version of GR2 Editor. Anyway, as I have stated before, importing the same object in a clean file didn't make things better.

TheDarkWraith

01-25-14, 09:45 AM

Vertex declarations/Normals, Tangents and Binormals rendering: they seem to work as supposed. :up: I can see 1 Normal and up to 6 Tangents and Binormals coming out of each balloon vertex. Does it mean that each vertex has been split into six during importing, each with slightly different topology?

Material updating: textures/material properties are getting updated now. Everything looks fine within GR2 Editor (lighting enabled) :up: but... no matter what ambient/diffuse/specular/shininess settings I set in Wings3d, the result is always the same in Goblin (i.e. an over reflective model, as for the crates that we discussed before).

If you see multiple binormals and tangents for a vertex then it has been cloned by the importer (it needed to because different UV data for each clone was found).

Using the new normals, tangents, and binormals features I can see what's going on with them:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7291

And they look fine. All the normals are pointing outwards and the binormals and tangents are orthogonal where they need to be (the normals, binormals, and tangents form a corner).

This is an interesting thing of why it renders 'washed-out' in Goblin...What I'm having a hard time with is why the importer needed to clone some of the vertices multiple times when it appears they are only really needed once. Take the body for instance along the side. I can see multiple binormals and tangents which tells me that there are multiple vertices at that one vertex. I don't see why.

As far as the verifier saying it might be corrupt it's saying that because it found 'filler' between embedded strings. Most likely because you imported this into the GR2 file using a version < 400. It's nothing to worry about.

TheDarkWraith

01-25-14, 10:04 AM

http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7292

This is looking straight down at the top of the barrage balloon. Look at the vertex right in the middle of the screen. There are like 6-10 vertices at that one point! Why? The importer found that vertex to have multiple references with all different UV data. Why does that one vertex have multiple UV data? It's displaying one texture only. There's something wrong with the Wings3D export or you did something really screwy in the UV mapping.

gap

01-25-14, 10:10 AM

If you see multiple binormals and tangents for a vertex then it has been cloned by the importer (it needed to because different UV data for each clone was found).

Yep, I thought so. This has obvioulsy an effect on file size and memory usage. Using Meshalb and his object sorter, Privateer actually managed to compress model's size, but look how it looked:

http://i108.photobucket.com/albums/n12/privateer_2006/SH5%20Stuff/nailed-it.jpg

http://www.subsim.com/radioroom/showthread.php?p=2152092#post2152092

This is an interesting thing of why it renders 'washed-out' in Goblin...What I'm having a hard time with is why the importer needed to clone some of the vertices multiple times when it appears they are only really needed once. Take the body for instance along the side. I can see multiple binormals and tangents which tells me that there are multiple vertices at that one vertex. I don't see why.

Yep, I see what you mean: I would have expected to see duplicate vertices along the borders of UV areas, but now every vertex seem to have multiple interations, no matter its position on the mesh/UV map :hmm2:

In any case I am afraid that this vertex iteration thing has nothing to do with the model looking washed out in Goblin. It is a material corruption.
I have re-imported the same object file in a copy of the same file I used for my previous tests, but disabled the update material checkbox. This is a Goblin rendering of the resulting file:

https://imagizer.imageshack.us/v2/475x366q90/69/gu0i.jpg

As far as the verifier saying it might be corrupt it's saying that because it found 'filler' between embedded strings. Most likely because you imported this into the GR2 file using a version < 400. It's nothing to worry about.

:up:

On a side note: I have a little (or big?) request. As it is now, you program won't let us to have multiple bone bindings per mesh. I wonder if this can be changes. It would be useful for when we need to iterate a mesh many times and, I suppose, it would reduce greatly memory usage.

TheDarkWraith

01-25-14, 10:17 AM

In any case I am afraid that this vertex iteration thing has nothing to do with the model looking washed out in Goblin. It is a material corruption.
I have re-imported the same object file in a copy of the same file I used for my previous tests, but disabled the update material checkbox. This is a Goblin rendering of the resulting file:

On a side note: I have a little (or big?) request. As it is now, you program won't let us to have multiple bone bindings per mesh. I wonder if this can be changes. It would be useful for when we need to iterate a mesh many times and, I suppose, it would reduce greatly memory usage.

Look at the extended data between the file with the correct rendering and the one that doesn't. What is different?

You should be able to specify as many bone bindings as you want for a mesh. If that isn't working then I need to look into it. I coded that in a long time ago.

gap

01-25-14, 10:23 AM

There's something wrong with the Wings3D export or you did something really screwy in the UV mapping.

This is the UV map:

https://imagizer.imageshack.us/v2/557x557q50/268/mc5s.jpg

The top of the balloon (highlighted) is a continuous surface (I have just checked that there aren't unwelded vertices/edges). I can't see anything wrong in it. A 3ds max export of the same object provided by Targor, looks identical both in Wings and in GR2 Editor (same GR2 file size once imported, same binormals/tangents). :hmmm:

TheDarkWraith

01-25-14, 10:29 AM

Here's how my app rendered the texture coordinates:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7293

What's interesting is that it had to tile it 2X2. I have to look over the code but I'm almost 100% sure it only tiles if it finds additional texture coordinates :hmmm:

TheDarkWraith

01-25-14, 10:43 AM

okay looking over the render texture coordinates code the app only tiles if the texture coordinates exceed 1.0 (u or v) and every multiple of 1.0 (plus or minus) causes an additional tiling.

Thus since it had to tile 2 X 2 either or both the u and v texture coordinates exceeded 1.0 (texture coordinates were in the range of -1.0 to 1.0 or 0.0-2.0 or -2.0-0.0). But clearly some of those texture coordinates are not being used so they are redundant and should be removed.

Wings3D doesn't show tiling - that's one thing I disliked about it. Instead of tiling it just ensures all UV coordinates fall in 0.0-1.0 range (when rendering them)

gap

01-25-14, 10:57 AM

Look at the extended data between the file with the correct rendering and the one that doesn't. What is different?

IIRC, Ambient Color, Diffuse Color, Specular Color and Shininess Strength are affected. But no matter what they are set to, once the material get "corrupt" (after being updated by your application), the model will look washed out in Goblin.

You should be able to specify as many bone bindings as you want for a mesh. If that isn't working then I need to look into it. I coded that in a long time ago.

Either this feature got broken somehow, or I use it the wrong way :hmmm:

okay looking over the render texture coordinates code the app only tiles if the texture coordinates exceed 1.0 (u or v) and every multiple of 1.0 (plus or minus) causes an additional tiling.

Thus since it had to tile 2 X 2 either or both the u and v texture coordinates exceeded 1.0 (texture coordinates were in the range of -1.0 to 1.0 or 0.0-2.0 or -2.0-0.0). But clearly some of those texture coordinates are not being used so they are redundant and should be removed.

Wings3D doesn't show tiling - that's one thing I disliked about it. Instead of tiling it just ensures all UV coordinates fall in 0.0-1.0 range (when rendering them)

The balloon body/side ropes UV map has not tilling. Ridging cables and picketing lines are tiled many times though. The tiling is shown correctly in Wings3d :yep: and in GR2 Editor, but not in game

TheDarkWraith

01-25-14, 11:05 AM

Figured out why it looks 'washed-out'. Change the shininess strength to 0 in the extendeddata. Problem solved :up:

I'm looking over my code to see if I screwed up and that value should be in range 0-1.0 vice 0-100.

TheDarkWraith

01-25-14, 11:07 AM

Yep I screwed up in the code. Shininess strength should be in range 0.0-1.0. I'll correct the code :up:

For your barrage balloon set shininess strength to 0.5 and it will look like you wanted it to.

gap

01-25-14, 11:18 AM

Yep I screwed up in the code. Shininess strength should be in range 0.0-1.0. I'll correct the code :up:

For your barrage balloon set shininess strength to 0.5 and it will look like you wanted it to.

It works :yeah:

gap

01-25-14, 12:56 PM

Thus since it had to tile 2 X 2 either or both the u and v texture coordinates exceeded 1.0 (texture coordinates were in the range of -1.0 to 1.0 or 0.0-2.0 or -2.0-0.0). But clearly some of those texture coordinates are not being used so they are redundant and should be removed.

I have scaled the UV map of my balloon body model using Wings3d's "Max uniform" command. this command moves each item to the center, and scales it so that its length/width (whatever is bigger) is equal to one texture unit. In other words, it ensures that no UV coordinate exceeds the 0-1 range.

Result: after re-importing the object with GR2 Editor, and clicking on the 'Show' button, the texture is tiled 3 x 3 times, rather than 2 x 2. :doh:

My suspect is that either your code has 0-1 set as texture range, but with 0 and 1 not included, or for some reson Wings3d slightly exceeds this range :yep:

Edit:

no, it can't be this: I have scaled all my UV items so that they are well within the size of one texture, but GR2 Editor keeps showing them in a 2 x 2 frame :hmmm:

TheDarkWraith

01-25-14, 01:14 PM

TheDarkWraith

01-25-14, 02:00 PM

Ok I updated the renderer so that it's using the correct shininess value. Now if you get shininess strength value > 1.0 you will see this (if lighting is enabled):
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7294

Shininess strength was 50.0 in the above. With it set to 0.5 you get this:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7295

Much better. Now you can verify it here along with Goblin :up:

Looking into the mesh bone binding problem now

gap

01-25-14, 02:18 PM

Ok I updated the renderer so that it's using the correct shininess value. Now if you get shininess strength value > 1.0 you will see this (if lighting is enabled)

Brilliant :up:

Looking into the mesh bone binding problem now

Using the same GR2 file that we have been experimenting on today, I have cloned the 'BalloonMkVII_wires' bone, gave it the 1 flag and changed its x position.

Problem #1: the "Update" button never worked for me (always greyed out). I can store the bone changes without updaing them though, and though being warned on saving that there are changes that need to be stored/updated, my changes are saved correctly.

Problem #2: I tried to link the cables to the new mesh. By pressing Ctrl, I can select a new bone by keeping the old one selected. After confirming the change, nothing happens in the Editor. When I open again the bone editing window, I can see that the mesh is still linked to the old bone, but not to the new one.

Problem #3: I can discard the old bone linking and select a new one (without pressing Ctrl). The change is accepted apparently. The next time I open the bone linking Editor, it shows that the new bone is selected, but the viewport tells me that the mesh is still linked to the old bone. :hmmm:

TheDarkWraith

01-25-14, 02:32 PM

I have scaled the UV map of my balloon body model using Wings3d's "Max uniform" command. this command moves each item to the center, and scales it so that its length/width (whatever is bigger) is equal to one texture unit. In other words, it ensures that no UV coordinate exceeds the 0-1 range.

Result: after re-importing the object with GR2 Editor, and clicking on the 'Show' button, the texture is tiled 3 x 3 times, rather than 2 x 2. :doh:

My suspect is that either your code has 0-1 set as texture range, but with 0 and 1 not included, or for some reson Wings3d slightly exceeds this range :yep:

Edit:

no, it can't be this: I have scaled all my UV items so that they are well within the size of one texture, but GR2 Editor keeps showing them in a 2 x 2 frame :hmmm:

I 'broke' into the code at the point where it goes to render the texture coordinates and dumped the contents of the mesh's UV coordinates. I don't understand why DirectX did this but here's an excerpt of those uvs:

u=0.959849 v=-0.300698
u=0.976901 v=-0.300698
u=0.976901 v=-0.002600
u=0.959849 v=-0.002600
u=0.959849 v=-0.598797
u=0.976901 v=-0.598797
u=0.976901 v=-0.300698
u=0.959849 v=-0.300698
u=0.964299 v=-0.300698
u=0.967409 v=-0.300698
u=0.970569 v=-0.300698
u=0.973906 v=-0.300698
u=0.973906 v=-0.002600
u=0.970569 v=-0.002600
u=0.967409 v=-0.002600
u=0.964299 v=-0.002600
u=0.964299 v=-0.598797
u=0.967409 v=-0.598797
u=0.970569 v=-0.598797
u=0.973906 v=-0.598797
u=0.973906 v=-0.300698
u=0.970569 v=-0.300698
u=0.967409 v=-0.300698
u=0.964299 v=-0.300698
u=0.976302 v=-0.002600
u=0.975703 v=-0.002600
u=0.975104 v=-0.002600
u=0.974505 v=-0.002600
u=0.976302 v=-0.300698
Since there are values in 0.0-1.0 range and values in -1.0-0.0 range the app tiled them 2X2. So the app is doing exactly what it was programmed to do.

DirectX must have 'optimized' these UVs when I called the DirectX function to optimize the mesh :hmmm:. My local copy of the vertices that were used to build the mesh have the 'correct' uvs with all in the range 0.0-1.0. Strange. DirectX is doing what it needs to do I guess :)

TheDarkWraith

01-25-14, 02:34 PM

Using the same GR2 file that we have been experimenting on today, I have cloned the 'BalloonMkVII_wires' bone, gave it the 1 flag and changed its x position.

Problem #1: the "Update" button never worked for me (always greyed out). I can store the bone changes without updaing them though, and though being warned on saving that there are changes that need to be stored/updated, my changes are saved correctly.

Problem #2: I tried to link the cables to the new mesh. By pressing Ctrl, I can select a new bone by keeping the old one selected. After confirming the change, nothing happens in the Editor. When I open again the bone editing window, I can see that the mesh is still linked to the old bone, but not to the new one.

Problem #3: I can discard the old bone linking and select a new one (without pressing Ctrl). The change is accepted apparently. The next time I open the bone linking Editor, it shows that the new bone is selected, but the viewport tells me that the mesh is still linked to the old bone. :hmmm:

I'm looking into it now...

gap

01-25-14, 02:48 PM

I 'broke' into the code at the point where it goes to render the texture coordinates and dumped the contents of the mesh's UV coordinates. I don't understand why DirectX did this but here's an except of those uvs:

...

Since there are values in 0.0-1.0 range and values in -1.0-0.0 range the app tiled them 2X2. So the app is doing exactly what it was programmed to do.

DirectX must have 'optimized' these UVs when I called the DirectX function to optimize the mesh :hmmm:. My local copy of the vertices that were used to build the mesh have the 'correct' uvs with all in the range 0.0-1.0. Strange. DirectX is doing what it needs to do I guess :)

Do you mean that UV coordinates are changed in memory? :doh:

Summing up, what would be the adverse effect of UV coordinates not being in the 0-1 range? During my tests in game I couldn't notice anything wrong except for the balloon "jumping" on screen at times (as if some frames of their animation were skipped), when looked through the binoculars with the boat swinging. The game didn't lag anyway: I don't know how to explain it, but only the balloons seemed to lag, while the rest of the scene went on flawlessy :)

TheDarkWraith

01-25-14, 03:27 PM

Do you mean that UV coordinates are changed in memory? :doh:

Summing up, what would be the adverse effect of UV coordinates not being in the 0-1 range? During my tests in game I couldn't notice anything wrong except for the balloon "jumping" on screen at times (as if some frames of their animation were skipped), when looked through the binoculars with the boat swinging. The game didn't lag anyway: I don't know how to explain it, but only the balloons seemed to lag, while the rest of the scene went on flawlessy :)

I dumped a DirectX internal data structure just to see what it was doing with the uvs. Nothing to worry about.

uvs do not have to be in 0-1.0 range. They can be any value. How they will be handled outside the 0-1.0 range depends on how the wrapping is defined.

v1.1.418.1 released. See post #1
This addresses your #1 problem. Let me know if it's still not working.
The C# operator || (short-circuit OR) was not working like it was supposed to and thus was causing something to happen that wasn't supposed to. Now the Update button will become active as soon as you move something OR you change the Position, Rotation, Scale, Flags of a bone or mesh. Note I said Flags. If you change the Flags from 0 to say 1 (Position) then you need to press the Update AND Store buttons. Failure to do so will result in Flags being reset when you press the Reset button (if you ever press it)

gap

01-25-14, 04:06 PM

v1.1.418.1 released. See post #1
This addresses your #1 problem. Let me know if it's still not working.

Testing it right away :salute:

gap

01-25-14, 04:18 PM

Testing it right away :salute:

Changed bone position data, but the 'Update' button was still grayed out; changed flags from 0 to 1, but nothing changes, as far as that button is concerned....

Anyway I wonder what is its use, since I am able to press the 'Store' button and to save any bone change without updating :06:

TheDarkWraith

01-25-14, 04:24 PM

Changed bone position data, but the 'Update' button was still grayed out; changed flags from 0 to 1, but nothing changes, as far as that button is concerned....

Anyway I wonder what is its use, since I am able to press the 'Store' button and to save any bone change without updating :06:

You sure you are using v1.1.418.1? The update button should've gone active as soon as you changed the flags or moved the bone (or you move a mesh)

The update writes the changes to memory. Until you press the update button the changes are temporary. Changes have to be written to memory before they can be Stored (set as new default).

gap

01-25-14, 04:41 PM

You sure you are using v1.1.418.1?

So I asked myself before posting my last report, and I double-checked :haha:

Yes, I am sure, v1.1.418.1 (its window is still open from my last test, and I can clearly read the version number from the header bar) :yep:

The update writes the changes to memory. Until you press the update button the changes are temporary. Changes have to be written to memory before they can be Stored (set as new default).

I (still) can press the 'Store' button without pressing 'Update' first.

TheDarkWraith

01-25-14, 04:49 PM

I (still) can press the 'Store' button without pressing 'Update' first.

That's interesting. How did you do that?

EDIT: actually there's one way that will happen. If you change the Flags in the extendeddata then the store button will be active without the update button active. Since you didn't change any position, rotation, or scale then the update button is not active.

gap

01-25-14, 05:01 PM

That's interesting. How did you do that?

Oh, not everyone got the skills for doing it :smug: :D

Out of jokes... it has always been like this for me: when I tweak a bone the 'Store' button becomes available in place of 'Update'. This is something I can live with, because (despite any warning by GR2E) I can still save the changes, but since you asked to break you application, I thought I should inform you about this oddity

gap

01-25-14, 05:05 PM

EDIT: actually there's one way that will happen. If you change the Flags in the extendeddata then the store button will be active without the update button active. Since you didn't change any position, rotation, or scale then the update button is not active.

Whether I modify or not position, rotation, or scale data, 'Store' is always activated instead of 'Update' :yep:

TheDarkWraith

01-25-14, 05:15 PM

Whether I modify or not position, rotation, or scale data, 'Store' is always activated instead of 'Update' :yep:

Close all opened GR2 files.
Open your barrage balloon.
Select the last bone in the bones treeview
Is the Update or Store button active?
Edit the bone's extendeddata and set Flags to 7
Is the Update or Store button active?
If Store active then press Store to store the new flags value of 0x7
Store should now go inactive
Now move the bone on it's Z axis
As soon as you started moving it the Update button should've gone active along with Reset
Press Update
Store should've now gone active and Update goes inactive
Press Store
Store goes inactive and Reset goes inactive
Move bone again
Update should go active along with Reset
Press Reset
Update and Reset should go inactive and bone should move back to last stored position (last press of Store)

TheDarkWraith

01-25-14, 05:31 PM

Problem #2: I tried to link the cables to the new mesh. By pressing Ctrl, I can select a new bone by keeping the old one selected. After confirming the change, nothing happens in the Editor. When I open again the bone editing window, I can see that the mesh is still linked to the old bone, but not to the new one.

Problem #3: I can discard the old bone linking and select a new one (without pressing Ctrl). The change is accepted apparently. The next time I open the bone linking Editor, it shows that the new bone is selected, but the viewport tells me that the mesh is still linked to the old bone. :hmmm:

Problem #2: I see why you can't add more bone bindings than what was originally declared. I test for this equality and if not satisfied (you asked for more bone bindings than what was originally declared) then it jumps to an empty function :haha: Whoops. Forgot to code that one :D

Problem #3: fixed. Now the treeview is updated with the change.

I'm coding in a 'Clean' function. This will 'clean' the GR2 file of irrelevant data (fillers for one). This will be a continuous WIP.

gap

01-25-14, 05:32 PM

Close all opened GR2 files.
Open your barrage balloon.
Select the last bone in the bones treeview
Is the Update or Store button active?

None of them

Edit the bone's extendeddata and set Flags to 7
Is the Update or Store button active?

Store

If Store active then press Store to store the new flags value of 0x7
Store should now go inactive

Done, and the Store button went inactive

Now move the bone on it's Z axis
As soon as you started moving it the Update button should've gone active along with Reset

Done (through the Transform Position vindow). Store and Reset went active.

Press Update
Store should've now gone active and Update goes inactive
Press Store
Store goes inactive and Reset goes inactive

Pressed Store instead

Move bone again
Update should go active along with Reset

As before: Store and Reset are active

Press Reset
Update and Reset should go inactive and bone should move back to last stored position (last press of Store)

Done; Store and Reset went inactive, and bone moved back to its last stored position.

On my system, the Store button picks up and blocks all the "messages" sent to Update :yep:

gap

01-25-14, 05:34 PM

Problem #2: I see why you can't add more bone bindings than what was originally declared. I test for this equality and if not satisfied (you asked for more bone bindings than what was originally declared) then it jumps to an empty function :haha: Whoops. Forgot to code that one :D

Problem #3: fixed. Now the treeview is updated with the change.

:yeah:
those are important features!

TheDarkWraith

01-25-14, 05:53 PM

Done (through the Transform Position vindow). Store and Reset went active.

Ok, that makes sense. Try moving the bone using the render window. Select the bone in the bone treeview. Place mouse in the render window. Click the render window. Press C to cage the camera. Ensure T is visible in the bottom right of the app, if not then press T. Ensure Z is visible in the bottom right of window, if not press Z. Now press and hold right mouse button and move mouse forward. Soon as mouse started moving the Update and Reset button should've gone active. Press C to uncage the camera.

When you update the Position, Rotation, or Scale using the extendeddata window you bypass the Update. Obviously you know exactly where you wanted the item since you are directly typing it in!

gap

01-25-14, 06:22 PM

Ok, that makes sense. Try moving the bone using the render window. Select the bone in the bone treeview. Place mouse in the render window. Click the render window. Press C to cage the camera. Ensure T is visible in the bottom right of the app, if not then press T. Ensure Z is visible in the bottom right of window, if not press Z. Now press and hold right mouse button and move mouse forward. Soon as mouse started moving the Update and Reset button should've gone active. Press C to uncage the camera.

When you update the Position, Rotation, or Scale using the extendeddata window you bypass the Update. Obviously you know exactly where you wanted the item since you are directly typing it in!

Okay, it works now. Never actually used the mouse-drag method, and it never popped to my mind that the input method could have mattered until I wrote my last report. Sorry for wasting you time. :88)

P.S. but why, even after saving/reloading, meshes don't follow the translation of their own bone? :doh:

TheDarkWraith

01-25-14, 06:43 PM

Okay, it works now. Never actually used the mouse-drag method, and it never popped to my mind that the input method could have mattered until I wrote my last report. Sorry for wasting you time. :88)

P.S. but why, even after saving/reloading, meshes don't follow the translation of their own bone? :doh:

I'm almost 99% sure that's not how SH5/Goblin works. I really don't understand why meshes have bone bindings except for those that have deformable data (skin data). Look how the meshes are saved in 3D space in the GR2 files. They are pre-positioned to where they need to be.

If you can prove to me that the bone bindings control where the meshes are then I will change it. Also if you can then it poses another problem: what happens when a mesh has multiple bone bindings (and the mesh is not deformable)?

gap

01-25-14, 07:16 PM

I'm almost 99% sure that's not how SH5/Goblin works. I really don't understand why meshes have bone bindings except for those that have deformable data (skin data). Look how the meshes are saved in 3D space in the GR2 files. They are pre-positioned to where they need to be. If you can prove to me that the bone bindings control where the meshes are then I will change it.

You are probably right: after having a look at the Stuka, I am also convinced that the placement of each mesh relative to its neighbouring meshes, is done through vertex coordinates rather than position/rotation data. This involves that having multiple bone bindings for one given mesh wouldn't help the way it did in SHIII-IV, where one could use multiple iteration of the same mesh for sparing memory usage on models composed by many similar parts in different positions.

As for why bones with position/rotation data are linked to non-deformable meshes, I have a theory. Most control surfaces have position data, but I think their rotation is done through controllers (as in previous games) rather than through GR2 animations. End of the similarities; as opposed to its predecessors (where, rudders, dive planes, etc rotated along their standard axes and node translation was required for their correct positioning along the model), SH5 uses pre-positioned meshes and translation data might be required for determining the pivot point of rotating surfaces :hmm2:

gap

01-25-14, 07:28 PM

...End of the similarities; as opposed to its predecessors (where, rudders, dive planes, etc rotated along their standard axes and node translation was required for their correct positioning along the model), SH5 uses pre-positioned meshes and translation data might be required for determining the pivot point of rotating surfaces :hmm2:

My reasoning would be invalidated if before exporting a mesh your application added position data from its linked bone its vertex coordinates. If that was true, then SH5 would work exactly as SHIII&IV (i.e. rotation axes, where required, coinciding with main x or y axes, and position data used for item positioning)...

TheDarkWraith

01-25-14, 07:44 PM

My reasoning would be invalidated if before exporting a mesh your application added position data from its linked bone its vertex coordinates. If that was true, then SH5 would work exactly as SHIII&IV (i.e. rotation axes, where required, coinciding with main x or y axes, and position data used for item positioning)...

Why don't you do this: take a few bones and move them, like really far, and see if the meshes associated with them change in Goblin/Game. See what happens :hmmm:

gap

01-25-14, 07:48 PM

By the way: look at the rudder of the Stuka. Its proximal edge (ignoring the small upper appendage), around which the surface is supposed to rotate, got a z coordinate of -0.564341 once exported. This is identical to the z position of the bone that the mesh is linked to.

Either the original position was 0, and your application converted it into -0.564341 by adding bone position to vertex coordinates while exporting, or this -0.564341 tells the game where the pre-positioned rudder must rotate :yep:

gap

01-25-14, 07:54 PM

Why don't you do this: take a few bones and move them, like really far, and see if the meshes associated with them change in Goblin/Game. See what happens :hmmm:

I did this already. There is not apparent difference in Goblin :yep:

TheDarkWraith

01-25-14, 08:00 PM

I did this already. There is not apparent difference in Goblin :yep:

That's what I remembered from long ago. Like I said I don't see the purpose of the mesh bone bindings except for the deformable (skin) data. I'd like to understand what their purpose is :shifty:

gap

01-25-14, 08:36 PM

That's what I remembered from long ago. Like I said I don't see the purpose of the mesh bone bindings except for the deformable (skin) data. I'd like to understand what their purpose is :shifty:

isn't this enough?
----------\/----------

By the way: look at the rudder of the Stuka. Its proximal edge (ignoring the small upper appendage), around which the surface is supposed to rotate, got a z coordinate of -0.564341 once exported. This is identical to the z position of the bone that the mesh is linked to.

Either the original position was 0, and your application converted it into -0.564341 by adding bone position to vertex coordinates while exporting, or this -0.564341 tells the game where the pre-positioned rudder must rotate :yep:

...or are the control surfaces that I am talking about to be considered as part of the "deformable" category? :06:

Anvart

01-26-14, 02:12 AM

gap

01-26-14, 08:31 AM

Today, for the first time looked this program ... and I have a question ... how much else author will be puff our brains with his non friendly "monster"? Only one non human interface kills any wish...

Hi Anvart,

have you actually tried using the "monster"? If you feel disoriented, pose your questions and we will help you as much as we can; if on the other hand you have any suggestions for making GR2 Editor more user friendly, post them and I am sure TDW will be glad to read them.

But just don't blame your lack of motivation on GR2 Editor's interface :03: :salute:

TheDarkWraith

01-28-14, 02:55 PM

Today, for the first time looked this program ... and I have a question ... how much else author will be puff our brains with his non friendly "monster"? Only one non human interface kills any wish...

Being that this 'monster' has been in constant development for over 1.5 years I never heard any input from you or many others as to how you would like the interface to be. Thus not my problem. You had a chance and you didn't take it.

What I suggest you do is either:
1) learn it
2) don't use it
3) write your own

If you choose to write your own, I wish you luck :smug:

TheDarkWraith

01-28-14, 03:03 PM

Another piece of the Granny puzzle fell into place today :D I was playing around with the lifeboat GR2 (CMD_smallboat) and I turned on bounding box rendering and saw that the bounding box for the DMG_col mesh was not where I thought it should be:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7306

I looked over the code for any errors and couldn't find anything wrong with my code. Next I fired up Granny Viewer to see how it renders them:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7305

Look at that! That little tooltip says:
'Toggles whether or not yellow boxes are drawn to indicate the OBB bounds of each bone for each mesh'

This means that the bounding box's position (center) is determined by the bone's position (the bone in each bone binding). This also means that if a mesh has more than 1 bone binding then it will also have x bone binding bounding boxes.

I'm updating my code for this new discovery. Now I understand at least one reason for the mesh bone bindings.

tonschk

01-28-14, 04:05 PM

gap

01-28-14, 04:26 PM

Another piece of the Granny puzzle fell into place today

...

This means that the bounding box's position (center) is determined by the bone's position (the bone in each bone binding). This also means that if a mesh has more than 1 bone binding then it will also have x bone binding bounding boxes.

In other words, does it works likewise dat format files, where mesh position follows node position? :hmm2:

TheDarkWraith

01-28-14, 04:33 PM

Hello :salute: TheDarkWraith :up:, please can you suggest me an example path for me to open with your GR2 Editor/Viewer ? LNK@ paths ? , with my poor knowledge about this, at the moment I am not able to open anything, thank you

Any sub

In other words, does it works likewise dat format files, where mesh position follows node position? :hmm2:

No. The bone bindings (bones) are controlling (actually providing an offset) where the bounding box is positioned on the mesh. I'm not sure how bounding boxes and DMG_col nodes go together (if at all) :hmmm: Actually I'm not sure of the purpose of the bounding boxes at all.

Someone should try editing the bounding box for something and make it really small and located way above the object and see if it effects whether the object gets collided with (via a shell/another object).

TheDarkWraith

01-28-14, 07:47 PM

Fixed the code to account for this new discovery I made. Now the bounding boxes and bounding spheres are part of the bone binding class.

Accounting for the bone binding's bone's position now renders the bounding box in the correct position in 3D space:
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7307

Looks just like Granny Viewer :D Gotta love it...

Moving the bone binding's bone's position also moves the bounding box associated with it.

Also fixed a problem I found when you move individual vertices of a mesh using the mouse.

TheDarkWraith

01-28-14, 08:03 PM

v1.1.424.1. released. See post #1

- Fixed problem when moving individual vertices of a mesh with the mouse
- Started coding in new Feature: File-->Clean. This will clean the GR2 file of unneeded entries and objects. Currently only removes 'filler' found between embedded strings. I would strongly suggest only using this right after you load a file. If the 'cleaner' encounters an exception and it has modified the file then it will close the file to protect it (thus you lose everything if you didn't save it before).
- Fixed problem in renderer where it was using the incorrect shininess strength value
- Adjusted code to account for discovery made of how bounding boxes are controlled via bone binding's bone (they provide an offset)
- Added code for any lights defined to be rendered in 3D space. You can render the light's position and it's name. Selecting the light in the lights treeview will cause the rendered 'spot' to double in size. Selecting the same light again in the lights treeview will render the 'spot' normal size. This makes it easy to find the light. You can also set the render color for the lights.
- Enhanced the importers so that if they encounter a Ks value > 1.0 in the MTL file then they will scale it to 0.0-1.0 range (so it's compatible with Granny) - this fixes the problem gap was having with the barrage balloon

tonschk

01-29-14, 03:36 AM

Hi there, I try to open any sub but I cannot figure out how to open :wah:
http://i194.photobucket.com/albums/z58/tonschk/try_zpsc4e88e5a.png (http://s194.photobucket.com/user/tonschk/media/try_zpsc4e88e5a.png.html)

Any sub

.

TheDarkWraith

01-29-14, 10:27 PM

Hi there, I try to open any sub but I cannot figure out how to open :wah:

You need to set the install path to your \Silent Hunter 5 folder.
Now all you need to do is click File-->Open and select the GR2 file you want to open

v1.1.427.1 released. See post #1

Fixed rendering problem with some units (a part or parts of the unit would not render)
Did some optimizations to make the loading/saving faster

TheDarkWraith

01-29-14, 11:55 PM

v.1.1.428.1 released. See post #1

More optimizations done to make the loading process faster
Optimizations done to make the moving/rotation of a mesh or moving of it's vertices faster
Fixed rendering problem with the bounding spheres (they were rendering in incorrect positions)

gap

01-30-14, 02:21 AM

v1.1.424.1. released.

v1.1.427.1 released.

v.1.1.428.1 released.

Sorry for not reporting lately, I have been quite busy during the last few days, and thank you for your great work. :yeah:

Maybe this is a banal question, but seeing how fast you are progressing with your application, I wonder how far are we from the possibility to add new meshes to a granny file (or delete them), as you mentioned in another thread. Together with animations, that is probably one of the most important features needed for creating 'complex' units, i.e. composed by many independent parts, without having to carefully select the GR2 template that we start importing our meshes in :yep:

tonschk

01-30-14, 03:30 AM

:yeah::up::sunny:

and thank you for your great work. :yeah:

TheDarkWraith

01-30-14, 07:19 AM

Maybe this is a banal question, but seeing how fast you are progressing with your application, I wonder how far are we from the possibility to add new meshes to a granny file (or delete them), as you mentioned in another thread. Together with animations, that is probably one of the most important features needed for creating 'complex' units, i.e. composed by many independent parts, without having to carefully select the GR2 template that we start importing our meshes in :yep:

In time it will come :up:

tonschk

01-31-14, 05:31 PM

Thank you for the help, finally I was able to load something, when I try to close the application, the viewer ask me if I want to save the modification made by the viewer itself to be able to open the GR2 file (I didnt do anything)

http://i194.photobucket.com/albums/z58/tonschk/finally_zps901685bc.png (http://s194.photobucket.com/user/tonschk/media/finally_zps901685bc.png.html)

You need to set the install path to your \Silent Hunter 5 folder.
Now all you need to do is click File-->Open and select the GR2 file you want to open

TheDarkWraith

01-31-14, 05:50 PM

tonschk

02-01-14, 08:23 AM

Are those "missing embedded strings" modifications gonna negatively or positively affect the SH5 simulator if I click "yes save changes" ?, thank you for your help :up:

You said yes to add missing embedded strings. That is why it's asking if you want to save the changes.

TheDarkWraith

02-01-14, 08:42 PM

Are those "missing embedded strings" modifications gonna negatively or positively affect the SH5 simulator if I click "yes save changes" ?, thank you for your help :up:

Neither. If you start modifying the file then you will need them.

Fixed the texture coordinate rendering problem I found when rendering gap's barrage balloon's uvs. All his uvs were in the range of 0.0-1.0 but the app still tiled them 2X2. What I changed was where the app was getting the uvs from. Before I was taking them straight from the mesh. I found that when dumping the DirectX internal data structures it 'optimizes' the uvs and other data so they are not 'original' anymore. Now the app takes the uv data from the vertices in the mesh's PrimaryVertexData class.
http://www.subsim.com/radioroom/picture.php?albumid=642&pictureid=7310

Also did some more optimizations on the loading to decrease the loading time even further. I'll never attain Granny Viewer speed but every little bit helps :D

Also fixed problem of bounding box(s) not being recomputed when importing

gap

02-02-14, 02:41 AM

Fixed the texture coordinate rendering problem I found when rendering gap's barrage balloon's uvs.

...

Also did some more optimizations on the loading to decrease the loading time even further. I'll never attain Granny Viewer speed but every little bit helps :D

Also fixed problem of bounding box(s) not being recomputed when importing

:yeah:

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. :hmm2:

Useless to say that the lesser the vertices, the smaller the file size (on disc and in memory), the smoother the rendering of units in game :)

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...

tonschk

02-02-14, 05:21 AM

Every little bit helps :yeah:

Also fixed problem of bounding box(s) not being recomputed when importing

TheDarkWraith

02-02-14, 11:38 AM

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 :up:

gap

02-02-14, 12:19 PM

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. :hmm2:

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 :up:

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

TheDarkWraith

02-02-14, 02:17 PM

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. :hmm2:

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

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 :up: 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

02-02-14, 03:30 PM

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.

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 :up: Then after you modify the normal the app will have to calculate the new binormal and tangent since they are based on the normal.

:up:

TheDarkWraith

02-02-14, 08:05 PM

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

02-03-14, 04:15 AM

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

02-03-14, 04:29 AM

Amazing :sunny: Thank you

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

02-03-14, 09:59 PM

Amazing :sunny: 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 :rock:

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 :D 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 :yeah: 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

02-04-14, 05:15 AM

increasing the performance of the GR2 Editor :sunny::yeah: Very good

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 :yeah:

tonschk

02-06-14, 12:43 AM

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

http://i194.photobucket.com/albums/z58/tonschk/tower_zps1b20f5b9.png (http://s194.photobucket.com/user/tonschk/media/tower_zps1b20f5b9.png.html)

TheDarkWraith

02-06-14, 08:09 AM

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

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

02-16-14, 11:23 AM

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). :hmmm:

TheDarkWraith

02-16-14, 11:28 AM