GR2 Editor/Viewer/Extractor/Importer

[pedrobas]

Originally Posted by TheDarkWraith

The thing about this app is it rouses the curious to take a look...then after taking a look they try something...that try eventually turns into a mod or a new discovery! Case in point: look what Vanilla figured out with the waypoints and the turning issue.

That what happened to me, i´m still fighting trying to put the Schnorchel_RWR on top of Schnorchel but didn´t yet. I created a new bone as you said called like the original cfg#R02_SCHNORCHEL in the same position that it was the original, then i asociated it with a controler sensordata but didn´t work, i´ll continue playing with it.
Now it´s a joy to move it around with the mouse and keys.
Very well done TDW.

[Vanilla]

Originally Posted by TheDarkWraith

...
The thing about this app is it rouses the curious to take a look...then after taking a look they try something...that try eventually turns into a mod or a new discovery! Case in point: look what Vanilla figured out with the waypoints and the turning issue.

That's right! And unfortunately some of those discoveriers are not pleasant. Has anybody noticed that the boat's rooms are misaligned (floor and ceiling on different level) and have diferent gauge? I've just did with the new version. My my, Ubi doesn't care a thing about quality do they? Alright, joking, it is not a major issue anyway. Or maybe u-boats were constructed this way? Here is a picture from Goblin (to show that it is not TDWs editor bug):

[Gotmilk]

Originally Posted by Vanilla

Has anybody noticed that the boat's rooms are misaligned (floor and ceiling on different level)

Yes i have also seen this. Almost a year back i used Privateers tool to extract models from granny. I took them into 3D application and tried to align them I got the same result that you have on your screenshot.

I did not know what to make of it. Maybe the subs truly were built that way.

But i doubt it.

[TheDarkWraith]

I'm back visiting the picking problem. I added code to visually see the ray that is shot from center of screen to direction you clicked (lime green in color in screenshot). I also added code that renders the bounding box's min position as an orange point and it's max position as a red point. From the screenshot you can see clearly that the ray passes through the boundingbox but DirectX says it doesn't intersect (Geometry.BoxBoundProbe function) All I did was rotate the object 180 degrees and tried to pick it. If I don't rotate the object it works perfectly. Really puzzled by this one

[The General]

Originally Posted by Vanilla

Has anybody noticed that the boat's rooms are misaligned (floor and ceiling on different level) and have different gauge?

Is this responsible for the strange fact that when you first spawn into the game on the Bridge, you have to take a step or two forward to fall onto the correct plane, next to the UZO and level with the other crewmen on deck? Your player's POV is hovering in a slightly elevated position when you start a game. Have you noticed this?

[Vanilla]

Originally Posted by The General

Is this responsible for the strange fact that when you first spawn into the game on the Bridge, you have to take a step or two forward to fall onto the correct plane, next to the UZO and level with the other crewmen on deck? Your player's POV is hovering in a slightly elevated position when you start a game. Have you noticed this?

That's interesting, i didn't know this. As far as I remember player's position is defined by a bone as well. What if we move this bone. Let me see.

[Vanilla]

Originally Posted by Gotmilk

Yes i have also seen this. Almost a year back i used Privateers tool to extract models from granny. I took them into 3D application and tried to align them I got the same result that you have on your screenshot.

I did not know what to make of it. Maybe the subs truly were built that way.

But i doubt it.

My guess it has happened because each room was made as a stand-alone piece, then joined together rather hastily due to forced release, the only thing they made sure is done is that the hatches and doors are aligned.

[Vanilla]

Originally Posted by TheDarkWraith

I'm back visiting the picking problem. I added code to visually see the ray that is shot from center of screen to direction you clicked (lime green in color in screenshot). I also added code that renders the bounding box's min position as an orange point and it's max position as a red point. From the screenshot you can see clearly that the ray passes through the boundingbox but DirectX says it doesn't intersect (Geometry.BoxBoundProbe function) All I did was rotate the object 180 degrees and tried to pick it. If I don't rotate the object it works perfectly. Really puzzled by this one

....

It is sometimes difficult to say whether something intersects something in this kind of set up. I often think that I've moved a bone correctly just to discover when turning the scene that the darn thing is way off. Maybe it is not DirectX but eye-balls Mk.1 that are wrong? Don't take it personal, tho.

[The General]

Originally Posted by Vanilla

That's interesting, i didn't know this. As far as I remember player's position is defined by a bone as well. What if we move this bone. Let me see...

Are you checking this now? Or should I come back tomorrow night?

[TheDarkWraith]

Originally Posted by Vanilla

It is sometimes difficult to say whether something intersects something in this kind of set up. I often think that I've moved a bone correctly just to discover when turning the scene that the darn thing is way off. Maybe it is not DirectX but eye-balls Mk.1 that are wrong? Don't take it personal, tho.

I know it intersects because if I don't yaw the object 180 degrees DirectX says it intersected. Seems like something wrong with that DirectX function call...I'm going to switch to bounding sphere check for the coarse check. Those that pass that test then go to the 'heavy' checker where it checks each triangle in the mesh to see if the ray intersected or not. I do this already when you select individual faces for the texture coordinates

[Vanilla]

Originally Posted by The General

Are you checking this now? Or should I come back tomorrow night?

Oh, I am sorry I didn't know you were waiting... I found the avatars bone on the surface but not tried to move it yet. I will see what happens when I move it tomorrow.

The crew turning-on-spot problem has raised its ugly head again, I just cannot make a char get out of bed and start running without lazily turning on the spot first, looks ugly. I just've spent a lot of time trying to figure out what is going on and still do not understand what the difference between teleporting at the end of a walk and just before the walk.

[TheDarkWraith]

Originally Posted by Vanilla

Oh, I am sorry I didn't know you were waiting... I found the avatars bone on the surface but not tried to move it yet. I will see what happens when I move it tomorrow.

The crew turning-on-spot problem has raised its ugly head again, I just cannot make a char get out of bed and start running without lazily turning on the spot first, looks ugly. I just've spent a lot of time trying to figure out what is going on and still do not understand what the difference between teleporting at the end of a walk and just before the walk.

I've been battling this problem for over 8 months now I have great waypoints for crew running to front of ship on crash dive and they all run and take their positions but they turn going through every compartment. I even have crew running to deck gun when you ask for it to be manned...same problem though they turn at every compartment break

Picking problem solved by using bounding spheres and those that passed the bounding sphere check get sent to the 'heavy' checker - checking each individial triangle for intersection. The only problem with this is you have to click on a part of the object now. Take for instance the cranes on King George V: they have space inbetween the links for the crane. If you manage to click on this empty space it won't be 'picked'. You have to click on some part of it like the links or the body of the crane itself.

[TheDarkWraith]

test version 1.1.70.0 available here: http://www.mediafire.com/?a41hb428jd4267h

Fixed all problems and errors so far except for BIGREG's 3DS Max one on import.

All objects now correctly translate and rotate based on their axis
The XYZ in the bottom right corner now means what axis of freedom/rotation is enabled
Spawned worker threads for the importer and exporter so main thread is not locked up
Exporter and importer now tell you what they're doing so you have some idea what's going on
While importing/exporting the main thread is 'alive' thus you can move camera around view the loaded objects. All other functions are disabled while importing/exporting
Picking problems solved
Fixed logic errors in the cursors and the displaying of axis of freedom/rotation
Under the misc tab you have the ability to show/hide the world and camera axis panels. You also have the ability to show/hide the lock diamond
Fixed bug of where you could possibly rotate/scale/translate an object if it's Flags were 0
Fixed bug of where you could edit position/rotation/scale data for an object even if the Flags didn't allow it

Hopefully I covered everything you all have posted so far except for BIGREG's import problem with 3DS Max file. If I left something out let me know

Next version I'll spawn worker threads when loading the file so that it will load even faster (I can spawn worker threads for each PrimaryVertexData and Mesh so that all these can be loaded in parallel)

Also looking into why the exportation of some meshes (Room_QR1's Objects_01) takes so long. Will try to optimize it.

As you know or don't know the app is currently using my first importer I wrote. I'm going to revise that importer so that it will read in AO items also (since we have the ability to export AO items we need to be able to import them also)

Working on revising the second importer I wrote. The second importer will allow you to change the geometry of the object. You will no longer be locked into the mesh's number of verticies you exported from. You'll be able to replace the object with an entirely new object. The main things I have to do to it is make it compatible with my linked list code and tell it how to interface with Sentinel.

Waypoints: thinking out loud here: app gives you the ability to load a waypoint_edges_x file so that you can visually see the waypoint interconnects. Maybe even let you define the interconnects and have the app write/update the waypoint_edges_x file...

Keep the bug reports coming. Ideas always welcome also

[Vanilla]

Originally Posted by TheDarkWraith

I've been battling this problem for over 8 months now I have great waypoints for crew running to front of ship on crash dive and they all run and take their positions but they turn going through every compartment. I even have crew running to deck gun when you ask for it to be manned...same problem though they turn at every compartment break

Picking problem solved by using bounding spheres and those that passed the bounding sphere check get sent to the 'heavy' checker - checking each individial triangle for intersection. The only problem with this is you have to click on a part of the object now. Take for instance the cranes on King George V: they have space inbetween the links for the crane. If you manage to click on this empty space it won't be 'picked'. You have to click on some part of it like the links or the body of the crane itself.

Well, I can make them running to the front without turning at the end of a compartment using the method I posted. I think (or more precisely I thought) it works this way: when teleporting the char should first adopt receiving waypoint orientation (that is facing away from the blue X-axis) and only then appear on the new waypoint this is why they do not turn when going to the back. By using a special 180 degrees rotated waypoint we can force them not to turn when going forward.
Then, however, I discovered that this is not true when it all happens inside a compartment. For example: I teleport a char out of his bed (or use animation of jumping out) and onto a 'path' waypoint, then I order him to go to the front, or make 'jumping out' a transition animation and use 'Goto' command straight from the bed. Guess what happens, this time he doesn't turn before the teleport as in the cross-compartment case but instead teleports straight away and appears on the initial 'goto' path waypoint always facing towards the stern no matter the orientation of all the waypoints axii or anything else, then he naturally turns to face the next waypoint and only then starts his walk or run. I have no clue why he should always appear on the waypoint facing to the stern it is weird since if you make a character appear on a rotated waypoint he will initially appear on it turned in accordance with the waypoint orientation moreover the animation he does on it will be turned it accordingly, I guess it is the path-finding algorithm that forces him to face towards the stern and it is somehow connected with the parent bone orientation. My other thought was that at the end this all boils down to the particular animation orientation since 'walk' or 'run' animations don't force chars to turn at the end while other animations have 'hard-coded' orientation. But then the animation is played with the waypoint orientation. The only thing that is left is to try to turn the parent bone i.e. to create a duplicating set of waypoints complete with a new parent bone with everything rotated 180 to make the algorithm think that I am teleporting char not inside one compartment but rather between two separate ones, but then I am almost sure this will cause the char to rotate in bed before teleporting.

[TheDarkWraith]

Coded in spawning more background worker threads during the loading process. Room_QR1.GR2 used to take a little over 16 seconds to load on my system. Now it takes just a little over 13 seconds (23% speed increase). Not too shabby Still can't load as fast as GrannyViewer