[Bf-committers] Blender roadmap article on code blog

[Ton Roosendaal]

Hi,

Been busy all week with other stuff, interesting long thread :)
Quick observations below:

> 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. 

I always wondered what other projects/companies do with such reports. Is there a public example where I can see the handling of such report logging, with evidence for how this is being used well, the benefits? Or is it just for statistics?

> 2) Increase community leverage, sharing, library asset encapsulation --
> more bridges between pro-artists and amateur blender pilots. <snip>

Good ideas, for me that's part of the asset project in our roadmap.

> 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. <snip>

Lots of this is also just because how things evolved. One by one. Not as part of a grand master plan. Although I agree with the benefits you mention, I'm very wary for the consequences of simply adding it. We have to keep track of (existing) design focus, stability, keeping it manageable, etc. 

For example: the Sequencer code now can get a full makeover without breaking the rest of Blender. It's highly needed to do that.

Solutions for having tracking/compositing/sequencer work together are there too. What I'd like to explore is some kindof image-depsgraph. A user then can manage image dependencies in Blender like: render to image, which gets used as a texture in other render, which goes to compositor, which goes into a VSE, etc etc.

> 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.

I can't add much to what has been said in other replies here. I also don't know any of these languages... but to me it seems we're really not doing that bad now. I don't see evidence Python is not satisfying current (technical) users either.

- Where Python is too slow (I/O), we can also improve the api a lot still. For our UI now it's more than fast enough.

- For Node "plugins" where speed is crucial (render, compo, future particle, modifiers, etc) we should explore first what already have. OpenCL, OpenShading, LLvm, ... or just a good C/C++ api.

-Ton-


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