GhostView

[Ronin]

Okay, guys.  I've gotten to the point where GhostView is pretty stable.  It's just a novelty for other people even though it's a tool for me.  The program is in no way finished.  But it will allow you to look at Ghost Recon and Sum of All Fears maps.  I was going to try it on Rogue Spear maps but I can't find my copy of it.  I may have to hit the bargain bins for a new copy.  Or I may just download the demo if I can find it.

I added mipmaps to the textures a little while ago and I simplified the camera controls a bit.  Here's what Red Square looks like from ground level with the Kremlin at your back:



I'm releasing the binary for the program so you guys can play around with it if you want.  It doesn't matter where you put the program but I'd put it into your Ghost Recon game directory.  When you run it, just use File->Open to open a map.  It won't open more than one map at a time.  But the program starts up in like two seconds so that's not a problem and I've got bigger fish to fry right now. Have fun!
 
If someone wants to try Rogue Spear maps, please let me know if it works on them. I doubt very much that it will. One word of warning.  You may have to kill the program with task manager if it finds textures it doesn't understand.  You'll know it if it happens. :moon:  

[Zazoo]

Cool.

BTW, the RS maps are similar, but have considerable differences in their structure.
~Mike

[Dr.Jeckyl]

upload it as an attachment also just in case.

[Ronin]

Cool.

BTW, the RS maps are similar, but have considerable differences in their structure.
~Mike

Yeah, I looked at the RS maps and they are definitely different (I just loaded the RS demo).  Map version 2.5 (I think).  The material entries have the texture listed as part of the material like what you were talking about.  I'm wondering if that's the map version that the plugins RSE released generate.

It should be possible to modify the GhostView program (and my map classes) to handle those older maps.   I guess any plugins created for other editors would also have to generate those older maps so that RS could run them.

Anyway, Mike, I'd like to send you the source code for the GhostView program just so that it can't be lost so easily.  I've shot myself in the foot a couple of times, before.  I still kick myself for losing the source to the RSB tool I wrote.  I'm working on a new one.  I'm amazed how many different types of RSB files there are.

So, Mike, can I send you an email with the source as a zipped attachment?  I really don't want that code to get out into the wild right now because of what might be done with it.  Although, other people could do the same thing we did.  Otherwise, I'd post it here on the forum. I already have it on offsite storage but I don't want that stuff lost.

[Ronin]

upload it as an attachment also just in case.

It took me a few minutes to figure it out, but I have attached it to the post.  It's about 77K, I think.  I should probably put versions on it but I'm not bothered with it.

[Zazoo]

So, Mike, can I send you an email with the source as a zipped attachment?  I really don't want that code to get out into the wild right now because of what might be done with it.  Although, other people could do the same thing we did.  Otherwise, I'd post it here on the forum. I already have it on offsite storage but I don't want that stuff lost.

Sure!
PM me.

~Mike

[Dr.Jeckyl]

It took me a few minutes to figure it out, but I have attached it to the post.  It's about 77K, I think.  I should probably put versions on it but I'm not bothered with it.

i killed your link so you don't get leeches.

[Ronin]

i killed your link so you don't get leeches.

Thanks.  I'll probably get them from the image links anyway, won't I?

[Dr.Jeckyl]

not if you change those to attachments. :wink:
if you don't mind you're more than welcome to put it back up.

[Ronin]

I've been looking into some of the other game data files.  And I find that the POB and QOB files have much in common with the data in the map files.

I'm thinking that I should set my sights a little lower at first when trying to create and exporter for Maya to OGR.  What I mean is to create first an exporter for POBs (skyboxes and other items) which are one of the simpler geometry files.  Then move up to QOB files which are used for things like weapons.  Then move up to entire Maps.

What I learn doing the POBs then the QOBs will help a lot, I think, when creating a Map exporter (and the necessary editing mods for Maya).

Part of being able to do any of these things is create code that will allow Maya to use RSB files for textures so that no conversion is necessary to use the existing OGR texture files.

I've noticed that some of the POBs, QOBs and MAPs refer to textures that are TGAs and BMPs instead of RSBs.  I don't know why this is unless there was a bug in their map exporter plugin that didn't change the extension to RSB.  When I look in the directory where the file should be, they are always RSB files.  That's something that I'll have to be conscious of when building the exporters.

There's a learning curve involved with writing exporters.  The one for MilkShape wasn't too bad since the SDK for it is fairly simple (as is MilkShape).  But MEL and Maya are pretty sophisticated programs.  Fortunately, I've had the offer of advice when I get that far.  So the start there shouldn't be too rocky. (thanks, Wolfsong! )

I started a new project this evening called POBView which will be used to completely understand POBs.  I'll also be creating QOBView for the same purpose (understanding QOBs).  I have looked at them enough to have a pretty good understanding of them already.  I should have a POB viewer working in a day or so.  The QOB viewer will probably take a few days after that.  I don't know if anyone has ever put up a viewer for either of those before.  So they might have a practical use (ability to look at objects without having to have Max or load them up in OGR).

I'm curious, what do the skinners use for skinning?  Is there some sort of paint program that allows you to paint in 3D for skins?  How do you view your skins once they are done?

[Wolfsong]

Skinning is done in the 3D program of choise (today 3DS Max as it can export) and Photoshop as it has the RSB plugin.

But there are other programs you can use if you want to paint in "3D". DeepPaint being the most common one of those. Other, so called 2½D programs, used for creating normal maps also has limited possibility to paint textures in them.

Got some more news. Maya 8.5 has apparently implemented Python at the same level as MEL. Haven't tried it yet so don't know how capable it is in Maya at this time.

[Ronin]

I assume that DeepPaint uses the 3DS files to paint on?  I don't suppose it will let you paint directly on the RSB files associated with a QOB?

Also, any idea when (or if) Maya PLE will be move up to 8.5?  Or is it always a version or two behind Maya Complete? (I have no idea)

I figured out a fairly weird bug in GhostView this evening because I didn't want to transfer that bug into POBView (which I'm considering just merging with GhostView since they have numerous classes in common).

It had to do with something as innocuous as the loaded texture counter.  I wasn't resetting it.  Consequently, it tried to access memory that wasn't allocated when loading a new map and _blam_, down went the proggy.  I found it quite by accident after looking at the problem for a couple of hours.  It's amazing to me (sometimes) how often I find the resolution to bugs after I stop looking for them.

I'm pretty sure this bug was why the MFC version was losing the textures on subsequent file loads.  I don't understand why it didn't just "blow up" (crash) in that version but the memory configuration was quite different and it was quite likely it was writing into memory allocated for the program that wasn't being used.  It may not have been document/view architecture anyway. :roll:

I may poke around with that later. But I may not.  It may just be a waste of time since I've gotten GhostView working so well.

[Wolfsong]

I assume that DeepPaint uses the 3DS files to paint on?  I don't suppose it will let you paint directly on the RSB files associated with a QOB?

Also, any idea when (or if) Maya PLE will be move up to 8.5?  Or is it always a version or two behind Maya Complete? (I have no idea)

DeepPaint uses the model, any big format (Max, Maya, Lightwave, XSI, and so on) and a designated texture files which you actually do the painting on. Using the UV coordinates you have laid out on the model in the modeling progam, or one made just for unwrapping UV, such as DeepUV. So basically you draw on an image file and only use the model to "shape" the canvas. You also see both the flat texture and the model, which you can rotate around, at the same time.

On Maya PLE, Idon't know how Autodesk handles it. Alias was usually pretty quick in upgrading the PLE to the latest version. It's not much work as it's basically the same files.

[Ronin]

@Wolfsong - Thanks very much.  You are, as ever, very helpful!  


I've decided to merge the POB viewer with the MAP viewer.  That way I don't have so much code duplicated.  It does complicate the MAP viewer a bit.  But not that much.  The program can easily tell what type of file has been loaded and display it accordingly.  The framework for handling those two types of files will set the stage for adding the QOB viewer as well.  I will probably add support for the ENV files, too, if for no other reason that to show the map WITH the skybox.

The SHT files are only useful to the game engine and are created on the fly by the engine if they dont' exist for each map when the map is loaded for the first time.

Using the same Object class for the maps and the POBs means that I have to get that working well enough that any types that are not fully understood are just skipped so that the object parsing doesn't stall and the POB objects can be displayed.

I'll eventually all the types handled.  I made a little headway with the map objects when I was looking at the type 2F (47) objects in the POB files.  I figured out that it's a heirarchy with "child" objects.  Some have other data but I'll figure out what to do with that eventually.

[Ronin]

Work continues on GhostView.  I've got the type 47 objects mostly figured out.  The link processing is mostly working but it still has glitches.

I still have to get the type 50 and 52 objects working.  I suspect that the type 50s have some animations in them (doors, etc.).

I'm going to have to figure out a way to get the texture seach working.  The textures for the maps are in the map directory.  But the POB files have some of the textures in the textures directory and some in the map directories.  The house.pob file has some textures in "textures" and some in the "mapm14_mountain" directory.  I may have to use the first few characters as a "hint" for that.  Some of the textures also look a bit weird.  Possibly because of missing textures, though.  The skybox POBs are working, though.  I still need to be able to parse the env files.  That will take some XML parsing.

So far, I think I've created about 20 data classes for this program.  Not all are first level data structures.  Some (about half) are child objects.

[Ronin]

I figured out the glitch on parsing the map objects.  The type 46 (0x2E) objects don't have any model text.  I was trying to parse out possible model text on all of them.  But the type 46 doesn't have any, ever.

So, now, with that parsed out, I can see that the POB objects are drawn entirely from the ObjectList. The maps may be, too but I haven't finished parsing out the type 50 and 52 objects, yet.

The linkage between the objectlist and the geometry list is in the name of the objects and the name attached to the geometry.  Even though there is only one entry for "" in the object list, there are about 10 entries in the geometry list.  By drawing all the "" entries from the geometry list when you encounter the "" entry in the objectlist, you draw the entire house.  The same is true for all the other objects.

In the house.pob file, there is a "house" entry as well as entries for all the pieces of the truck (the truck itself and the wheels).  Each type 47 entry has at least one child (a type 46).  The type 47s can also be chained together in a hierarchy with a new transformation matrix and location for each level which would be concatenated to the top level object like bones in an IK model.

I'm going to convert the drawing routine for the POBs today to process through the objects and draw those rather than just through the geometry.  By using the matrices and locations from the objects, the truck and it's wheels should show up in the correct position relative to the house.

This is what I've been working toward with the objectlist from the start.  At last I've got one type of object pegged.  That should aid considerably in getting the others handled, too.  The heirarchy processing should be the same for all the object types but I can't take that for granted.  Now, I'm going to go back and focus on the other object types.  That block of unknown data in the middle of the type 52 objects just _has_ to be something to do with animations.  I'll look at the names and see if that's true.

[Ronin]

I've got the POB and QOB viewer working mostly.  There are still some versions of the various parts that don't work right.  I found a type 35 in the GeometryList today that I need to handle as well.

I haven't worked out all the texture location issues, yet, either.  When I tried to view the Barrett M82 sniper rifle, it just showed up in "white" with no texture.  I looked for the texture it said was missing and I can't find it.  It's probably there somewhere but not where I told the program to look.  I'm wondering how the game engine deals with that, now.

Here's a view of the M16 with the M203 attached from the OGR QOB file for it:



One note.  I'm used to using fairly large coordinate systems like having character heights in the range of 64 to 72 units.  OGR uses a unit of measure where one unit equals one meter.  This means that the average "normal" male character height would be about 1.75 to 1.85  meters.  A 72 "unit' high person would be about 235 feet tall.  In other words, absolutely ginormous.

Since the coordinate system uses such small units, I've had a little trouble adjusting the program to deal with it when placing the camera at a "reasonable" location.  Since there's no reference point so you know the camera location or the location of the model.  They are sometimes hard to locate by tilting and panning the camera.  I'm probably going to measure the height of the model then try to position the camera at the midpoint altitude then point camera at it initially.

I've had to adjust the movement units so that the camera doesn't move so far with each tap of the controls.  With maps it's not so bad.  But with an item like the M16 which only about a meter long, you can lose it pretty quickly.  The adjustments helped but it's probably still a little too "jumpy".

I've pretty much decided that the first thing I want to try an exporter for is the QOB files.  They are by far the simplest. Just a material list and a geometry list with a few helper points.  If I can get that working, then I can progress to exporting POBs which have an object list as well.  Then the BIG jump to exporting MAPs.

I've got the SDK for Maya, now and I'll be looking over the docs in the next few days.  I'll try just exporting a _very_ simple model to start with.  Probably just a box.

I worked on the ObjectList some more this evening, too.  That type 52 object  just makes no sense.  I can't tell how the program knows how many of what there is in that data.  Each one is just a different size with no indication of how it will be organized.  Some have 5 sets of 2 vertices followed an integer.   Some have 8 sets.   Some are followed by a matrix.  Some are followed by several type 2 entries with no indicator of how many there are.  The sets of double vertices and integers are interspersed between several type 2 objects with no apparent indication of why they are there or how to tell that that's what they are.  Each time I look at it it makes a _little_ more sense but only because I see some patterns.  But I haven't found a key to it, yet.  There HAS to be one otherwise you couldn't write a program to read it.  But I haven't found it yet.  It's a big frustrating to spend this much time on something and still be stymied by it.  But I'm not going to let it beat me.  That strange data doesn't appear to animation data.  Not unless the trees are animated... :roll:  

Anyway, /me goes back to work on it.  As Mike would say,  "Weeee!".

[Zazoo]

That strange data doesn't appear to animation data.  Not unless the trees are animated... :roll:

The trees in GR are animated.

I have no idea if that's what the data is for though.
~Mike

[Ronin]

The trees in GR are animated.

I have no idea if that's what the data is for though.
~Mike

For a second, I thought you were yanking my chain.  But the I remembered that the trees do seem to sway a bit in game.  So I guess it IS animation data.  I can't think what else it could be for.

That would mean that there would have to key-frame data, locations and timing.  Some of the floating point data is the max and min values for a IEEE float, though.  I do recall that all animations for OGR have to be setup as linear.  So that helps some.  I just wish I knew the key for figuring out when that data would appear and how much of there would be.  Each time it appears there's a different amount of it.  Usually only the first and last entries appear to have any valid data in them. Otherwise the floats are min/max and the integer following is zero.

@Mike, I need to send you a source update for GhostView.  I've made a LOT of changes since the last one.  I'll use the same name and location as last time.  Let me know when you've snagged it.  PM me if you can't recall where to look.

[Zazoo]

For a second, I thought you were yanking my chain.  But the I remembered that the trees do seem to sway a bit in game.  So I guess it IS animation data.  I can't think what else it could be for.

If it helps any, when making maps in MAX there was no way to specify animation data for trees (not like with doors and other objects). I always assumed all trees were automatically animated by a generic animation routine within the engine itself. So it may not be animation data...?

@Mike, I need to send you a source update for GhostView.  I've made a LOT of changes since the last one.  I'll use the same name and location as last time.  Let me know when you've snagged it.  PM me if you can't recall where to look.

I got it!

~Mike