Hi, I'd like to ask people with good knowledge of Blender's animation and animation related structures to please consider this problem, this is rather important for neXyon's GSOC project.
Thanks, Martin --- On Sun, 7/17/11, neXyon <nex...@gmail.com> wrote: > From: neXyon <nex...@gmail.com> > Subject: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC > To: bf-committers@blender.org > Received: Sunday, July 17, 2011, 2:31 AM > Hi guys! > > There's a serious problem with the way how animation works > in regard to > audio. The main problem is, that the animation system > pushes the output, > so it sets the data, renders a frame, advances to next > frame (setting > the data there) and renders again and so on, this works > pretty good for > video. But it doesn't work with audio, especially as audio > has a very > high temporal resolution (48000 eg. samples per second) > compared to > video (eg 25 frames per second) and moreover for audio the > output device > pulls the data, instead of the animation system pushing it, > so the other > way round. > > I talked to Martin (Poirier) and Joshua (Leung) and even we > three > together cannot think up a nice solution for the problem, > maybe some > genious mind here on the list who is more into the > animation code than I > am has a really nice idea. > > Here are specific problems in detail: > > * Subsample Accuracy: To avoid stair steps as we currently > have in > volume animation. > * Multi Threading: Audio runs in a separate thread. > * Speed: The access mechanism has to be realtime capable! > * Asynchronous access: Audio playback is ahead of video > playback > normally (buffering the samples, feeding them to the output > device). > > The first point can be solved easily with a proper > interpolation if you > have two nearby samples, one in the past, one in the > future, so this > basically requires the animation data to be cached/buffered > somehow or > at least asynchronous accessible. As the cached data also > solves points > 3 and 4 it's pretty obvious that we need the data cached, > we had that > conclusion already. > > Questionable is now how to get the cache? One obvious > solution is to > require the user to "bake" it, but this heavily impacts how > easy the > system can be used and as we also already concluded this is > a really > ugly solution. Better is the automatic caching which leads > us to the > problem point 2 multi threading. I don't know if it's > possible to cache > in the main thread? I bet not. And as long as blenders > (animation) data > isn't accessible multithreaded we still have no solution > for the problem. > > So now your help is needed. Any ideas? If not I'll have to > do the baking > solution to finish the project. > > Regards > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
