[Bf-committers] blendercasts reloaded...

[blenderleo]

Macros sound interesting, and the function is close to the idea of 
blendercast.

Does a script (addon) have access to the latest operations (and their 
settings!)?
If every op is recognized by the script and stored in a way like 
"bpy.ops. ...", then each op could be redone easily, I think.
I'll trust in the dev's opinion ;)

Am 23.11.2013 17:41, schrieb patrick boelens:
> A long, long time ago I remember there being a discussion about macro's in Blender. Iirc the core concept of those was the same: allow a user to record a set of actions and replay them.
>
> To me it seems like the proposed Blendercast would rely heavily on such a feature. If macros ever get developed in the future, this may be something to keep in kind. For example, they could be extended to allow saving to and loading from files (i.e.: boxModelHouse.macro), jumping to a particular time or "step", setting a playback speed and show the name and parameters of the action being performed in real-time (i.e.: Extrude face (0, 0, -0.5), Scale face (0.2, 0.2, 0.2)).
>
> Perhaps something like that would be a more feasible alternative. It could then be used as an addition to tutorials for instance, both written and screencasted, as well as having a wider use-case.
>
> Just my two cents.
>
> -Patrick
>
>> From: brechtvanlommel at pandora.be
>> Date: Sat, 23 Nov 2013 17:11:59 +0100
>> To: bf-committers at blender.org
>> Subject: Re: [Bf-committers] blendercasts reloaded...
>>
>> On Sat, Nov 23, 2013 at 4:44 PM, Gaia <gaia.clary at machinimatrix.org> wrote:
>>> On 23.11.2013 15:30, Brecht Van Lommel wrote:
>>>> For me the reasons not to do this are:
>>>>
>>>> * It shifts work from tutorial makers to developers, and it's the
>>>> developers that are already the bottleneck at the moment, we have many
>>>> people making tutorials. So developer time seems a more rare resource
>>>> at the moment.
>>> I am not sure why this would shift work from tutorial makers to developers.
>>> Or do you mean "creating this tool would need developer resources" ?
>>> Otherwise why would tutorial makers not use such a tool ? Its not so
>>> different
>>> to use compared to creating screen casts ...
>> I think you would want to implement this feature to make it easier for
>> people to make tutorials or to help them make better tutorials? So
>> basically that means you will have developers spending time helping
>> out by implementing this feature (which is really complex), and it
>> seems like those resources would be best spent elsewhere.
>>
>>>> * I have never seen such a system done well in other applications, the
>>>> few times I've come across it, it's always been pretty frustrating.
>>> What made these tools frustrating ? Is this a bad concept or did you
>>> only step
>>> into tools which had it badly implemented ?
>>>> I'm not sure why, maybe it's just a coincidence and there are
>>>> applications (of Blender's complexity) out there that do this very
>>>> well.
>>> This actually keeps me on track :) Actually this is a good argument for
>>> continue thinking about how it could be done better :)
>> My guess is that it is a bad concept because it's a fragile high tech
>> solution to a problem that already has a proven low tech solution
>> (video tutorials), where the tutorial creator has more control by
>> being able to take their recorded video into a video editor to cut and
>> enhance it, without working within the inevitable limitations of a
>> solution like blendercast.
>>
>> Brecht.