[13:06] <Jorrit> Erroroman, nev7n, thebolt: so... gmeshanim :-)
[13:06] <Erroroman> yeah :-)
[13:06] <Jorrit> Erroroman, nev7n, thebolt: anyone wants to start with some thoughts/ideas?
[13:06] <Erroroman> first
[13:06] <Jorrit> Or perhaps even the seed of a plan?
[13:06] <thebolt> well, if i start i am going to sound very negative :P
[13:06] <Erroroman> some words about genmesh anim
[13:07] <Jorrit> Erroroman: ok
[13:07] <Erroroman> it started as anim plugin to genmesh
[13:07] <Erroroman> Jorrit - you have made it if you remember
[13:07] <Jorrit> Erroroman: I made the plugin system to genmesh yes. But not gmeshanim2 :-)
[13:07] <Erroroman> i know, so i tried to adopt the current system to a skeleton animation system
[13:07] <Erroroman> ofcorse the result is not that good
[13:08] <thebolt> i have very hard seeing the interface between gmeshanim2 and genmesh to be the limitation
[13:08] <Erroroman> i was thinking about special interface that is independend from genmesh animation
[13:08] <thebolt> in fact, most limitations i see is either due to sloppy coding or imho bad design decisions
[13:09] <Jorrit> thebolt: perhaps you can give a (small?) list of things you see as mistakes?
[13:09] <Erroroman> thebolt: i know that, thatws why genmesh anim2 was splited in skeleton interface and animation system
[13:09] <Jorrit> daredemo: hmm looks ok.
[13:09] <Erroroman> i think that skeleton is ok
[13:09] <Erroroman> or almost ok
[13:09] <daredemo> Jorrit, no it doesnt :P coz there's no window
[13:09] <thebolt> Erroroman: i don't .)
[13:10] <Erroroman> thebolt: okay?
[13:10] <thebolt> first problem is the excessive use of interfaces, having per-bone interface with a separate per-bone-updater etc makes it _very_ heavy on virtual calls runtime
[13:10] <thebolt> same with the animation .. having one object per key-frame is just excessive
[13:11] <Erroroman> thebolt: okay, thats true
[13:11] <thebolt> as i see it there should pretty much be two interfaces there... the skeleton and the animation (and an animation mixer or even better animation controller)
[13:12] <Erroroman> yes
[13:12] <thebolt> thats totally unrelated to the interface between gmeshanim2 and genmesh.. so its just bad design :P
[13:13] <Erroroman> thebolt:  okay, what do you suggest?
[13:13] <thebolt> second bad thing is that all updating etc does alot of matrix->quat->matrix conversions..  (bones expose their transforms as csTransform, not quat+vector..)
[13:14] <Erroroman> thebolt: yes, thats because quat had many problems in the past
[13:14] <Erroroman> convertion matrix->quat->matrix
[13:14] <thebolt> Erroroman: well, the right thing then is to solve them, not do sloppy code :P
[13:15] <Erroroman> thebolt: yeah
[13:16] <thebolt> third (there are in total five things that really hit me when reviewing this stuff).. the animation in-memory format is very (and i mean _very_) memory heavy
[13:16] <Erroroman> every key frame holds transforms of the bones
[13:17] <Erroroman> thats it
[13:17] <Erroroman> it can be optimized as keeping quat + pos
[13:17] <thebolt> thats not the only thing it holds
[13:17] <thebolt> every keyframe is its own scf object.. means hm.. 36 byte or so overhead
[13:18] <thebolt> also it use a hash for holding transforms..
[13:18] <thebolt> hashes are not memory friendly either.. a packed array with indices & transforms is better
[13:18] <Erroroman> nope
[13:19] <Erroroman> the hashes are only per animation
[13:19] <Erroroman> per running animation*
[13:19] <MistaED> hmm would it be more memory efficient if the animation transforms can also be weighted/curved/flattened like in blender/maya and not just be linear? then not as many keyframes are needed
[13:19] <thebolt> no, csSkeletonAnimationKeyFrame contains a hash of the transforms
[13:20] <thebolt> MistaED: not needed, which i can explain later..
[13:21] <Erroroman> thebolt: bleh, true ... i have to remind myself the code
[13:21] <MistaED> thebolt, k that's good, don't let me keep you from the discussion ;)
[13:21] <thebolt> fourth.. the spline-fitted quadratic interpolation.. there is no need _ever_ (for realtime stuff) to use anything but linear interpolation (slerp)
[13:21] <thebolt> the whole point is to place the _keyframes_ at the righ places..
[13:21] <Jorrit> daredemo: sorry. Only way for now.
[13:22] <Erroroman> thebolt: squad gives much better visual results thatn slerp
[13:22] <thebolt> Erroroman: not if the keyframes are placed right
[13:22] <thebolt> Erroroman: esp not if you have per-track keyframing instead of whole-body keyframes and an optimization pass for placing of keyframes
[13:22] <Erroroman> you need more key frames for smooth rotation
[13:22] <Erroroman> with slerp
[13:23] <thebolt> not really
[13:23] <thebolt> or not that mayn at least
[13:23] <thebolt> and its way faster
[13:24] <Erroroman> thebolt: yes it is faster, but i think spline rotation should be supported
[13:24] <nev7n> sry - got called away, just reading back...
[13:25] <Erroroman> brb
[13:25] * MistaED homes that 24 keyframes/sec isn't too memory-intensive then, if spline rotation isn't supported
[13:25] <thebolt> Erroroman: well,, when the top-of-the-line commercial animation libraries don't need it i don't see why we should, except as a way to hide bad input data :)
[13:26] <Erroroman> b
[13:27] <Erroroman> thebolt: okay, but adding that was based on many tests and exports
[13:27] <thebolt> and as MistaED says, with optimized storage format you should be able to use at least 10 frames / s in sections of high movement etc
[13:27] <thebolt> Erroroman: yea, but did you do optimized (mathematically optimized) placement and value for keyframes etc?
[13:28] <thebolt> that makes a major difference
[13:28] <Erroroman> thebolt: no, just keeping the same frame data
[13:28] <thebolt> Erroroman: exactly, and what i am saying is that one should (in preprocessing/export) fix the data and instead use the simplest (and fastest:) way of doing it runtime
[13:28] <Erroroman> thebolt: the most of the modeler software works with spline, and the final result in CS differs the input animation
[13:29] <thebolt> Erroroman: yea, but you can fit a slerp-interpolated curve to be very close to the spline
[13:29] <nev7n> so issues with current animation system are to do with design and efficiency
[13:29] <MistaED> Erroroman, what if you bake the animation for 24 keyframes/second?
[13:29] <Erroroman> okay, probably a test can show what is better - more frames with slerp or less frames with squad
[13:30] <nev7n> are there also features that need adding?
[13:30] <thebolt> Erroroman: not neccesarily just _more_ but _better placed_
[13:30] <thebolt> if you have 5 frames / second you can place the frames at 0, 0.2, 0.4, 0.6, 0.8, 1.0, etc
[13:30] <thebolt> but that is probably not the best way to place them
[13:30] <MistaED> i think carmack recently complained about this with quake wars only having 30keyframe/second animation
[13:31] <thebolt> you probably get better result (better == matching the input better) by having uneven keyframe rate
[13:31] <thebolt> nev7n: there are also features missing
[13:31] <Erroroman> thebolt: 3ds max plces animations when it detects that the bone has more than 180 degrees rotation
[13:31] <nev7n> I guess fixing the underlying design should take the priority over adding features though
[13:31] <Erroroman> i just use these frames
[13:31] <thebolt> Erroroman: so? thats not related (or my problem)
[13:32] <thebolt> thats just bad input data then :P
[13:32] <Erroroman> no, i just don't make any reaordering of the keys
[13:32] <thebolt> bad input data shouldn't force us to use inefficient runtime
[13:32] <nev7n> Errorman: so you're saying you just use the keyframes from the input
[13:32] <MistaED> Erroroman, 3dsmax might have a bake option, in maya there's one to keyframe all the frames, even the ones which you made in the spline curves
[13:33] <Erroroman> okay, so we have another problem - the exporter, should exporter take care for this?
[13:33] <nev7n> thebolt: you're asking for us to optimise those keyframes - can that be done automatically or isn't that usually down to the skill of the animator
[13:33] <Erroroman> or it case the animation loader?
[13:33] <thebolt> MistaED: probably gives too many.. but its easier to remove (and move around) keyframes than create new ones ;)
[13:33] <thebolt> Erroroman: exporter / preprocessor tool
[13:33] <Erroroman> okay
[13:33] <Jorrit> Is someone logging this gmeshanim conversation?
[13:33] <thebolt> nev7n: you can do that mathematically
[13:33] <thebolt> Jorrit: yes, i am
[13:33] <MistaED> thebolt, yeah for the ones which will only be linear it should be easy to delete out
[13:33] <Jorrit> ok good
[13:34] <thebolt> nev7n: its a quadratic optimization with constraints
[13:34] <nev7n> thebolt: I guess you can do some optimisations mathematically but I'd have though that there were some parts of animation that were more important and might need more keyframes
[13:34] <nev7n> *thought
[13:34] <thebolt> nev7n: yea, but usually more important is when much happens (lots of movement).. and an automatic optimization would take that into account
[13:35] <nev7n> just a case of making any optimisation optional I would have thought - but turned on by default
[13:35] <thebolt> what we had at Starbreeze (company i worked this summer) was a mode in our editor for optimizing animations
[13:35] <thebolt> basically the animator had a slider where they set how much to compress (== optimize) each of the animations
[13:36] <nev7n> for peach maybe best done as a blender plugin, but that doesn't solve for other animation packages
[13:36] <thebolt> so, let me get to my fifth point (i really soon have to go and get lunch, but will eat by computer.. takes a few minutes to prepare it)
[13:36] <MistaED> ok the more keyframes=memory bottleneck or cpu bottleneck? for very long animations (for like a machinima/in-game cutscene) would it be wise to have an animation stream-loader mode?
[13:37] <thebolt> fifth point is the ultimate lack of features when it comes to selecting, mixing and blendning animations
[13:37] <Erroroman> thebolt: thats true: there is no animation mixer or something similar
[13:37] <thebolt> MistaED: well, depends.. can be either or both :) for in-game cutscenes you probably can take it to be a bit more different from the in-editor look as long as it looks ok ;)
[13:38] <thebolt> hm, bb in max 10 minutes..
[13:38] <MistaED> a mixer would be GREAT :)
[13:38] <nev7n> any other features missing?
[13:38] <Jorrit> The mixer is the most crucial one.
[13:39] <Jorrit> So. We now have a 5-point plan :-)
[13:39] <Jorrit> When thebolt returns I guess we can discuss how much this 5-point plan can fit inside current gmeshanim2.
[13:39] <MistaED> thebolt, k, i was planning on some nice cutscenes using an animation constant stream straight from maya/blender and not just blending in-game animations
[13:40] <nev7n> Errorman: is it going to be possible to address all those things with genmeshanim2 and still retain backward compatibility?
[13:41] <Jorrit> nev7n: that's another good question.
[13:41] <Erroroman> nev7n: yes
[13:41] <Erroroman> i think that removing sqiad is a bad idea
[13:41] <Erroroman> i doubd we can just  fix animatios and get similar results
[13:41] <Erroroman> probably make it optional
[13:42] <nev7n> it would be good to work on a CEL interface to the animation at the same time
[13:42] <Jorrit> nev7n: CEL has some support already. Caedes worked on that. But yes, it would be good to see how to fit in blending there.
[13:43] <MistaED> i'm not sure if this would be a 6th point or combined with the 5th point, but what about procedural animations mixed with keyframed ones? like for ragdolls, corrective IK for feet and "lookat" options (constraints?)
[13:43] <MistaED> just for examples
[13:44] <Erroroman> brb too
[13:46] <thebolt> b
[13:46] <thebolt> Jorrit: i'd say blending is as important as mixing.. but usually same component doing that
[13:47] <thebolt> Erroroman: if it is optional you still have the memory requirement for it
[13:47] <Jorrit> thebolt: ah blender != mixing?
[13:47] <thebolt> Jorrit: well, dpeends on whos terminology you use ;)
[13:47] <thebolt> guess you should use blending & transition rather
[13:48] <thebolt> one for having several animations at once on the same skeleton
[13:48] <thebolt> (possibly only affecting a part of it)
[13:48] <thebolt> the other for automatic transition between animations
[13:48] <thebolt> so say you are walking and switching to running, to get a smooth transition
[13:49] <thebolt> Erroroman: another problem with the quadratic stuff is that its very hard to predict for anti-skid stuff etc
[13:50] <Erroroman> b
[13:51] <Erroroman> yes\
[13:51] <Erroroman> thats true
[13:51] <thebolt> a linear interpolation between two quats P and Q will always just pass through points between P and Q
[13:51] <thebolt> while a quadratic one might go "away" from Q before changing direciton
[13:52] <Jorrit> brb
[13:52] <Erroroman> yes, but it spline looking better :-)
[13:52] <Erroroman> -it
[13:52] <Erroroman> +is
[13:53] <thebolt> and i don't think you need it, i much rather have a fast and efficient system that displays what you give it instead of something thats "too smart"
[13:56] <MistaED> thebolt, with your go "away definition of the quadratic, what implications would that cause? like an unpredicted hitch in some of the rotation/movement?
[13:56] <Erroroman> thebolt: okay, anything about the skinning? GPU ot CPU?
[13:56] <thebolt> Erroroman: both
[13:56] <thebolt> MistaED: hm?
[13:57] <MistaED> thebolt, when you explained the quats P & Q, you said it might go "away" before changing direction, i'm just trying to work out if that means you'd get unexpected animation glitches or?
[13:57] <Erroroman> thebolt: i think the CPU one is good in vproc, GPU one is crap, it needs work around model and passing less bones than the shader limit
[13:58] <Erroroman> i have some work around that, sutosplitting the model in submodels
[13:58] <nev7n> another feature request - some documentation :)
[13:58] <Erroroman> autosplitting*
[13:58] <thebolt> actually, the vproc is wrong place for it
[13:58] <thebolt> (have we worked out)
[13:58] <thebolt> it needs to be earlier in pipeline :P
[13:58] <Erroroman> okay
[13:59] <thebolt> also, i think submesh splitting is the way to go, however it needs to be smart to take other reasons for submesh splitting into account as well (such as material boundaries etc)
[13:59] <Erroroman> yes, i have that code .. just a sec, i have some screens
[14:00] <thebolt> (also, it should also be done in exporter :)
[14:00] <Erroroman> actually i think that the conversion tool must take care forthat
[14:00] <Erroroman> hehe :-)
[14:00] <thebolt> the runtime part should jsut do the minimal it have to do
[14:00] <Jorrit> b
[14:01] * Jorrit agrees with putting as much work in exporter as possible.
[14:01] <Erroroman> here is how it works now:
[14:02] <thebolt> exporter or preprocessor tool (to make code-sharing between different exporters easier)
[14:02] <Erroroman> the mesh is splited in 2 meshes that uses small number of bones
[14:02] <Erroroman> http://img206.imageshack.us/my.php?image=snapshot15ht2.jpg
[14:02] <Erroroman> http://img206.imageshack.us/my.php?image=snapshot14zv9.jpg
[14:02] <Erroroman> and the final mesh http://img149.imageshack.us/my.php?image=snapshot16sb1.jpg
[14:02] * MistaED hopes there will be a good maya exporter too
[14:02] <Erroroman> it is automatic and splits the mesh in a "smart" way
[14:02] <thebolt> MistaED: given we have no general maya-exporter atm, i wouldn't count too much on it..
[14:03] <thebolt> MistaED: i think that for quite some time our main way for maya will be maya->collada->cs or so..
[14:03] <Erroroman> but the code is in C++ placed in genmeshanim ... which makes it harder :-)
[14:03] <MistaED> thebolt, there's crystalmaya, i'll try to ask dentoid/cyanox/iceeey perhaps :)
[14:03] <thebolt> MistaED: well, its not that well working and very limited :)
[14:03] <thebolt> (i also have it around here somewhere.. )
[14:03] <MistaED> thebolt, yeah if the collada pipe is good i'll just use that :)
[14:04] <thebolt> the goal is to make it good :)
[14:04] <MistaED> i wasn't impressed with the collada import/export blender currently has
[14:04] <Jorrit> Are we coming close to a plan regarding this?
[14:04] <Jorrit> And then we have to decide who will work on it.
[14:04] <thebolt> Jorrit: we haven't started to discuss a plan yet ;)
[14:04] <Jorrit> Also we have to decide what can be reused of gmeshanim2.
[14:04] <Jorrit> And how compatible we can (want to) be.
[14:09] <nev7n> thebolt: Errorman believes the current genmeshanim2 system can be updated to include the above and maintain backward compatibility, would you agree with that?
[14:10] <Jorrit> Even if we can we still have to see if it is worth the effort. Another option would be to start a new gmeshanim3 and deprecate the old one.
[14:10] <Jorrit> But I can't really judge that atm.
[14:10] <Erroroman> hm
[14:10] <Jorrit> Even when we start fresh we can still reuse code whenever possible.
[14:11] <thebolt> i don't think its worth building on the current code.. the amount of cod ethat is reusable is pretty small, esp on the "structure" level
[14:11] <Jorrit> Just have to see what the easiest way is here.
[14:12] <nev7n> I've said I'm happy to help working on the animation system but I would need some experienced help
[14:13] <Jorrit> Well, don't know what thebolt still has in mind. But perhaps one way would be to start making a proposal for an api based on what has been said here and perhaps based on what gmeshanim2 already has?
[14:13] * MistaED will be happy to watch :) and offer cool models to test it with
[14:14] <nev7n> OK - let me make a start by suggesting an API and we can take it from there
[14:15] <Jorrit> thebolt: agreed with that?
[14:15] <thebolt> there have been lots of good papers at this and last years siggraph & gdcs on character animation, read them too :)
[14:15] <thebolt> yea, sure
[14:15] <thebolt> sounds good
[14:15] <nev7n> I'll do some research at the same time and consult on irc as I go
[14:16] <Jorrit> good
[14:16] <Jorrit> Perhaps post on crystal-develop too with questions.
[14:16] <Jorrit> Erroroman: are you still subscribed to that?
[14:16] <Erroroman> sec
[14:16] <Erroroman> was away for a minute
[14:16] <thebolt> also, one thing we need for a new system is something that have people who know (and wants to) touch it :P
[14:16] <Jorrit> thebolt: if it is well written and planned in advance then I guess that should be no problem.
[14:17] <thebolt> Jorrit: yea
[14:17] <Jorrit> Another question. Do we keep on basing it on genmesh + plugin system?
[14:17] <Jorrit> By doing that we have the advantage of having all the genmesh stuff already handled.
[14:17] <Jorrit> i.e. vertex buffers and stuff.
[14:17] <Jorrit> But another option might be to make a new mesh object.
[14:17] <Erroroman> Jorrit: okay, agreed, new API is better idea :-)
[14:19] <Jorrit> thebolt: your opinion?
[14:19] <nev7n> I'll see if I can write up some of the discussion so far into a wiki somewhere
[14:19] <Erroroman> Jorrit: and i think it must be something different from "genmesh anim" in general
[14:19] <Erroroman> completely new interface that is specialy for that
[14:21] <thebolt> Jorrit: i'm not sure.. in the end i think there should be one mesh for static objects and one for animated.. but not sure if this is the time to do it.. might be actually..
[14:21] <thebolt> the additioal "overhead" of making a meshobject isn't that big..
[14:21] <Jorrit> If we are doing this change then perhaps it would be best to make a new mesh object out of it.
[14:21] <Jorrit> nev7n: so add that to the plan. We'll start a new mesh object for this.
[14:21] <Jorrit> That will make the api and usage easier too I think.
[14:21] <nev7n> OK
[14:21] <dingobloo> if sprcal3d has taught us anything it's that highly specialised mesh objects go unmaintained
[14:21] <Jorrit> dingobloo: well this one has very general usage.
[14:22] <Jorrit> dingobloo: I mean it is a mesh object many people will want to use.
[14:22] <Jorrit> dingobloo: and we also have separate mesh objects for particle systems and terrain.
[14:22] <MistaED> already it's sounding to be > sprcal3d
[14:22] <Jorrit> dingobloo: so why not a skeletal animated mesh?
[14:23] <nev7n> which wiki should I use to put this stuff the CS trac one?
[14:23] <Jorrit> nev7n: trac one
[14:23] <Jorrit> nev7n: and thanks for helping with this! This works is important!
[14:24] <nev7n> no problem - it's interesting stuff
[14:24] <dingobloo> Jorrit: well whatever happens i would encourage at much code be shared if at all possible..very simple things went overlooked when cal3d was done
[14:25] <Jorrit> yes, that's true.
[14:25] <thebolt> dingobloo: well, genmeshanim2 isn't maintained atm either :P
[14:25] <dingobloo> yes but it benefits from changes made in genmesh
[14:25] <dingobloo> give or take
[14:25] <thebolt> not really
[14:25] <Jorrit> dingobloo: or if the changes are too extensive it will break instead of benefit :-)
[14:26] <nev7n> I think we can suggest a new mesh object but decide whether we want one later in the design process
[14:30] *** Jorrit is now known as JorritAfk
[14:30] <JorritAfk> b in an hour
[15:02] <nev7n> thebolt, JorritAfk, MistaED, Erroroman, all: I've summarised the animation discussion here: http://www.crystalspace3d.org/trac/CS/wiki/new%20animation%20system
[15:15] <MistaED> hmm for the 5th point that includes mixing more than 2 animations at once right? and ones which only animate a certain section but not all? ie. legs running while torso aims as 2 separate animations?
[15:20] <thebolt> MistaED: possibly more than two, and more than one can affect the same bones
[15:24] <nev7n> MistaED: thanks, I've updated http://www.crystalspace3d.org/trac/CS/wiki/new%20animation%20system
[15:53] <Jorrit> nev7n: short but to the point :-)
[16:01] <nev7n> Jorrit: I'm nothing if not concise
[16:06] <vknecht> nev7n: might be worth to add the chat log nevertheless (probably expurged from off-topic lines), so that people could see who was involved in decisions, and why those choices where made
[16:06] <vknecht> just my 2 cents, though
[16:06] <Jorrit> I agree yes.
[16:08] <vknecht> mmm, also it doesn't mention cal3d stuff, so one would wonder if that new one will overtake it, or if cal3d still be supported, or deprecated, ...
[16:09] <thebolt> deprecated & removed..
[16:11] <vknecht> so as I understand it, the new animation will have to support cal3d ?
[16:11] <Jorrit> vknecht: ???
[16:12] <vknecht> ok, I guess cal3d format support will be dropped, then :)
[16:13] <Jorrit> vknecht: or at least deprecated.
[16:16] <vknecht> anyway, I'm doing the purging a log of discussion to put it in that trac page
[16:23] <nev7n> vknecht: thanks
[16:23] <Jorrit> nev7n: let us know if you hit any problems or severe case of RL.
[16:24] <nev7n> Jorrit: will do