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

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:

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:

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:

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:

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

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

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:

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:

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

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

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