Jump to content

Feedback Needed: GHOUL3 format


Recommended Posts

I am considering working on a new GHOUL3 format that improves substantially upon the previous GHOUL2 format and makes the game more moddable. This is more of a wishlist than something I can guarantee will happen (at the moment).

 

Model Features (GLM3)

  • Wrinkle maps (?)

 

Animation Features (GLA3)

  • Removed hardcoding of animation names; they can be user defined and scripted in as needed
  • GLAs can optionally be split into several GLAs bound by a meta file, so they can be loaded as needed by the game. Much faster loadtime and less wasteful memory usage.
  • Resplit animations into four additive regions, instead of three; adding an additional lipsync channel instead of these being handled haphazardly by FACE animations
  • 16-bit (FP16) quaternions and rotations, upgrade from FP8 for more precise motion OR 32-bit (FP32) quaternions and rotations
  • Adaptive delta compression instead of a flat list of quaternions/transformation for smaller filesize and memory footprint
  • RLE encoding? for smaller filesize
Smoo likes this
Link to comment

I would consider researching what other games are doing for storing animation data. MD5 animations do some kind of storing of deltas but perhaps things have improved even further since then. Rich might know more if he's happy to discuss.

Link to comment

I would consider researching what other games are doing for storing animation data. MD5 animations do some kind of storing of deltas but perhaps things have improved even further since then. Rich might know more if he's happy to discuss.

The adaptive delta compression was Rich's idea.

Link to comment

allow multiple GLA loading. I'd like to see individual GLAs per animation, so animations are modular. We can then see multiple animation mods be used together.

 

remove hardcoded bone axis orientation. skeletons with non-matching bone axis orientations to what the code expects will have borked aiming. An External file would give greater control.

 

Scale animation. Would really cool to have this. Animations that would take several bones to pull off could only take 1. Example, enlarging a sphere.

 

Not sure if an exporter/compiler thing or not, but allow position only animation. Right now in order to have position animation processed, there must also be rotation animation.

Link to comment

remove hardcoded bone axis orientation. skeletons with non-matching bone axis orientations to what the code expects will have borked aiming. An External file would give greater control

This should definitely be something that the exporter does. The game should have a single known orientation, and if the file being exported doesn't match that then the exporter needs to reorient everything. I say this because it makes more sense (and is more optimal) to offload an operation, which will do exactly the same thing every time the animation is loaded, to the exporter where it can be done once.

Link to comment

wrinkle maps should be handled by the Shader system-- because they are blended with the base normal map.

 

@@eezstreet - since neither you nor @@RichW nor any other coder wanted to update Carcass for this (from our Discord discussion yesterday)... please tell us your pipeline for going from: 3ds Max, Maya, Softimage, Blender, etc. to a new Ghoul3 format.

Link to comment

MD5 animations could probably smoothed out simply by just doubling the frame count and frame speed so that a 10 sec animation plays 10 sec after re-scaling but with more interpolation you get a smoother playback. Similar to rendering at a higher frame rate.

 

Making 2 skeletons with similar proportions but different local transforms would be difficult, would require math to be done by the game engine constantly but I'm no coder so I'm not sure. This is how it's done when using scripted expressions in Softimage using 1 transform value to drive another objects totally different transform value like for instance translating a cube along the local +Y to rotate a sphere in local -X. Seems like the game engine constantly doing all that math for 60 or so bones every frame would slow things down.

Link to comment

I never would've seen this if I hadn't replied to that PM to correct Gummelt and seen the notification. So apologies in advance that I will probably forget to ever come back here and check this thread. Feel free to poke me on #ja if there are questions.

 

My suggestions for format improvements would be:

 

  • Use FP16 instead of the poorly-range-quantized U16. It will work out more handily for both rotations and translations. I recommend pre-filtering IEEE special-cases in the tool, which will make conversion to FP32 actually faster than the scale & bias the engine does with current data.
  • Probably a good idea to just have a format option/header flag to allow F32. Slightly more implementation cruft, but it would also be possible to allow only specific frames/sequences within the format to use FP32.
  • Adaptive delta compression is an option, but honestly, is probably overkill. It would only be really appropriate if you aimed to shrink the data even smaller than what shipped with JK2/JA 15+ years ago.

I changed Unity for a commercial title recently to use FP16 instead of FP32 for virtually all of their Hermite coefficients, doing auto-analysis of the error in FP32->FP16 conversion to determine per-sequence which anim curves should be left as FP32. It applied to all forms of animation data (translation, rotation, scale, and other custom splines) and cut around around 70MB off of the game's memory footprint. Absolutely no one noticed when the change went in. So something like this will probably work out just fine without the need to really get any fancier.

 

One other thing: I don't see any particular advantage to RLE encoding or other storage-level compression, as there's always zlib/pk3 for that. Most compression would also be of limited utility if you did go with a very aggressive adaptive delta scheme. (storing n-bit streams for each joint on a per-sequence basis would, however, have somewhat of a downside of needing to "decompress" up to the frame being requested if you need to transform for a frame within a sequence out of order) Probably best to keep it simple here, just switching to FP16 and utilizing the full FP16 range will be a massive win in quality already, with no cost in storage. Giving flexibility to choose FP32 for rotations and/or translations on a per-frame, per-sequence, and/or per-file basis on top of that should be all anyone really needs in this realm. Unless you wanted to develop a brand new state machine driven animation system or something, but that would also necessitate reworking massive swaths of game code and wouldn't be a nice drop-in replacement anymore.

 

Anyway, happy to shove a commandline option into Noesis to export GLA in this format. Let me know how it shakes out.

DT85, Archangel35757 and Circa like this
Link to comment

@@DT85 - per the PM thread request, would you send Rich your jittering 1st person view model animation in FBX format (which you said also jittered when using both Carcass 2.2 and Noesis GLA conversion tools). Also send him the resulting GLA of it... since you already have all the file assets in all the formats. Thanks.

 

Edit: I think you can attach the files to the PM thread.

Link to comment

I'll send the wind animation source and the JKA gla as this is the best example of the jitter. Yes it's before the precision was fixed in 2.2, but 2.2 will still give you jitter if the animation has very fine movement.

Link to comment

I'll send the wind animation source and the JKA gla as this is the best example of the jitter. Yes it's before the precision was fixed in 2.2, but 2.2 will still give you jitter if the animation has very fine movement.

That's why I would like him to see your 1st person view model idle animation GLA (and its FBX version) ...because it shows the jitter (even if reduced) still present using Carcass 2.2. Thanks. :winkthumb:

Link to comment

I already fixed it by altering the animation. Had no reason then to keep a backup of it, so I didn't.

 

Ran the imported both_wind through noesis to make a gla and there's no jitter. No point uploading that. You should create a test animation with one of your models, I don't really have any time to spend on this atm.

Link to comment

I already fixed it by altering the animation. Had no reason then to keep a backup of it, so I didn't.

 

Ran the imported both_wind through noesis to make a gla and there's no jitter. No point uploading that. You should create a test animation with one of your models, I don't really have any time to spend on this atm.

How did you "fix" the animation-- since you said it jittered using both Noesis and Carcass?

 

It will have to wait until this next weekend for me to try and replicate any jitter-- because I didn't find/see any jitter from our test animation after compiling with Carcass 2.2.

 

How many frames was your idle animation?

Link to comment

@@eezstreet, I would recommend holding off on this new format until I can recreate and confirm any jitter... if my results (using both Carcass 2.2 and Noesis) show no jitter then there's no need to waste your time that could be spent elsewhere.

This is a wishlist. Not a commitment of an actual new format.
Link to comment
  • 5 months later...

Actually, it would be great if this new Ghoul3 format could be based on Ritual's Tiki format from Star Trek Elite Force 2.

 

  • TIKI Model System
  • Built-in scripting on a frame-by-frame basis
  • Client-side and server-side scripting reduces net-transmission of effects
  • 4-part character state system for independent control over eyes, head, torso, and leg orientations
  • Low memory footprint Skeletal Animation System
  • Bone support for attaching other models or effects
  • Variable playback rates for animation
  • Movement deltas determined from animation eliminates skating of actors
  • Support for movement driven animation (player speed controls rate of animation)
  • Improved lighting model correctly lights models from light sources around him rather than at his feet
  • Real time interpreted player state system.
  • Single skin weighted mesh (deformable meshes)

That would add enough modern features to make JO/JA last another decade :)

Link to comment

Almost none of that is related to the animation or model system itself. And none of the code is public even for study afaik.

 

Ghoul2 is already quite advanced as it is. The rest would be likely pertaining to some form of scripting in the game code logic.

Link to comment

This site seems to have quite a bit of info on the tiki format: http://ritualistic.chrissstrahl.de/games/ef2/gdkdocs/content/fakk2_tiki.html

 

I didn't mean to implement all those features, but when comparing it to the proposed ghoul3 format it does have quite a bit of overlap :)

 

Personally I would love to have this new model format support skeletal animation, as I understand it, this would allow for more complex motion without distorting the mesh.

Also, I assume that the wrinkle maps for the ghoul3 model are there to avoid clipping issues with clothing?

 

Looking forward to this new format!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...