Re: [Bf-committers] VSE Strip-Wise Rendering
On Tue, Sep 28, 2010 at 11:39 AM, Peter Schlaile wrote: > Anti-Shake or motion tracking sound like tools, that should run within a > seperate background rendering process. We could add something to the > interface, that enables an effect track to have a custom render/bake run. > Like: please render/bake motion tracking data into fcurves (which will > feed the entire strip into the effect bake function only once and we use the > fcurves later for actual frame translation and rotation.). If I may be so bold, I'd highly recommend that all of the time based tools reside in the same area, whatever that ends up. Optical flow, tracking, image stabilizing, rolling shutter removal, etc., _all_ require optical motion vector calculations and as such, the most robust option there is likely to build upon OpenCV or VXL (which I believe Nuke uses) and simply abstract the appropriate layer on top. OpenCV, from what I have seen, offers a good deal of choice in algorithm and such, which would allow Blender to provide options as to which algorithm the artist requires for a given sequence. This likely fits into the industry grade tool pipeline that Blender seems to work toward. Regarding motion vectors and tracking however, the ability to manipulate or add points (Empties?) is very much a mandatory feature. As such, this would extend a good portion of this into the 3D interface where it is well suited, as the bulk of the editing manipulation is already present. It is tremendously exciting to see new interest here... Sincerely, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] VSE Strip-Wise Rendering
Hi Leo, > Looking at the code for the VSE it appears solid, but not very modular, > nor suitable for effects that need access to more than the current > frame. Since the tools I have fall into that category ? the anti-shake, > for example, needs to compute the optical flow for each pair of frames ? > it is currently near-impossible to port them over in a way that would > give a good user experience or remain modular enough to be maintainable. Problem is: the idea behind the VSE is, that it should try to do most / all things in realtime. That doesn't alter the fact, that we need optical flow, so my idea was: add a optical flow builder, similar to the proxy builder in 2.49 and link the generated optical flow files to the strips. That makes it possible to: a) use optical flow files generated by other software (like icarus tracker) b) use optical flow information from scene files or even Open EXR-files (I'd think, the vector pass together with the Z-pass could be used for that) c) let the optical flow information be calculated in the background, when none is available and reuse it later for realtime display. >for each frame: >for each strip: >render >composite > > gets turned into: > >for each strip: >for each frame: >render >composite I don't really know, how you want to do that in realtime. But maybe I got you wrong. If you want to display one arbitrary frame in the middle of a Sequencer Editing, what exactly does your code actually do? My understanding of your idea is currently: I'd have to render everything from the beginning and that sounds, uhm, slw? :) > This way, we could do frame rate conversion naturally. We could do > speedup/slowdown, interpolation, anti-shake, and everything easily. > Effects that only require access to the current frame would still work > as a kernel inside a strip. Since the common base here is optical flow, I'd think, it is better, to generate optical flow files and use them with the current design. Anti-Shake or motion tracking sound like tools, that should run within a seperate background rendering process. We could add something to the interface, that enables an effect track to have a custom render/bake run. Like: please render/bake motion tracking data into fcurves (which will feed the entire strip into the effect bake function only once and we use the fcurves later for actual frame translation and rotation.). Since I have to rewrite proxy rendering for 2.5 anyways, we could add something like that, too. (The 2.49 proxy builder didn't run in background and was more or less a hack.) Regarding the tools you have written, do you thing, that adding per effect strip render/bake would solve your problems? (It could be done in such a way, that the bake function could request arbitrary frames from it's input track.) Cheers, Peter -- Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Build problem for X64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28.9.2010 15:13, Damir Prebeg wrote: > Hi Nathan, > >> > Files libfaac-0.dll, libfaad-2.dll, libmp3lame-0.dll, libx264-67.dll and > xvidcore.dll are still missing in repositories. They are not missing; instead, the cmake files still need to be adapted for the change that they are not there anymore. /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMof+KAAoJEKtfN7KsE0Ttfm4IALCiR4Js/fnzq2RfT51YbMPe GkTf2UMHAad1zmzdHEaGucMjhwivq/agirrbwoPmcpSDsOBVxTL3WpqOINoZZmAo UHIt90gYrpZ3NvVehW/pspotZNS8T9L4Ir/y1/cmHgYGxqPJ7EsEuBZubXR4iYYj SuqCaLcZoa+CQmMZy3C0uhSf391OiVqxr3vA/XwC1S7aukexOAWz9BfjsDASdB0K 8gjlFpEkOapePFHc1+xRgd22i9/U/iGeKdapy4P42uqQboib26lxfSW8UH/uGPPE Eu4vEqdVCOQm6hNmQjC0VsPIi9CkbXXQ5sC01bhU6NmaK46X0GSTlu3jdYhSjEE= =t7D3 -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Build problem for X64
Hi Nathan, > Since I'm using VC++ 2008 Express, I've had to add 'amd64' in > supported_arch > > list at line 235 in file > > scons\scons-local-1.2.0.d20090223\SCons\Tool\MSCommon\vs.py > > (supported_arch=['x86', 'amd64']) > > No idea why you have to do this, maybe because you use the express > version of vc++ 2008? (And I didn't know it even supported 64bit > compiling, I thought only vc++ 2010 express did that). > > I had to add amd64 because scons looks in that list what compiler supports. If it finds Express then scons exits before even tries to compile Blender. Officially VC++ 2008 Express doesn't like x64 and OPENMP but I have figured out how to enable support for both. Now, with help of cmake I can build 32 or 64bit but only from VC++ IDE since scons throws me those linking errors. > Make sure you use the correct Python version: > * use the latest 32bit Python 2.6.x install to build 32bit Blender > * use the latest 64bit Python 2.6.x install to build 64bit Blender > > If you don't you'll still run into linking problems. > Yes, I have and use 64bit python 2.6.6 > > Not related with this problem to this, about a week a go (before I've > tried > > to compile 64bit) I've started to have problems with 32 bit builds in > VC++ > > IDE because some files in ffmpeg libs are missing (libfaac-0.dll, > > libfaad-2.dll, libmp3lame-0.dll, libx264-67.dll and xvidcore.dll) > > > Make sure you have updated your lib/windows and lib/win64 checkouts. > I've updated our FFMPEG dependencies. > > Files libfaac-0.dll, libfaad-2.dll, libmp3lame-0.dll, libx264-67.dll and xvidcore.dll are still missing in repositories. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Screen-cast issues
I thought the fps in the render panel is not used for screen cast.
In the user preference window it has 2 properties for screencast.
FPS. which is described as the frame rate that the screencast is to be
played back.
Wait Timer(ms). which is described as the time in milliseconds between
each frame recorded by screen cast.
I played with changing the fps in the scene render panel and it didn't
seem to do anything.
On Tue, Sep 28, 2010 at 6:58 PM, Nathan Letwory
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 28.9.2010 8:42, Andrew Green wrote:
>> I have been playing with the blender screen-cast functionality. I have
>> noticed the timing never seems right for me.
>> Even when I modify the settings for screen-cast to represent what
>> should be a real time recording.
>> It is off by a lot. if i record for 30 seconds i will get 15 or 20
>> seconds video from it.
>
> That's because in user preferences FPS for screen casting is by default
> on 10. If you screencast directly to a movie, make sure you have the
> same FPS.
>
> /Nathan
>
>>
>> I think it's due to a couple of things.
>> After it has written one frame it will simply sleep for x ms and then
>> write the next frame. I'm pretty sure when it sleeps it will
>> overshoot. Also there is the extra time to actually save the frame.
>> This makes it worse over time.
>> There is also the possibility that an image has not been grabbed
>> yet(which is done separately by the job manager) when the loop resumes
>> which means it will go and sleep for an extra x ms.
>>
>> I really haven't given it much thought. Would it be the best idea to
>> get the system time when recording is started. Then use this to
>> determine when a frame should be written. This way a frame may be
>> saved slightly off time. Though the results wouldn't accumulate and
>> throw the results completely off.
>>
>> Heres what i was thinking in a tiny bit more detail. It's simple plus
>> if there is a system pause for 1 second when many frames should have
>> been written it will write those frames and make sure the time match
>> of the video and the real world.
>>
>> diffTime=currentTime-startTime;
>> if(diffTime>=framePause){
>> saveCurrentFrame();
>> startTime+=framePause;
>> }
>>
>> Would you guys agree that this is the cause of the issue?
>> Do you guys feel this is sensible solution for me to implement? Or do
>> you think I am crazy?
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> - --
> Nathan Letwory
> Letwory Interactive
> http://www.letworyinteractive.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMoa40AAoJEKtfN7KsE0TtJvUH/0x7OFbtwD5axlBVQ+uCBduX
> e5tj+urYKHeCFhF2N4c9MKS11H3Y5E3wjmh1TPWu+PTtd24BS7yYzxKhMya57G0Z
> DlzTy+UAAt/MTnjj4EM6pN75PnJTgHeZnDh9ZzLG03Yg0KoC51B1KXGJeHDWA1c5
> I3ge7d10YJySaNcU2qMqlP1n8HDbm39J1XCTCHIJaCh4KqymdmLOs//phnEydSzT
> HCGiqQbINwvwYvtWYSgtWX/aMRjTUoJ1R5i1oasIBsGFtxuvrV2xR9uR2UEi98bU
> n3YVzHpFL1/6OR/VbzWqCs5hDzCIZSDO8nr20vfIXZsfrZZ1eORgx+jvw2yDjkQ=
> =0CS3
> -END PGP SIGNATURE-
> ___
> 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] State Blender 2.5 documentation wiki
Dear Luca, > > can someone give me a note how is the state of the 2.5 > > documentation wiki > > (http://wiki.blender.org/index.php/Doc:Manual)? > > That's not the right location. > 2.4 : http://wiki.blender.org/index.php/Doc:Manual > 2.5 : http://wiki.blender.org/index.php/Doc:2.5/Manual Thank for clarification. > Later on we'll move 2.4 manual in > http://wiki.blender.org/index.php/Doc:2.4/Manual > but for now, at least until 2.5 is in beta, we'll still use 2.4 as > main documentation. The problem I all the time have when using Blender 2.5 is that the documentation does not fit very well to the implementation. Especially new and completely changed features are difficult to use in the right way (I fighted already with particles/hair, animation, lights and many other things). Thus I looked for some documentation which fit to 2.5. Torsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Screen-cast issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28.9.2010 8:42, Andrew Green wrote:
> I have been playing with the blender screen-cast functionality. I have
> noticed the timing never seems right for me.
> Even when I modify the settings for screen-cast to represent what
> should be a real time recording.
> It is off by a lot. if i record for 30 seconds i will get 15 or 20
> seconds video from it.
That's because in user preferences FPS for screen casting is by default
on 10. If you screencast directly to a movie, make sure you have the
same FPS.
/Nathan
>
> I think it's due to a couple of things.
> After it has written one frame it will simply sleep for x ms and then
> write the next frame. I'm pretty sure when it sleeps it will
> overshoot. Also there is the extra time to actually save the frame.
> This makes it worse over time.
> There is also the possibility that an image has not been grabbed
> yet(which is done separately by the job manager) when the loop resumes
> which means it will go and sleep for an extra x ms.
>
> I really haven't given it much thought. Would it be the best idea to
> get the system time when recording is started. Then use this to
> determine when a frame should be written. This way a frame may be
> saved slightly off time. Though the results wouldn't accumulate and
> throw the results completely off.
>
> Heres what i was thinking in a tiny bit more detail. It's simple plus
> if there is a system pause for 1 second when many frames should have
> been written it will write those frames and make sure the time match
> of the video and the real world.
>
> diffTime=currentTime-startTime;
> if(diffTime>=framePause){
> saveCurrentFrame();
> startTime+=framePause;
> }
>
> Would you guys agree that this is the cause of the issue?
> Do you guys feel this is sensible solution for me to implement? Or do
> you think I am crazy?
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
- --
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMoa40AAoJEKtfN7KsE0TtJvUH/0x7OFbtwD5axlBVQ+uCBduX
e5tj+urYKHeCFhF2N4c9MKS11H3Y5E3wjmh1TPWu+PTtd24BS7yYzxKhMya57G0Z
DlzTy+UAAt/MTnjj4EM6pN75PnJTgHeZnDh9ZzLG03Yg0KoC51B1KXGJeHDWA1c5
I3ge7d10YJySaNcU2qMqlP1n8HDbm39J1XCTCHIJaCh4KqymdmLOs//phnEydSzT
HCGiqQbINwvwYvtWYSgtWX/aMRjTUoJ1R5i1oasIBsGFtxuvrV2xR9uR2UEi98bU
n3YVzHpFL1/6OR/VbzWqCs5hDzCIZSDO8nr20vfIXZsfrZZ1eORgx+jvw2yDjkQ=
=0CS3
-END PGP SIGNATURE-
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch #24042: Toggle visibility/renderablilty for object and all child-objects
Dear developers, I just created patch entry #24042 "Toggle visibility/renderablilty for object and all child-objects" in the patch tracker. This patch is a proposal for changing the behavior of the toggle visibility/renderablity buttons in the outliner a little bit. What the the patch changes: When you have multiple objects which are linked via the parent relation to some main-object (many times this is an "Empty"-object) and you click on the toggle buttons for visibility and renderability for the main-object the visibility and renderability of that object only is changed, not the visibility/renderability of the child-objects. This is IMHO a little confusing and annoying, because to change the visibility/renderability of the whole multi-part object you have to click on each child-object (please correct me if this functionality is already there and I did not find it). With the patch the visibility/renderability of all child-objects is toggled, too, except those which are not selectable. Thus making the whole multi-object visible/renderable resp. not visble/renderable. The not-selectable-exception is IMHO useful if some object should e. g. never be shown or rendered, like helping objects for making holes in some other object etc. Please let me know what you think of this patch. Torsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
