[Bf-committers] Enhancement of texture management in Properties (buttons space)

[Brecht Van Lommel]

Looks good to me, tested it with a bunch of different setups and it
seems to handle it all fine, even the blender internal
texture/material nodes which seem to break on every change here :) The
code looks ok to me too, did not find anything to comment on.

On Thu, May 16, 2013 at 3:40 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> Hi devs,
>
> The goal of this patch ( http://www.pasteall.org/42290/diff ) is to
> address the somewhat weak handling of stackless textures in Blender with
> default (BI) renderer. To do so, it's defining an "other" texture
> context, and when in this one, it switches to using the "new shading"
> texture handling already known with Cycles engine.
>
> So now, in the new "other" tex context, you can (depending on active
> data) have direct access to modifiers', force's or brushes' textures...
>
> I also refactored a bit how texture contexts are handled (once again, we
> had some quite similar code in both space_buttons and RNA sources). This
> should also solve some harmless glitches like "no texture context
> selected in UI" sometimes when you remove data related to current
> texture (see e.g. after removing the material from default cube, in
> startup scene).
>
> This usage of two different systems for textures, and the handling of
> switches between them, has been a bit tricky to get working right, but
> it is OK now I think. I also had to add a bool flag to buttons space,
> SB_TEX_USER_LIMITED (use_limited_texture_context in RNA), which
> indicates "new shading" texture code whether it has to ignore materials,
> lamps etc. (BI) or not (Cycles).
>
> Btw, pinned textures from modifiers/force/etc. were also broken (showing
> nothing), now it should work too.
>
> Best regards,
> Bastien
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers