[Bf-taskforce25] Output Targets

[Campbell Barton]

+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