eezstreet Posted May 15, 2017 Share Posted May 15, 2017 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 neededGLAs 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 animations16-bit (FP16) quaternions and rotations, upgrade from FP8 for more precise motion OR 32-bit (FP32) quaternions and rotationsAdaptive delta compression instead of a flat list of quaternions/transformation for smaller filesize and memory footprintRLE encoding? for smaller filesize Smoo likes this Link to comment
The Punisher Posted May 16, 2017 Share Posted May 16, 2017 Removal of hardcoded animations would be really great. Would be nice if they can be assigned via simple file like the NPC file or any other file that can be easily modified and called from within game. Link to comment
SomaZ Posted May 16, 2017 Share Posted May 16, 2017 Wrinkle maps could be done with ghoul2 models too. This is on the gl2 wishlist. I thought on using the shader system for it. Archangel35757 likes this Link to comment
AshuraDX Posted May 16, 2017 Share Posted May 16, 2017 @@eezstreet Storing of Tangents and Bitangents for Normalmapping. SomaZ and DT. like this Link to comment
Xycaleth Posted May 16, 2017 Share Posted May 16, 2017 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
eezstreet Posted May 16, 2017 Author Share Posted May 16, 2017 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
DT. Posted May 16, 2017 Share Posted May 16, 2017 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
Xycaleth Posted May 16, 2017 Share Posted May 16, 2017 The adaptive delta compression was Rich's idea.I understand that but maybe there's other things that can be improved too. Link to comment
Xycaleth Posted May 16, 2017 Share Posted May 16, 2017 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 controlThis 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
Archangel35757 Posted May 16, 2017 Share Posted May 16, 2017 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
eezstreet Posted May 16, 2017 Author Share Posted May 16, 2017 To start out with, a Noesis plugin for GHOUL3. Anything else is gravy. Link to comment
Archangel35757 Posted May 16, 2017 Share Posted May 16, 2017 To start out with, a Noesis plugin for GHOUL3. Anything else is gravy.Perhaps @@DT85 will expound on his issues with the current Noesis ==》Ghoul2 workflow. Link to comment
minilogoguy18 Posted May 19, 2017 Share Posted May 19, 2017 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
RichW Posted May 22, 2017 Share Posted May 22, 2017 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. DT., Circa and Archangel35757 like this Link to comment
Archangel35757 Posted May 22, 2017 Share Posted May 22, 2017 @@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
DT. Posted May 22, 2017 Share Posted May 22, 2017 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
Archangel35757 Posted May 22, 2017 Share Posted May 22, 2017 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. Link to comment
DT. Posted May 22, 2017 Share Posted May 22, 2017 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
Archangel35757 Posted May 22, 2017 Share Posted May 22, 2017 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
Archangel35757 Posted May 23, 2017 Share Posted May 23, 2017 @@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. Link to comment
eezstreet Posted May 23, 2017 Author Share Posted May 23, 2017 @@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
Lord Grievous Posted November 22, 2017 Share Posted November 22, 2017 Skeletal animations? Link to comment
Lord Grievous Posted November 23, 2017 Share Posted November 23, 2017 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 SystemBuilt-in scripting on a frame-by-frame basisClient-side and server-side scripting reduces net-transmission of effects4-part character state system for independent control over eyes, head, torso, and leg orientationsLow memory footprint Skeletal Animation SystemBone support for attaching other models or effectsVariable playback rates for animationMovement deltas determined from animation eliminates skating of actorsSupport 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 feetReal 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
ensiform Posted November 24, 2017 Share Posted November 24, 2017 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
Lord Grievous Posted November 24, 2017 Share Posted November 24, 2017 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
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now