16:26:42: <marco2> If you want have a look at the wiki we made about our lip sync project http://emusiquegestion.free.fr/index.php?title=ExtraLipSync
...
16:26:55: <LetterRip> marco2, thanks for the link
...
16:28:09: <vladius> kaito: good .. their project looks very promising
16:28:19: <joeedh> look at the wiki link.
16:28:25: <vladius> kaito: I mean _very_ promising
16:28:30: <joeedh> http://emusiquegestion.free.fr/index.php?title=ExtraLipSync
16:28:49: <LetterRip> Lynx3d, heheh
16:29:17: <MarcOO> hi im with marco2 for this project also
16:29:20: <LetterRip> marco2 proposal looks good, but light on the technical side of things
16:29:29: <marco2> It's just the first steps of the project, if you have any comments please don't hesitate
16:29:31: <kaito> marco2: why is this a new editor in blender?
16:30:00: <kaito> it seems to me you can also live with a more advanced shape key editor
16:30:41: <kaito> and then its a python script, or all c? or excisting library?
16:30:48: <LetterRip> marco2, note kaito is ton our technical lead and head coder of the animation tools also
16:30:59: <joeedh> marco2: hrm. this would be great as a script. but python can't do very good gui stuff at the moment :S
16:31:03: <kaito> shit!
16:31:12: <kaito> LetterRip: now you spoil the fun!
16:31:19: <joeedh> marco2: you could write it as a external python app, that has a special mode for running in blender :) use you're own gui library, etc.
16:31:23: <LetterRip> kaito doh
16:31:25: <LetterRip> sorry
16:31:36: <kaito> they could have replied with "who the f* you think you are!" :)
16:31:42: <joeedh> you should've picked on aligorith :)
16:32:15: <marco2> We were thinking about a C/C++ code but a python plugin could be fine
16:32:24: <kaito> LetterRip: joke. i'm fine :)
16:32:30: <joeedh> marco2: hrm your system is too simplistic. . .is has to have support for combinations of shapes.
16:32:35: <slikdigit> marco2: can I make a suggestion?
16:32:47: <marco2> of course
16:33:00: <joeedh> marco2: and also support to work with drivers, instead of shapekeys.
16:33:06: <slikdigit> well, it would be nice if you can bake to other than shape keys
16:33:29: <kaito> like, its action with drivers
16:33:31: <kaito> ?
16:33:32: <joeedh> maybe the system should use python to actually apply the phonomes. . .
16:33:34: <slikdigit> that way you can setup facial animation any way you want
16:33:36: <Lekaway> combinations of shapes << very important
16:33:36: <slikdigit> yes
16:33:37: <LetterRip> figured you wre joking
16:33:47: <joeedh> so you define a python callback, that can set shape keys or drive armature bones or something.
16:34:11: <slikdigit> for instance, plumiferos uses shapekeys and lattice deform driven by armature, or by object controllers
16:34:27: <slikdigit> you'd want to "bake" to the controller
16:34:49: <cwant> slept through another meeting, I don't suppose SoC project ideas was discussed?
16:35:23: <kaito> I am talking aligorith into looking at shapekey/action/nla editing from XSI, like this http://www.edharriss.com/tutorials/tutorial_xsi_soft3d_character_import/images/image008.jpg http://www.edharriss.com/tutorials/tutorial_xsi_soft3d_character_import/images/image009.jpg
16:35:25: <joeedh> you can get the proper position/rotation/whatever of the controller by using the underlying ipo that drives it all. . .unless the user uses pydrivers of course, but then pydrivers arn't very usefull for shape keys anyway.
16:35:32: <slikdigit> and like joeedh says, it has to support combinations to be really useful
16:35:56: <Briggs> this is shapekey based or bone driven?
16:35:57: <slikdigit> each phoneme is built from a mix of several keys, not just one to one
16:36:00: <marco2> thanks for the link I' m gonna take a look at that
16:36:16: <joeedh> kaito: imho, for really good editors like that I think the UI code needs to be refactored to work with the concept of containers.
16:36:31: <kaito> and a container = ?
16:36:33: <joeedh> kaito: separating UI code into blender-UI-code and editor-hacked-together-UI-code isn't good :S
16:36:34: <Briggs> slikdigit, mroe than that, you have to be able to switch to 'combination' shapes when the individual keys mixed togather form an 'overdriven' combination
16:36:50: <joeedh> kaito: like a text editor has a text field and a scrollbar.
16:37:43: <LetterRip> realize all this is student project - with a - umm 6 week timeline or so?
16:37:47: <joeedh> Briggs: does blender uses normal mixing for shapekeys? e.g. like the Mix node, uses a = a + (b-d)*factor equation, etc.
16:38:00: <Briggs> havnt a clue.
16:38:26: <slikdigit> Briggs: I may understand that, but not sure
16:38:31: <joeedh> kaito: UI code should really be based on containers, with new widgets being based on old ones. I've found this works very well in practice.
16:38:44: <slikdigit> joeedh: it's simple additive
16:38:52: <marco2> We have more than 8 weeks allowed for coding
16:38:54: <slikdigit> on vertex translation
16:39:05: <LetterRip> slikdigit, shouldn't it be using slerp?
16:39:11: <LetterRip> spherical interpolation?
16:39:12: <joeedh> kaito: and also I think GUI code needs to be state, not stateless, since that also means separating GUI code that shouldn't be separate.
16:39:51: <kaito> marco2: you might consider to make it a python project entirely. that way you can do this first for own projects (lipsync anims), and not have to worry about official release specs that fit in current projects
16:39:56: <slikdigit> LetterRip: I'd have to know what that meant, but no, it doesn't
16:40:00: <brecht> LetterRip, slerp is for rotations, vertex positions are not rotations
16:40:35: <LetterRip> brecht - ermm isn't the transition between two vertex positions likely a rotation?
16:40:48: * Bobalicious is away: Jellyfish mind control hat-ON!
16:41:07: <joeedh> what if shapekeys were embedded in nla strips? then you could per-strip specify differeng mixing modes, mix, add, subtract, multiply, etc.
16:41:22: <marco2> kaito: our aim is to produce a clear code according to the specs so our project won't be another inused python plugin if everything works well
16:42:22: <joeedh> marco2: well, keep in mind having one-shape-key-per-phonome as a spec might be a bad idea. . .at least if its going into blender.
16:42:33: <joeedh> going into Blender on the C side I mean.
16:42:49: <LetterRip> gnight all
16:42:54: <joeedh> night
16:43:11: <stivs> python plugins that work seem to get used. and have the advantage that you can use C code in them for extensions.
16:43:37: <kaito> marco2: but who is going to be your reference? i.e. is that animators who do lipsync animation for movies?
16:43:39: <Briggs> slikdigit, when combining two shapes, a certain point they create 'broken' geometry, so you have to sculpt a new shape that is combination of those two. When your animation sliders get to a certain combination of shape 1 and shape 2, it blends from those to the 'combination shape' of 1 and 2
16:43:42: <MarcOO> joeedh: we want to make combination instead of one key only
16:43:45: <UnNamed> stivs: what speed for passing the data around?
16:43:49: <Briggs> slikdigit, this is how most FACS based animation systems work.
16:43:56: <joeedh> MarcOO: ok.
16:43:58: <slikdigit> Briggs: ah, yes, FACS
16:44:11: <slikdigit> I lack the patience to make so many shapes
16:44:19: * joeedh lacks the money for the manual :S
16:44:32: <MarcOO> Briggs : that what we we re thinking
16:44:33: <kaito> marco2: you might consider to ask the plumiferos team what kind of tool would speedup their work. Slikdigit here did a lot of lipsync too for elephants dream, and i think an editor as you picture here isnt what they are looking for really
16:44:36: <Briggs> slikdigit, thats why systems exist to autmagically transfer the shapes from one character to another.
16:45:14: <joeedh> MarcOO: also you guys might want to contact different animators and see what they think. . .maybe look on cgtalk.
16:45:25: <joeedh> I wouldn't post anything about your project there, though :)
16:45:53: <joeedh> at least not till it gets going.
16:46:02: <marco2> kaito : ok, indeed we have to consider what would be usefull for animators
16:46:15: <MarcOO> joeedh: ok good advise we 'll do
16:46:36: <UnNamed> MarcOO: any doc or publication about this lipsync?
16:46:43: <joeedh> http://emusiquegestion.free.fr/index.php?title=ExtraLipSync
16:47:02: <vladius> kaito: btw, will freestyle developers incorporate it as a python plugin?
16:47:16: <kaito> marco2: you could check on state-of-art in other 3d programs or in papers about tools used in movies
16:47:29: <kaito> blender should have statoftheart++!