Re: [Bf-committers] Autokey and 3D viewport outline
El 13/10/12 13:17, Guillermo Espertino (Gez) escribió: > What about a color outline (red/orange) around the 3d view? > It would be very noticeable without being distracting. > > Gez I mean, the proposed solution IS NOT distracting and it would be visible ONLY when users activate it. And that has a plus: Autokey effects can be very bad if you don't want autokey, so it's better to have an obvious visual hint that it's active to avoid fuckups So what's wrong with the outline? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Autokey and 3D viewport outline
El 13/10/12 05:00, Gianmichele Mariani escribió: > Agree with Daniel here. It needs to be' a visual indicator, one than > doesn't need the timeline to be open, and not flashing in front of you > What about a color outline (red/orange) around the 3d view? It would be very noticeable without being distracting. Gez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] lib/linux64 and libpng-1.5
El 23/09/12 16:56, Sergey Sharybin escribió: > P.S. There's a plan to get rid of pre-compiled Linux libraries as soon as > Debian Wheezy is released as stable. After this in all supporting > distributives all the dependencies would be much easier compilable than > continuing maintaining pre-compiled libraries from our side. I just downloaded 2.64 RC2 and I have the same problem in Debian Testing with JPGs, but PNGs seem to work. Why is that? It's because that build Blender is using pre-compiled libraries and should use Debian's? Will I have the same problem when 2.64 final is released? Gez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render and Scene Panel Audit?
El 27/09/12 09:45, Brecht Van Lommel escribió: > Basically: > > * Alpha mode should be turned into a transparent on/off setting, same > as Cycles. If it's off there is no alpha, if it's on it's > premultiplied. Oh, that makes sense and it would be easy to understand for anyone. Also, premultiplied as default seems the best option for render layers. Key doesn't offer a benefit for rendered images over a pre-divided associated image. > * RGB/RGBA is a file saving option, does not belong in the shading > panel. This option should default to RGBA and save alpha if it is > available. With the current Sky rendering that is not ideal, but if we > have a transparent on/off switch it makes sense. I wonder if it's really necessary to have a RGB/RGBA switch as a saving option if you chose "transparent" in the rendering panel. If you did that, is clear that you want transparent (RGBA) and not RGB. Leaving the transparent option and the RGB/RGBA switch in the output panel makes it necessary to select two options to get the right output. Two options is basically the same we have now. > * File formats should automatically convert premul<=> key alpha based > on whatever the standard is for that file format. So PNG key, EXR > premul, etc. I don't agree here. That shouldn't be automatic. Or at least if it's automatic, a non-destructive option to revert it should be offered (maybe a "prediction" based on the format could be used, giving the chance of changing it if it's wrong). That conversion is destructive, and there are a couple of edge cases where the conversion is not only not needed, but also undesirable. Sometimes you want to keep the RGB data from your unassociated alpha images for several reasons, like: - A masked unassociated file (a PNG for instance) stores the original RGB data of the fully transparent pixels, you could need it. - You could need to use an unassociated alpha format for a luminescent alpha over (for instance a photo of a candle shot over black background. The alpha channel shows the opaque parts but there is a glow in the masked part you want to keep and composite via an alpha over node). The second example is quite frequent, because it's necessary for compositing glares, glows and volumetric lights. Premultiplied formats should be used for that, of course. But if you bring your files from other applications like Photoshop or GIMP that's a problem, since those applications automatically multiply alpha when an associated alpha format is chosen. The problem here is that an associated alpha image is not necessarily an image where the RGB data was pre-multiplied by its alpha, so any file could be an associated alpha image, from an artistic point of view, depending on the effect you want to achieve, hence using a flag to define what's "premultiplied" or not doesn't cover all the possible cases. In my opinion inputs should be left as they are, and offer the chance of forcing pre-multiplication if it's needed, just like we have now. It takes a little effort from the user, but it covers all the possibilities. As you pointed out in the wiki page, Blender has to adopt one single alpha convention (and associated seems to be the most adequate option), but perhaps it's not possible to make it completely transparent to the user, because of the potential complexity of the compositing work. It's clear that having this kind of flexibility complicates things for color management, but apparently that's the path applications like Nuke followed, instead of automatic. Sorry for being repetitive, but there's a number of minor changes that can be applied to improve things considerably, like unifying the alpha convention of viewers and 3D view to expect premultiplied and make the application more consistent internally. This is what we have now: The textures preview expects associated (no matter what you chose in the shading panel) because shaders seem to expect associated alpha textures too. The GLSL 3D view expects unassociated (again, no matter what "alpha" is selected in the shading panel). Viewers seem to expect unassociated too. I don't think it's necessary to go through a complete overhaul of the internals to get that right. What it seems to be needed there is just skipping a multiplication in the 3D view and the image viewer and that would make those viewers consistent whith the shading system, which seems to expect associated. The inputs/outputs would be still in charge of the user, just like now. Gez ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Render and Scene Panel Audit?
El 26/09/12 18:38, Troy Sobotka escribió: > Suggestions: > > 1) Migrate Alpha to the Output panel where the other alpha oriented > output factors are stored. > 2) Migrate Color Unpremultiply to either the Output panel or the Color > Management panel. Also I think the "sky" option should be re-evaluated. Being the default, it does more harm than good, because it's completely useless for compositing, and RGBA images created with it will have all its semi-transparent pixels contaminated with the sky color, rendering them useless for using in other applications without some sort of background color removal (like After Effect's "premultiplied with color" option in the interpret footage dialog). In my opinion the sky background should be an option attached to the type of output. If it's RGBA, then sky is useless. If it's RGB without an alpha channel, then sky could be an option. There has to be a way to simplify the workflow, and make more straightforward to choose RGB or RGBA outputs, use composite nodes or not. That's the key of the problem: The only case when the sky option is useful is when the output won't have an alpha channel, so that option should be visible only when the output is RGB. Currently we have a default with RGB and Sky, and if you want to export a proper RGBA file you have to change two options, not one (and if you forget one of them and throw a long render you're screwed). And if you want to use the compositor you have to activate yet another option! It's three steps for something that should probably the default behavior. I haven't thought about this thoroughly, but what about just removing the alpha options from the shading panels and leave only the RGB and RGBA options there, showed in a more prominent way? If the user chooses RGB, it will use the sky background. If the user chooses RGBA, it will use the alpha "mode" set in the color preferences (premultiplied/straight)* and the "use composite nodes" option will be used (and probably the switch could go away too). I mean, why do we have to activate that option? What's the problem of having it always active when RGBA output is used? *) Maybe the alpha association should be set in the color management panel or even in the user preferences. Having it near the file output in the render panel can be misleading and lead users to think that it's an option that governs the alpha association of the output file. It should be perfectly clear that the option defines the default behavior for the alpha association in rendering, which is something that can be changed during compositing. ___ 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
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
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
