[Bf-committers] Blender roadmap article on code blog

[Campbell Barton]

On Tue, Jun 25, 2013 at 7:17 AM, David Jeske <davidj at gmail.com> wrote:
> I like the overall structure of this roadmap.
>
> It prompted me to cleanup and post my own 2013 Roadmap
> Wishlist<http://wiki.blender.org/index.php/June_2013_Roadmap_Wishlist_Jeske>,
> in-case it helps anyone's thinking/brainstorming.
>
> If Blender does only four things in the next few years, I would personally
> like them to be:
>
> 1) Include opt-in usage and automatic crash reporting in *every* blender
> build, and a web dashboard to live usage/crash stats to devs and the
> community. ( It looks like Google breakpad integration is
> in-progress<http://wiki.blender.org/index.php/User:AlexK/Breakpad>.
> )

While this _sounds_ good, I'm not so sure about it, Typically its most
useful if we get a blend file and steps to redo.
The backtrack on its own gives a hint at whats wrong but isn't enough
to fix the bug.

There is the case where users get crashes and dont report them- so it
would serve a purpose, but I suspect this would end up being used as
more of a statistic then something we actually use to fix bugs --- so
we could know for eg, that 30% or crashes are caused by running out of
ram. 20% caused by bugs in OpenGL drivers... etc

Since we are already deluged in bug reports from the tracker, we might
not be able to usefully handle more reports.

> 2) Increase community leverage, sharing, library asset encapsulation --
> more bridges between pro-artists and amateur blender pilots.
> Material-sharing is being figured out. I'd like to be able to enapsulate a
> more complex parameterized block into something with external "easy to use"
> push-buttons... For example, (a) let me group/encapsulate/re-use/share a 10
> node more advanced color-keying setup with an external mask-input,
> key-color-input, and exposed "internal RGB curve editor" used for
> foreground feather color correction; (b) let me wrap up the (scene, model,
> logic, animation, script, and render setup) for a 3d rendered and
> composited video-title-effect which can be used directly from the
> video-sequence-editor with simple animatable fields like "color", "title
> text", "font", "position".

+1

> 3) Refine and add more end-to-end capabilities. IMO compositing and VFX
> have a multiplicative not additive effect on Blender's utility. Somehow
> having merely "reasonable" integrated 3d+compositing+vfx is better for some
> tasks than having non-integrated best-of-breed tools for each. Small
> refinements could be a video-sequence-editor refresh and
> non-photo-realistic-shading to complement freestyle. Bigger leaps might be
> comic/graphic-novel layout and authoring, 3d-sound-rendering/sequencing, or
> live-broadcast/streaming using BGE/interactive-mode.

Useful but this isn't my field, to me its one of many areas that could
be improved for sure.

> 4) Incorporate an extension language which can support Intellisense,
> type-checking, and fast execution. A big goal is to make scripting easier
> with Intellisense. Another goal is to enable both new blender additions and
> old code to be in a solid, typechecked, memory-managed high-level-language.
> Until recently, I wished for .NET/Mono/C# integration, like some people
> wished for in Maya before they decided on Python. However, I think there is
> a new exciting option which is lighter weight and may fit better, and that
> is TypeScript + Javascript-V8. (Typescript <http://www.typescriptlang.org/>is
> a class-based Javascript "facade" with optional-static typing, and
> Javascript-V8 is 10-30x
> faster<http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=v8&data=u64>than
> CPython 3). Obviously this would be done in a way which leverages the
> investment in Python exports/apis.

This is really big project and not something a dev is likely to do
for-fun unless there is a high likely hood its going to be accepted in
trunk.

We could make the C++ RNA api more generally useful (what cycles is
currently using),
We could need to streamline the process of making a CPython module
that uses C++ RNA so its not a big deal for developers to create new
components in C++, currently its possible just not documented and only
cycles makes use of it.

Since we are already including LLVM it could be interesting to check
on the status of some LLVM based languages though from what I can tell
none have the same level of traction/maturity as .NET languages
(unless you count clang) - compared to C#, F#, IronPython etc.

There is nothing stopping us from bundling CPython/LLVM,
CPython/OpenCL but these are not quite the same as allowing a new
language in blender.
more ways CPython can send some computations to an foreign system and
get back results (yes, opencl is a language, but when its called from
python its limited a bit in what it can do within blender).

There are some interesting projects...
- https://github.com/dabeaz/bitey
- http://www.llvmpy.org
- http://documen.tician.de/pyopencl (not sure if this supports py3)

So this is big topic, not something that happens unless there is clear
defined direction and big push to develop the system and make it well
integrated.

> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell