subject:"Re\: \[Bf\-committers\] Blender roadmap article on code blog"

Re: [Bf-committers] Blender roadmap article on code blog

2013-07-02 Thread Vincent Akkermans

On Monday, 1 July 2013 at 20:21, David Jeske wrote:
 On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org 
 (mailto:t...@blender.org) wrote:
  
   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?
   
  
  
 Billrey's blender blog recently posted a link to this old but excellent
 talk on Firefox UI design, from 2011. At 38 minutes, it talks about their
 Usage Statistics Heat Map, and how they used it to streamline the option
 locations when redesigning menus.
  
 http://www.youtube.com/watch?v=hMDBwa4huUY#at=302
  
 The whole talk is really worth watching.. it's both an interesting
 visualization of some common UI design principles, and Firefox's approach
 to enabling open-source innovation by establishing clear design-rules to
 empower and enable more freedom within those design rules.
  
  

There are a few other examples that I know of.  

Firstly, there are some good papers from Autodesk Research that talk in detail 
about how they use data from their Customer Involvement Program (read: usage 
data collection) to prototype and verify new features. A recent work is Patina 
[1], where they use heatmaps, like in the Firefox talk by Faaborg. However, 
they present these heatmaps to the user so that the user becomes aware of the 
features that other people (from the same community) use. This allows them to 
discover features of complex software. Another example is CommunityCommands [2] 
in which a user is profiled through their command usage and by means of a 
collaborative filtering technique new commands are recommended to the user, 
based on the type of usage. Chronicle [3] is worth mentioning as well, because 
it uses this type of data to allow the user to query and retrieve information 
from the design process of a document.  

Then there's work by Terry [4] who instrumented The Gimp to collect usage data 
with an open source ethos. The analysis of it isn't fully explored though.

There's a good overview of how to employ usage data in usability studies by 
Hilbert and Redmiles [5]. Although the paper is from quite a while ago it 
introduces many aspects one has to think about when doing this kind of 
usability work.

Another good example is from Heer and others [6] where they describe how they 
used usage data to understand user behaviour and manage to turn this into 
concrete improvements of their visualisation software.

Microsoft also collects usage data [7], but I haven't found (also haven't 
looked too hard) many details.

I personally think there is a lot of value in remotely collected usage data for 
a) users, as can be seen from the Autodesk research, and b) developers, as can 
be seen from [7].

Apologies for the barrage of references.

Cheers,

Vincent

  
[1] http://autodeskresearch.com/publications/patina
[2] http://autodeskresearch.com/publications/communitycommands
[3] http://autodeskresearch.com/publications/chronicle
[4] Terry, M., Kay, M., Van Vugt, B., Slack, B., and Park, T. Ingimp: 
introducing instrumentation to an end-user open source application.  
[5] Hilbert, D.M. and Redmiles, D.F. Extracting usability information from user 
interface events. ACM Computing Surveys (CSUR) 32, 4 (2000), 384–421.
[6] Heer, J., Mackinlay, J., Stolte, C., and Agrawala, M. Graphical Histories 
for Visualization: Supporting Analysis, Communication, and Evaluation. 
Visualization and Computer Graphics, IEEE Transactions on 14, 6 (2008), 
1189–1196.
[7] https://www.microsoft.com/products/ceip/EN-US/default.mspx
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-07-02 Thread CoDEmanX

Am 29.06.2013 16:41, schrieb Ton Roosendaal:
 - 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.

There are two areas where it's notably slow: user preferences input and 
addon UI - due to the high number of layout elements I guess. However, 
it's acceptable in this area.

Where python performance really bugs me is I/O. Due to GIL, python can't 
make use of multi-core systems (runs with max. 25% of an i5 with two 
real cores / four virtual cores). And multiprocessing isn't really 
applicable, since blender doesn't allow multiple threads accessing the 
RNA system without crashes.

Looking at the OBJ importer, the real bottleneck is the mesh splitting 
code. It takes a serious amount of time for gigabyte-sized OBJs, and a 
huge amount of memory (like 500 MB OBJ, 6 GB mem). Not sure if one could 
optimize the python code, but a C/C++ importer would always be superior 
(see Meshlab speed!). Any plans on merging assimp support from Bratwurst 
into trunk?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-07-02 Thread Jürgen Herrmann

Hi,

Wouldn't it be possible to implement a c/c++ importer and expose it to the 
python api in a compatible way?

The obj file structure is quite straightforward and should be easy to 
implement. But I have no experience with blenders python interface.

/Jürgen

Am 02.07.2013 um 19:45 schrieb CoDEmanX codem...@gmx.de:

 Am 29.06.2013 16:41, schrieb Ton Roosendaal:
 - 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.
 
 There are two areas where it's notably slow: user preferences input and 
 addon UI - due to the high number of layout elements I guess. However, 
 it's acceptable in this area.
 
 Where python performance really bugs me is I/O. Due to GIL, python can't 
 make use of multi-core systems (runs with max. 25% of an i5 with two 
 real cores / four virtual cores). And multiprocessing isn't really 
 applicable, since blender doesn't allow multiple threads accessing the 
 RNA system without crashes.
 
 Looking at the OBJ importer, the real bottleneck is the mesh splitting 
 code. It takes a serious amount of time for gigabyte-sized OBJs, and a 
 huge amount of memory (like 500 MB OBJ, 6 GB mem). Not sure if one could 
 optimize the python code, but a C/C++ importer would always be superior 
 (see Meshlab speed!). Any plans on merging assimp support from Bratwurst 
 into trunk?
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-07-01 Thread David Jeske

On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org wrote:

  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?


Billrey's blender blog recently posted a link to this old but excellent
talk on Firefox UI design, from 2011. At 38 minutes, it talks about their
Usage Statistics Heat Map, and how they used it to streamline the option
locations when redesigning menus.

http://www.youtube.com/watch?v=hMDBwa4huUY#at=302

The whole talk is really worth watching.. it's both an interesting
visualization of some common UI design principles, and Firefox's approach
to enabling open-source innovation by establishing clear design-rules to
empower and enable more freedom within those design rules.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-30 Thread Jürgen Herrmann

Hi David,

I am confused. What takes you so long to get stuff to build?
It took me half an hour to get blender to build on MSVC 2008 with CMake the 
first time.
~10 minutes download time.
~10 minutes finding out what to click in CMake-GUI
~10 minutes build time.

Now when I change blender code it is a matter of 3 Minutes from pressing the 
compile button to testing the code. Incremental builds are great ;)


Am 30.06.2013 um 05:13 schrieb David Jeske dav...@gmail.com:

 When I fix bugs in unfamiliar projects, I spend 90% of my time getting it
 to build and playing sherlock holmes tracking down weak-linkages like
 dynamic-typed variables and weak-linkages (like strings used as enums in C)
 -- and 10% of my time actually trying to understand or fix code.
 
 In strong typed code (C, C++, C#, TypeScript, etc) and a modern IDE (Visual
 Studio or one of its many clones), that 90% shrinks dramatically, as I can
 see, understand, and explore the types of variables immediately. I
 hover-over a variable in the IDE it shows the type. I hit goto
 declaration it takes me to the type-declaration. No project wide grep or
 guessing at the type of that dynamic-typed a paramater.
 
 How about Python Traits? Note I have no idea how difficult it would be to
 
 use Traits as a wrapper for Blender's API, although Enthought does
 provide a
 Traits based wrapper for VTK so I'm sure it would be possible.
 
 I'm not very familiar with Traits, but from a quick look it appears to be a
 run-time assignment validation and format coercion package. It does not
 appear to contain any compiled time variable type information, or the
 ability to do type-aware code-navigation or completion.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-30 Thread David Jeske

On Sun, Jun 30, 2013 at 12:17 AM, Jürgen Herrmann shadow...@me.com wrote:

 I am confused. What takes you so long to get stuff to build?


Mostly because when unfamiliar with the tools and blender build, each small
mistake caused a 15-20 minute build cycle on my laptop.. the time added up
fast. If I was setting it up *again* on MacOS I think it would only take me
30-40 minutes like for you.

Here are some details..

1. I made the mistake of configuring the build flags like the instructions
said. Turning on a couple standard blender features which are not on in
the default build, like ffmpeg, which then caused build problems, perhaps
because they require additional installs. This cost time mucking with
CMake, clean, re-building. I think this was probably 30-40 minutes.

2. I am unfamiliar with the toolchain (XCode). There is an instruction to
switch the build target from all to install. I'm very unfamiliar with
the XCode UI, so the action I took was not the correct way to switch the
build-target. (IMO the XCode UI is very unintuitive here) There is even a
screenshot in the wiki-page, but my newer XCode looks newer, and I didn't
understand what the screenshot was saying. I built and cleaned all-build
several times trying to understand why it wouldn't launch.. until I finally
realized I wasn't building the install target correctly. Probably 70-90
minutes of scratching my head, repeated clean/rebuilding.

3. After it built and ran, it took me quite a while to find the
debug-launch blender target in the XCode UI.. because instead of being
near the all_build and install targets, it's near the bottom of a
build-targets popup menu with ~200 things in it -- requiring hunting and
scrolling down to find it.

I'm going to update the wiki instructions page slightly to help make these
steps more clear for someone unfamiliar with XCode.

On a related note, a friend of mine is still fighting the windows build
because it's having some issue colliding with the version of python he has
on his machine for Google App Engine development.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread Benjamin Tolputt

On 29/06/2013, at 3:47 PM, Campbell Barton wrote:

 Mono follows an MS spec for the language runtime (CLR), not sure what
 the second program you refer to is.
 At least the technology isn't owned by MS and its open-source.
 
 People may be wary of using MS derived technology but from what I can
 tell Mono wouldn't tie us to MS any more then Java would to Oracle.

Unlike the way Java was setup by Sun, Microsoft owns patents required for the 
CLR  C#. Yes, the source code is out in the wide world, but even the FSF has 
been clear about the threat Microsoft's patents poses to platforms that use the 
C#.

Personally, I don't think that Microsoft gives a damn about Blender (and agree 
Mono would not tie Blender to them), but should they start to use their patents 
against someone they *do* care about, it's possible that open-source projects 
using C#/CLR patents might be caught in the crossfire. 

Not trying to start a flamewar or anything, and I've used C# in a few projects 
now (so I'm not adverse to it's use per se), but there are reasons some folks 
are wary of using C#/Mono in an cross-platform, open-source project. Microsoft 
uses it's patents aggressively in it's commercial role and there it isn't 
unreasonable to assume they would use the C#/CLR ones if they see the need.

--
Benjamin Tolputt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread 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
 fasterhttp://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=alllang=python3lang2=v8data=u64than
 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@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread David Jeske

On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal t...@blender.org wrote:

  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?


I'm not aware of anyone who publishes information about how much their own
software crashes, this would probably be very hard to manage PR on.

I will say that at the large well known companies I've worked for, we
tracked and graphed usage, error, and performance stats for nearly-all
server-side and most client side software (opt-in on the client side).

When the graphs all look good they are not used much, but when odd things
start happening, the graphs are often the only way to know something is
going wrong. It also helps avoid bad priorities, because the data is more
statistically relevant than one person telling you XYZ when there are
thousands or millions of users.

As for the detailed crash dumps, and stack backtraces.. The utility of
these is very related to how much correlation there is between the stack
and the actual bug. Parasitic memory-stomp bugs can't be found with these
reports. However, many other types of bugs become quite obvious by
correlating the stacks and looking at a few user-written descriptions. I
have more personal experience with this for server-side than client-side,
but then I have been more involved with server-side than client-side
development.

The real kicker is, IMO, usage, crash, and performance reporting has more
value for the application than ANY other similar amount of feature work --
because it tracks activity of all code. Reliability and Performance are two
of software's most important features, so it is very useful to pay
attention to them.

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.


That's an excellent vision. It feels very much like blender as an art
build pipeline. AFAIK, big shops setup that kind of stuff with builds and
scripts. Doing it inside blender could have a bunch of great advantages (a)
interactivity, (b) easier sharing, (c) more accessible to artists who are
not programmers... among others..
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread Jed

Campbell Barton wrote
theres not much incentive to
rewrite - only for the sake of cleaner code.

I totally understand and wouldn't argue they should be, never touch a
working system and all that. Having the TODO make pep 8 compliant comment
in the header is also a good hint that they are perhaps not the best
inspiration for new code.

Campbell Barton wrote
Afraid every time I try do something non-trivial in someone else's
open-source project (non-blender), its pretty steep learning curve
too, getting from some template/example code to something useful is
just tricky and theres so much assumed knowledge about how components
work together, what kind of patterns your expected to use etc...

...clip...

For functions local to a file they often aren't commented much. I can
see why you might like comments here but I would leave this up to the
author of each script to choose how much to comment internal
functions, classes etc - rather then defining a policy

As you note, one of the hardest parts of getting your head around a complex,
unfamiliar, code base is figuring out all the unstated assumptions about
component interactions and design patterns. The only way I can do that is by
diving in to the existing production code. Having the API documented is
great but it is no substitute for being able to see how people intimately
familiar with it are using it. Sure I can work out what is going on by
reading the code, but having consumer functions that are using the API well
document goes a long way towards flattening out the learning curve.

David Jeske wrote
On Fri, Jun 28, 2013 at 1:35 PM, Knapp lt;

magick.crow@

gt; wrote:
I think it would be nice to see a typed scripting option

How about Python Traits? Note I have no idea how difficult it would be to
use Traits as a wrapper for Blender's API, although Enthought does provide a
Traits based wrapper for VTK so I'm sure it would be possible.

--
View this message in context:
http://blender.45788.x6.nabble.com/Blender-roadmap-article-on-code-blog-tp109587p110358.html
Sent from the Bf-committers mailing list archive at Nabble.com.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread David Jeske

When I fix bugs in unfamiliar projects, I spend 90% of my time getting it
to build and playing sherlock holmes tracking down weak-linkages like
dynamic-typed variables and weak-linkages (like strings used as enums in C)
-- and 10% of my time actually trying to understand or fix code.

In strong typed code (C, C++, C#, TypeScript, etc) and a modern IDE (Visual
Studio or one of its many clones), that 90% shrinks dramatically, as I can
see, understand, and explore the types of variables immediately. I
hover-over a variable in the IDE it shows the type. I hit goto
declaration it takes me to the type-declaration. No project wide grep or
guessing at the type of that dynamic-typed a paramater.

 How about Python Traits? Note I have no idea how difficult it would be to

 use Traits as a wrapper for Blender's API, although Enthought does
provide a
 Traits based wrapper for VTK so I'm sure it would be possible.

I'm not very familiar with Traits, but from a quick look it appears to be a
run-time assignment validation and format coercion package. It does not
appear to contain any compiled time variable type information, or the
ability to do type-aware code-navigation or completion.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-29 Thread Jonathan Merritt

I think that you've hit upon two of the important factors here:
  - familiarity
  - discoverability
To which I would also add
  - refactorability (is that a word? :-)

Those familiar with a project might not see the value in strong typing
simply because it doesn't add much to their personal experience.  They have
less need to explore types, usage locations, etc., because they're already
familiar with them.  However, strong typing does add an additional level of
confidence when re-factoring, which can even benefit those who are
intimately familiar with a code base.  Anecdotally, you hear about this
from people who have had to re-factor Python... things like You really
come to appreciate your test suite when refactoring, etc.  The reliance on
test suites arising because many compile-time checks are impossible with
dynamically-typed languages.

Jonathan Merritt.


On Sun, Jun 30, 2013 at 1:13 PM, David Jeske dav...@gmail.com wrote:

 When I fix bugs in unfamiliar projects, I spend 90% of my time getting it
 to build and playing sherlock holmes tracking down weak-linkages like
 dynamic-typed variables and weak-linkages (like strings used as enums in C)
 -- and 10% of my time actually trying to understand or fix code.

 In strong typed code (C, C++, C#, TypeScript, etc) and a modern IDE (Visual
 Studio or one of its many clones), that 90% shrinks dramatically, as I can
 see, understand, and explore the types of variables immediately. I
 hover-over a variable in the IDE it shows the type. I hit goto
 declaration it takes me to the type-declaration. No project wide grep or
 guessing at the type of that dynamic-typed a paramater.

  How about Python Traits? Note I have no idea how difficult it would be to

  use Traits as a wrapper for Blender's API, although Enthought does
 provide a
  Traits based wrapper for VTK so I'm sure it would be possible.

 I'm not very familiar with Traits, but from a quick look it appears to be a
 run-time assignment validation and format coercion package. It does not
 appear to contain any compiled time variable type information, or the
 ability to do type-aware code-navigation or completion.
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-28 Thread Campbell Barton

On Fri, Jun 28, 2013 at 7:13 AM, Jed Frechette jedfreche...@gmail.com wrote:
On Thu, 27 Jun 2013 12:33 Campbell Barton ideasma...@gmail.com wrote

On Thu, Jun 27, 2013 at 10:58 AM, Jed jedfreche...@gmail.com wrote:
I agree about the existing
Python code being hard to read.
Am happy to take criticism for python code, but curious which parts
you found problematic to follow.

One particularly crufty bit I was looking at recently is the Smart UV
Project module (http://preview.tinyurl.com/ldujq8r). None of the functions
have doc strings, large portions of the code are commented out and
presumably obsolete, unusual naming conventions, etc. The Lightmap UV
unwrapping module is much better but also doesn't have any doc strings.

Both these scripts suffer from 2.4x - 2.5x-rna - 2.6x-rna-ngons.
2.5x+ api's for mesh manipulations use RNA and are very limited, 2.4x
was more flexible and had more useful functionality built-in.

However it was always my intention with 2.5x to use bmesh-python
whenever mesh editing needed to be done from Python, it just played
out that by the time we got this BMesh-API available, the scripts you
mention were working with RNA-API and theres not much incentive to
rewrite - only for the sake of cleaner code.

If I needed to make any significant changes to these script's Id
rewrite them for sure.

To see the the difference between a script written using RNA-API's and
BMesh-API, check these 2 scripts (both do a vertex dirt-map effect and
are fairly similar)

rna:
https://svn.blender.org/svnroot/bf-blender/trunk/blender/release/scripts/startup/bl_operators/vertexpaint_dirt.py
bmesh:
https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/oscurart_worn_edges_map.py

I've tried to include examples in the text editors templates to help
give users some samples of working scripts,
is there some area you think should be added to here that would help?

The examples are very helpful, however most of the time my questions are
more Why than How and inevitably about some corner case that isn't quite
covered by one of the cookbook recipes. I don't know that this is
necessarily a documentation issue as much as I simply haven't committed
enough time to fully understanding how Blender's internals work. This
certainly goes to David's point about the difficulty of diving in for
casual users, unfortunately I don't know how to bypass the learning curve.
Fortunately, the last time I spent much time on scripting Blender was ~3
months ago and I remember thinking at the time that the more conceptual
API documentation had improved since the last time I looked at it.

Afraid every time I try do something non-trivial in someone else's
open-source project (non-blender), its pretty steep learning curve
too, getting from some template/example code to something useful is
just tricky and theres so much assumed knowledge about how components
work together, what kind of patterns your expected to use etc...
Not to be dismissive and put this in the `too hard` basked, but if new
devs want to contribute to an advanced graphics app, they can expect
to have to get their hands dirty a bit...
(unless we attempt to hide details and expose simple API's - 2.4x
attempted this with its Python API and it didn't work so well, of
course we could try again).

Nevertheless, your point is well taken. That our existing code is not
always so readable and it makes it harder to learn by example.

I had a quick look over google's standards and while we don't follow
all, a lot of them are aligned with pep8 (and common sense),
if you think there are some we could benefit from, I'd be interested
to know which ones specifically.

I like that Google's standard is explicit about how to document things
like function arguments and return values, whereas PEP 257 doesn't really
give any guidance other than do it. Numpy's docstring style guide is
also quite good about this.

Currently we use sphinx style comments, but this is only used for API
functions in modules intended to be re-used by other scripts, eg:
http://www.blender.org/documentation/blender_python_api_2_67_release/bpy.utils.html

I might quibble with some of Google's choices but the main things I like
about it for my own projects are that: it is in one place, is pretty
comprehensive, I can point someone else to it and expect a reasonable
result, and I didn't have to write it. I know Blender has a style guide
for C code and it would probably be good to have one for Python, even if
it is just a paragraph saying Follow PEP 8 257.

Yep, this should be set out more clearly in our wiki docs (added to my
todo list)

Integrating ipython is fairly straightforward

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-28 Thread Knapp

 Yes, there is a performance cost for Mono/V8 relative to C, but for many
 types of code that gap is quite small, about 1-3x

Speaking only as an artist:

LOL

I dare you to go to BlenderArtist and tell them you have decided to
include 2 Microsoft programs in Blender that will slow down there
render times by 300%!

They are dancing in the streets there because of a 20% speedup in
cycles that might be coming!! Need I even talk about the hate of Mono
correct or not?


-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-28 Thread David Jeske

On Fri, Jun 28, 2013 at 1:35 PM, Knapp magick.c...@gmail.com wrote:

  Yes, there is a performance cost for Mono/V8 relative to C, but for many
  types of code that gap is quite small, about 1-3x

 Speaking only as an artist:

 LOL

 I dare you to go to BlenderArtist and tell them you have decided to
 include 2 Microsoft programs in Blender that will slow down there
 render times by 300%!


A language used for UI extension and tools does not affect render-times.
OSL is already the way to user-extend cycles and that is not part of the
discussion.

Python is allowed for 2d compositing nodes now. Using C# or TypeScript/V8
for these nodes would speed them up 3-10x. However, don't get too excited,
because a single composite node, even in Python, is probably only 2-20% of
the total composite time and only 0.1-0.5% of total render time if there is
a 3d scene.

..so I think your concern about how this would somehow slow down rendering
is mis-placed. It wouldn't.

That said, there are many good points in this discussion about extension
languages. I think it would be nice to see a typed scripting option, but I
also agree that getting some of the benefits I hope for would take lots
more than adding the language option. I'm going to have to think on this
some more, and for now I'm removing/replacing this item in my personal
roadmap wishlist with a different one...

4) Make Blender UI, launch-state, splash more friendly to users who wish to
use only a subset of functionality (without compromising the power users).
The first case-in-point, 2d-compositor-only users. -- Why? -- Blender is
arguably one of the most powerful open-source 2d compositors. However, the
UI doesn't make this apparent or easy to do without understanding 3d
rendering. Making blender more friendly to these users will mean more
blender users, more potential developers, and more goodness.

Easier said than done, but I think it's worthy.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-28 Thread Campbell Barton

eeh, there is some misinformation here...

On Sat, Jun 29, 2013 at 7:54 AM, David Jeske dav...@gmail.com wrote:
On Fri, Jun 28, 2013 at 1:35 PM, Knapp magick.c...@gmail.com wrote:

Yes, there is a performance cost for Mono/V8 relative to C, but for many
types of code that gap is quite small, about 1-3x

Speaking only as an artist:

LOL

I dare you to go to BlenderArtist and tell them you have decided to
include 2 Microsoft programs in Blender that will slow down there
render times by 300%!

Mono follows an MS spec for the language runtime (CLR), not sure what
the second program you refer to is.
At least the technology isn't owned by MS and its open-source.

People may be wary of using MS derived technology but from what I can
tell Mono wouldn't tie us to MS any more then Java would to Oracle.

A language used for UI extension and tools does not affect render-times.
OSL is already the way to user-extend cycles and that is not part of the
discussion.

Python is allowed for 2d compositing nodes now. Using C# or TypeScript/V8
for these nodes would speed them up 3-10x. However, don't get too excited,
because a single composite node, even in Python, is probably only 2-20% of
the total composite time and only 0.1-0.5% of total render time if there is
a 3d scene.

PyNodes don't allow python to be used for blenders existing C++ compositor,
See:
http://blender.stackexchange.com/questions/553/is-it-possible-to-create-a-compositor-node-with-pynodes-that-outputs-camera-clip

However there has been some talk of using OSL for compositor nodes,
apparently it could be supported but I dont know details here.

..so I think your concern about how this would somehow slow down rendering
is mis-placed. It wouldn't.

That said, there are many good points in this discussion about extension
languages. I think it would be nice to see a typed scripting option, but I
also agree that getting some of the benefits I hope for would take lots
more than adding the language option. I'm going to have to think on this
some more, and for now I'm removing/replacing this item in my personal
roadmap wishlist with a different one...

4) Make Blender UI, launch-state, splash more friendly to users who wish to
use only a subset of functionality (without compromising the power users).
The first case-in-point, 2d-compositor-only users. -- Why? -- Blender is
arguably one of the most powerful open-source 2d compositors. However, the
UI doesn't make this apparent or easy to do without understanding 3d
rendering. Making blender more friendly to these users will mean more
blender users, more potential developers, and more goodness.

Easier said than done, but I think it's worthy.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-27 Thread Jed Frechette

On Thu, 27 Jun 2013 12:33 Campbell Barton ideasma...@gmail.com wrote

 On Thu, Jun 27, 2013 at 10:58 AM, Jed jedfreche...@gmail.com wrote:
 I agree about the existing
 Python code being hard to read.
Am happy to take criticism for python code, but curious which parts
 you found problematic to follow.

One particularly crufty bit I was looking at recently is the Smart UV  
Project module (http://preview.tinyurl.com/ldujq8r). None of the functions  
have doc strings, large portions of the code are commented out and  
presumably obsolete, unusual naming conventions, etc. The Lightmap UV  
unwrapping module is much better but also doesn't have any doc strings.

 I've tried to include examples in the text editors templates to help
 give users some samples of working scripts,
 is there some area you think should be added to here that would help?

The examples are very helpful, however most of the time my questions are  
more Why than How and inevitably about some corner case that isn't quite  
covered by one of the cookbook recipes. I don't know that this is  
necessarily a documentation issue as much as I simply haven't committed  
enough time to fully understanding how Blender's internals work. This  
certainly goes to David's point about the difficulty of diving in for  
casual users, unfortunately I don't know how to bypass the learning curve.  
Fortunately, the last time I spent much time on scripting Blender was ~3  
months ago and I remember thinking at the time that the more conceptual  
API documentation had improved since the last time I looked at it.

 I had a quick look over google's standards and while we don't follow
 all, a lot of them are aligned with pep8 (and common sense),
if you think there are some we could benefit from, I'd be interested
 to know which ones specifically.

I like that Google's standard is explicit about how to document things  
like function arguments and return values, whereas PEP 257 doesn't really  
give any guidance other than do it. Numpy's docstring style guide is  
also quite good about this.

I might quibble with some of Google's choices but the main things I like  
about it for my own projects are that: it is in one place, is pretty  
comprehensive, I can point someone else to it and expect a reasonable  
result, and I didn't have to write it. I know Blender has a style guide  
for C code and it would probably be good to have one for Python, even if  
it is just a paragraph saying Follow PEP 8  257.

 Integrating ipython is fairly straightforward

I suspect a lot of users would greatly appreciate IPython's improved  
object introspection and user friendliness.

Cheers,

-- 
Jed Frechette
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread David Jeske

On Tue, Jun 25, 2013 at 10:49 PM, Benjamin Tolputt
btolp...@internode.on.net wrote:

...though now we have to define integral. I would like to see more
blender UI and experimental features built in a static-typed extension
language like C#/Mono or TypeScript.

I gotta say I neither want, agree, nor think this will ever happen.

I understand, and you may be right. I'd like to respectfully share a few
counter-points to your message...

For the latest Mac OSX version (i.e. the one I'd be running if I wasn't
building it myself) - that's 87MB. The latest stable Mono runtime is a
103MB download - all by itself and without any of Blender packaged into it.

That 103MB Mono download size is not related to the embedded size as it
includes all kinds of stuff that would not be included. One dev found that
the embedded mono-runtime for his project was about
20MBhttp://shishkin.wordpress.com/2009/12/24/mono-as-a-lightweight-net-runtime/.
Many of the libs he included are not needed for Blender, though the
compiler would be needed because I want to compile directly from blender, I
suspect 20-25MB is close. V8+TypeScript is much smaller then Mono or Python
and is likely to remain so even as TypeScript matures, but with a loss of
included module functionality.

Secondly, and perhaps Campbell can speak to this, but I don't think type
safety is the largest source of bugs in Blender.

I'm specifically talking about segfaults, and I think we are having a
semantic issue. Type-validity, bounds-checking, and lack of direct pointer
manipulation are all part of Type-Safety. By my view, nearly any segfault
that occurs in C, other than failing to check a pointer for null, is
ultimately a type-safety issue in someone's code.

Of course a Type-Safe program can crash (aka, throw an Exception that
can't be handled). However, that backtrace is a pretty good indication of
where part of the problem lies. Wheras a segfault in C could be caused by
any number of data-stomps unrelated to the call stack.

Thirdly, type-safety in languages like C# TypeScript comes with a
performance cost.

Yes, there is a performance cost for Mono/V8 relative to C, but for many
types of code that gap is quite small, about 1-3x
slowdownhttp://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=alllang=csharplang2=gccdata=u32,
shockingly Javascript-V8 is similar. Certainly smaller than CPython vs
C's 30-50x
slowdownhttp://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=alllang=python3lang2=gccdata=u32
.

I admit it's hard to predict what the slowdown would be for accessing
DNA/RNA without trying it.

A C#/Mono implementation is going to need a development environment setup
just like the current C/C++/Python setup does.

An Embedded C#/Mono environment would include a C# compiler in blender,
just like Python's compiler is included in blender. Likewise for a
V8/TypeScript environment. All the source could be included and users could
edit/compile/run directly within blender, just like Python.. It would just
be faster and static-typed.

There is a reason that most the third-party libraries used are written in
C/C++ and it's not just because it's the de facto coding language of the
OSS world.

Well.. there are lots of reasons more third party libraries are written in
C/C++. Those languages have been around longer. Integrating GC models is a
hard problem, so C/C++ offers the greatest flexibility for library code,
since it can be imported into any runtime. And of course, when code is
heavily leveraged, the work of expunging all pointer and bounds bugs is
worth the effort for the performance gains.

However, I don't think any of these arguments hold for new experimental
blender features and UI. I personally would gladly give up 1-3x performance
for new features to get no segfaults, simpler code, and the ability for any
user to edit/compile/debug/patch that code within blender without
setting-up a build system.

With all that in mind, it took me less than a hour to setup my build
environment both on Windows on OSX (I already had the developer tools
installed).

This evening I followed the steps to setup an OSX / XCode build, hoping to
fix my list of retina bugs. A couple hours later I have a built-binary, but
it crashes immediately on launch. I'm too unfamiliar with blender to have a
clue what is causing it.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread Campbell Barton

On Wed, Jun 26, 2013 at 7:42 PM, David Jeske dav...@gmail.com wrote:
On Tue, Jun 25, 2013 at 10:49 PM, Benjamin Tolputt
btolp...@internode.on.net wrote:

...though now we have to define integral. I would like to see more
blender UI and experimental features built in a static-typed extension
language like C#/Mono or TypeScript.

I gotta say I neither want, agree, nor think this will ever happen.

I understand, and you may be right. I'd like to respectfully share a few
counter-points to your message...

Checking on the runtime size of these embeddable languages,
is typically not so large if you strip them down, so size alone isn't
argument against.

Secondly, and perhaps Campbell can speak to this, but I don't think type
safety is the largest source of bugs in Blender.

This seems like admitting defeat before identifying the problem,
as if you say --- Blender crashes for me therefor you should use a
new language

We should _really_ try to figure out what bugs you are running into
before leaping to conclusions.
Having dealt a lot with blender bugs I have my own opinions on this,
but these are also not backed up by facts/statistics
(in that respect something like break-pad would help for sure)...

But my own anecdotal experience is that areas of Blender can be made
very stable if developers focus on workflows/areas of the code -
running well,
but there are areas that fall under developers radars and users just
run into bugs --- grumble, and suffer crashes when these should be
getting fixed.

Its hard for us to know if your experience is caused by a few specific
bugs, or overall poor quality of code.
But we should try to find out before making assumptions.

One area I'm disappointed in Blender is with threading, in both Duran
and Mango we had to disable view-port redrawing during render because
of threading crashes, we just ran into too many hard to track down
bugs which ended up being related to Blender shooting its self in the
foot with threaded data access.

A few times I spent hours to track down the bugs and result was -
Blender is just had multiple threads accessing the same data (helgrind
is quite good at pointing these errors our, and while some of these
are harmless, enough are real bugs too).
We should just lock Blender while rendering baking (any other
operation that depends on data not getting manipulated while it runs),
the benefit of being able to spin the 3d view around while rendering
is minimal compared to the problems it causes.

The fact you can crash Blender by toggling edit-mode while baking
vertex colors is ridiculous - try it!

...too many other ways to crash during bake to mention - but theres
nothing stopping you swapping out mesh data or converting the mesh to
a curve during bake.

Thirdly, type-safety in languages like C# TypeScript comes with a
performance cost.

I admit it's hard to predict what the slowdown would be for accessing
DNA/RNA without trying it.

This can be made to work of course.

A C#/Mono implementation is going to need a development environment setup
just like the current C/C++/Python setup

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread David Jeske

On Wed, Jun 26, 2013 at 4:56 AM, Campbell Barton ideasma...@gmail.comwrote:

 This seems like admitting defeat before identifying the problem,
  as if you say --- Blender crashes for me therefor you should use a
 new language


I fear my wordy detail is confusing my message. What I'm trying to say is..

I wish more blender code for UI and new features could have zero delay,
zero work, zero build-setup between a casual user-dev like me seeing a
(small) problem in the UI or a new feature, and doing an
edit/compile/run/patch cycle.

This way, all of the limited time I have to touch blender code could be
spent trying to actually fix code, instead of the current situation of
spending 1-4 hours wrangling the current build just to spend 1-4 hours
making patches to fix a couple bugs. Or not even starting because I know
this is what I'm in for. The more eyeballs fixing bugs the better.

This is where the slippery slope of my thought began, and it went like
this...

- I don't think we can make the C build instant to setup and included with
blender...
- so to get there would require more code to be written in an extension
language that blender can compile/run itself (like Python).
- Except I don't think more of blender should be pushed into Python...
because it's slow. and because code with no types is hard to read and
understand, and without compile-time type-checking, harder for non-authors
to change without fear of breaking something. Casual coding in a foreign
codebase without types and type-aware-completion is also much harder.
- So it would be great to have an extension language that didn't have these
problems. Something as fast as possible, that has static types,
type-aware-completion, type-checking, and where the compiler and build
context can be cheaply built right into blender.

What language systems can do that? Hmm.. well. There is  Mono/C#/Boo, and
there is TypeScript/V8. And maybe Google Dalvik/Java, though probably not
the JVM. Hmm.. might be an interesting idea to integrate one of these. The
graph editor, outliner, property panels, movie clip editor, masking and
tracking, video sequence editor -- tons of the UI could be written in one
of these languages without affecting blender performance much, making all
that code more accessible to more devs. The more eyeballs fixing bugs the
better. I wonder what other people might think of this idea.

I'm not expecting that to necessarily sell you, but I hope it is a clearer
explanation of my thinking.


 Read through your other comments, reasonable points but I would want
 to be convinced the errors you hint at _can't_ be fixed first.


Of COURSE they can be fixed! Any code can be fixed, in any language. This
isn't about a magic language. It is about iteration speed for the
setup/edit/compile/run cycle. The faster than cycle is, the more casual
devs can be roped in to help improve blender -- for however much code is
written in that extension environment.


  This evening I followed the steps to setup an OSX / XCode build, hoping
 to
  fix my list of retina bugs. A couple hours later I have a built-binary,
 but
  it crashes immediately on launch. I'm too unfamiliar with blender to
 have a
  clue what is causing it.

 Crashes immediately is more likely to be some kind of build error (or
 incompatible libs/environment) then a bug in the code.


Ohh it was totally setup user-error on my part. I'm not saying the blender
build is somehow broken. Obviously there are lots of devs working on
blender, including all the new GSOC folks.

I spent another thirty minutes retracing my steps. Turns out when it said
to toggle to the install target, I did the wrong thing because I don't
know XCode enough to have understood the very-nice screenshot in the doc
the first time through. Now I need to figure out how to source debug, since
the XCode run button doesn't seem to launch blender.

 which is all sort of my point. The time between when I thought darn
it, I'm just going to try to fix this, and when I can actually begin to
dig through the code in this case was 2-3 hours of my time, and 12 hours
wall-clock.

Plus, I'm a software engineer. I'm impatient and hate setting up builds,
but I'm comfortable working in big foreign builds, and C/C++, with
code-generators, and third-party libs. However, I suspect there are also a
lot of amateur coders/scripters who would spend some time reading through
UI/feature code in C# or TypeScript trying to Code-Monkey out a patch..

my theory is that reducing that setup overhead to just a few minutes
and using an easy language -- for an interesting subset of non-core blender
code -- would mean a lot more eyeballs helping fix bugs and improve
blender.

Of course the real book you can throw at me is that I spent more time on
this email discussion than I did setting up the build. :) However, I don't
think that invalidates the argument. Even if nobody is on board with me, I
hope it's interesting food for thought. Now I need to go fix some

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread Jed

David Jeske wrote
In short, I want to help more of the blender community turn into blender
devs and debuggers.

...clip...

Python isn't used for
enough of blender, and the code which is there is very hard to read,
understand, change because there are no types and there is no compile
typechecking.

As someone with a fair bit of experience using Python for various things but
only the occasional need to write Blender scripts I agree about the existing
Python code being hard to read. However, the difficulties I've had have
never really been due to lack of types. Instead, wildly varying styles and
often little if any inline documentation have been the biggest issues for
me. Combine this with the fact that Python is a pretty thin wrapper around
the underlying structures, which I don't fully understand, and I'm usually
able to come up with something that works but I'm never quite sure if I've
done it the right way.

Personally, I would love to see all new Python code complying to Google's
Python Style Guide. In fairness, the new code I've looked at usually is
better, however, often I'm looking at IO addons and other tools that have
been around for awhile gathering cruft.

Oh yeah, the biggest problem: Blender's Python console isn't iPython. :-)

--
View this message in context:
http://blender.45788.x6.nabble.com/Blender-roadmap-article-on-code-blog-tp109587p110189.html
Sent from the Bf-committers mailing list archive at Nabble.com.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread Campbell Barton

On Thu, Jun 27, 2013 at 4:20 AM, David Jeske dav...@gmail.com wrote:
 On Wed, Jun 26, 2013 at 4:56 AM, Campbell Barton ideasma...@gmail.comwrote:

 This seems like admitting defeat before identifying the problem,
  as if you say --- Blender crashes for me therefor you should use a
 new language


 I fear my wordy detail is confusing my message. What I'm trying to say is..

 I wish more blender code for UI and new features could have zero delay,
 zero work, zero build-setup between a casual user-dev like me seeing a
 (small) problem in the UI or a new feature, and doing an
 edit/compile/run/patch cycle.

 This way, all of the limited time I have to touch blender code could be
 spent trying to actually fix code, instead of the current situation of
 spending 1-4 hours wrangling the current build just to spend 1-4 hours
 making patches to fix a couple bugs. Or not even starting because I know
 this is what I'm in for. The more eyeballs fixing bugs the better.

 This is where the slippery slope of my thought began, and it went like
 this...

 - I don't think we can make the C build instant to setup and included with
 blender...
 - so to get there would require more code to be written in an extension
 language that blender can compile/run itself (like Python).
 - Except I don't think more of blender should be pushed into Python...
 because it's slow. and because code with no types is hard to read and
 understand, and without compile-time type-checking, harder for non-authors
 to change without fear of breaking something. Casual coding in a foreign
 codebase without types and type-aware-completion is also much harder.
 - So it would be great to have an extension language that didn't have these
 problems. Something as fast as possible, that has static types,
 type-aware-completion, type-checking, and where the compiler and build
 context can be cheaply built right into blender.

 What language systems can do that? Hmm.. well. There is  Mono/C#/Boo, and
 there is TypeScript/V8. And maybe Google Dalvik/Java, though probably not
 the JVM. Hmm.. might be an interesting idea to integrate one of these. The
 graph editor, outliner, property panels, movie clip editor, masking and
 tracking, video sequence editor -- tons of the UI could be written in one
 of these languages without affecting blender performance much, making all
 that code more accessible to more devs. The more eyeballs fixing bugs the
 better. I wonder what other people might think of this idea.

 I'm not expecting that to necessarily sell you, but I hope it is a clearer
 explanation of my thinking.


 Read through your other comments, reasonable points but I would want
 to be convinced the errors you hint at _can't_ be fixed first.


 Of COURSE they can be fixed! Any code can be fixed, in any language. This
 isn't about a magic language. It is about iteration speed for the
 setup/edit/compile/run cycle. The faster than cycle is, the more casual
 devs can be roped in to help improve blender -- for however much code is
 written in that extension environment.

  This evening I followed the steps to setup an OSX / XCode build, hoping
 to
  fix my list of retina bugs. A couple hours later I have a built-binary,
 but
  it crashes immediately on launch. I'm too unfamiliar with blender to
 have a
  clue what is causing it.

 Crashes immediately is more likely to be some kind of build error (or
 incompatible libs/environment) then a bug in the code.


 Ohh it was totally setup user-error on my part. I'm not saying the blender
 build is somehow broken. Obviously there are lots of devs working on
 blender, including all the new GSOC folks.

 I spent another thirty minutes retracing my steps. Turns out when it said
 to toggle to the install target, I did the wrong thing because I don't
 know XCode enough to have understood the very-nice screenshot in the doc
 the first time through. Now I need to figure out how to source debug, since
 the XCode run button doesn't seem to launch blender.

  which is all sort of my point. The time between when I thought darn
 it, I'm just going to try to fix this, and when I can actually begin to
 dig through the code in this case was 2-3 hours of my time, and 12 hours
 wall-clock.

 Plus, I'm a software engineer. I'm impatient and hate setting up builds,
 but I'm comfortable working in big foreign builds, and C/C++, with
 code-generators, and third-party libs. However, I suspect there are also a
 lot of amateur coders/scripters who would spend some time reading through
 UI/feature code in C# or TypeScript trying to Code-Monkey out a patch..

 my theory is that reducing that setup overhead to just a few minutes
 and using an easy language -- for an interesting subset of non-core blender
 code -- would mean a lot more eyeballs helping fix bugs and improve
 blender.

 Of course the real book you can throw at me is that I spent more time on
 this email discussion than I did setting up the build. :) However, I don't
 think

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-26 Thread Campbell Barton

On Thu, Jun 27, 2013 at 10:58 AM, Jed jedfreche...@gmail.com wrote:
David Jeske wrote
In short, I want to help more of the blender community turn into blender
devs and debuggers.

...clip...

Python isn't used for
enough of blender, and the code which is there is very hard to read,
understand, change because there are no types and there is no compile
typechecking.

As someone with a fair bit of experience using Python for various things but
only the occasional need to write Blender scripts I agree about the existing
Python code being hard to read.

Am happy to take criticism for python code, but curious which parts
you found problematic to follow.

However, the difficulties I've had have
never really been due to lack of types. Instead, wildly varying styles and
often little if any inline documentation have been the biggest issues for
me. Combine this with the fact that Python is a pretty thin wrapper around
the underlying structures, which I don't fully understand, and I'm usually
able to come up with something that works but I'm never quite sure if I've
done it the right way.

I've tried to include examples in the text editors templates to help
give users some samples of working scripts,
is there some area you think should be added to here that would help?

IMHO we are pretty good with style (bundled scripts follow pep8,
although 80-column width optional),
I had a quick look over google's standards and while we don't follow
all, a lot of them are aligned with pep8 (and common sense),

if you think there are some we could benefit from, I'd be interested
to know which ones specifically.

As for the IO scripts definitely gather cruft, **but i can explain!** :)
first we rushed in a direct port from 2.4x - was gsoc project, and we
we're happy to have something functional (otherwise uses had to go
back to 2.4x),
then with BMesh if further complicated things since we had to deal
with tessface/ngon conversions.
So at this point they are really not nice to read - we just fix bugs
and keep them working.

Oh yeah, the biggest problem: Blender's Python console isn't iPython. :-)

Integrating ipython is fairly straightforward, can be optional console
mode from the menu (if ipython is found).
IIRC at the time the py-console was added ipython didn't have python3
support so we did our own.

--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-25 Thread Campbell Barton

On Tue, Jun 25, 2013 at 7:17 AM, David Jeske dav...@gmail.com wrote:
 I like the overall structure of this roadmap.

 It prompted me to cleanup and post my own 2013 Roadmap
 Wishlisthttp://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-progresshttp://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
 fasterhttp://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=alllang=python3lang2=v8data=u64than
 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

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-25 Thread David Jeske

On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton ideasma...@gmail.comwrote:

  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.



 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


My intent is not to create more work for devs, but less work.

Ubiquitious crash reporting is not for devs to crawl through individual
reports, but to create a strategic source of *real* stats about when there
are too many crashes and when things are stable. It's simply applying the
simple mantra of to improve it, measure it.

For example, my 2.67b crashed 5+ times in 14 hours doing a trivial VFX toy
project. Other than me emailing people, nobody even sees these crash stats.
If I email people, I waste their time with non-reproducable crash
anecdotes. I think an automatic crash report onto a graph would be better
than being blind to the data, or being distracted by the anicdotes.

Also, this kind of tool is incredibly useful when a dev is working on
fixing a bug, because user comments can be searched to see if there is a
pattern. It might also be possible to track the last several operators, or
the time spent in different areas, also to see if there is a pattern.

 4) Incorporate an extension language which can support Intellisense,
   type-checking, and fast execution.



 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.


Agreed. This is why I'm starting with socializing.

Also keep in mind that these new options are really only now becoming
possible. Back when Blender integrated Python, Mono/C# was not great, and
V8 didn't exist. Today Mono is embedded in many notable things, including
Unity. I think TypeScript looks pretty incredible, but it's also very
bleeding edge. (They just released generics/type-parametrics in 0.9 a
couple weeks ago).

We could make the C++ RNA api more generally useful (what cycles is
 currently using),


I think I should back up and better explain my motivation. In short, I want
to help more of the blender community turn into blender devs and debuggers.
Setting up a blender build is too big a hurdle. Python isn't used for
enough of blender, and the code which is there is very hard to read,
understand, change because there are no types and there is no compile
typechecking. (though I admit types are not as powerful as tests)

As a result, I'd like to see more blender code written in a
language/environment which is easier to code-in (type-aware-completion),
easier to understand (static typing), unlikely to crash blender
(type-safety), unlikely to do bad things (sandboxing), performs well (fast
execution), and can be debugged/patched without setting up a C blender
build.

These are similar to the motivations which created Open Shading Language,
but that solution is very domain specific.

C++ isn't typesafe and requires setting up the whole blender build to
touch. This is fine for core-development like Cycles or parts of the
blender Core, but not great for rapid development, addons and community
debugging.

Python type-safety is nice, and users can touch it without a blender build
setup. However, not much of blender is written in it!  I don't think this
is mostly because of limitations in the Python API, but because code
without types is fragile and hard to read, and CPython is very very slow
(though PyPy could help).

Really this isn't about providing a language which is more attractive than
Blender Python, but one which is more attractive than Blender-C !

C#/.NET is pretty fantastic in this respect, because it's pretty darn
comfortable for C programmers, moreso even than Java, yet has all the
features above. However, it has some drawbacks, including a fairly large
runtime and unclear sandboxing situation.

Google's Javascript V8 engine is small, decently close to Mono performance,
has excellent sandboxing, and with TypeScript can support static typing and
type-aware-completion. I suspect the C-to-V8 data-structure marshaling is
probably slower than C-to-Mono, but it's hard to say for sure.

Since we are already including LLVM it could be interesting to check
 on the status of some LLVM based languages..


Please explain your thinking here. Mono/C# has an LLVM backend. How does a
language targetting LLVM help?

By my view it's the marshalling/API layer which creates the work of the
linkage, mapping from dangerous C pointers and datastructures to typesafe
APIs and structures.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-25 Thread Jürgen Herrmann

Crash reporting might be useful but integrating this in a manner that makes 
sense might be very intensive work.

You're not really trying to lure us into coding integral parts of blender in 
python, c# or mono, are you?
A new/additional scripting language might be cool and is definitely something 
we should think about.

There is a reason why coders always fall back to c/c++, that reason is speed.
Imho Type safety in c++ is not as critical as you present it here.

Ok you could replace some parts of blender with scripted code, but I don't 
agree with your arguments at all.

/Jürgen

Am 25.06.2013 um 21:14 schrieb David Jeske dav...@gmail.com:

 On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton ideasma...@gmail.comwrote:
 
 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.
 
 
 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
 
 
 My intent is not to create more work for devs, but less work.
 
 Ubiquitious crash reporting is not for devs to crawl through individual
 reports, but to create a strategic source of *real* stats about when there
 are too many crashes and when things are stable. It's simply applying the
 simple mantra of to improve it, measure it.
 
 For example, my 2.67b crashed 5+ times in 14 hours doing a trivial VFX toy
 project. Other than me emailing people, nobody even sees these crash stats.
 If I email people, I waste their time with non-reproducable crash
 anecdotes. I think an automatic crash report onto a graph would be better
 than being blind to the data, or being distracted by the anicdotes.
 
 Also, this kind of tool is incredibly useful when a dev is working on
 fixing a bug, because user comments can be searched to see if there is a
 pattern. It might also be possible to track the last several operators, or
 the time spent in different areas, also to see if there is a pattern.
 
 4) Incorporate an extension language which can support Intellisense,
 type-checking, and fast execution.
 
 
 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.
 
 Agreed. This is why I'm starting with socializing.
 
 Also keep in mind that these new options are really only now becoming
 possible. Back when Blender integrated Python, Mono/C# was not great, and
 V8 didn't exist. Today Mono is embedded in many notable things, including
 Unity. I think TypeScript looks pretty incredible, but it's also very
 bleeding edge. (They just released generics/type-parametrics in 0.9 a
 couple weeks ago).
 
 We could make the C++ RNA api more generally useful (what cycles is
 currently using),
 
 I think I should back up and better explain my motivation. In short, I want
 to help more of the blender community turn into blender devs and debuggers.
 Setting up a blender build is too big a hurdle. Python isn't used for
 enough of blender, and the code which is there is very hard to read,
 understand, change because there are no types and there is no compile
 typechecking. (though I admit types are not as powerful as tests)
 
 As a result, I'd like to see more blender code written in a
 language/environment which is easier to code-in (type-aware-completion),
 easier to understand (static typing), unlikely to crash blender
 (type-safety), unlikely to do bad things (sandboxing), performs well (fast
 execution), and can be debugged/patched without setting up a C blender
 build.
 
 These are similar to the motivations which created Open Shading Language,
 but that solution is very domain specific.
 
 C++ isn't typesafe and requires setting up the whole blender build to
 touch. This is fine for core-development like Cycles or parts of the
 blender Core, but not great for rapid development, addons and community
 debugging.
 
 Python type-safety is nice, and users can touch it without a blender build
 setup. However, not much of blender is written in it!  I don't think this
 is mostly because of limitations in the Python API, but because code
 without types is fragile and hard to read, and CPython is very very slow
 (though PyPy could help).
 
 Really this isn't about providing a language which is more attractive than
 Blender Python, but one which is more attractive than Blender-C !
 
 C#/.NET is pretty fantastic in this respect, because it's pretty darn
 comfortable for C programmers, moreso even than Java, yet has all the
 features above. However, it has some drawbacks, including a fairly large
 runtime and unclear sandboxing situation.
 
 Google's Javascript V8 engine is small, decently close to Mono performance,
 has excellent sandboxing, and with TypeScript can support static typing and
 type-aware-completion. I suspect the C-to-V8 data-structure marshaling is
 probably

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-25 Thread David Jeske

On Tue, Jun 25, 2013 at 12:40 PM, Jürgen Herrmann shadow...@me.com wrote:

 You're not really trying to lure us into coding integral parts of blender
 in python, c# or mono, are you?


No..  Blender core code is large and depends on many useful third party
C/C++ libraries. I'd guess it's going to be C for a very long time
(possibly it's entire useful life).

...though now we have to define integral. I would like to see more
blender UI and experimental features built in a static-typed extension
language like C#/Mono or TypeScript.

 There is a reason why coders always fall back to c/c++, that reason is
 speed.
 Imho Type safety in c++ is not as critical as you present it here.


Let me explain my motivations differently...

Blender is an incredible piece of software, and I'm thrilled it exists,
thrilled to use it, and thrilled to support it.  I'm working on a VFX clip
right now, and I'm just *astonished* at what I'm able to accomplish -- as a
software engineer with little art-skill. who has never done any filming,
compositing, or even node-editing before. It's truly awesome

So it's sad that, for me, Blender crashes WAY too much and more than
any other program I have ever used. I'm just an amateur who hardly does
anything fancy.

This is why my #1 is automatic crash reporting and a crash-stats dashboard.
The only other blender users I have direct contact with also say it crashes
alot. I see it crash in youtube tutorials. I personally would like to know
how much it crashes. I think measurement is often a good step to
improvement.

However, lets get back to type-safety...

My (unproven) theory is the crashes and instability is primarily for two
reasons (a) devs are volunteers and there is more interest in incorporating
cutting edge features than spending time making sure every piece of C/C++
code is well behaved. (b) blender is primarily used on windows, and a
windows build takes quite a while to setup and get working, so it's easier
for software-engineer blender users to just work-around bugs and crashes
than help fix blender.

(a) can be improved with type-safety, but only for code that is written in
the type-safe environment.

(b) I'm guilty of myself. I have spent time filing bugs for small problems
that might have taken me less time to actually fix and submit a patch -- if
I had a working build. However, I've tried to setup a working windows build
before and given up for frustration and lack-of-time. I despise setting up
builds. Build setups are notorously under-documented, and my machines are
used for development, so I often can't just install the tools the build
wants in all the standard places because it collides with other versions of
the same tools. All of this means I just work around the issue and file a
bug instead.

...so, I agree type-safety is not a panacea. In fact, if I get to choose
between type-safety and enabling any blender user-dev to quickly and
trivially edit/compile/run/patch/share blender code, I'd take the latter.

The only path to instant embedded edit/compile/run/debug cycles I've ever
seen is extension languages, which also happen to mostly be typesafe, so
this is why I see the two as intertwined. A magic push button way to
automatically setup a windows build would be a great alternative if it can
be done.

A new/additional scripting language might be cool and is definitely
 something we should think about.



 Ok you could replace some parts of blender with scripted code, but I don't
 agree with your arguments at all.


Let's keep in mind the term script language is very imprecise, and is
being blurred by technology like JIT and virtual machines.

To clarify, I don't want to see more of blender written in Python, nor do I
want to see another dynamic typed scripting language added to Blender.
Consistency is good and Python is a good scripting language.

What I would like to see is: (a) Blender crash less, (b) an easier workflow
for a software-engineer blender-user making a small fix.

My hypothesis is that a static-typed extension language like
C#/Java/TypeScript would be a more viable way to develop real features,
not just scripts. This would allow more of blender UI and new experimental
features to be built in an extension language that won't crash blender. A
language that the user-dev community could more readily fix and improve,
because they wouldn't need to setup and maintain a whole blender-core build
to contribute.

Any of that seem more attractive?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-25 Thread Benjamin Tolputt


On 26/06/2013, at 3:07 PM, David Jeske wrote:

 ...though now we have to define integral. I would like to see more
 blender UI and experimental features built in a static-typed extension
 language like C#/Mono or TypeScript.

I gotta say I neither want, agree, nor think this will ever happen. I say this 
as someone that is actually disappointed Python was chosen over another 
language for Blender's scripting language of choice.

I'm not trying to trash your ideas, because I understand somewhat where you're 
coming from in regards to wanting to improve Blender stability, but it does 
need to be tempered with a some facts.

Let's start with the runtime size. Everything you need ti run Blender comes 
packaged in the download. For the latest Mac OSX version (i.e. the one I'd be 
running if I wasn't building it myself) - that's 87MB. The latest stable Mono 
runtime is a 103MB download - all by itself and without any of Blender packaged 
into it.

Secondly, and perhaps Campbell can speak to this, but I don't think type safety 
is the largest source of bugs in Blender. At the level of code I've played in, 
the types of variables are clear and not violated through casting back  forth 
through void pointers (or similar nonsense). Sure, there'll be code in the 
application that does that kind of thing but, from what patches/bug-fixes I've 
looked at the solutions of, those practices are not the source. Again, I think 
Campbell could speak to this with far more authority (perhaps even pointing out 
I'm wrong), but that's the situation as I see it.

Thirdly, type-safety in languages like C#  TypeScript comes with a performance 
cost. There is a reason that most the third-party libraries used are written in 
C/C++ and it's not just because it's the de facto coding language of the OSS 
world. C/C++ is almost about one step up from the metal (when used the way most 
engineers write code). Type-safe languages, such as those you suggest, need to 
inject a runtime platform between the metal and the coded application - that 
middle layer provides your safety... using more CPU  memory than would be 
needed for the C/C++ equivalent. It's a trade-off and, frankly, Blender needs 
all the speed and memory it can get a hold of ;) 

I could go on  on about this. I've had to make this decision (safer language 
or faster code) many times. You can get fast  bug-free code in C/C++. I'll 
concede you might get the bug-free code in C# (or similar) quicker... but the 
resulting executable will be larger, take more memory, and run slower. 

With all that in mind, it took me less than a hour to setup my build 
environment both on Windows  on OSX (I already had the developer tools 
installed). If you want to do it, it's not that hard. If you don't want to do 
it, the ability to code in an alternate language isn't going to change that 
much. A C#/Mono implementation is going to need a development environment setup 
just like the current C/C++/Python setup does.

--
Benjamin Tolputt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-24 Thread David Jeske

I like the overall structure of this roadmap.

It prompted me to cleanup and post my own 2013 Roadmap
Wishlisthttp://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-progresshttp://wiki.blender.org/index.php/User:AlexK/Breakpad.
)

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.

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.

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
fasterhttp://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=alllang=python3lang2=v8data=u64than
CPython 3). Obviously this would be done in a way which leverages the
investment in Python exports/apis.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Daniel Stokes

I would like to know more about what Ton means by the line What should
then be dropped is the idea to make Blender have an embedded “true” game
engine from the blog post.

What exactly is proposed to be dropped here? It looks to me all that is
proposed to be dropped is an idea, changing the focus of the game engine to
make it better at what it can do rather than making it a clone of other
game engine/game editors. Are we actually talking about removing features
and/or the ability to publish a game? The blog post mentions creating 3D
interaction for walkthroughs, for scientific sims, or game prototypes.
This can still make use of existing code/features as well as the ability to
publish and distribute these creations.

As a BGE developer I have often considered a closer integration of the BGE
and the rest of Blender for their mutual benefit. At its simplest, closer
integration means better viewport visualization, and more maintained code
for the BGE. Stronger integration yields even more interesting ideas as Ton
outlines in the blog post. As I said in my original response, this sounds
like a great idea as long as those three conditions (mostly we aren't
losing a lot of functionality for current BGE users) are met.

As to the idea of me changing GSoC projects, I am not entirely against it,
but I would like to better understand both Ton's proposal and the potential
new project before jumping ship to a vague/undefined project.

Regards,
Daniel Stokes


On Sun, Jun 16, 2013 at 10:46 PM, Benjamin Tolputt 
btolp...@internode.on.net wrote:

 On 17/06/2013, at 3:23 PM, Campbell Barton wrote:

  Then it may be a good argument for Daniel to make a start on
  interactive-animation tools,

 If he is amenable to the switch, then that would make a decent compromise
 to offer surely?

  While this is a valid point, (as far as I know) none of these devs
  have stepped up to really supporting the BGE and helping become a
  maintainer.
  They mostly submit one feature they need for their game, then become
  inactive with BGE dev.

 I wasn't pointing it out as a reason against Ton's move, I was using it to
 support the *earlier* point that there is a lack developer effort/focus
 toward the BGE. The patches/submissions to Blender aren't being accepted, a
 good-sized proportion of BGE advocates are recommending that one use a
 build that applies most of them, and yet they admit is almost a fork due to
 the variance between official BGE and HG1 build BGE.

 Perhaps it will be a benefit to both BGE and Blender if they become
 separate projects? Blender can focus on asset creation (with the data
 structures and code compromises that make that efficient) whilst the BGE
 can start optimising the code/structures it uses to make it better for
 running a game.

  ... you could argue this is catch22 - if we accepted their patches
  they would become more active and submit more fixes but I still
  think if someone really wanted to become active and take the BGE
  forward they could - despite some slow patch review.

 Whilst you could argue the catch-22 aspect, I'd have to disagree that slow
 patch review isn't a big issue in it's own right. Watching a patch wither
 on the vine is a very demotivating experience, especially if it fixes
 something and the bug is left in the main project despite you having put
 the effort into solving it so the core development team didn't have to.
 That's something being bandied about the Blender-verse lately as well.

 Sure, if you want to be active enough, you'll walk over shards of broken
 glass to keep submitting your patches but that doesn't mean we should
 expect them to. Again, not an argument against the BGE
 removal/simplification as I support/defend Ton's decision in this regard.
 Just pointing out that the argument (like the it's not as good as the
 competition one) is pretty poor on it's own.

 --
 Benjamin Tolputt
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Bastien Montagne

Please don’t be stupid! Comparing XP and Linux on a market share basis 
is just pure nonsense. There’s at least two huge differences between 
those OS's:
*One is 12 years old, the other one is plain modern (don’t think anyone 
would care to maintain Blender for over 10 years old linux, nor even for 
OSX!).
*Even though a few XP are listed in 
http://wiki.blender.org/index.php/Dev:Ref/Supported_platforms (and I’m 
not sure this list is really up-to-date), you’ll find far more Blender 
devs under linux.

And despite the fact that XP is still about 40% of PCs connecting to the 
web, you’ll have a hard time finding any commercial 3D software 
supporting it (most don’t even support Vista anymore). While a fare 
amount of them do support Linux.

It would interesting to know the amount of XP PCs that download Blender, 
btw. My guess is that it would be far less than 40%.

So in a word, if we drop OpenGL below 2.1 (or even 3.0), it makes sense 
to me to also drop XP. You can’t waist time (and even often limit your 
app possibilities) to support obsolete stuff forever!

On 17/06/2013 06:52, Alexandr Kuznetsov wrote:
 Drop linux. It has 1% market share, less than xp. No more x11 hacks. And
 Mac OS X Tiger. Oops, too late. Somebody already did it.

 On 6/17/2013 12:46 AM, Harley Acheson wrote:
 Jürgen,

 If we are considering dropping Windows XP we should probably also
 consider dropping the other operating systems that have even less usage.
 Which is everything else besides Windows 7. So every version of
 Mac and all flavors of Linux combined.  LOL

 Harley
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Jürgen Herrmann

Hi Bastien,
Good to hear that I am not totally alone with my point of view ;-)
Ton sent in some interesting statistics of the blender.org website visitors:

http://lists.blender.org/pipermail/bf-committers/2013-May/040268.html
http://lists.blender.org/pipermail/bf-committers/2013-May/040269.html
http://lists.blender.org/pipermail/bf-committers/2013-May/040274.html

And I started a poll in blenderartists :
http://www.blenderartists.org/forum/showthread.php?291199-32-or-64bit

The results speak for themselves ...
/Jürgen

Am 17.06.2013 um 09:43 schrieb Bastien Montagne montagn...@wanadoo.fr:

 Please don’t be stupid! Comparing XP and Linux on a market share basis 
 is just pure nonsense. There’s at least two huge differences between 
 those OS's:
 *One is 12 years old, the other one is plain modern (don’t think anyone 
 would care to maintain Blender for over 10 years old linux, nor even for 
 OSX!).
 *Even though a few XP are listed in 
 http://wiki.blender.org/index.php/Dev:Ref/Supported_platforms (and I’m 
 not sure this list is really up-to-date), you’ll find far more Blender 
 devs under linux.
 
 And despite the fact that XP is still about 40% of PCs connecting to the 
 web, you’ll have a hard time finding any commercial 3D software 
 supporting it (most don’t even support Vista anymore). While a fare 
 amount of them do support Linux.
 
 It would interesting to know the amount of XP PCs that download Blender, 
 btw. My guess is that it would be far less than 40%.
 
 So in a word, if we drop OpenGL below 2.1 (or even 3.0), it makes sense 
 to me to also drop XP. You can’t waist time (and even often limit your 
 app possibilities) to support obsolete stuff forever!
 
 On 17/06/2013 06:52, Alexandr Kuznetsov wrote:
 Drop linux. It has 1% market share, less than xp. No more x11 hacks. And
 Mac OS X Tiger. Oops, too late. Somebody already did it.
 
 On 6/17/2013 12:46 AM, Harley Acheson wrote:
 Jürgen,
 
 If we are considering dropping Windows XP we should probably also
 consider dropping the other operating systems that have even less usage.
 Which is everything else besides Windows 7. So every version of
 Mac and all flavors of Linux combined.  LOL
 
 Harley
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Angus Hollands

In response to B. Tolputt's email, I think there are one or two things that
need to be addressed. Firstly, the animation tools are perfectly functional
in both Blender and BGE, unless you could clarify.
The multiplayer aspect is true, and something that I am working on, and
considering that unity itself requires scripting to use the multiplayer
system, one may argue that we too have multiplayer by that standard.
I don't want to make too many assertions from the articles contents, but
the concern for myself is the time and energy I've spent working with and
inside blender source in order to realise my goals. For other users the
prospects of a stalled engine are not appealing, and whilst one could use
legacy releases of blender, it would be undesirable.

I agree that there are certain aspects that could use some attention, and
to this effect there are users including myself who intend to contribute
their development. I think what the bge would benefit from is an updated
design document
Just my thoughts.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Ronan Ducluzeau aka zeauro

I think that Ton should be conscious that people don' t really know how 
to use BGE.
Serious ressources about BGE like mike pan's files are 2.5 .blends.
You have to find a complex project to understand the meaning of states 
in logic editor.
Yo!Frankie is outdated. There are few games that can demonstrate that.
But if no major informative sites like wiki or BA points to them; you 
have to hope that a kind expert of BGE answer your question.
Often on forums, we see a guy that want to update Yo!Frankie to 2.6.
It takes much more time and effort to produce .blends with game 
interaction rather than a modeling or a Cycles tutorial.
Since 2.5 development, there are rumors telling that devs will drop 
completely BGE.
So, new incomers who are triyng it are really warriors.
Let them time to produce content.
I know a guy who was making games with 2.49 and directly passed to unity 
without testing BGE navigation mesh.
A month ago, during an afternoon, we tried it and character type; we had 
a lot of funs, some difficulties with animation of linked characters. He 
found charater jump great.
He was amazed when I talked to him about BGUI. He never heard about that.
It is not because features are discussed and developped during months on 
dev-mailing list or irc that users will automatic be conscious at 
official release that it exists. They finish their 6_8 months project 
with the same release that was used to begin it. Then, they read release 
logs of the last version and ignore release logs in between.
The discussion around BGE could turn like stupid interface threads where 
people who use unity or other engines are numerically proeminent and 
will ask to re-invent what is already there.

I have also a lot of doubts about the 3 series period.
I made a book on 2.63 (Bmesh).
Somebody asked me to make a demonstration about blender for 3D 
printing before 2.67 release.
So, I showed 2.67 printing tools with a build of the day instead of 
offficial 2.66, explaining that tools would be quickly available.
And a guy asked to me why I based my book on 2.63 instead of 2.62.
It was the version in packages of his linux distribution.
Do you really think that people will understand the purpose of these 
series ?
They will download what seems to be the last version 2.8 and then 
complain :blender sucks because there is no documentation and no 
ressources about this release.
And when people will go on forums to find a specific feature; the answer 
will be :
_Try the last 2.7 unstable release. All basic functions are bugguy but 
this specific feature is far better than in 2.6 and does not exist yet 
in experimental 2.8.
_Finally, I prefer to wait 3.0 to test blender.
I think that you can give a special cool name to the serie like 
BlenderGTX 1 to BlenderGTX 20 without the error of communication to name 
it 2.8X.


On 17/06/2013 08:00, Daniel Stokes wrote:
 I would like to know more about what Ton means by the line What should
 then be dropped is the idea to make Blender have an embedded “true” game
 engine from the blog post.

 What exactly is proposed to be dropped here? It looks to me all that is
 proposed to be dropped is an idea, changing the focus of the game engine to
 make it better at what it can do rather than making it a clone of other
 game engine/game editors. Are we actually talking about removing features
 and/or the ability to publish a game? The blog post mentions creating 3D
 interaction for walkthroughs, for scientific sims, or game prototypes.
 This can still make use of existing code/features as well as the ability to
 publish and distribute these creations.

 As a BGE developer I have often considered a closer integration of the BGE
 and the rest of Blender for their mutual benefit. At its simplest, closer
 integration means better viewport visualization, and more maintained code
 for the BGE. Stronger integration yields even more interesting ideas as Ton
 outlines in the blog post. As I said in my original response, this sounds
 like a great idea as long as those three conditions (mostly we aren't
 losing a lot of functionality for current BGE users) are met.

 As to the idea of me changing GSoC projects, I am not entirely against it,
 but I would like to better understand both Ton's proposal and the potential
 new project before jumping ship to a vague/undefined project.

 Regards,
 Daniel Stokes

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Benjamin Tolputt

On 17/06/2013, at 8:22 PM, Angus Hollands wrote:

 In response to B. Tolputt's email, I think there are one or two things that
 need to be addressed. Firstly, the animation tools are perfectly functional
 in both Blender and BGE, unless you could clarify.

Blender does not have Animation Blend Trees nor does it have Animation State 
Machines. Like many things, you can hack a basic one together using Python with 
some effort, but the Blender Game Engine does not have them out of the box. I 
was quite specific about what was missing (and present in Unity) and I checked 
again before posting.

 The multiplayer aspect is true, and something that I am working on, and
 considering that unity itself requires scripting to use the multiplayer
 system, one may argue that we too have multiplayer by that standard.

Sorry, but there is a *big* difference between being able to send messages over 
the network (Python) and being able to just toggle on game object state 
synchronisation (Unity). There is more to claiming multiplayer support than 
having a TCP/IP pipe available. Just as there is more to having built-in 
Animation State Machine support than just a Turing complete scripting language.

I'm not trying to belittle the BGE, but I'm not speaking out of ignorance 
either. 

--
Benjamin Tolputt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Ton Roosendaal

Hi,

We only have to respect two aspects for supported platforms:

- be able to move forward with Blender in ways we like to
- have developers available to keep platforms supported

Market shares don't have to play a role. I also don't know of any project here 
that would practically require to drop 32 bits. If someone has that issue, we 
can openly review that.

Same goes for XP support. I have no evidence it wouldn't allow to run opengl 
2.1 features. 

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 17 Jun, 2013, at 10:07, Jürgen Herrmann wrote:

 Hi Bastien,
 Good to hear that I am not totally alone with my point of view ;-)
 Ton sent in some interesting statistics of the blender.org website visitors:
 
 http://lists.blender.org/pipermail/bf-committers/2013-May/040268.html
 http://lists.blender.org/pipermail/bf-committers/2013-May/040269.html
 http://lists.blender.org/pipermail/bf-committers/2013-May/040274.html
 
 And I started a poll in blenderartists :
 http://www.blenderartists.org/forum/showthread.php?291199-32-or-64bit
 
 The results speak for themselves ...
 /Jürgen
 
 Am 17.06.2013 um 09:43 schrieb Bastien Montagne montagn...@wanadoo.fr:
 
 Please don’t be stupid! Comparing XP and Linux on a market share basis 
 is just pure nonsense. There’s at least two huge differences between 
 those OS's:
 *One is 12 years old, the other one is plain modern (don’t think anyone 
 would care to maintain Blender for over 10 years old linux, nor even for 
 OSX!).
 *Even though a few XP are listed in 
 http://wiki.blender.org/index.php/Dev:Ref/Supported_platforms (and I’m 
 not sure this list is really up-to-date), you’ll find far more Blender 
 devs under linux.
 
 And despite the fact that XP is still about 40% of PCs connecting to the 
 web, you’ll have a hard time finding any commercial 3D software 
 supporting it (most don’t even support Vista anymore). While a fare 
 amount of them do support Linux.
 
 It would interesting to know the amount of XP PCs that download Blender, 
 btw. My guess is that it would be far less than 40%.
 
 So in a word, if we drop OpenGL below 2.1 (or even 3.0), it makes sense 
 to me to also drop XP. You can’t waist time (and even often limit your 
 app possibilities) to support obsolete stuff forever!
 
 On 17/06/2013 06:52, Alexandr Kuznetsov wrote:
 Drop linux. It has 1% market share, less than xp. No more x11 hacks. And
 Mac OS X Tiger. Oops, too late. Somebody already did it.
 
 On 6/17/2013 12:46 AM, Harley Acheson wrote:
 Jürgen,
 
 If we are considering dropping Windows XP we should probably also
 consider dropping the other operating systems that have even less usage.
 Which is everything else besides Windows 7. So every version of
 Mac and all flavors of Linux combined.  LOL
 
 Harley
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Ton Roosendaal

Hi Daniel,

I wrote the blog post as a discussion piece, something we can spend on for 
months, or a year, or as much time we need. We have a quite long way to go 
before a new GE can be defined to be feasible anyway.

I would also like to see a wide consensus about future plans for Blender. For 
that reason you shouldn't see it as 'bad timing', or a suggestion to refocus 
your work. 

The GE itself, and its current users, will really benefit your work now. Your 
gsoc project is also meant to solve a lot of current issues (bugs) anyway. I 
hope you can continue that work happily. 

(Long answer to your questions in a next mail)

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 17 Jun, 2013, at 8:00, Daniel Stokes wrote:

 I would like to know more about what Ton means by the line What should
 then be dropped is the idea to make Blender have an embedded “true” game
 engine from the blog post.
 
 What exactly is proposed to be dropped here? It looks to me all that is
 proposed to be dropped is an idea, changing the focus of the game engine to
 make it better at what it can do rather than making it a clone of other
 game engine/game editors. Are we actually talking about removing features
 and/or the ability to publish a game? The blog post mentions creating 3D
 interaction for walkthroughs, for scientific sims, or game prototypes.
 This can still make use of existing code/features as well as the ability to
 publish and distribute these creations.
 
 As a BGE developer I have often considered a closer integration of the BGE
 and the rest of Blender for their mutual benefit. At its simplest, closer
 integration means better viewport visualization, and more maintained code
 for the BGE. Stronger integration yields even more interesting ideas as Ton
 outlines in the blog post. As I said in my original response, this sounds
 like a great idea as long as those three conditions (mostly we aren't
 losing a lot of functionality for current BGE users) are met.
 
 As to the idea of me changing GSoC projects, I am not entirely against it,
 but I would like to better understand both Ton's proposal and the potential
 new project before jumping ship to a vague/undefined project.
 
 Regards,
 Daniel Stokes
 
 
 On Sun, Jun 16, 2013 at 10:46 PM, Benjamin Tolputt 
 btolp...@internode.on.net wrote:
 
 On 17/06/2013, at 3:23 PM, Campbell Barton wrote:
 
 Then it may be a good argument for Daniel to make a start on
 interactive-animation tools,
 
 If he is amenable to the switch, then that would make a decent compromise
 to offer surely?
 
 While this is a valid point, (as far as I know) none of these devs
 have stepped up to really supporting the BGE and helping become a
 maintainer.
 They mostly submit one feature they need for their game, then become
 inactive with BGE dev.
 
 I wasn't pointing it out as a reason against Ton's move, I was using it to
 support the *earlier* point that there is a lack developer effort/focus
 toward the BGE. The patches/submissions to Blender aren't being accepted, a
 good-sized proportion of BGE advocates are recommending that one use a
 build that applies most of them, and yet they admit is almost a fork due to
 the variance between official BGE and HG1 build BGE.
 
 Perhaps it will be a benefit to both BGE and Blender if they become
 separate projects? Blender can focus on asset creation (with the data
 structures and code compromises that make that efficient) whilst the BGE
 can start optimising the code/structures it uses to make it better for
 running a game.
 
 ... you could argue this is catch22 - if we accepted their patches
 they would become more active and submit more fixes but I still
 think if someone really wanted to become active and take the BGE
 forward they could - despite some slow patch review.
 
 Whilst you could argue the catch-22 aspect, I'd have to disagree that slow
 patch review isn't a big issue in it's own right. Watching a patch wither
 on the vine is a very demotivating experience, especially if it fixes
 something and the bug is left in the main project despite you having put
 the effort into solving it so the core development team didn't have to.
 That's something being bandied about the Blender-verse lately as well.
 
 Sure, if you want to be active enough, you'll walk over shards of broken
 glass to keep submitting your patches but that doesn't mean we should
 expect them to. Again, not an argument against the BGE
 removal/simplification as I support/defend Ton's decision in this regard.
 Just pointing out that the argument (like the it's not as good as the
 competition one) is pretty poor on it's own.
 
 --
 Benjamin Tolputt
 ___
 Bf-committers mailing list
 Bf-committers@blender.org

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Przemyslaw Golab

 Really good reference of GE and Animation Tool integration is Source Film
Maker it's really powerful tool Allowing to record gameplay and edit it as
animations in traditional fashion, even if it's point cloud bake per frame.
Something like this could benefit Blender in new production workflows,
action recording, puppetry.

Although I would like to see REAL oss game engine, with real tools, not
only naked core like most oss game engines out there... BGE is going
nowhere, mostly because of license. Making it first flag citizen in Blender
could ignite life into this project.
Making usable engine for deployment would probably be something for it's
own project.


2013/6/17 Ton Roosendaal t...@blender.org

 Hi Daniel,

 I wrote the blog post as a discussion piece, something we can spend on for
 months, or a year, or as much time we need. We have a quite long way to go
 before a new GE can be defined to be feasible anyway.

 I would also like to see a wide consensus about future plans for Blender.
 For that reason you shouldn't see it as 'bad timing', or a suggestion to
 refocus your work.

 The GE itself, and its current users, will really benefit your work now.
 Your gsoc project is also meant to solve a lot of current issues (bugs)
 anyway. I hope you can continue that work happily.

 (Long answer to your questions in a next mail)

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute
 Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



 On 17 Jun, 2013, at 8:00, Daniel Stokes wrote:

  I would like to know more about what Ton means by the line What should
  then be dropped is the idea to make Blender have an embedded “true” game
  engine from the blog post.
 
  What exactly is proposed to be dropped here? It looks to me all that is
  proposed to be dropped is an idea, changing the focus of the game engine
 to
  make it better at what it can do rather than making it a clone of other
  game engine/game editors. Are we actually talking about removing features
  and/or the ability to publish a game? The blog post mentions creating 3D
  interaction for walkthroughs, for scientific sims, or game prototypes.
  This can still make use of existing code/features as well as the ability
 to
  publish and distribute these creations.
 
  As a BGE developer I have often considered a closer integration of the
 BGE
  and the rest of Blender for their mutual benefit. At its simplest, closer
  integration means better viewport visualization, and more maintained code
  for the BGE. Stronger integration yields even more interesting ideas as
 Ton
  outlines in the blog post. As I said in my original response, this sounds
  like a great idea as long as those three conditions (mostly we aren't
  losing a lot of functionality for current BGE users) are met.
 
  As to the idea of me changing GSoC projects, I am not entirely against
 it,
  but I would like to better understand both Ton's proposal and the
 potential
  new project before jumping ship to a vague/undefined project.
 
  Regards,
  Daniel Stokes
 
 
  On Sun, Jun 16, 2013 at 10:46 PM, Benjamin Tolputt 
  btolp...@internode.on.net wrote:
 
  On 17/06/2013, at 3:23 PM, Campbell Barton wrote:
 
  Then it may be a good argument for Daniel to make a start on
  interactive-animation tools,
 
  If he is amenable to the switch, then that would make a decent
 compromise
  to offer surely?
 
  While this is a valid point, (as far as I know) none of these devs
  have stepped up to really supporting the BGE and helping become a
  maintainer.
  They mostly submit one feature they need for their game, then become
  inactive with BGE dev.
 
  I wasn't pointing it out as a reason against Ton's move, I was using it
 to
  support the *earlier* point that there is a lack developer effort/focus
  toward the BGE. The patches/submissions to Blender aren't being
 accepted, a
  good-sized proportion of BGE advocates are recommending that one use a
  build that applies most of them, and yet they admit is almost a fork
 due to
  the variance between official BGE and HG1 build BGE.
 
  Perhaps it will be a benefit to both BGE and Blender if they become
  separate projects? Blender can focus on asset creation (with the data
  structures and code compromises that make that efficient) whilst the BGE
  can start optimising the code/structures it uses to make it better for
  running a game.
 
  ... you could argue this is catch22 - if we accepted their patches
  they would become more active and submit more fixes but I still
  think if someone really wanted to become active and take the BGE
  forward they could - despite some slow patch review.
 
  Whilst you could argue the catch-22 aspect, I'd have to disagree that
 slow
  patch review isn't a big issue in it's own right. Watching a patch
 wither
  on the vine is a very demotivating experience, especially if it

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-17 Thread Daniel Stokes

Ton,

Thank you for your response. It sounds like what you have in mind is
actually similar to thoughts I have already had for the game engine, though
perhaps on a more ambitious scale. It would certainly help BGE development
if more of the game engine code was shared with the rest of Blender.

I look forward to seeing how this progresses.

Regards,
Daniel Stokes


On Mon, Jun 17, 2013 at 10:02 AM, Przemyslaw Golab 
golab.przemys...@gmail.com wrote:

  Really good reference of GE and Animation Tool integration is Source Film
 Maker it's really powerful tool Allowing to record gameplay and edit it as
 animations in traditional fashion, even if it's point cloud bake per frame.
 Something like this could benefit Blender in new production workflows,
 action recording, puppetry.

 Although I would like to see REAL oss game engine, with real tools, not
 only naked core like most oss game engines out there... BGE is going
 nowhere, mostly because of license. Making it first flag citizen in Blender
 could ignite life into this project.
 Making usable engine for deployment would probably be something for it's
 own project.


 2013/6/17 Ton Roosendaal t...@blender.org

  Hi Daniel,
 
  I wrote the blog post as a discussion piece, something we can spend on
 for
  months, or a year, or as much time we need. We have a quite long way to
 go
  before a new GE can be defined to be feasible anyway.
 
  I would also like to see a wide consensus about future plans for Blender.
  For that reason you shouldn't see it as 'bad timing', or a suggestion to
  refocus your work.
 
  The GE itself, and its current users, will really benefit your work now.
  Your gsoc project is also meant to solve a lot of current issues (bugs)
  anyway. I hope you can continue that work happily.
 
  (Long answer to your questions in a next mail)
 
  -Ton-
 
  
  Ton Roosendaal  -  t...@blender.org   -   www.blender.org
  Chairman Blender Foundation - Producer Blender Institute
  Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
 
 
 
  On 17 Jun, 2013, at 8:00, Daniel Stokes wrote:
 
   I would like to know more about what Ton means by the line What should
   then be dropped is the idea to make Blender have an embedded “true”
 game
   engine from the blog post.
  
   What exactly is proposed to be dropped here? It looks to me all that is
   proposed to be dropped is an idea, changing the focus of the game
 engine
  to
   make it better at what it can do rather than making it a clone of other
   game engine/game editors. Are we actually talking about removing
 features
   and/or the ability to publish a game? The blog post mentions creating
 3D
   interaction for walkthroughs, for scientific sims, or game prototypes.
   This can still make use of existing code/features as well as the
 ability
  to
   publish and distribute these creations.
  
   As a BGE developer I have often considered a closer integration of the
  BGE
   and the rest of Blender for their mutual benefit. At its simplest,
 closer
   integration means better viewport visualization, and more maintained
 code
   for the BGE. Stronger integration yields even more interesting ideas as
  Ton
   outlines in the blog post. As I said in my original response, this
 sounds
   like a great idea as long as those three conditions (mostly we aren't
   losing a lot of functionality for current BGE users) are met.
  
   As to the idea of me changing GSoC projects, I am not entirely against
  it,
   but I would like to better understand both Ton's proposal and the
  potential
   new project before jumping ship to a vague/undefined project.
  
   Regards,
   Daniel Stokes
  
  
   On Sun, Jun 16, 2013 at 10:46 PM, Benjamin Tolputt 
   btolp...@internode.on.net wrote:
  
   On 17/06/2013, at 3:23 PM, Campbell Barton wrote:
  
   Then it may be a good argument for Daniel to make a start on
   interactive-animation tools,
  
   If he is amenable to the switch, then that would make a decent
  compromise
   to offer surely?
  
   While this is a valid point, (as far as I know) none of these devs
   have stepped up to really supporting the BGE and helping become a
   maintainer.
   They mostly submit one feature they need for their game, then become
   inactive with BGE dev.
  
   I wasn't pointing it out as a reason against Ton's move, I was using
 it
  to
   support the *earlier* point that there is a lack developer
 effort/focus
   toward the BGE. The patches/submissions to Blender aren't being
  accepted, a
   good-sized proportion of BGE advocates are recommending that one use a
   build that applies most of them, and yet they admit is almost a fork
  due to
   the variance between official BGE and HG1 build BGE.
  
   Perhaps it will be a benefit to both BGE and Blender if they become
   separate projects? Blender can focus on asset creation (with the data
   structures and code compromises that make that efficient) whilst the
 BGE
   can

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Jürgen Herrmann

Hi Ton, 

sounds great at a first glance ;) I really like the 2.7 targets.

Imho we should also think about dropping WinXP support and 32bit code in the
future. (Maybe for 2.8?)
This would make life easier for devs as we don't have to care about legacy
compatibility stuff and can focus on writing neat and fast 64bit code.
And a major code cleanup might be overdue.

/Jürgen

-Ursprüngliche Nachricht-
Von: bf-committers-boun...@blender.org
[mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal
Gesendet: Sonntag, 16. Juni 2013 15:45
An: bf-blender developers
Betreff: [Bf-committers] Blender roadmap article on code blog

Hi all,

Here's a write-up for projects and focus the next years:
http://code.blender.org/

Feedback welcome :)

-Ton-


Ton Roosendaal  -  t...@blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A  -
1018AD Amsterdam  -  The Netherlands



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Daniel Stokes

You're getting some negative responses to the proposed BGE changes on the
blenderartists forums, including several suggestions of forking the project:

http://blenderartists.org/forum/showthread.php?297037-Project-GameBlender-a-radical-solution-involving-the-BGE-as-an-independent-project
http://blenderartists.org/forum/showthread.php?297023-Future-of-the-BGE

I personally think the proposed BGE changes could be interesting as long as
three things happen:
1. We don't lose existing BGE features
2. We don't lose the ability to publish BGE games
3. We don't lose a focus on performance for BGE games

A tighter integration of the BGE and the rest of Blender could be very
beneficial to the BGE with its limited development resources, but many
people fear losing the engine they have invested time into learning or
developing. Furthermore, I would like to point out that the BGE is at least
on par with the free version of Unity feature wise.

Regards,
Daniel Stokes


On Sun, Jun 16, 2013 at 6:53 AM, Jürgen Herrmann shadow...@me.com wrote:

 Hi Ton,

 sounds great at a first glance ;) I really like the 2.7 targets.

 Imho we should also think about dropping WinXP support and 32bit code in
 the
 future. (Maybe for 2.8?)
 This would make life easier for devs as we don't have to care about legacy
 compatibility stuff and can focus on writing neat and fast 64bit code.
 And a major code cleanup might be overdue.

 /Jürgen

 -Ursprüngliche Nachricht-
 Von: bf-committers-boun...@blender.org
 [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal
 Gesendet: Sonntag, 16. Juni 2013 15:45
 An: bf-blender developers
 Betreff: [Bf-committers] Blender roadmap article on code blog

 Hi all,

 Here's a write-up for projects and focus the next years:
 http://code.blender.org/

 Feedback welcome :)

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A  -
 1018AD Amsterdam  -  The Netherlands



 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Alexandr Kuznetsov

Hi Jürgen Herrmann.


Stop stealing my april fools prank.  Afaik, there aren't any significant 
Windows API  additions in vista/7/8 which we might use (Like raw input)
Plus, if a program has pointers right, x32/x64 compatibility isn't that 
hard. Plus, we already have DNA conversion, including endiness.  On the 
countrary, I would encourage to support x32 ( and even PPC architecture) 
to ensure portability.

Best,
Alex

On 6/16/2013 9:53 AM, Jürgen Herrmann wrote:
 Hi Ton,

 sounds great at a first glance ;) I really like the 2.7 targets.

 Imho we should also think about dropping WinXP support and 32bit code in the
 future. (Maybe for 2.8?)
 This would make life easier for devs as we don't have to care about legacy
 compatibility stuff and can focus on writing neat and fast 64bit code.
 And a major code cleanup might be overdue.

 /Jürgen

 -Ursprüngliche Nachricht-
 Von: bf-committers-boun...@blender.org
 [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal
 Gesendet: Sonntag, 16. Juni 2013 15:45
 An: bf-blender developers
 Betreff: [Bf-committers] Blender roadmap article on code blog

 Hi all,

 Here's a write-up for projects and focus the next years:
 http://code.blender.org/

 Feedback welcome :)

 -Ton-

 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A  -
 1018AD Amsterdam  -  The Netherlands



 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Benjamin Tolputt

On 17/06/2013, at 11:46 AM, Daniel Stokes wrote:

 Furthermore, I would like to point out that the BGE is at least
 on par with the free version of Unity feature wise.

Firstly, let me state that whilst I actually approve of Ton's moves regarding 
BGE, I'm not writing this email in an effort to discourage those that want to 
keep the BGE (or their favourite elements thereof) in core Blender. Whilst I 
prefer alternate engines for various reasons, I see no problems with there 
being an official game engine for Blender should the issues Ton raised in the 
blog be resolved (in particular, the developer effort issue).

With that said, and without actually being a Unity evangelist (I too don't use 
it), the above is false and needs to be corrected in the same email archive as 
the claim was made. BGE is *not* on par with the free version of Unity feature 
wise. 

Unity has multiplayer support for free, BGE does not
Unity has (working) animation tools Blender  BGE do not. Including animation 
specific state machine  blend tree support.
Unity also has built-in PVS occlusion culling, LOD terrain  foliage, automated 
texture atlasing, integrated Web Browser plugin (with bi-directional API access 
to/from the browser), one-click iOS  Android deployment, and so on. That's 
just the free version (the pro one has quite a bit more over  above BGE).

There are features out of the box that BGE has that Unity Free does not 
(Detour/Recast nav-mesh routing comes to mind), but that means BGE has an 
alternate feature-set to Unity Free, not really one on par with it.

As one of the reasons Ton mentioned for the decision regarding the BGE was the 
lack of a competitive featureset compared to other offerings, we need to be 
honest about these things if we're going to discuss changes to his proposal on 
the matter.

--
Benjamin Tolputt

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Jürgen Herrmann

Hi Alexandr,

I am actually not fooling on this. One example for API not present in XP is : 
InterlockedCompareExchange64 ( 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683562(v=vs.85).aspx)
But that is actually not the problem! MS drops XP support next year, so XP 
users will get rare. Why should we support XP in blender 2.7/2.8?
32/64 bit portability is just more work to do. You loose speed in some places 
but you might be right. Just for portability this might be good. But on the 
other hand who uses 32bit applications in 3D?
It makes absolutely no sense to stay in 32bits when you can have more Memory in 
a 3D application ;)

/Jürgen



Am 17.06.2013 um 04:18 schrieb Alexandr Kuznetsov kuzsa...@gmail.com:

 Hi Jürgen Herrmann.
 
 
 Stop stealing my april fools prank.  Afaik, there aren't any significant 
 Windows API  additions in vista/7/8 which we might use (Like raw input)
 Plus, if a program has pointers right, x32/x64 compatibility isn't that 
 hard. Plus, we already have DNA conversion, including endiness.  On the 
 countrary, I would encourage to support x32 ( and even PPC architecture) 
 to ensure portability.
 
 Best,
 Alex
 
 On 6/16/2013 9:53 AM, Jürgen Herrmann wrote:
 Hi Ton,
 
 sounds great at a first glance ;) I really like the 2.7 targets.
 
 Imho we should also think about dropping WinXP support and 32bit code in the
 future. (Maybe for 2.8?)
 This would make life easier for devs as we don't have to care about legacy
 compatibility stuff and can focus on writing neat and fast 64bit code.
 And a major code cleanup might be overdue.
 
 /Jürgen
 
 -Ursprüngliche Nachricht-
 Von: bf-committers-boun...@blender.org
 [mailto:bf-committers-boun...@blender.org] Im Auftrag von Ton Roosendaal
 Gesendet: Sonntag, 16. Juni 2013 15:45
 An: bf-blender developers
 Betreff: [Bf-committers] Blender roadmap article on code blog
 
 Hi all,
 
 Here's a write-up for projects and focus the next years:
 http://code.blender.org/
 
 Feedback welcome :)
 
 -Ton-
 
 
 Ton Roosendaal  -  t...@blender.org   -   www.blender.org
 Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A  -
 1018AD Amsterdam  -  The Netherlands
 
 
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Campbell Barton

Regarding dropping the current BGE.

Not being as good as competition is a stupid argument (on its own),
quite a few of blenders features aren't as good as other software.

Why not kick out the video editor because its inferior to
most-commercial-video-editors ?


The problem IMHO is more that the BGE is not getting much developer
attention and not likely to pick up any time soon.

While I'm not against improving interactive features for Blenders
animation system, I think this wont make for a great game-engine
(probably it just gives us handy utility to use for small demos).

Since we currently don't have so much developer interest to work in
the game-engine, I'm wondering who has the time to work on an
interactive animation system (not just get it working but make it work
really well, alpha sorting, fast add/remove objects without depsgraph
recalcs, python api's to physics world so you can react to collisions,
add ability to write own shaders, etc...).

The timing here is unfortunate too.
It's not nice for Daniel Stokes to find out the BGE will be
discontinued the day he starts working on GSOC. (BGE Level of Detail
and Bug Fixing/Polishing)
Bug-fixing a system that gets removed in a year isn't such good use of
resources.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Jürgen Herrmann

Hi Thomas, 

You are right, I just said we should think about it, not do it right away ;)
But IMHO we are limiting ourselves to a technology that will get obsolete in 
the future. Maybe I am a bit too fast on that one...
Maybe 3.0 would be a better choice for this.

/Jürgen

Am 17.06.2013 um 06:34 schrieb Thomas Dinges blen...@dingto.org:

 Hi,
 you should keep in mind that Blender is also very much used in poor 
 countries, where a lot of people still use XP and X32.
 At one point, yes we should not worry about Windows XP anymore, but 
 doing this before MS drops support is premature.
 
 Dropping x32 will not happen any time soon though. Even Windows 8 is 
 still available as x32 version. Again, you have to see the larger 
 picture. There are a lot of people who cannot simply buy a new computer 
 with x64 support. ;)
 
 Thomas
 
 Am 17.06.2013 06:27, schrieb Jürgen Herrmann:
 Hi Alexandr,
 
 I am actually not fooling on this. One example for API not present in XP is 
 : InterlockedCompareExchange64 ( 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms683562(v=vs.85).aspx)
 But that is actually not the problem! MS drops XP support next year, so XP 
 users will get rare. Why should we support XP in blender 2.7/2.8?
 32/64 bit portability is just more work to do. You loose speed in some 
 places but you might be right. Just for portability this might be good. But 
 on the other hand who uses 32bit applications in 3D?
 It makes absolutely no sense to stay in 32bits when you can have more Memory 
 in a 3D application ;)
 
 /Jürgen
 
 
 
 Am 17.06.2013 um 04:18 schrieb Alexandr Kuznetsov kuzsa...@gmail.com:
 
 Hi Jürgen Herrmann.
 
 
 Stop stealing my april fools prank.  Afaik, there aren't any significant
 Windows API  additions in vista/7/8 which we might use (Like raw input)
 Plus, if a program has pointers right, x32/x64 compatibility isn't that
 hard. Plus, we already have DNA conversion, including endiness.  On the
 countrary, I would encourage to support x32 ( and even PPC architecture)
 to ensure portability.
 
 Best,
 Alex
 
 On 6/16/2013 9:53 AM, Jürgen Herrmann wrote:
 Hi Ton,
 
 sounds great at a first glance ;) I really like the 2.7 targets.
 
 Imho we should also think about dropping WinXP support and 32bit code in 
 the
 future. (Maybe for 2.8?)
 This would make life easier for devs as we don't have to care about legacy
 compatibility stuff and can focus on writing neat and fast 64bit code.
 And a major code cleanup might be overdue.
 
 /Jürgen
 
 -- 
 Thomas Dinges
 Blender Developer, Artist and Musician
 
 www.dingto.org
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Thomas Dinges

Hi,
you should keep in mind that Blender is also very much used in poor 
countries, where a lot of people still use XP and X32.
At one point, yes we should not worry about Windows XP anymore, but 
doing this before MS drops support is premature.

Dropping x32 will not happen any time soon though. Even Windows 8 is 
still available as x32 version. Again, you have to see the larger 
picture. There are a lot of people who cannot simply buy a new computer 
with x64 support. ;)

Thomas

Am 17.06.2013 06:27, schrieb Jürgen Herrmann:
 Hi Alexandr,

 I am actually not fooling on this. One example for API not present in XP is : 
 InterlockedCompareExchange64 ( 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms683562(v=vs.85).aspx)
 But that is actually not the problem! MS drops XP support next year, so XP 
 users will get rare. Why should we support XP in blender 2.7/2.8?
 32/64 bit portability is just more work to do. You loose speed in some places 
 but you might be right. Just for portability this might be good. But on the 
 other hand who uses 32bit applications in 3D?
 It makes absolutely no sense to stay in 32bits when you can have more Memory 
 in a 3D application ;)

 /Jürgen



 Am 17.06.2013 um 04:18 schrieb Alexandr Kuznetsov kuzsa...@gmail.com:

 Hi Jürgen Herrmann.


 Stop stealing my april fools prank.  Afaik, there aren't any significant
 Windows API  additions in vista/7/8 which we might use (Like raw input)
 Plus, if a program has pointers right, x32/x64 compatibility isn't that
 hard. Plus, we already have DNA conversion, including endiness.  On the
 countrary, I would encourage to support x32 ( and even PPC architecture)
 to ensure portability.

 Best,
 Alex

 On 6/16/2013 9:53 AM, Jürgen Herrmann wrote:
 Hi Ton,

 sounds great at a first glance ;) I really like the 2.7 targets.

 Imho we should also think about dropping WinXP support and 32bit code in the
 future. (Maybe for 2.8?)
 This would make life easier for devs as we don't have to care about legacy
 compatibility stuff and can focus on writing neat and fast 64bit code.
 And a major code cleanup might be overdue.

 /Jürgen

-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Alexandr Kuznetsov

Drop linux. It has 1% market share, less than xp. No more x11 hacks. And 
Mac OS X Tiger. Oops, too late. Somebody already did it.

On 6/17/2013 12:46 AM, Harley Acheson wrote:
 Jürgen,

 If we are considering dropping Windows XP we should probably also
 consider dropping the other operating systems that have even less usage.
 Which is everything else besides Windows 7. So every version of
 Mac and all flavors of Linux combined.  LOL

 Harley
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Harley Acheson

Jürgen,

If we are considering dropping Windows XP we should probably also
consider dropping the other operating systems that have even less usage.
Which is everything else besides Windows 7. So every version of
Mac and all flavors of Linux combined.  LOL

Harley
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Benjamin Tolputt

On 17/06/2013, at 2:41 PM, Campbell Barton wrote:

 Not being as good as competition is a stupid argument (on its own),
 quite a few of blenders features aren't as good as other software.

Agreed. On it's own, it's a terrible argument. After all, there are *dedicated* 
game engines out there that are worse than their competition ;)

Some of the reasons *why* is isn't as good as the competition are worthy 
arguments though, but I don't think Ton is making them directly. Possibly to 
sidestep the argument that would entail (I've made the mistake before of 
punching that there tar-baby *eek* ).

 The problem IMHO is more that the BGE is not getting much developer
 attention and not likely to pick up any time soon.

This I think is the kicker. Where development effort is spent is a frequent 
subject in the Blender-verse these days and for good reasons. Only the features 
that have developer focus get maintained and improved. Features that are not 
maintained in a larger body of work can have a detrimental affect on other 
areas (e.g. This module relies on feature X using function Y - we can't change 
function Y without altering the module... and we don't really maintain that 
module anymore).

 The timing here is unfortunate too.
 It's not nice for Daniel Stokes to find out the BGE will be
 discontinued the day he starts working on GSOC. (BGE Level of Detail
 and Bug Fixing/Polishing)
 Bug-fixing a system that gets removed in a year isn't such good use of
 resources.

I was unaware of this and have to agree, the timing sucks. That said, I'm not 
sure if it's a great argument for keeping the BGE as it is and integrated as it 
is. The whole sunk cost fallacy comes to mind and, while I don't want to be 
callous to Daniel Stokes, I can't see that his GSOC project will really change 
the underlying motivations that prompted this move.

There are folks on BlenderArtists talking about the large number of patches 
contributed for BGE that never made trunk and would almost constitute a fork 
themselves if applied (they're calling it the HG1 build. This is a symptom of 
the developer effort allocation problem mentioned earlier and would apply as 
much to a GSOC project as any other large patch correct?

--
Benjamin Tolputt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Jürgen Herrmann

Okay! Now it gets ridiculous :-D 
Guys you are right, market share is the point I missed.
But still in my opinion we are limiting blender to old tech whilst other 3D 
software goes ahead and drops old stuff much faster ;-)
I think 2.9/3.0 won't be here before 2016, so I am talking about a 3-4 year 
period. I don't want to kill XP tomorrow ;)


Am 17.06.2013 um 06:52 schrieb Alexandr Kuznetsov kuzsa...@gmail.com:

 Drop linux. It has 1% market share, less than xp. No more x11 hacks. And 
 Mac OS X Tiger. Oops, too late. Somebody already did it.
 
 On 6/17/2013 12:46 AM, Harley Acheson wrote:
 Jürgen,
 
 If we are considering dropping Windows XP we should probably also
 consider dropping the other operating systems that have even less usage.
 Which is everything else besides Windows 7. So every version of
 Mac and all flavors of Linux combined.  LOL
 
 Harley
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
 
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Campbell Barton

 The timing here is unfortunate too.
 It's not nice for Daniel Stokes to find out the BGE will be
 discontinued the day he starts working on GSOC. (BGE Level of Detail
 and Bug Fixing/Polishing)
 Bug-fixing a system that gets removed in a year isn't such good use of
 resources.

 I was unaware of this and have to agree, the timing sucks. That said, I'm not 
 sure if it's a great argument for keeping the BGE as it is and integrated as 
 it is. The whole sunk cost fallacy comes to mind and, while I don't want to 
 be callous to Daniel Stokes, I can't see that his GSOC project will really 
 change the underlying motivations that prompted this move.

Then it may be a good argument for Daniel to make a start on
interactive-animation tools,

 There are folks on BlenderArtists talking about the large number of patches 
 contributed for BGE that never made trunk and would almost constitute a fork 
 themselves if applied (they're calling it the HG1 build. This is a symptom 
 of the developer effort allocation problem mentioned earlier and would apply 
 as much to a GSOC project as any other large patch correct?

While this is a valid point, (as far as I know) none of these devs
have stepped up to really supporting the BGE and helping become a
maintainer.
They mostly submit one feature they need for their game, then become
inactive with BGE dev.

... you could argue this is catch22 - if we accepted their patches
they would become more active and submit more fixes but I still
think if someone really wanted to become active and take the BGE
forward they could - despite some slow patch review.

 --
 Benjamin Tolputt
 ___
 Bf-committers mailing list
 Bf-committers@blender.org
 http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender roadmap article on code blog

2013-06-16 Thread Benjamin Tolputt

On 17/06/2013, at 3:23 PM, Campbell Barton wrote:

 Then it may be a good argument for Daniel to make a start on
 interactive-animation tools,

If he is amenable to the switch, then that would make a decent compromise to 
offer surely?

 While this is a valid point, (as far as I know) none of these devs
 have stepped up to really supporting the BGE and helping become a
 maintainer.
 They mostly submit one feature they need for their game, then become
 inactive with BGE dev.

I wasn't pointing it out as a reason against Ton's move, I was using it to 
support the *earlier* point that there is a lack developer effort/focus toward 
the BGE. The patches/submissions to Blender aren't being accepted, a good-sized 
proportion of BGE advocates are recommending that one use a build that applies 
most of them, and yet they admit is almost a fork due to the variance between 
official BGE and HG1 build BGE. 

Perhaps it will be a benefit to both BGE and Blender if they become separate 
projects? Blender can focus on asset creation (with the data structures and 
code compromises that make that efficient) whilst the BGE can start optimising 
the code/structures it uses to make it better for running a game. 

 ... you could argue this is catch22 - if we accepted their patches
 they would become more active and submit more fixes but I still
 think if someone really wanted to become active and take the BGE
 forward they could - despite some slow patch review.

Whilst you could argue the catch-22 aspect, I'd have to disagree that slow 
patch review isn't a big issue in it's own right. Watching a patch wither on 
the vine is a very demotivating experience, especially if it fixes something 
and the bug is left in the main project despite you having put the effort into 
solving it so the core development team didn't have to. That's something being 
bandied about the Blender-verse lately as well.

Sure, if you want to be active enough, you'll walk over shards of broken glass 
to keep submitting your patches but that doesn't mean we should expect them to. 
Again, not an argument against the BGE removal/simplification as I 
support/defend Ton's decision in this regard. Just pointing out that the 
argument (like the it's not as good as the competition one) is pretty poor on 
it's own.

--
Benjamin Tolputt
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

53 matches

Mail list logo