GhostView

[Ronin]

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

Okay,  I found a new object type today (type 51) that's even more bizarre than the type 50 (or is it 52?)...

The trees are in an object block called "forest" or something like that.  Maybe that's a key to the exporter to jam some animation data in there.  I took a break from that for a while and got the recursive drawing routines done for the POBs.  That code should also work for when I can draw the maps using the object data rather than just straight out of the geometry list.

I had to take a break from working on parsing those objects.  After staring at the hex dump of the data for so long, my eyes were starting not to focus at all.

So I started reading the docs for the Maya SDK.

I got it!

~Mike

Great, I'll take it down, now.

[Zazoo]

Any plans to incorporate the CHR model files?
The data is structured similar to the other 3D files, with an additional chunk of skeletal data tacked on the end (hit-box data and bone entries with indicies into the vertex list IIRC).

~Mike

[Ronin]

Any plans to incorporate the CHR model files?
The data is structured similar to the other 3D files, with an additional chunk of skeletal data tacked on the end (hit-box data and bone entries with indicies into the vertex list IIRC).

~Mike

You must be a mind reader. I looked at the CHR files a bit yesterday.  The geometry stuff is indeed similar.  There's a lot of IK bone stuff following it.  That will take a little time to figure out.  What surprised me is that in the heirarchy the same bone may be in there a dozen times.  I don't know why, yet.  I figured it might be for animation purposes.

Generally an IK model really just gives the bones as a hierarchy with translations and transformations for each bone relative to its parent with some rotation information (rotation angles and limits).  More sophisticated IK models also give values for resistance to rotation at each joint.

These appear to be well articulated models.  They even have three part spines.

I'm not going to tackle CHR files for a while.  I really need to get the ObjectList data fully figured out.  Or, at least, be able to parse it completely without it blowing up on every other model.  I need to start a "book" on the ObjectList with each piece of data documented by type and version and variations between the versions and types noted.   Then I can come up with an algorithm to parse them successfully.  I'm just going to have to get more organized about it than I have been up to now.

[Zazoo]

I built and released a CHR tool that worked in conjunction with 3D Studio and the official exporter (QOB).
If I can find the tool I'll upload it again, I'm pretty sure there are still copies of it floating around the internet.

It was a bit cumbersome to use, but it worked, producing useable (in-game) CHR models that animated correctly (it didn't do anything with the skeletal data, only the skin data):

This is the format I discovered for the SKIN part of the CHR files:

Code:

Lng - String Length
Str - "Skin" & ASCII(0)
Lng - ? (always 1? # of skins?)
Lng - String Length
Str - Skin name
Lng - Number of Vertices in model (from Vertex list)
---------{
     Lng - Vertex Index
     Lng - Number of bones assigned to vertex
     --------{
           Lng - String Length
           Str - Bone Name
           Float - Weight of influence
     }-------- (repeat # of bones)
}---------(repeat # of vertices)

Basically, the skin has an entry for every vertex in the model. For each vertex there is a list of the "bones" (from the previous SpineRoot entries) that vertex belongs to and the "influence" of those bones on the vertex is given (from 0 to 1 IIRC). For example, a vertex that is right in the center of the forearm will only be assigned to a single bone (forearm), and the vertex recieves all animation data (transforamtions) from that bone alone. However, bones along joints (e.g. a vertex on the elbow of a character) is usually given multiple bone assignements, with relative weights for each bone specified. When the game transforms these vertices while animating the character it uses a weighted average of the transformations for each bone assigned to the vertex. At least this is how it appeared to work when I built my tool. My tool did everything I expected, and models in-game worked according to how I understood the bone system to work. So I'm pretty sure this is how it is done.

Prior to the Skin data is a SpineRoot object which defines the skeleton's structure and the hit-box (I think) data for the skeleton itself. This I did not decode. Instead I just grabbed the entire section for a few models (small, medium, large characters) and used these as representative skeletons for the models made with my tool (users had the option to pick a "small", "medium", or "large" frame, which was just a copy of the skeletal data from a representative game CHR). The differences between small, medium, and large models was negligible. Swaping the skeletal data for a "small" framed model with that of "large" framed model shows very little noticable difference in-game (you'd have to compare the animating models side-by-side to figure it out). As such, all you could do with my tool was attach the model to the skeleton (hang). I never got arround to working with the skeletal data (Piggyson of RSE released an offical CHR tool which pretty much killed my motivation to continue that project :tongue:). It would be interesting to see if the skeletal system is flexible enough to create various huminoid and non-huminoid shapes.

~Mike

[Ronin]

Hey! Thanks for the info, Mike.  That will definitely come in handy when I get to the point where I can do the CHR stuff.

Handling the skeleton the way you did is probably not a bad idea.  But I would like to see (as you suggested) if the CHRs can be used for other character files (horses or cows maybe? -- farms with LIVESTOCK, imagine that! )

I didn't spend more than about 10 minutes looking at the CHR files, before.

BTW, did you get the classes you wanted at school?  I know it's early, yet.  But how's it going?

[Zazoo]

Yeah, I got my classes. I'm only taking three this semester because I transfer in the Fall.
Still sort of nervous about how the job market will be for an entry level M.S. Electrical Engineer in his early 30's... Everyone keeps telling me I'm "still young", and I know I am. But I'm still going to be competing with people around 10 years younger than me. I guess I've got a little while before I really have to worry about that part of it. :tongue:

~Mike

[Ronin]

Yeah, I got my classes. I'm only taking three this semester because I transfer in the Fall.
Still sort of nervous about how the job market will be for an entry level M.S. Electrical Engineer in his early 30's... Everyone keeps telling me I'm "still young", and I know I am. But I'm still going to be competing with people around 10 years younger than me. I guess I've got a little while before I really have to worry about that part of it. :tongue:

~Mike

Try to think of it this way.

You would be more desirable as a hire because you are married and have been for several years.  Companies generally want to hire people who are stable.  Marriage is usually an instant stabilizer for males.

You are more mature than most "kids" just getting out of college.  And you have a resume that, while possibly not directed to your new field, shows that you can hold down a job.  And you are still young enough that you aren't going to retire in a few years nor are you likely to be a drain on their group health plan.

You are in the prime of your life.  Use that as a selling point in your cover letters.  I think you will be just fine.  I'm pretty sure if I needed an EE, I'd hire you.

[Zazoo]

I'm pretty sure if I needed an EE, I'd hire you.

So, does that mean I can come work for you when I get out of college?
Sweet...

:tongue:

~Mike

[Ronin]

So, does that mean I can come work for you when I get out of college?
Sweet...

:tongue:

~Mike

Umm. Yeah!  I'll have to either start my another business or get a job first, though... :tongue:  

[Ronin]

I added code to search the map directories for the proper one when I encounter a texture that starts MXX_ where XX is 01 through 99.  This seems to be working for all the textures.

One odd thing.  I've noticed that both of the house POBs seem to have trucks INSIDE the houses.  I may not be handling a translation someplace.  It's odd that the truck should appear inside the house.  On house2.pob it's embedded in the house walls.  In house.pob, it's just inside the house.

I'm working on object type 51 tonight.  When I get that done, I'll go back to the other one that's giving me fits.  The others seem to be working okay, now, although I haven't figured out what all the data is for.

Here's a picture of House2.pob with the truck embedded in the house.


The "gaspump.pob" file has the type 51 objects in it.  It appears to have damage textures and possibly some animation.  This is from the "village" mission.  I don't recall the gas pumps blowing up at all.  They might, but I don't remember that.  I'll have to go play the mission just to see...

[Ignacio]

I don't know if this has been reported, but I tried using your GHOSTVIEWER in R6 Rogue Spear and it does not work.

[Ronin]

I don't know if this has been reported, but I tried using your GHOSTVIEWER in R6 Rogue Spear and it does not work.

Yup, the maps are a different format in RS. :yup:

[Ronin]

Update: (sorry, no pictures...)

I wrote a simple XML parser to handle the ENV and other XML style files in the game.  Now I can open an ENV file and it will (eventually) open the map and the skybox that goes with it.  It will allow you to see what the map will look like "in game" with the skybox.

@Mike, the lights are in the map file because they are used to dynamically light the "actors" in the game when that flag is set on them.  I may have mentioned this before but you how it is when you get old... :roll:

The objects are coming along slowy.  I thought I had a breakthrough on one type but that turned out to just be for that map.  So I had to roll that back and I'm still working on figuring all that out.

The Maya SDK is very interesting.  You can do a LOT of things with that SDK.  Between that and MEL, there is very little you can't add to the program.  I'm still looking at how to attach new data to the existing data.  That will be necessary to set flags for things.  I'm thinking I can embed the planning level/room data into a new working map file format.  This will remove the need for a separate planning level file.  This new format would be just to store the map until a new GR/SOAF map is exported.

I'm experimenting with the SDK, now some.  My first attempt will be to try to export a very simple QOB.  One thing I'm not sure about is whether Maya and GR use the same "handedness" (right handed versus left handed rendering).  I may also have to translate between Z up and Y up.

I just hope the default values for the unknowns will work.  I'll find out soon enough I suppose.

[Zazoo]

@Mike, the lights are in the map file because they are used to dynamically light the "actors" in the game when that flag is set on them.  I may have mentioned this before but you how it is when you get old... :roll:

Yeah, I mentioned in the previous thread that it was my mistake assuming the lighting data wasn't in the MAP file. I was remembering the lighting list being empty, which it is --when you first export a map from 3D Studio. The lighting tool fills the list, but I was mistakenly remembering the lighting solution file (DMP) as the lighting data used by the game. The DMP file is only used by the lighting tool and does nothing in-game.

Sorry if my mistake made things harder!
~Mike

[Ronin]

Yeah, I mentioned in the previous thread that it was my mistake assuming the lighting data wasn't in the MAP file. I was remembering the lighting list being empty, which it is --when you first export a map from 3D Studio. The lighting tool fills the list, but I was mistakenly remembering the lighting solution file (DMP) as the lighting data used by the game. The DMP file is only used by the lighting tool and does nothing in-game.

Sorry if my mistake made things harder!
~Mike

No problem, Mike.  I found that the DMP files are there in the Rogue Spear maps.  Maybe you also were thinking some about those.  I have been looking at those a bit over the last few days trying to see how the different versions of the data are different.

It didn't screw me up at all.  It did confuse me a little.  But that's pretty much my natural state these days... :wink:

Anyway, you know how it is with us old folks.  We keep telling the same stories because we forgot we told them already...