[JAEnhanced] Enhanced Development Platform (EDP)

[afi]

Great! In theory, would it be possible to have a tool that can render menus and let's you test them without having to start the actual game?

[therfiles]

Absolutely wonderful. Fantastic work! Perhaps a list of "shown" and "hidden" itemdefs? Sometimes, a lot of elements could be hidden and not accessible immediately. In addition, some action/mouse-overs draw itemdefs to a set point of coordinates (think the "glow" that draws on the Base JA menus). Would this be changeable?

[eezstreet]

@@eezstreet

 

If you're interested - I have a clean, "DF2-free" version of DF2's GL2 here for you. I started off from JKE master and added the GL2 stuff in, minus widescreen in-case you have something of the like in JKE already. JK2 should also have GL2 support in the cmake files, but it's untested:

 

https://github.com/DT85/DF2-EDP/tree/Clean-GL2

 

 

Changes from JKE master:

 

- renamed all sp vanilla renderers to GL1

- added GL2 with untested JK2 support in cmake files

 

 

EDIT:

 

I've noticed that some stuff that's in JK2's code, isn't in JKA's code. For example, json. Will the JK2 features be shared at some point?

Yes, when a proper release of EDP comes. A lot of the features are still very heavy WIP at the moment (nav editor can't save yet, among other things).

I intend to create a whole bunch of issues on the Github page detailing everything I need to complete.

 

Were the functions that were missing from GL2 but required for JK2 (eg, jpeg buffering) added?

[eezstreet]

Great! In theory, would it be possible to have a tool that can render menus and let's you test them without having to start the actual game?

I'm not sure I understand the purpose of such a tool - you can do all of the editing ingame with this tool (for the most part).

In the future I am also considering making a binary menu format that will load faster and only be editable ingame.

 

Absolutely wonderful. Fantastic work! Perhaps a list of "shown" and "hidden" itemdefs? Sometimes, a lot of elements could be hidden and not accessible immediately. In addition, some action/mouse-overs draw itemdefs to a set point of coordinates (think the "glow" that draws on the Base JA menus). Would this be changeable?

This is part of the plan, yes. The controls and feature list are still subject to change.

[Smoo]

ah it similar to movie battles one, just sucks u cant turn it off if u wanted on mb2, or can u?

[Tempust85]

I've copied over your stubs commit, but within a JK2_Mode ifdef.

 

https://github.com/DT85/DF2-EDP/commit/ad386ed58d9862af997fba73397b896499c371aa

[eezstreet]

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

[The Punisher]

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.

[SomaZ]

Wrinkle maps could be done with ghoul2 models too. This is on the gl2 wishlist. I thought on using the shader system for it.

[AshuraDX]

@@eezstreet Storing of Tangents and Bitangents for Normalmapping.

[Xycaleth]

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.

[eezstreet]

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.

[Tempust85]

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.

[Xycaleth]

The adaptive delta compression was Rich's idea.

I understand that but maybe there's other things that can be improved too.

[Xycaleth]

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.

[Archangel35757]

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.

[eezstreet]

To start out with, a Noesis plugin for GHOUL3. Anything else is gravy.

[Archangel35757]

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.

[minilogoguy18]

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.

[RichW]

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.

[Archangel35757]

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

[Tempust85]

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.

[Archangel35757]

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.

[Tempust85]

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.

[Archangel35757]

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?