[Bf-committers] OpenGL ES 1.1 or 2.0 for mobile
Just to clarify a bit about numbers: To run GLES 2.0 you need an android version = 2.2 http://developer.android.com/resources/dashboard/platform-versions.html It means 93.9% of phones are compatible. Ps: my phone is a very entry level one more than an year old and it supports gles 2. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] OpenGL ES 1.1 or 2.0 for mobile
More like 82% http://developer.android.com/resources/dashboard/opengl.html There are phones with android = 2.2 which don't have hardware support for GLES 2.0 DiThi 2012/6/5 Francesco Zoffoli maker...@gmail.com: Just to clarify a bit about numbers: To run GLES 2.0 you need an android version = 2.2 http://developer.android.com/resources/dashboard/platform-versions.html It means 93.9% of phones are compatible. Ps: my phone is a very entry level one more than an year old and it supports gles 2. ___ 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] Masks are not only for Mattes
El 05/06/12 02:46, Troy Sobotka escribió: It would seem like a wonderful juncture to perhaps analyze our design choices and consider future limitations at this juncture... +1 This implementation is somewhat disconnected from the compositor. Masking and tracking is usually more necessary in the composite context than in a single clip context. My gut says that the right place for tracking and masking would be on top of the viewer, and probably extending the image/UV editor adding these functionalities as modes would be more flexible than having a separate window. If tracking and masking would be nodes, double clicking on them could connect the output to the viewer window (UV/Image Editor) and display the proper widgets and options instead of having to change manually windows and modes. That could also work for widgets for transform nodes, for instance. Gez. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
The UV editor is suited for UV editing and reviewing what parts of the image go to what parts of the mesh. The UV editor can be seen as an image viewer/painter, but, in the end it is not a swiss knife of functionality either. Its primary intended for modifying the data themselves while the track editor and compositor can be seen as operating -based- on the data. IMO, this discussion should not be targeted at the uv editor but to a better interoperability between compositor/tracker. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Masks are not only for Mattes
I think the mask editor could be more generic: Consider a mask as a raster 2D vector image input, could be edited only in the UV/image editor as a vectorial image ( with the possibility to view a video/image backdrop) adding the current tools of the 2d bezier curve ( shape keys, modifiers..), not in the video editor as a mask (now the video editor is full of tracking information). Later could be a start development of vectorial textures, and if you add the ability to rasterize color and edges (antigrain lib), and 2D bones, we have the possibility of 2D animations finally!! (flsh, Anime Studio...), animated vector textures, toon, and 2D FX =:-) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
And how would you parent a mask to a track marker in the UV editor? Besides, editing the mask in a 3rd place makes the workflow very clumsy. Jump from UV editor to Track editor to compositorIMO the current integration is fine, what is lacking IMO is support for static images. If this fits into the tracker or the compositor or some combination of the two is another issue. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
El 05/06/2012 18:45, Antony Riakiotakis escribió: And how would you parent a mask to a track marker in the UV editor? With drop-down menu with a track marker names. I think the code mask tools can be a gateway to integrate vector images in the blender workflow, animated vector textures, 2D animation., Besides, editing the mask in a 3rd place makes the workflow very clumsy. Jump from UV editor to Track editor to compositorIMO the current integration is fine, what is lacking IMO is support for static images. If this fits into the tracker or the compositor or some combination of the two is another issue. ___ 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] Masks are not only for Mattes
El 05/06/12 13:23, Antony Riakiotakis escribió: The UV editor is suited for UV editing and reviewing what parts of the image go to what parts of the mesh. The UV editor can be seen as an image viewer/painter, but, in the end it is not a swiss knife of functionality either. Its primary intended for modifying the data themselves while the track editor and compositor can be seen as operating -based- on the data. IMO, this discussion should not be targeted at the uv editor but to a better interoperability between compositor/tracker. Ok, maybe I didn't express myself with enough clarity. I meant that we have the composite viewer in one place and the tracking/masking tools in another. Since viewers and image analysis tools live currently in the UV/Image editor, I proposed to take masking and tracking there, but maybe it's better to have a specialized viewer window (perhaps the same clip window) and take the viewer and image analysis tools from the UV/Image editor to the clip editor window. The point is having masking and tracking also available for composites, not just for clips. And having both operations working as nodes instead of separated tools would be more flexible because you could feed those tools with both, footage and (pre)composites. Gez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
IMO linking track to mask should be done in compositor by linking data together. Lets drop tracker, and talk about animation. Let say you have a 3 object animated in your scene. You get its position to screen and need some kind of shape around it (for whatever reason you can image). So you would link this data onto the Shape anchor point, and then animate the shape itself, all that in the compositor. Another case : I mixed a few stock footage together to create a nice explosion. Now I need to place this explosion on the ground, and I would like to draw a mask around it to blend it and feather it a bit more with my background. How do you that ? - Creating a node in comp to bring back data into Clip editor ? you loose the interactivity of quick masking - Render your explosion footage first, bring it into the clip editor, do the mask on it and looking into another compositor output viewer to see how the masking I'm doing in Clip Editor is looking so far ? huge waste of time, and not so confortable Masking need to be flexible, re-usable, and as interactive as it can get. Having it in CE is nice for garbage masking (with a big G) which can be used by trackers to know which track area it should use, or perhaps for keying... but not for compositing at all. But again, I guess this is just the first step of a long time wanted feature :) 2012/6/5 Antony Riakiotakis kal...@gmail.com And how would you parent a mask to a track marker in the UV editor? Besides, editing the mask in a 3rd place makes the workflow very clumsy. Jump from UV editor to Track editor to compositorIMO the current integration is fine, what is lacking IMO is support for static images. If this fits into the tracker or the compositor or some combination of the two is another issue. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
This is maybe a ridiculous suggestion: feel free to shoot it down: - we currently have one 3D editor. Here we do all our 3d tasks, modelling, animation, rigging, curves, meshes, etc. We can select and manipulate many different types of 3d objects, in different ways. -we can do *much less* things in 2d (blender is after all a 3d program). Yet we have multiple specialized windows for 2d editing: UV editor, movie clip editor. (arguably the sequence editor is some sort of 2d nla). So maybe, we are making 2d editing too compartmentalized; and we should have 1 2d editor where you can do any 2d tasks? or is this silly? I'm not actually pushing for this, it is only an observation/idea. On Tue, 2012-06-05 at 13:59 -0300, Guillermo Espertino (Gez) wrote: El 05/06/12 13:23, Antony Riakiotakis escribió: The UV editor is suited for UV editing and reviewing what parts of the image go to what parts of the mesh. The UV editor can be seen as an image viewer/painter, but, in the end it is not a swiss knife of functionality either. Its primary intended for modifying the data themselves while the track editor and compositor can be seen as operating -based- on the data. IMO, this discussion should not be targeted at the uv editor but to a better interoperability between compositor/tracker. Ok, maybe I didn't express myself with enough clarity. I meant that we have the composite viewer in one place and the tracking/masking tools in another. Since viewers and image analysis tools live currently in the UV/Image editor, I proposed to take masking and tracking there, but maybe it's better to have a specialized viewer window (perhaps the same clip window) and take the viewer and image analysis tools from the UV/Image editor to the clip editor window. The point is having masking and tracking also available for composites, not just for clips. And having both operations working as nodes instead of separated tools would be more flexible because you could feed those tools with both, footage and (pre)composites. Gez ___ 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] Masks are not only for Mattes
+100 for that in the viewer (whatever if its ImageViewer or Composite or new space. You should be able to work directly on your comp. and there is no point to link mask to a footage. a Mask should be rasterized in comp and plug into alpha or matte socket Having it in MCE is nice for garbage tracking, but not suited for compositing at all ! (I'm not even talking about motion design where you'd actually play with shapes and keep it as is) 2012/6/5 Guillermo Espertino (Gez) gespert...@gmail.com El 05/06/12 13:23, Antony Riakiotakis escribió: The UV editor is suited for UV editing and reviewing what parts of the image go to what parts of the mesh. The UV editor can be seen as an image viewer/painter, but, in the end it is not a swiss knife of functionality either. Its primary intended for modifying the data themselves while the track editor and compositor can be seen as operating -based- on the data. IMO, this discussion should not be targeted at the uv editor but to a better interoperability between compositor/tracker. Ok, maybe I didn't express myself with enough clarity. I meant that we have the composite viewer in one place and the tracking/masking tools in another. Since viewers and image analysis tools live currently in the UV/Image editor, I proposed to take masking and tracking there, but maybe it's better to have a specialized viewer window (perhaps the same clip window) and take the viewer and image analysis tools from the UV/Image editor to the clip editor window. The point is having masking and tracking also available for composites, not just for clips. And having both operations working as nodes instead of separated tools would be more flexible because you could feed those tools with both, footage and (pre)composites. Gez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
Guys, i've got no idea what you're arguing here about. All current discussion is like current masking tools are not good enough to be used for compositing and that's indeed correct. It was developed to be used for greenscreen keying needs to resolve project Mango's needs. And from this POV defining masks in clip editor totally makes sense because it requires close interaction with tracking stuff. Current design of mask editing is flexible enough to be integrated into another spaces like image editor (which is in fact pretty much easy) and even compositor (which is a bit more tricky because it'll require some design changes in compositor itself and it's not priority for now). Rough roadmap would be: - Finish usecase related on masking garbage of footage greensreen keying (which implies improvements in feather control, rasterizer and so) - Probably it'll also require integrating masking tools into Image Editor to be able to mask garbage using result of keying node as reference backdrop - Check on possibilities of integrating this tools into compositor. So i'd suggest to be a bit more patient and instead of continuing this not actually useful discussion (we're aware of all this!) return back to work. -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
El 05/06/12 14:58, Bassam Kurdali escribió: This is maybe a ridiculous suggestion: feel free to shoot it down: - we currently have one 3D editor. Here we do all our 3d tasks, modelling, animation, rigging, curves, meshes, etc. We can select and manipulate many different types of 3d objects, in different ways. -we can do *much less* things in 2d (blender is after all a 3d program). Yet we have multiple specialized windows for 2d editing: UV editor, movie clip editor. (arguably the sequence editor is some sort of 2d nla). So maybe, we are making 2d editing too compartmentalized; and we should have 1 2d editor where you can do any 2d tasks? or is this silly? I'm not actually pushing for this, it is only an observation/idea. That's interesting! What about a viewer window that can fed with the viewer from composite, the 3D viewport (from camera) or individual footage? They could be used even as layers (for instance, the 3D view from camera on top of a compositing viewer, or the composite over an imported footage). Having masks, tracking and node widgets on top of that would be incredibly flexible. It's also just an idea, but perhaps an idea that is worth to explore and draft, at least to see if there are any significant issues. Gez. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Change of MinGW64 compiler
Hi all, recently I have looked into a problem with MinGW-w64 builds that causes crashes when rendering with multiresolution and subsurf modifiers with openmp enabled. From correspondence on MinGW-w64 mailing list it looks like it is related to the specific MinGW-w64 build we are using. I have recently built with openmp enabled with another MinGW-w64 package and it looks like it works fine. There are a few things to take care of, mainly recompile openexr to resolve some thread issues but everything else seems to be OK, though other issues may creep up of course. Are there any objections to this? I am aware we may have to update the builder too but I will test whether a recompiled openexr works with the current compiler without issues. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
I think I have judged prematurely, masks can have some usefulness in the image editor too, especially in the context of painting. But from what I gather from the mango thread all these things are possible and can be done, it's just that currently they are just implemented for rotoscoping. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Masks are not only for Mattes
And from this POV defining masks in clip editor totally makes sense because it requires close interaction with tracking stuff. I can't say I do agree with that statement, but I get the point... yet sometimes those kind of thinking brings really bad design which tends to stick around for a while :p ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Change of MinGW64 compiler
hi i get this error compiling the x64: using windows 7 x64 and scons, svn r47487 and lib is updated! http://www.pasteall.org/32654 Regards Yousef Harfoush ba...@msn.com Date: Tue, 5 Jun 2012 22:33:35 +0300 From: kal...@gmail.com To: bf-committers@blender.org Subject: [Bf-committers] Change of MinGW64 compiler Hi all, recently I have looked into a problem with MinGW-w64 builds that causes crashes when rendering with multiresolution and subsurf modifiers with openmp enabled. From correspondence on MinGW-w64 mailing list it looks like it is related to the specific MinGW-w64 build we are using. I have recently built with openmp enabled with another MinGW-w64 package and it looks like it works fine. There are a few things to take care of, mainly recompile openexr to resolve some thread issues but everything else seems to be OK, though other issues may creep up of course. Are there any objections to this? I am aware we may have to update the builder too but I will test whether a recompiled openexr works with the current compiler without issues. ___ 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] MSVC + Scons build error
The specification of the following headers has come off by Sconscript of makesrna. incs += ' #/intern/smoke/extern' ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Improved Mini-Axis
http://www.pasteall.org/pic/show.php?id=32768 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
