[Bf-taskforce25] Output Targets

[Dalai Felinto]

Hi Brecht,

I'm using your last commit (21829) and the gain with your propose is
really visible (literally visible since it frees a lot of space). I
think that's definitively better then having game_buttons and
game_logics. Definitively a go !

A question:
Are we going to hide only buttons?
IMHO we could also hide Nodes (all composite nodes, all texture nodes,
a few material nodes), editors (sequencer, sculpt maybe), ...

Cheers,
Dalai

2009/7/23 Campbell Barton <ideasman42 at gmail.com>:
> +1, for UI switching based on an output target.
>
> Id recommend we support 2 cases.
>
> 1) An external script copied into our scripts dir can register an
> output target without any UI functions. (for render export, a single
> render class would be registered). In this case blenders default UI
> would display as usual.
>
> 2) The external tool can define its own UI panels per category.
> each category thats defined by the script would override all blenders panels.
> Category could be divided as they are in the UI, - Material/Texture/World etc.
> ---
>
> This way people writing new outputs are not instantly faced with
> writing their own UI's, they can just use blenders settings where
> needed. But when they want to add their own options they can register
> their own panels.
>
> Replacing an entire category with your own buttons might sound like
> overkill, but I think its easiest to manage and least error prone.
>
> If a script author wants to use one of blenders existing panels
> without duplicating it, they could import the "buttons_material.py"
> and register one of its panels as their own. - all in python so we
> don't have to worry about merging 2 outputs panel sets in the api.
>
> Otherwise IMHO Blenders Python UI is high level enough that copying
> python scripts to base your own panel set off is OK.
>
> Defining new categories would be nice but not a priority.
>
> On Thu, Jul 23, 2009 at 1:33 PM, Daniel H<gg20k1 at gmail.com> wrote:
>> I agree, this is a great idea. Especially for the new artists who try
>> Blender, hear about render engine XYZ and wonder why transparency isn't what
>> they expect, or whatever.
>> Speaking off (off topic a little), will things like the material preview
>> have the ability to be performed by the external render engine? That would
>> be brilliant.
>> The trick I see is in the last part of your message, Brecht. I really have
>> no idea on this, so I'm just thinking out loud, but doesn't the render
>> engine have to provide a config file or such to let Blender know what exec
>> to run and library info? If so, can't that just be expanded to include
>> functions/features that the engine knows how to handle/target?
>> I really should get into the code someday and see what all y'all are doing
>> to make things run...
>> Daniel
>>
>>
>> On Thu, Jul 23, 2009 at 3:03 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
>>>
>>> +1 !
>>> I really think this is something useful/necessary.
>>>
>>> So how about a profile option? Blender could come with a few pre
>>> configurated profiles (Full, BGE, Yafaray, ...) and could have an
>>> option to let the user define it's own profile. (also an option to an
>>> external render engine to define it profile on-the-fly).
>>>
>>> My idea:
>>> When you go to [Profile Edit Mode] all the panels that are disabled
>>> appears as disabled/dissaturated/grayish (as we have already for
>>> disable buttons). You then have the option to go through the whole
>>> Blender and disable/enable editors, panels, buttons. Once you are done
>>> you click stop editing and all the disabled options disappear.
>>>
>>> > F12 could even start the game (ok, perhaps that is a bit too far :).
>>> It's a nice idea, but I think that mixing default keymaps is messy. I
>>> would rather stick to (1) Blender default keymap  (2) User default
>>> keymap
>>>
>>> > Also then the scene and physics panels could show game engine related
>>> > properties instead of having them in the logic editor or a separate tab.
>>> I'm not sure I like this panel-dancing thing :) I think a simple
>>> enable/disable option would make easier to remember where the settings
>>> are in different profiles.
>>>
>>> > The main issue against I think is that for the game engine you also
>>> > sometimes bake something with the regular render engine, or do some
>>> > simulation you bake into shape keys etc. This would require explicitly
>>> > switching the engines each time. I'm not sure if this is a big problem,
>>> > i.e. perhaps separate files are used for this in many cases, need
>>> > artists feedback on this. There could also be a shortcut key for it of
>>> > course, to make switching fast.
>>> I don't think switching engines (or profiles as I'm calling it) it's a
>>> big problem. And I believe that separate files are very common for
>>> that kind of stuff.
>>>
>>>
>>> Cheers,
>>> Dalai
>>>
>>> http://blenderecia.orgfree.com
>>> 2009/7/22 Brecht Van Lommel <brecht at blender.org>:
>>> >
>>> > Hi,
>>> >
>>> > An idea I've been thinking about is showing / hiding panels and buttons
>>> > based on the output target / engine. By that I mean external render
>>> > engines, but also the game engine or external game engines. Hiding all
>>> > the settings that are irrelevant to that engine would make it much more
>>> > clear what is supported.
>>> >
>>> > For example for the game engine only a subset of material options is
>>> > supported, and it would be much clearer showing only the supported ones.
>>> > Also then the scene and physics panels could show game engine related
>>> > properties instead of having them in the logic editor or a separate tab.
>>> > F12 could even start the game (ok, perhaps that is a bit too far :).
>>> >
>>> > The main issue against I think is that for the game engine you also
>>> > sometimes bake something with the regular render engine, or do some
>>> > simulation you bake into shape keys etc. This would require explicitly
>>> > switching the engines each time. I'm not sure if this is a big problem,
>>> > i.e. perhaps separate files are used for this in many cases, need
>>> > artists feedback on this. There could also be a shortcut key for it of
>>> > course, to make switching fast.
>>> >
>>> > Further there is also the implementation issue, for external engines you
>>> > can't just place if() statements in the panel code, there needs to be
>>> > some other way to define what to show. Not sure how to do this best yet,
>>> > ideas for that are welcome too.
>>> >
>>> > Brecht.
>>> >
>>> >
>>> > _______________________________________________
>>> > Bf-taskforce25 mailing list
>>> > Bf-taskforce25 at blender.org
>>> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>> >
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>