Added a new example examples/animations/md3_animations_tags/ to showcase this. I had some fun combining Tremulous MD3 human torso + head (to tag_head) + weapon (to tag_weapon). They work nicely with animations, I can toggle between human animations like attack, gesture → and the weapon and head stay correctly glued (and animated) to the body.
In the long run, glTF will consume less memory (since it doesn’t have to store precalculated animations in memory, and can be animated at runtime on GPU). Although in the current implementation we waste this opportunity, but it’s planned to be improved ( Roadmap | Manual | Castle Game Engine ). So currently, they (MD3 and glTF) will actually consume approximately the same memory in CGE, for the models with the same number of vertexes.
In general: if you can migrate your workflow to glTF, I would recommend to do it.
glTF is better than MD3 in many ways.
E.g. skeleton in glTF is smoothly animated, while with MD3 you only have precalculated frames (30 frames per second by default) so e.g. setting TimePlayingSpeed = 0.1 will reveal that the animation is not really smooth for MD3.
glTF also supports PBR (better way to specify realistic materials), where MD3 doesn’t say anything about materials (just a texture…) and is really supposed to be used unlit.
and more stuff. glTF supports animating transformations or skeletons. glTF has metadata (see Blender | Creating Game Data | Castle Game Engine what it means). glTF allows to specify camera, and even camera animation. glTF also has “morph targets” (not yet supported by CGE, but will be).
In general, while we have a lot of fun in this thread with MD3, you should be aware that it’s a rather old 3D format, missing some feature. We support it, because it’s easy and fun But glTF is a modern format, with much more features and a brighter future (glTF extensions are being developed by Khronos). And ultimately in CGE we want to support 100% of glTF in 100% efficient way.
Thank you so much for everything! This is definitely really awesome! On the topic of glTF, I knew that was the main format you wanted to support and tried that first, but it looked like I couldn’t export glTF vertex animations from Blender, at least without some trickery of turning it into an alembic first and then a glTF so that it thinks it’s an alembic (I can give you the actual YouTube video for this trick if you’re interested), but the engine didn’t like that even though it worked flawlessly with other ones, like it imported the animation as static rather than properly animated,
So I thought that using skeletal/rigged animations like it’s supposed to be used for would consume more hard drive space and RAM than something that does support vertex animations, but that’s not true and the vertex/frame by frame animations actually consume more data in the long run because of how they are calculated?
If you mean “Shape Key” animations, then this is indeed our TODO for glTF – we do not support glTF “morph targets” yet.
In the long run, skeletal/riggen animations can consume less memory, once we implement Roadmap | Manual | Castle Game Engine . Before that, they will be pretty much equal in memory consumption for CGE (which is our TODO – we can do better!).
More news about MD3, since I was playing with that code:
We now support choosing MD3 skins. While by default for xxx.md3 we load xxx_default.skin, but you can now change the skin, by adding an anchor like #skin:yyy to the URL. For example, loading head.md3#skin:light will load the skin from head_light.skin.
I did some fixed to handling skins, to detect better indicated texture.
This is even better, even though the multi-part example was perfect as it was, it’s even better to have an easy to look at reference page for any help I might need for the file format.
It looks like though, that the next release isn’t up on the downloads page yet? I know that’s very understandable and there’s no rush, especially because it’s a free project made out of love, and also that you need lots of time to make sure any release is good quality and bug free, so I guess it will probably take more than a couple of weeks.
The releases on Download | Castle Game Engine are done automatically by Jenkins (automated software) from the latest GitHub master commits, once they pass a few tests.
So there’s no need to wait weeks, just wait a few hours
And you will need the new engine version (some of the examples I mentioned require new engine to work), as most of above work (tags, better skins) is in the engine itself, not in example code.
You can check when it’s ready by looking at Comparing snapshot...master · castle-engine/castle-engine · GitHub . Right now this page shows commit titled “Make human models good, showcase new skin support” at the bottom. When that page will no longer show this commit, it means it will be part of downloads of Download | Castle Game Engine . Don’t worry that version number doesn’t change, it is a “snapshot” release now, so version keeps showing 7.0-alpha.snapshot.
Wow! It is really great you guys do it super fast, cause I know usually it does take months or even years for most free game engine developers to release their work to the public, because it needs to be tested thoroughly etc, but maybe you guys just test and verify features super fast?
I do have a different question that is totally unrelated to this thread though, about how to check if a specific object collides with another specific object and not just the world in general, so I will start a new topic for that.
Okay, even when I ignored the title from the download as you suggested, and let the download complete for the latest version (after uninstalling the old one obviously), I still don’t see the example for md3 tags. Is it because it’s not added yet and still being tested in GitHub? I thought you said in a post above it was complete/implemented fully.
I do see the “split into logical pieces” example you posted above is added, so I know it’s different than the last version I got and is newer, but I don’t see anything mentioning md3 tags in the title.
Oh wait, especially cause the link reads “Github” clearly/obviously, you just meant it’s finished on Github, but I have to wait some more for it to be added to the official download from the page, because it’s still being looked over in Github? That’s the only logical explanation I can think of, which again is fine because I know it takes time to update large software projects like game engines
Specifically, the line that made me think the example was off Github and in the official download was that “MD3 tags are now supported :)” (verbatim/exact words)
I said a few posts above to “wait a few hours”, and these few hours now happened
Longer answer:
I think I never explained correctly how our “automatic builds” work, hence your confusion. Let me try to clear it up So what happens is:
When I or any other CGE developer implements something, and it is accepted, it goes to the “master” branch of the GitHub repository. You can see recent commits there e.g. on Commits · castle-engine/castle-engine · GitHub .
When I say on forum “I committed this fix/improvement to GitHub master”, then it means this has happened.
There exists a “moving tag” in the GitHub repository called “snapshot” that always corresponds to the commits included in the downloads on Download | Castle Game Engine.
Our automated system (called Jenkins) automatically scans the repository for changes.
When it sees that new commits appeared in the “master” branch, it runs a number of automated checks on the engine (that everything, including all examples, compiles with all compilers (FPC, Delphi), for all platforms (Windows, Linux, …)). There are a lot of automated tests, they take a few (6-8) hours to finish usually (assuming all the tests pass).
When all tests pass, Jenkins builds a new version of engine binaries (like castle-editor.exe).
When it is done, Jenkins 1. updates the “snapshot” tag to point to the latest commit that passed the tests, 2. updates the binaries on Download | Castle Game Engine to the build that corresponds to this commit. (You can assume that 1 and 2 happen at the same time; it’s not precisely true, but they are close (< 1 minute).)
In effect, you can use the page that compares the commits between “master” and “snapshot” ( Comparing snapshot...master · castle-engine/castle-engine · GitHub ) to determine whether a particular feature is already included in the build. This page shows the difference between “master” and “snapshot”, that is: commits that have been made to “master” but are not available in the downloads yet. When the commit is part of “master”, but it is not present on that page → it means that the commit is now part of the download, because it is then in both “master” and “snapshot”.
I think I discovered another problem, making sure to uninstall and re-install the engine again to make sure I am keeping up to date on the updates Jenkins adds automatically,
The MD3 data support page in the manual you linked above seems to suggest this is intentional, but if it is I would like to ask why, because in the original Tremulous it certainly wasn’t like this.
Anyway, the problem is that even though as the example demonstrates, the animations for the head and torso work fine, the animations for the legs import the animations for the torso as well as the legs, which is not good, because it throws the animation off and it starts playing running in one half of the animation and walking in the other, for instance, as it assigns the wrong frames to the leg animations - in Tremulous and Quake 3, torso specific animations are not played on the legs at all, and leg specific animations are not played on the torso at all.
I would assume this is because the engine reads the animation.cfg in sequential order from top to bottom for every model, which is okay for torsos and heads, but not good for legs, because the leg specific animations come after the torso specific animations the way it is written for Tremulous or Quake 3.
( Sorry for big delay in answering – too many tasks, too little time )
I investigated and found the reason why animations of legs on Tremulous characters played weirdly.
It’s fixed now
The reason was unrelated to the fact that we expose “all animations on all MD3”. Just the treatment of LEGS_ frames requires a very specific hack in code, which seems to be some falloff from old id Tech hacks. I found others also doing it (see MenderD3/src/md3_parse.c at 4b95d8b0d03e46513d49e12c17ecac23f1ba8dd4 · MJL85/MenderD3 · GitHub , comment “For some reason or another the frame numbers…”). We do it too now.
On a related note, I also fixed treatment of frames-per-second values from animation.cfg in our engine. So all animations should now play with correct speed.
Along with the fix, I also improved our examples/animations/md3_animations_tags to show all humans with legs They have also been placed in “design files” , if you’re not sure what it is you can watch https://www.youtube.com/watch?v=peiWjieZpbM .
Indeed, as manual MD3 | Creating Game Data | Castle Game Engine states, we import all animations animation.cfg and make them available for MD3 in the same directory. There is just no way to avoid it, from what I can tell – there is no information (in any file) that e.g. for humans in Tremulous ( examples/animations/md3_animations_tags/data/tremulous-data/data-1.1.0/models/players/human_base/ ) only the LEGS_xxx animations should be made available for the lower.md3 files.
We just cannot avoid this. As far as I know all engines using MD3, including id Tech 3, have the same limitation. Since there’s no intrinsic connection between which MD3 models can play which animation, it is just something coded/adjusted per code. Tremulous developers just know to only play LEGS_xxx animations on lower.md3 files.
That being said, this should not be a problem for you. If you just play LEGS_xxx animations on lower.md3 files, everything should work fine. (after my fix today )
We indeed read sequentially, but this should not cause any problem. The animation names are unique, at least when I’m looking at Tremulous humans. Leg animations have names like LEGS_xxx, so they exist independently of e.g. BOTH_xxx and TORSO_xxx animations.
Okay, thank you for clarifying the issue was different than I assumed, and fixing it. I didn’t know that in the actual original Quake 3, the legs were programmed differently than torso and head, but that makes sense why it imports weirdly into Castle Engine.
Now I can officially play full md3 animations once the change is uploaded by Jenkins hopefully tomorrow.
