GR2 Editor/Viewer/Extractor/Importer

[gap]

Originally Posted by TheDarkWraith

That tells me that I possibly didn't check to see if vertice cloning was needed for the AO vertices...I'll look over the code but have a feeling that's the problem as evidenced by the scrambled AO texture coordinate rendering.

yep, looks exactly the same to me

As an aside, I am going to give the model winter textures, for better mimetism against snowy landscapes. Do you know if the _winter suffix works on land units the same way it does with ships and terrain locations? The same could be done with aircraft, for giving them winter camo schemes.

Originally Posted by TheDarkWraith

On another note I'm making another new patch. It deals with the sonar sensor of units. Basically what I'm doing is if the attacker is using sonar and the attackee is moving slow and is within a small distance of the bottom (1.0m?) then the attacker's sonar signal strength will be reduced by some random amount (say 25-50%?). This will account for ground clutter 'masking' the attackee and the attacker unable to discern where the attackee is due to it being near the bottom and moving slow.

From what I've researched subs were able to sit on the bottom to hide from enemy sonar.

Originally Posted by TheDarkWraith

I'm going to put a depth limitation on this also. If the max depth is < 40m? then this doesn't apply. Did this tactic work in shallow depths (< 40m)?

I have no direct information about that, but your assumption about depth limit looks plausible: shallow depth would have meant lesser distance between the emitter and the target = higher frequencies impacting on the target (short waves don't travel as far as long ones) = better pinging resolution. It would be nice if you modelled a gradual reduction of the ground effect at shallow depths, rather than ending it abrouptly at 40 m. gap out

[TheDarkWraith]

Originally Posted by gap

yep, looks exactly the same to me

I see only two ways you could get scrambled AO coordinates:
1) you imported the AO texture coordinates separately (only had import AO checked - basically you were only importing AO texture coordinates) or
2) you imported the AO texture coordinates and AO vertex data and the number of AO vertices == number of non-AO vertices BUT the face definitions were different between AO and non-AO

I adjusted the code for 1 above. For 2 above I can't fix that - you need to ensure you are generating AO texture coordinates on the same object you generated the non-AO texture coordinates so that the face definitions will be the same for non-AO and AO.

Give me a link to the files you were using that gave the scrambled AO texture coordinates so I can view them in Debugger.

[Stormfly]

...and what about active sonars limited down angle (Sonar Shadow), not shure if that is moddeled allready, the problem they had was, if distance was close enough and sub was deep enough, the active contact boke up...

...i know that pretty good, it was moddeled in Destroyer Command, as we hunted sub`s in mp, we could estimate targets dept while comparing the active ping`s distance with a value in a table as the active contact broke up while closing in, giving the sub not to much time changing it, by executing the bombing run after the dept for the trash cans was set.

[urfisch]

i followed this project a few years ago. so, im out of info on it. short question: is it now possible to add new units? as far as i can see, its only possible to edit units, but not to import new ones in sh5. right?

[gap]

Originally Posted by TheDarkWraith

I see only two ways you could get scrambled AO coordinates:
1) you imported the AO texture coordinates separately (only had import AO checked - basically you were only importing AO texture coordinates)

nope, the two coordinate sets were imported at the same moment

Originally Posted by TheDarkWraith

or
2) you imported the AO texture coordinates and AO vertex data and the number of AO vertices == number of non-AO vertices BUT the face definitions were different between AO and non-AO

To the best of my knowledge, the diffuse and the AO meshes are indentical but in their UV coordinates: same number of polygons, same number of edges, same number of vertices, but since the AO map encompasses two separate meshes, each composed by several geometries assembled together (i.e. bunker parts + rock parts), before baking it I had to combine the two meshes. I then separated the combined object and combined the resulting geometries again as per their original arrangement (bunker parts with bunker parts and rock parts with rock parts). Possible that when doing it vertices/faces order was scrambled? Does this order actually matter?

Originally Posted by TheDarkWraith

Give me a link to the files you were using that gave the scrambled AO texture coordinates so I can view them in Debugger.

Sure

https://www.mediafire.com/?4pbdduq8grm7bhx

Originally Posted by tonschk

Hello Gap , please do you know where are the GR2 flags files/folders of the ships ?

Main ship models located in the data\Sea folder;
ship parts (guns, sensors, crew, flags, etc.) located in different subfolders of the data\Library path.

Originally Posted by tonschk

I am not able yet to open the UZO GR2 files to check which is the condition of the GR2 shadows settings

Yep, that GR2 file is a special one, not yet supported by GR2 Editor (it misreads some data, and refuses therefore to open the file).

Provided that the problem of the UZO not casting shadows resides in its node properties, a possible workaround fix could be opening temporarily the file in a version of TDW's application which ignores the data misreading, exporting UZO's meshes, importing them in a supported file, setting their cast/receive shadow properties appropriately, and making u-boats' UPC files to point to the new model in place of the stock one.

I couldn't find any older version of GR2 Editor able to open that file unfortunately. Of course we could create an UZO model from scratch, but this is too much work for a fix that we aren't even sure that it is going to work (the only way to make it sure would be checking original model's node properties).

Originally Posted by tonschk

...I will try to open the flags GR2 files to enable the flags dynamic shadows and self shadowing, thank you for your help

Unfortunately you can't: the flag models used in SH5 are dat objects, and they are known for casting no shadows in game (this is one of the limitations of imported dat ships).

Unless someone finds a way to tweak the game shaders so that dat objects can cast/receive shadows, or deciphers GR2 animations enabling us to create GR2 flags, ship flags will never have shadows

[gap]

Originally Posted by Stormfly

...and what about active sonars limited down angle (Sonar Shadow), not shure if that is moddeled allready, the problem they had was, if distance was close enough and sub was deep enough, the active contact boke up...

Hi Stormy, do you mean something like this?



It is: a submarine close enough to her pursuer, or directly below it, would be outside the reach of its sound beam(s) or, in other words, Britsh WWII sonars could only detect tragets well in front of their sonar emitter. This is already modelle and/or achievable without need of a patch, through sensors' elevation and bearing parameters

Originally Posted by urfisch

i followed this project a few years ago. so, im out of info on it. short question: is it now possible to add new units? as far as i can see, its only possible to edit units, but not to import new ones in sh5. right?

Not exactly. We can already import in game brand new GR2 units. We cannot create GR2 files from scratch, but we can clone the stock ones by renaming their bones, and we can import any 3d model in them.

The one substantial limitation still standing, is the number of separate meshes we can have (we can replace the meshes of the GR2 file used as template, but we cannot create new ones). This forces us to plan our unit carefully, and to choose accordingly the GR2 template where we want to import the unit (it should have a number of meshes equal or bigger that the number of separate parts that we want our unit to be composed of).

But, if you ask me, the main obstacle to the creation of new GR2 ships and planes by SH5 quality stabdards, is the time required to do it and the lack of man power.

[tonschk]

Thank you very much for the help Gap, actually the UZO cast shadows (and self shadowing too) without problems, but when I tweak the .....data/Cfg/Shadows ...settings, the dynamic shadows of some items like the UZO disappear , therefore in my opinion the shadows settings that order when to start to cast shadows are not all synchronized and some shadows start to cast before and other shadows start to cast after (probably at determined resolution), the problem I have is to find where are those mysterious shadows settings and make/order all shadows work synchronised simultaneously together independently (or accordingly) to a specific resolution

Stock shadows settings cast UZO shadows and UZO self shadowing too




Modified shadows settings (sharper shadows), the UZO don't cast shadows anymore nor UZO self shadowing

[gap]

Originally Posted by tonschk

Thank you very much for the help Gap, actually the UZO cast shadows (and self shadowing too) without problems, but when I tweak the .....data/Cfg/Shadows ...settings, the dynamic shadows of some items like the UZO disappear

Nice screenies Enrico

the receive/cast shadow bone properties have no the complex settings that you are looking for: to the best of my knwledge they are boolean variables (they are either on or off). But have you noticed that the UZO pedestal in your second screenshot still has internal shadows and it casts shadows on the conning tower? Its mesh is located in the same model as the rest of the UZO. The difference among the two parts is that the pedestal is linked on the model's main bone, and the binoculars are linked to a child bone of the main bone. Either this difference, or a difference in the extended data properties of their respective bones, meshes or materials could be the cause of their different shadowing in game

[TheDarkWraith]

Originally Posted by gap

To the best of my knowledge, the diffuse and the AO meshes are indentical but in their UV coordinates: same number of polygons, same number of edges, same number of vertices, but since the AO map encompasses two separate meshes, each composed by several geometries assembled together (i.e. bunker parts + rock parts), before baking it I had to combine the two meshes. I then separated the combined object and combined the resulting geometries again as per their original arrangement (bunker parts with bunker parts and rock parts with rock parts). Possible that when doing it vertices/faces order was scrambled? Does this order actually matter?

Yes the order actually matters. Here's why:

Bunker.obj - small excerpt from beginning of face definitions:
f 1/21/1 33/20/33 32/46/32
f 1/582/1 73/566/73 33/581/33
f 1/273/1 416/274/416 2/230/2
f 2/564/2 82/543/82 83/565/83
f 2/564/2 83/565/83 1/582/1

Bunker_AO.obj - small excerpt from beginning of face definitions:
f 1/418/1 3/481/3 2/419/2
f 2/229/2 6/227/6 1/230/1
f 3/481/3 8/488/8 4/480/4
f 4/480/4 2/419/2 3/481/3
f 5/438/5 2/445/2 8/402/8

In Bunker.obj the indices would look like so:
1, 33, 32, 1, 73, 33, 1, 416, 2, 2, 82, 83, 2, 83, 1

In Bunker_AO.obj the indices would look like so:
1, 3, 2, 2, 6, 1, 3, 8, 4, 4, 2, 3, 5, 2, 8

Everytime there is a duplicate indice in the non-AO indice list the app will create a clone of that vertice to satisfy Granny's needs. If we just look at indice 1 it will need to be duplicated 3 times.

After the non-AO indice list is adjusted to account for duplicate indices the vertice list is generated from the indice list. The app then maps the face definitions from the AO to the non-AO. I think you can see why your AO's are scrambled now.

The problem will get worse the more the objects are optimized. If you had a straight 1:1 export then there would be no problem because the app wouldn't have to clone any vertices.

If the face definitions in the AO do not match the face definitions in the non-AO (except for the UVs) you will get scrambled AOs. You're talking one huge mapping nightmare trying to figure out how to match different face definitions, especially ones that have been optimized.

[gap]

Okay I see, thank you TDW

If I don't combine/separate/reassemble AO meshes but only remap their UV, their face sorting shouldn't change. Is that correct? The one problem would be the optimal sorting of UV coordinates within the UV space.

By combining multiple meshes, I can remap their UV map at once, letting Wings 3d to automatically scale/arrange UV coordinates so that they fit the UV square.

If, on the other hand, I UV map each mesh separately, the generated maps would overlap each other, and I would need to arrange them manually before baking the AO texture again (unfortunately Wings3d has not a "re-arrange UV map" feature, I wonder if any other free 3d application got something similar).

Maybe I have a better idea though: I could clone the current AO meshes, and UV map them again for diffuse channel usage. Their UV map is much simpler, and re-arranging it wouldn't take too long.

What do you think, it can work?

[TheDarkWraith]

Originally Posted by gap

What do you think, it can work?

Try it and see.

What you are striving for is the non-AO and the AO .obj files to be identical in regards to vertices defined (v), normals defined (vn), and face definitions defined (f) - except the UVs for the face definitions in the AO .obj file will be different.

When the app maps AO to non-AO the only thing it's 'bringing over' are the UVs defined in the AO .obj file. Thus it's critical the above matches between the two files.

[Stormfly]

Originally Posted by gap

Hi Stormy, do you mean something like this?

It is: a submarine close enough to her pursuer, or directly below it, would be outside the reach of its sound beam(s) or, in other words, Britsh WWII sonars could only detect tragets well in front of their sonar emitter. This is already modelle and/or achievable without need of a patch, through sensors' elevation and bearing parameters

yep that`s what iam talking about, so is the 65 deg. limitation part of the sensor sim, or allready modded ?

[TheDarkWraith]

Originally Posted by Stormfly

yep that`s what iam talking about, so is the 65 deg. limitation part of the sensor sim, or allready modded ?

It's already modeled in the sensor in the game. You can adjust those parameters to whatever you want using Goblin

[tonschk]

Thank you for the help , yes good idea , may be a way to sort out this awfully different shadowing behaviour is to tweak and change "ALL" the model's links to either the main bone or to the child bone, in this case (I guess) I need to change the links of the UZO binoculars to the main bone like they are already now for the UZO pedestal

Can you tell me please how you know that "the pedestal is linked on the model's main bone, and the binoculars are linked to a child bone of the main bone"?

Originally Posted by gap

the receive/cast shadow bone properties have no the complex settings that you are looking for: to the best of my knwledge they are boolean variables (they are either on or off). But have you noticed that the UZO pedestal in your second screenshot still has internal shadows and it casts shadows on the conning tower? Its mesh is located in the same model as the rest of the UZO. The difference among the two parts is that the pedestal is linked on the model's main bone, and the binoculars are linked to a child bone of the main bone. Either this difference, or a difference in the extended data properties of their respective bones, meshes or materials could be the cause of their different shadowing in game

[gap]

Originally Posted by Stormfly

yep that`s what iam talking about, so is the 65 deg. limitation part of the sensor sim, or allready modded ?

Originally Posted by TheDarkWraith

It's already modeled in the sensor in the game. You can adjust those parameters to whatever you want using Goblin

A bit off topic here, but if you can read Spanish I have found this interesting link about sonars (ranges, bearings, elevations, resolutions, disturbing factors, etc.):
http://simulaciondecombate.forumfree.it/?t=60108726

Let me know if you need for help with its translation

By the way of sonars: TDW, do you have any clue if termoclines are actually applied in game? and have you looked if multiple sensors of the same type can be used on the same unit?