Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi! Sorry for the late reply, but I had no internet for 3 days. Lars: The problem is that the Data API in blender doesn't have such mutexes and as such isn't thread safe, I guess making blender thread safe in this way, requires a GSoC project or even more on its own. Knapp: This is not about interpolation ;-) And why it's not readable? Imagine a thread accesses a pointer while another thread deletes that memory?! Brett: This doesn't change anything regarding the data access. Sergey: Well yes, the question is whether the main thread can do such a preprocessing. At least the cache can be updated with the current frame value once it's reached so that the value is correct at least the second time you playback after a change (not doing changes between first and second playback for sure). Regards ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Maybe this is an option; having the audio playback as the main time keeper, and then dropping frames in the view-port if they fail to render within time (within frame accuracy). But one problem is for a heavy scene this could mean that no frames are ever rendered in time and all are dropped, a work around could be: measure the average delay it takes to render a frame and skip ahead to rendering the next frame by that delay. -brett --- On Sun, 7/17/11, Martin Poirier wrote: > From: Martin Poirier > Subject: Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC > To: "bf-blender developers" > Date: Sunday, 17 July, 2011, 2:37 PM > 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 > wrote: > > > From: neXyon > > 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 > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
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 wrote: > From: neXyon > 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
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
On Sun, Jul 17, 2011 at 8:31 AM, neXyon wrote: > 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. > Use bezier curves to plot the sound volume but I guess you have that bit figured out having just read farther. Why is the animation data not readable multithreaded? I could understand writable though. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC
Hi. First, a disclaimer: I don't know the details of how the animation system is implemented. I do, however, work extensivly with multithreaded asynchronous data processing. My suggestion is this: - The animation system puts the audio-related info in a queue. A length of 3 images should be sufficient. Make it longer, if you have the memory and more cores. Make sure you have critical section/mutexes around the access code. - The audio system renders a frame and puts it in the same queue as the animation data. - The audio thread waits for the queue to be filled enough to its work. Whether you that by polling or a signal is up to you. It fetches the relevant animation data (Mutexes again!) and generates as much audio from it as it can. This is written to proper slot in the queue (e.g. one image before the animation data). - An additional thread (or a part of the animation thread) checks if audio data is available in the first entry of the queue, and sends it and the image to file. >From you description I'd guess, you need a mutex, a signal and a queue and the >code can remain almost unchanged. General advice, try to keep the number of mutexes low unless you a very compelling reason to do a more fine-grained locking. A few percent performance improvement is not a compelling reason to juggle 10 mutexes. My 2 cents Original-Nachricht > Datum: Sun, 17 Jul 2011 08:31:43 +0200 > Von: neXyon > An: bf-committers@blender.org > Betreff: [Bf-committers] Help needed! Animation problems for 3D Audio GSoC > 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 -- Dr. Lars Krueger Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
