[Bf-committers] questions about particles and collisions

[David Jeske]

I am trying to understand why particles (emitter and hair) ignore
collisions with their emitter objects, even if the emitter has a collision
modifier. (because this is very inconvenient)

I'm starting with emitter particles, because the situation there is simpler
and uncovers some of the challenges.

It seems like at least at some point someone thought particle-to-emitter
collisions should work, as evidenced by this code in particle_system.c,
collision_detect(). It is trying to prevent particles from colliding with
their emitter too early in their lifetime. (afaik this code currently does
nothing, because the emitter will never appear in the collision list, see
next)

   for (coll = colliders->first; coll; coll=coll->next) {
   ...
   /* particles should not collide with emitter at birth */
   if (coll->ob == col->emitter && pa->time < col->cfra && pa->time >=
col->old_cfra)
continue;

I can see that normal emitter particles ignore collisions with their own
emitter object because of this code-line in
particle_system.c:dynamics_step(). The second parameter (sim->ob) causes it
to skip itself when constructing the collider list.

   sim->colliders = get_collider_cache(sim->scene, sim->ob, NULL);

If I change the second parameter to NULL, it (may) include itself in the
collision list (if it has a collision modifier)

   sim->colliders = get_collider_cache(sim->scene, NULL, NULL);

Then placing a collision modifier on a particle emitter seems to cause the
particles to collide with their own emitter -- although there are some
issues.

One issue is that some particles appear to collide with the emitter at
birth (they emit opposite the normal), suggesting the first code-snippet is
insufficient to prevent this problem.

Another problem, is that if the emitter-collision-modifier is set to kill
particles, the first particle it kills seems to kill the entire particle
system. (see [1] below)


Are these the only two issues, or are there other problems?


I'm trying to figure out if this is reasonably fixable, or if it is just a
"bad idea" to pull on this thread. For example, is there something about
particles colliding with their own emitter that violates some expectation
of the modifier stack? Or is this simply a matter of coming up with
appropriate solutions to the odd cases and data interactions so it works
properly?

---

[1] On a related note, at ...
https://wiki.blender.org/index.php/Dev:Source/Physics/Collision_Modifier

It says:

 The collision modifier safes the position of the vertices
of the object at the corresponding position on the modifier
stack. It does this for the current and the last position
using GLOBAL coordinates. The data is only valid as long as

  * you don't skip ahead/back several frames
[TODO: should be enhanced later]
  * the number of vertices don't change on the
modifier stack.


Is this related? Does the particle death kill the collision 'safe' (seems
like it would, though i don't understand why this would kill the particle
system)? Does a vertex-count-change invalidate the collision modifer 'safe'
even when verticies are added "after" the collision modifier in the
modifier stack?
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] questions about particles and collisions

[David Jeske]

Quick update.

I have particle / emitter self-collision working, at least in my quick
test. Here is a test showing an emitter surface with both a collision
modifier and a particle system.

  https://www.youtube.com/watch?v=2WUeFGY4Rlg&feature=youtu.be

What I did was introduce a new particle state during the beginning of a
particle lifetime, PARS_BIRTHING, during which it does not collide. They
switch to PARS_ALIVE as soon as they are not colliding with anything. This
prevents particles from colliding with their own emitter while they are
spawning. Kill particles now also works correctly.


https://github.com/jeske/blender_hacking/commit/d9a96cbcf3915eda1e9b4b49437539fd52adf689

At this point, I'm doing more testing, and trying to figure out if this
unintentionally breaks anything. It seemed a rather easy change to make, so
I'm suspicious that there is a deeper reason particle/emitter
self-collision is disabled.

Can anyone think of a reason this is not a good thing to do?

Here is a little more background...

My new BIRTHING state ignores collisions with any object, not just the
emitter. I struggled to think of a scenario where this is bad, since
birthing a particle into a collision state seems both highly unlikely, and
might cause unwanted instability. Can anyone can think of a reason this is
generally bad, and why BIRTHING should be restricted to only ignoring
collisions with the emitter? If so it could be changed to do that instead
(the code for this will just be a more complicated).

My patch appears to work whether the collision modifier is before or after
the particle system, though I didn't yet test for subtlety. As a user, I
think I would expect the collision modifier before the particle system to
mean particles only collide with the emitter, and after the particle system
to mean the particles collide with the emitter and other particle system
particles. I don't know how feasible this is.

Interested in any feedback.




On Mon, May 30, 2016 at 11:31 AM, David Jeske  wrote:

> I am trying to understand why particles (emitter and hair) ignore
> collisions with their emitter objects, even if the emitter has a collision
> modifier. (because this is very inconvenient)
>
> I'm starting with emitter particles, because the situation there is
> simpler and uncovers some of the challenges.
>
> It seems like at least at some point someone thought particle-to-emitter
> collisions should work, as evidenced by this code in particle_system.c,
> collision_detect(). It is trying to prevent particles from colliding with
> their emitter too early in their lifetime. (afaik this code currently does
> nothing, because the emitter will never appear in the collision list, see
> next)
>
>for (coll = colliders->first; coll; coll=coll->next) {
>...
>/* particles should not collide with emitter at birth */
>if (coll->ob == col->emitter && pa->time < col->cfra && pa->time >=
> col->old_cfra)
> continue;
>
> I can see that normal emitter particles ignore collisions with their own
> emitter object because of this code-line in
> particle_system.c:dynamics_step(). The second parameter (sim->ob) causes it
> to skip itself when constructing the collider list.
>
>sim->colliders = get_collider_cache(sim->scene, sim->ob, NULL);
>
> If I change the second parameter to NULL, it (may) include itself in the
> collision list (if it has a collision modifier)
>
>sim->colliders = get_collider_cache(sim->scene, NULL, NULL);
>
> Then placing a collision modifier on a particle emitter seems to cause the
> particles to collide with their own emitter -- although there are some
> issues.
>
> One issue is that some particles appear to collide with the emitter at
> birth (they emit opposite the normal), suggesting the first code-snippet is
> insufficient to prevent this problem.
>
> Another problem, is that if the emitter-collision-modifier is set to kill
> particles, the first particle it kills seems to kill the entire particle
> system. (see [1] below)
>
>
> Are these the only two issues, or are there other problems?
>
>
> I'm trying to figure out if this is reasonably fixable, or if it is just a
> "bad idea" to pull on this thread. For example, is there something about
> particles colliding with their own emitter that violates some expectation
> of the modifier stack? Or is this simply a matter of coming up with
> appropriate solutions to the odd cases and data interactions so it works
> properly?
>
> ---
>
> [1] On a related note, at ...
> https://wiki.blender.org/index.php/Dev:Source/Physics/Collision_Modifier
>
> It says:
>
>  The collision modifier safes the position of the vertices
> 

Re: [Bf-committers] questions about particles and collisions

[David Jeske]

Lukas, thanks for your response.

At the root of my puzzling is the question... Is an explicit check to
assure a particle system only collides with a collision modifier on it's
emitter that appears *before* itself sufficient to allow self collisions?
It seems like it might be, and I'm wondering if there is any specific
reason it's not (situations where the collision modifier 'save state' might
be invalidated during the evaluation of modifiers that come after it on the
stack).

I could see how manual initial particle collision avoidance control could
be useful, and it would be pretty easy to add. Is this something artists
would like to have? Likewise, do you know if artists miss the fact that
particles don't currently have support for collision groups?

The applicability of the billiard ball example is lost on me, as afaik,
blender doesn't currently support particle-to-particle collisions.

I should disclaim that I don't have a stance on whether particle-to-emitter
collisions are good to add or not. Some part of me wants them in so to make
blender more consistent, but I recognize that isn't always a good reason to
add the complexity.

For me this is currently a fact-finding mission to better understand
particle-to-emitter collision issues, because I would like to have
hair-to-emitter collisions. They are motivated by an actual use case, whose
value I think is more obvious. However, after experimenting with
hair-to-emitter collisions, it appears that current interpenetration
problems with the cloth/hair sim need to be fixed before hair-to-emitter
collisions would be practically useful.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] NLA Editor / Animation Layers

[David Jeske]

Is it possible this result could be achieved using Delta* keying sets on
bones?

Currently, I can't find any way to add a Delta key on a bone, however, if
it were possible, I would imagine one could make the "overlay edit" strip,
key delta-edits onto it and use add blending. Deltas to the resting pose
(as shown in the video) could be made with Delta keys, add, and hold
extrapolation. For edits to the animation itself, the envelope of an edit
could be controlled by keying in zero-delta keys before and after the
actual edited point.

In order to make this delta workflow usable, we'd need a way to
interactively add a Delta key onto a bone in pose mode in the 3d-view. I
think this would compare the bone's current pose to the bone's keyframe
calculated pose without the active action, resulting in the delta, which
would be keyed.  This doesn't sound particularly complicated to add.

Does this sound like it would work?

Hidde, does it sound like this would get you a workflow that would work?
How do you control the envelope of an animation edit in Maya? (this wasn't
shown in the video, as he stopped the video to create his jump deltas)
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Porting of Blender on Android

[David Jeske]

On Sun, Aug 5, 2012 at 9:21 PM, Alexandr Kuznetsov wrote:

> The main problem is that Blender uses OpenGL for UI and 3D view, but
> Android (and other mobile devices) have only OpenGL ES (subset of OpenGL)
>

If you havn't yet seen this, you might find it relevant.. JWZ implemented a
basic wrapper offering OpenGL style calls ontop of OpenGL with reasonable
performance..

http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

[David Jeske]

On Tue, Jun 4, 2013 at 8:05 AM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> Here's another discussion where the popup idea comes up:
> http://lists.blender.org/pipermail/bf-committers/2010-March/026573.html
>
> It's a tradeoff, do we really want to degrade usability for this?


I don't think this is a question of degrading expert blender usability.
It's a question of protecting a broader less expert userbase from malicious
blend files.

I think your previous post is an excellent case for not SILENTLY disabling
scripts by default. [1] However, this is not the only option. For nearly a
decade MS-Word has been using a challenge dialog before running scripts. Is
there ideological opposition to default to showing a dialog before
processing python scripts in a blend file?

The decision at the time was that no, we do not. Also note that even
> disabling scripts does not make Blender secure, there's dozens of
> other ways to create malicious .blend files.
>

What are the other "dozen" ways blender could
read/destroy/send-files-to-the-internet/install-viruses with python scripts
disabled?

[1] http://lists.blender.org/pipermail/bf-committers/2010-April/027216.html
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Please turn off Auto Run Python Scripts by default

[David Jeske]

This issue would be less problematic if new versions of blender would read
preferences set from older versions. Currently in my experience all
preferences have to be re-set after each new version download. Which means
if you turn off "auto load scripts" it only stays off until the next
download.

On Tue, Jun 4, 2013 at 2:15 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> Regarding implementation of a popup: if it is desired, you could load
> the file with scripts disabled, and then in the info header have a
> warning and button to reload the file with scripts enabled. That's
> nicely non-modal too.
>

This seems like quite an elegant blender-esq option.

It does appear this is a vulnerability in other popular 3d modeling
tools... I believe the attack surface area of blender may be worse than
Maya or 3ds, as blender is a free download. However, it's probably
comparable to DAZ studio, which is also free and also has this
vulnerability.

http://www.coresecurity.com/content/blender-scripting-injection
http://www.coresecurity.com/content/maya-arbitrary-command-execution
http://www.coresecurity.com/content/3dsmax-arbitrary-command-execution
http://www.coresecurity.com/content/dazstudio-scripting-injection

It might be worth adding this comparison information to the FAQ.
___
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

[David Jeske]

I like the overall structure of this roadmap.

It prompted me to cleanup and post my own 2013 Roadmap
Wishlist,
in-case it helps anyone's thinking/brainstorming.

If Blender does only four things in the next few years, I would personally
like them to be:

1) Include opt-in usage and automatic crash reporting in *every* blender
build, and a web dashboard to live usage/crash stats to devs and the
community. ( It looks like Google breakpad integration is
in-progress.
)

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 is
a class-based Javascript "facade" with optional-static typing, and
Javascript-V8 is 10-30x
fasterthan
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

[Bf-committers] render percentage and compositor behavior?

[David Jeske]

I wanted a quicker render+composite for proofing, so I set
render-percentage to 50% expecting it to work, and poof, my composite
started doing very weird things and crashing. I'm sure there are some bugs
here, but I'm not sure what the intended behavior is, so I'm not sure what
test-case to reproduce and what bug to file.

See attached blend for some examples. Try connecting nodes up and compare
the preview to the rendered output. Try changing the render percentage and
re-rendering.

Can someone familiar with the intent here answer some questions?

a) What is render-percentage supposed to do in the compositor? ..to
image/movie input nodes? ..scale/translate nodes? --- Seems like sane
options are to affect all inputs and scale/translate, or not affect
composite at all (aka only affect that scene's render layer's output).
Neither of these is happening right now.

b) Where are Mix and Alpha-Over nodes supposed to get their output size
from? Currently they seem to get preview size from their first input, but
their render size from the scene?. This leads to inconsistent
preview-and-render. I don't know how render-size from the scene can be
valid, since you can bring in render layers from multiple scenes with
different sizes.

c) I don't see any way to tell what size image is appearing at a
node-output. It would be nice to have some info in viewer, or perhaps an
"Viewer Info" Property panel when a viewer is the active object.

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

Re: [Bf-committers] render percentage and compositor behavior?

[David Jeske]

oops, forgot the blend...

http://www.pasteall.org/blend/22318
___
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

[David Jeske]

On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton 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.
>


> 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

[David Jeske]

On Tue, Jun 25, 2013 at 12:40 PM, Jürgen Herrmann  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

[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
20MB.
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
slowdown,
shockingly Javascript-V8 is similar. Certainly smaller than CPython vs
C's 30-50x
slowdown
.

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] render percentage and compositor behavior?

[David Jeske]

On Tue, Jun 25, 2013 at 1:36 AM, Sergey Sharybin wrote:

> As for nodes output resolution, indeed almost any node is determing it's
> resolution from a resolution of it's inputs (exception is input nodes).


Currently Mix and Alpha Over determine their preview resolution from the
first-input, but their render resolution from something else (I suspect the
render-resolution, though it could be something else). This causes the
preview not to match the rendered-output when the first input is larger
than the render resolution.

>From your reply, it sounds like the preview behavior is correct, and the
render behavior is wrong. Aka, that Mix and Alpha Over nodes should output
in the resolution of their first input. Does that sound right? If so I'll
file a simple bug/blend.

Also not sure why different scenes would be an issue -- you're not allowed
> to render them with different resolutions when using them in compositor
> setup anyway.


 That's surprising. Why is that? I expected to be able to pipe any size
scene render into the compositor and translate it into place. Such as for
titling renders in the corner without having to render the full-size frame
of mostly black. (though I obviously havn't tried 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

[David Jeske]

On Wed, Jun 26, 2013 at 4:56 AM, Campbell Barton wrote:

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

Re: [Bf-committers] 2 axis uniform

[David Jeske]

I think if this goes in, it would be nice to have a transform version of
the same concept.

sent via mobile
On Jun 26, 2013 8:25 AM, "Sean Olson"  wrote:

> I like it.  It makes it pretty obvious what it does and exposes a very
> hidden feature that I use all the time that has a pretty difficult to
> remember keybind.  (I can never remember if it's ctrl or shift and have to
> experiment every time).
>
> I think your difficult task is probably going to be to find somebody to
> actually code a patch for the widget!
>
> +1
>
> -Sean
>
>
> On Fri, Jun 21, 2013 at 12:08 AM, Neal Connolly  wrote:
>
> > Here's the UI I mocked up for the 2 axis scale tool
> > http://www.pasteall.org/pic/show.php?id=53878
> >  Let me know what you think.
> > Also it would be great if you vertical segment to the cylinder.
> > Thanks,
> > Neal Connolly
> > UI Designer
> > www.avalian.com
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> ||-- Instant Messengers --
> || ICQ at 11133295
> || AIM at shatterstar98
> ||  MSN Messenger at shatte...@hotmail.com
> ||  Yahoo Y! at the_7th_samuri
> ||--
> ___
> 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] DPI scaling question...

[David Jeske]

I'm trying to fix some Macbook Retina DPI scaling bugs, and I need some
background on the UI_DPI_FAC.

The first bug is that new compositor nodes are placed wrong on retina. I
can see where they are created and placed in scripts/startup/bl_operators.
However, I don't understand where DPI scaling is supposed to happen.

It surprises me to see code all over which deals with DPI factor like
this...

 y = (ypixels <= 39.0f * UI_DPI_FAC) ? (ypixels - 10.0f * UI_DPI_FAC) :
29.0f * UI_DPI_FAC;

I expected it to be more centralized, where the whole UI would run in a
virtualized coordinate-space automatically adjusted for DPI, and DPI
scaling would be handled in the core mouse-event delivery and drawing code.
Only a few places that care about raw pixels or should not respond to dpi
changes would need to interact with DPI.

I suspect there is a reason it wasn't done this way, but I don't know what
it is, so it's hard for me to understand where DPI scaling should be done
to fix these bugs.

Can anyone enlighten me?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch [#35889] fix UI DPI and pixelsize scaling issues

[David Jeske]

I submitted a small patch to fix some DPI and PIXELSIZE scaling issues.

http://projects.blender.org/tracker/index.php?func=detail&aid=35889&group_id=9&atid=127
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] DPI scaling question...

[David Jeske]

On Thu, Jun 27, 2013 at 12:13 AM, Campbell Barton wrote:

> On Thu, Jun 27, 2013 at 4:53 PM, Campbell Barton 
> wrote:
> > Noticed node placement bug this morning,
> > fixed r57813.
> >
> > Though IMHO using DPI to coords for node placement isn't a good idea
> > (anything besides drawing), but perhaps theres a good reason for it?
>

I don't know what you mean here. Node placement from the right click menu
is supposed to occur at the cursor, but because the position is not
properly DPI scaled, it is often created offscreen on retina.


> this patch removes DPI scaling from the node space,
> http://www.graphicall.org/ftp/ideasman42/nodes_no_dpi_r57813.diff
>
> however I can see why its done now, without it a low DPI makes nodes
> smaller and further apart. :S
>

As far as I can see, in the current model of handling DPI, the new node
placement, node size and default spacing should be DPI scaled.

...which brings us back to my original question. Why is DPI exposed to so
much blender code? If there was a virtual coordinate system and DPI/PIXEL
scaling was hidden, then none of these places would know about DPI, node
placement would be right, and node spacing would be consistent.

Is this to avoid a wrapper around the GL calls for 2d operations? Does that
overhead matter? They could be inlined.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] render percentage and compositor behavior?

[David Jeske]

On Thu, Jun 27, 2013 at 1:44 AM, Sergey Sharybin wrote:

> > From your reply, it sounds like the preview behavior is correct, and the
> > render behavior is wrong. Aka, that Mix and Alpha Over nodes should
> output
> > in the resolution of their first input. Does that sound right? If so I'll
> > file a simple bug/blend.
>
> Well, yes and no :) Just preview outputs in the actual resolution of a
> buffer in compositor. Composite output crops stuff to a render resolution.
> And this behaves as it is intended and used to behave since forever i
> guess.
>

Can we agree that the preview appearance should always match the final
appearance? This is not currently true.

Technically speaking it's possible to make render result be the same as
> composite, but that'd be a breakage of current things and here i could not
> make any decisions. Would rather leave it to Ton to make such a decisions.


I'm not sure what you mean by "make the render result match the composite". Let
me rephrase the problem.

 Currently there are many situations where composite "preview" and
composite "final" do not look the same. This is because in final, nodes
individually crop to "3d render resolution", but in preview they ignore
render-resolution and "appear" to crop to the size of their first input.
 (see my blend file)

As for how to fix this... Two options are:

(a) Change the preview behavior to match today's "fixed resolution" final
behavior. Individual node previews will appear as if they are cropped
to the current scene "render resolution", so they will appear the same as
the "final".

(b) Change the final behavior to match the "flexible resolution" preview
behavior Individual node "final renders" will be done using strictly
their input resolutions, ignoring render-resolution. "render resolution"
will only affect the size of 3d RenderLayers sent into the composite, and
(possibly) the final composite output size.

Shot term, "a" might be a good option, because it will not change final
render behavior, it'll just fix the preview to match.

Long term, I think "b" is the right choice, for several reasons.

1. As far as I can see, B is strictly more capable than A. I believe
everything users can do today in the compositor with "A" can be done with
"B". I am certain there are several things that can be done with "B" that
can *not* be done with "A". For example, today's "A" model can not handle
composite situations where any intermediate nodes have outputs larger than
the 3d render size.

2. Blender is an excellent 2d image and video compositor even if you don't
need 3d rendering, arguably the best open-source compositor! I argue it is
confusing for compositing only users to put in 2d sources, wire them
together, and then have crop behavior affected by a 3d render-resolution
settings for a 3d renderer the user is not even using. There are other UI
issues here, like "Render Percentage" and the "Post Processing" section of
the render panel, but I'll save that for a separate discussion.

3. A primarily composite user might want to add just a small amount of 3d
to a video, such as a small rendered 3d titling + logo. For speed reasons
it is beneficial to render only the small title, and translate it into
place. This can't be done "interactively" today, because

Well, [forcing all render-layers to the composite-scene-resolution] is how
> render pipeline is designed to work atm, and it completely makes sense. I
> could see how having different resolution could help in some cases, but in
> general it'll be just asking for problems. Namely it'll be just PITA to
> keep resolutions in sync in general
>

I think this could be easily accommodated by a (default set) option in the
RenderLayer node to force the render in the current scene's resolution.

VFX: for example you'll need to go over all the scenes o change render
> percentage.
> That's not something artists will expect to do.
>

Currently render-percentage and the compositor is very broken. It only
"works" if you are only compositing 3d renders. If you add any video or
image sources, the output is very very broken and requires manually
adjusted scale nodes after every image/video source.

Long term, I think "render percentage" should really be "proofing / proxy
percentage" and should "magically" downsize all rendering, compositing,
matting, video sequence editing, etc.

I also think there is a growing UI issue regarding the view-specific
Property-sidebars and the global Properties-panel. Because the Properties
Panel is dedicated to 3d operations, the different view Property-sidebars
(node-editor, movie-clip-editor) have started to effectively become "view
specific" property panels. Which is sort-of okay, except that it's not
possible for non-3d users (such as compositor or VSE only users) to use
only a part of Blender without digging into the complexity of the global 3d
Properties Panel.  I'm going to make a proposal about this, but it's a
separate discussion.
___

[Bf-committers] multi-resolution compositing and preview (was: render percentage and compositing...)

[David Jeske]

On Thu, Jun 27, 2013 at 11:17 AM, Sergey Sharybin wrote:

> > Currently render-percentage and the compositor is very broken. It only
> > "works" if you are only compositing 3d renders. If you add any video or
> > image sources, the output is very very broken and requires manually
> > adjusted scale nodes after every image/video source.
> >
>
> Percentage is another story, let's don't mix it into current question ok?


I understand and agree -- let's talk only about multi-resolution
compositing preview discrepancies for now and remove render-percentage and
scene-render-resolution. I can do the coding, if I can only understand what
is broken! :)  Perhaps later I can look at render-percentage.

When multiple resolution inputs are involved (even all images, no 3d
render), I'm seeing the following issues...

1) The composite-node preview-thumbnail does not match the F12-render output

2) No way to backdrop something that matches F12-render-output, because a
viewer sees the data uncropped by render-resolution.

3) discrepancies between the preview node-thumbnails and final-render
node-output, due to differences in cropping and centering during preview vs
final..

Here is a screenshot which I think will help this discussion...

http://www.pasteall.org/pic/54391

This shows issue #1, where none of the node-previews actually look like the
F12-render output.

Is it safe to change only the composite node thumbnail to always match the
F12-render output?

Well, kind of yes. At least in case viewer is connected to the same node as
>  Composite Output. In other cases you still could want to see original
> image.
>

I see, that is tricky. I think it's confusing for the viewer to behave
differently based on whether or not composite output is connected to the
same output. However, it is desirable to be able to have a backdrop which
matches F12-render. Here are two ideas, do you like either of them?

(a) make the composite node also a "viewer", in that you could click on it
and have the backdrop pull from it. (this backdrop should 100% match
f12-render output)

(b) give the composite node an "output", which could be hooked to a viewer
to backdrop the composite/f12-rendered output.

I prefer "a", because it seems strange to me that the composite node can't
be a backdrop, and because it seems simpler. However, either seem fine. Any
reason not to do one of these?

. on to #3... Here is a screenshot...

http://www.pasteall.org/pic/54401

In this screenshot you can see another discrepancy. The add and mix nodes
have the same inputs, but their thumbnails are not the same size or aspect
ratio. Swapping the inputs on both nodes changes their thumbnail
size/aspect-ratio but they still don't match. Is there any reason for this
to be the case?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 2 axis uniform

[David Jeske]

Let's take this discussion to the funboard or blenderartists until it's
more well formed

http://lists.blender.org/pipermail/bf-funboard/2013-June/005221.html
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] vrbuilder - valuable critique on Blender as a tool for architectural visualization

[David Jeske]

On Fri, Jun 28, 2013 at 1:08 AM, Remigiusz Fiedler  wrote:

> this is a recently started blog with in-depth critique on Blender as a
> tool for architectural visualization:
>

I suspect you are referencing this specific post...

http://vrbuilder.wordpress.com/2013/06/26/1-month-self-exam-what-did-i-learn-until-now-ii/

I think some of his "new user onboarding" points are interesting
opportunities for improvements, though I'm not so on board with his
improvement ideas. I think most of this may be better discussed somewhere
else, though I'm really surprised by one thing that seems relevant here...

Rendering Speed and GPU rendering speed...

In particular, his assumption that GPU rendering (particularly laptop GPU)
would so obviously give him faster rendering speed. I see users expect this
alot, and I'm surprised by it. For a simple test, GPU rendering on my
Macbook Pro Retina (which is a pretty beefy GPU for a laptop), is more than
2x slower than CPU rendering. Are there really laptop combos where GPU
rendering is notably faster?

Even my desktop GTX670 is only about 1.8x faster than my 2.9ghz quad i7. I
know the 6xx have worse double-precision CUDA than the 5xx cores. From what
I've read, the real CUDA performance doesn't come until the expensive
workstation class Quadro cards. Are there economical GPU choices out there
which really blow away CPU rendering? Or is this just marketing driving
user interest?

Seems possibly worth making a blender wiki page with a combined GPU --AND--
CPU Cycles rendering benchmark table. Does something like that exist? This
is all I could find, and it's comparing only GPU-to-GPU performance.

http://benchmark.cd3dtech.com/Benchmark/benchmark.html

Of course this changes once you get into Quadro cards, but those are
expensive In the infamous words of a random blenderartist user... "so
your gpu has a roughly 10x speed increase over my cpu, which isn't bad at
all, although it's also about 10x the price"
___
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

[David Jeske]

On Fri, Jun 28, 2013 at 1:35 PM, Knapp  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] DPI scaling question...

[David Jeske]

On Wed, Jun 26, 2013 at 11:53 PM, Campbell Barton wrote:

> Noticed node placement bug this morning,
> fixed r57813.
>

Unfortunately, r57813 did not fix the node-placement bug on retina, because
the retina bug is related to U.pixelsize ... (see below)

Though IMHO using DPI to coords for node placement isn't a good idea
> (anything besides drawing), but perhaps theres a good reason for it?


My instinct, like Brecht, is that DPI and pixelsize shouldn't be seen by
most of the C code, and certainly not Python... only coordinate-space
transformations, 2d drawing primitives, and a couple places that need to
care about pixels. For example, the code currently has lines like:

  BLF_size(fontid,  * U.pixelsize, U.dpi);

Which IMO should be changed to hide the DPI and PIXELSIZE inside the
abstraction:

 BLF_size(fontid, );

Today, however, this is not how the code handles DPI and PIXELSIZE scaling.
I'm guessing we should wait until Ton has the time to tell us if there is a
good reason it's done the current way before looking at this bigger
picture...

In the meantime, I did some digging and I don't think the retina
node-placement location bug is related to pixelsize mouse-transforms. I
think it's related to drawing code that does not handle pixelsize.

Some 2d viewers, including the node editor, do not seem to be handling
pixelsize in their local offset and zoom transforms. You can see this
because if you drag blender from a retina to non-retina display, these
viewers suddenly appear to be at a different zoom level (node, uv-edit,
logic,  This is fine when transforms are relative. However, when the
coordinate is absolute in the view-space, it doesn't align with the drawing
coordinates which have not been adjusted for pixelsize.

..at least this is what I think is going on. It's going to take a little
more digging to be sure. I think i'll leave this bug until I've fixed some
simpler stuff.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] DPI scaling question...

[David Jeske]

On Fri, Jun 28, 2013 at 11:36 PM, David Jeske  wrote:

> In the meantime, I did some digging and I don't think the retina
> node-placement location bug is [not] related to pixelsize mouse-transforms.
> I think it's related to drawing code that does not handle pixelsize.
>

UGH, sorry, is **not** related to pixelsize mouse-transforms..
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] x/y transposes in rna_wm.c? or not?

[David Jeske]

sorry, nub dev question.. I noticed these entires in rna_wm.c with tooltips
saying "X" positions are "vertical", and "Y" positions are "horizontal"...
Is this the tooltip mistake it seems like to me, or is there some
non-obvious reason for this?


prop = RNA_def_property(srna, "mouse_x", PROP_INT, PROP_NONE);

RNA_def_property_int_sdna(prop, NULL, "x");

RNA_def_property_clear_flag(prop, PROP_EDITABLE);

RNA_def_property_ui_text(prop, "Mouse X Position", "The window relative
vertical location of the mouse");
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch [#35910] two TINY usability fixes in the node editor

[David Jeske]

TINY (hopefully uncontroversial) patch to fix "up to parent" usability in
the node-editor (and improve a tooltip)

http://projects.blender.org/tracker/index.php?func=detail&aid=35910&group_id=9&atid=127
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] HiDPI notes for other OS'es

[David Jeske]

I think there are at least three topics worth discussing here..

(a) how should blender "appear" on a hidpi display, relative to a regular
display (either dual monitor, or when moving a blend file between machines)

(b) how should the Blender code achieve this..

(c) how is hidpi detected on different systems.



first (a)... how should blender appear on hidpi?

On Sat, Jun 29, 2013 at 5:22 AM, Ton Roosendaal  wrote:
>
> ...it will show visually the same button sizes whether you are in retina
> mode or not.
>

I think this is the right behavior. Also, when a users has blender visible
on both retina and non-retina displays, those UI should "appear" the same
size. This requires HiDPI support to use something like the per-surface
"pixelsize" instead of the the user-preference "dpi" setting... so the
current strategy makes sense in that regard. (though the user-preference
might be better named "ui-scaling", since it really isn't strictly dpi)

now (b)...how should the code achieve this?...

Today there are bugs in this hidpi/pixelsize behavior, and I believe this
is in large part because of how exposed dpi/pixelsize are to drawing/input
code. For example, node-editor and uv-editor do not "appear" the same size
on retina and non-retina at the same local-zoom, because the current zoom
is not translated for pixelsize. This seems to be the source of another
retina bug, where adding a node using the context menu causes it to appear
at the wrong place on hidpi.

Ton - Do you have any long-term opposition to the code encapsulating
pixelsize (hidpi) and dpi (aka ui scaling) issues at a lower-level -- by
introducing a virtual coordinate system for blender, much like apple has a
virtual coordinate system? This would require changes to 2d drawing code,
as well as 3d view projection setup functions.. but as a benefit would free
(most) other code from dealing with DPI / pixelsize.

I don't know enough to attempt this change now, and it may not be the right
time to do it, since it would make ui-code merges more difficult. However,
I would like to know what you think about it.

In the short-term, it may be easier to fix both the uv-editor and
node-editor to use the current pattern and properly use pixelsize / DPI to
"appear" the same on retina and non-retina.

finally (c)...how is hidpi detected on different systems, and different
monitors on the same system

On Mac, the system gives you the pixelsize for a display surface, and it
seems to "magically" deal with windows spanning multiple surfaces, by
telling you one surface DPI and automatically scaling the content for the
other display.

On Linux, there are multiple ways to achieve multi-monitor. Last time I
looked, the most common method was using a dual-headed graphics card with a
"super big" coordinate space that looks like a single big monitor. I don't
think this can support heterogeneous normal/hi-dpi. Xinerama might be able
to.

AFAIK, Windows still hasn't fully figured out their HiDPI API strategy. I
suspect a hetrogenius normal/hi-dpi setup in windows would be problematic
today...
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] HiDPI notes for other OS'es

[David Jeske]

Looking away from the details for a moment.. It would be helpful to have a
clear "Blender HiDPI philosophy", so we know the right way to fix these
bugs... I'll take a shot at this now...

If I understand your philosophy Ton, I think it is:

1) Editors where 2d pixels are not edited (everything except the
uv-editor), should "appear" to be at the same zoom-level/origin when loaded
on normal and high dpi displays. This means that a single blend file loaded
on normal and high dpi would have 3dviews and node-editors positioned and
zoomed to show roughly the same amount of stuff.

Can we agree on #1?

For image drawing... we can check on it. I just wasn't sure if you want to
> have "zoom level 1" defined as 2 pixels for image pixels... that would be
> annoying I think.


Here is a second guidline to explain this...

2) Editors where 2d pixels can be directly edited (today just the
uv-editor), should keep their data-to-screen-pixel ratio constant when
loaded on normal and high dpi display. This means a uv-editor setup zoomed
to take up most of the screen on high-dpi, would be 2-4x the screen size
when loaded on normal dpi.

My sensibilities say to drop #2 and make everything #1. However, I'm not an
artist who paints on 2d uv-maps. It would be good to hear their opinion
here.  If #2 rule stays, it would be useful to know if this applies to
scenerios where the uv-editor is used a results display, such as
render/compositor results -- or only 2d image editing.

We might also consider these possible guidelines:

optional 3) Views showing 2d pixels have an obvious way to get to 1:1
mapping, and an obvious visual that they are in 1:1 mapping.

optional 4) Views showing 2d pixels have zoom steps and/or snaps to make
integer mappins easy to arrive at.

I like #3 more than #4, though I can see arguments for each.



After we get through the philosophy, we can apply it to the details

Not an easy fix in Blender is when 2d view transforms (like nodes) are used
> together with UI widget drawing. I kept this open, knowing node UI future
> is a todo item in general.
>

I see two related bugs in the node-editor which seem easy to fix, and I
would like to fix... but I don't know the "agreed" way to fix them without
the above HiDPI Philosophy. :)

A) Node-editor shift-a node placement not aligned to mouse on Retina...

http://projects.blender.org/tracker/index.php?func=detail&aid=35920&group_id=9&atid=498

B) Node-editor content in a blend is zoomed different on retina vs
normal...  (this is a bug if we agree on HiDPI Philosophy point #1 above)

Fixing "B" should automatically fix "A". However, if B is not a bug, then
the screen-to-nodespace coordinate transform for new node creation must be
changed to adjust for pixelsize. This is in python and AFAIK python does
not have access to pixelsize currently.

Given the fact every pixel in our UI is opengl code, it's inevitable that
> there's local conversions needed for UI items in views. In general this
> goes it very nice - when code itself is nice and using opengl correctly -
> and messy in parts only when hardcoded values are used.
>

The remainder bugs for HiDPI are mainly because hardly anyone is using it
> yet :)
> Each reported issue is really an easy fix.


I agree that today the "easiest" solution to fix the node-editor bugs above
is by adding a pixelsize adjustment in the right place, and I plan to do it
myself.

It is also "easy" to manually fix other similar bugs, and teach every
future blender UI coder to properly use DPI and pixelsize in their
screen-to-editor transforms.

However, in continuing to choose the short term "easy" route, we are
creating needless complexity, where unncessary amounts of code have to deal
with DPI and pixelsize.

I don't believe there is anything "inevitable" about having all drawing
code know about DPI and pixelsize. OSX Cocoa APIs pretty successfully hide
these details from all code that doesn't care about them by using a virtual
coordinate space. AFAIK, it's an "easy but larger refactor" to abstract DPI
and pixelsize behind drawing and drawing-setup abstractions -- freeign
future programmers from having to think about it.

Rather than debating what is possible though, perhaps I can rephrase this
as a more practical question "When might be a good time to consider
such a large-but-easy refactor patch, given GSOC branch merging and other
such things?"  I'd personally like to make this patch and show how it would
work, but there is no hurry, as it's going to be a while before I
understand blender code enough anyhow.
___
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

[David Jeske]

On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal  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] About the location of the Operator panel...

[David Jeske]

On Jun 29, 2013 7:01 AM, "Ton Roosendaal"  wrote:

> If you need to patch design to make it usable, we better go back to look
> at the core design concepts itself.


While the 3 current operator UIs (menu-bar modal text, tools-opperator
panel, and F6 floating panel) are usable.. they don't seem to be part of
any core design concept. They don't even have the same visual style, so
they appear unrealted to each-other for the untrained user.

I saw one ultra-simple blenderartists proposal to merely make them visually
consistent, by simply standardizing on the F6-floating-panel color-theme
(white text on the black background) for all 3. Please forgive my super-bad
mockup... I couldn't find the better looking original mockup. I hope you
get the idea...

http://www.pasteall.org/pic/54578

A slightly larger change, which I personally like, also from blender
artists, is to combine the F6 panel and tools-operator-panel into one
thing In the lower right of 3dview. It would normally show "collapsed"
with only the current/last operator title. Clicking on it, or pressing F6,
would toggle it open, providing the full operator edit UI.

Again, I couldn't find the original mockups, so I made these really bad
ones... please forgive the bad quality...

http://www.pasteall.org/pic/54573
http://www.pasteall.org/pic/54574

In the case of trigger-buttons like Gaia's property panel button case, or
add-on UI like for cell-fracture , the
panel could open floating next to the button press and retire to the
lower-right corner after the user stopped interacting with it.

I plan to eventually generate a patch to the second one just to see how it
"feels".
___
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

[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

[Bf-committers] Community leverage, asset encapsulation (was: Blender Roadmap)

[David Jeske]

On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton wrote:

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


> +1
>

Any thoughts on how we might make this work?

Here are some brainstorm thoughts about these two "strawman" goals..

(a) let [a user] group/encapsulate/re-use/share a 10
> > node color-keying setup with an external mask-input,
> > key-color-input, and exposed "internal RGB curve editor" used for
> > foreground feather color correction;
>

A first question is... does this concept of exposing "internal node
parameter UI" for specific fields, while hiding other internal nodes,
enable an interesting set of reusable compositing node-groups? What might
specific examples be?

 "foreground object chrome key with color correction" ~ 7 nodes
 "vignetting" ~4 nodes
...?


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

This seems like it needs some way to "hide" scene parts, so the scene
becomes locked and opaque from the outside, except for a set of easy to use
parameters -- which would be shown as easy to use things in the VSE. The
scene(s) might even be hidden from the scene list unless the VSE user
pushes the "edit" button to customize their internals.

Any other community sharing ideas?

Another one on my list is a bit simpler and related to asset sharing..

(c) create metadata to "link" the purpose of assets based on compatibility,
and use that meta to make it easier to browse, pick, and load relevant
pieces for a currently active object.  For example, if I want to load
alternate textures for a "wagon" model my local or a public asset library,
it would be useful to see only textures which have been mapped to "fit" the
wagon model. Likewise for shape keys, poses, etc..
___
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

[David Jeske]

On Sun, Jun 30, 2013 at 12:17 AM, Jürgen Herrmann  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] Wayland and Blender

[David Jeske]

This seems related...

http://lists.blender.org/pipermail/soc-2013-dev/2013-June/52.html

On Thu, Jun 27, 2013 at 7:58 AM, Wander Lairson Costa <
wander.lair...@gmail.com> wrote:

> I just pushed a repository [1] with my initial work, but there is
> nothing too exciting yet, I just created the skeleton code for wayland
> in Ghost and added a new option to cmake (WITH_WAYLAND) to build
> against the wayland libraries.
>
> [1] https://github.com/walac/blender-wayland
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] browsing keyframable attributes? graph editor auto-y-scale?

[David Jeske]

In the course of working on some Blender UI improvement proposals for
non-3d related tasks, I ran into a couple opportunities and I'm wondering
if they have been brought up before.

1) Is there any UI to browse only "keyframe-able" attributes which do not
yet have keyframes?  Is it easy/practical to do this in the current code?
Any thoughts about a mode for the graph editor which does this?

Why? In video-sequence-editing, the graph-editor the graph-editor seems
like a really nice and powerful UI for working with attributes. However, it
doesn't show attributes until they are keyframed once. I think it's tough
and "non-discoverable" for these users to discover simple keyframable
attributes like "volume" and "L/R pan" sprinkled elsewhere and "keyboard-i"
to keyframe them. Especially because the attribute editor widgets are
indistinguishable from non-keyframable editor widgets until they have been
keyframed once.

2) Any thoughts or previous discussion about an auto-y-scale mode for graph
editor?

Why? As am amateur user, I feel dealing with Zoom vs Y-scale in the graph
editor is somewhat annoying. However, tweaking 3d animation takes so much
time that a bit of time messing around with graph scale doesn't seem
relevant. In the VSE however, I'd like to have a small-graph editor and
quickly tweak parameters without fighting with the Y-scale so much. It
seems like some kind of simple feature could fix this... perhaps
auto-y-scale, perhaps y-scale-lock, not sure. Any 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

[David Jeske]

On Sat, Jun 29, 2013 at 7:41 AM, Ton Roosendaal  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

[Bf-committers] expectations about spline-handle type-toggle behavior...

[David Jeske]

I'm making a patch to adjust (fix!) some odd behavior related to
spine-handle toggling, which I filed in this bug..

http://projects.blender.org/tracker/?func=detail&aid=35952&group_id=9&atid=498

The main bug I filed is that the docs (and user expectation), say that
toggling a handle to "free" should cause the two handles to become
"disconnected from each other". However, the current code doesn't do this
when only one of the spline handles is selected, because it sets that
handle to free but leaves the other one "aligned" to the free one..
effectively making the spline feel like an aligned spline where one of the
handles works and the other is "locked" (i.e. broken).

I have a patch which fixes the above problem, and makes spline-handle
type-toggling work "much more predictably" from my perspective.

Can anyone tell me how the IPO_AUTO_HORIZ / HD_AUTO_ANIM spline-handle mode
is used?

Also, if anyone is a spline expert and cares about this, read the bug as I
have a bunch of other questions.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] HiDPI notes for other OS'es

[David Jeske]

On Sun, Jun 30, 2013 at 4:14 AM, Ton Roosendaal  wrote:
>
> The node editor has been badly patched indeed, which is solvable, but not
> so easy. I postponed it to wait for decisions or designs how we want the
> node editor to evolve.


I think I now understand what you meant about combining 2d and the widgets
in the node editor being a challenge for the current coordinate model. You
mean because the nodes themselves have widgets drawn into their faces
right?

The bug you mention (for adding nodes) is just a python scripting issue -
> it tries to do DPI magic there, which it shouldn't.
>

As far as I can see, the retina node-placement bug is not caused by
Campbell's recent patch that added those DPI calculations. It existed
before he added that, and is unaffected by it. If you take out those
calculations the bug is still present and exactly the same. The bug exists
because there is a pixelsize (not DPI) compensation issue -- this is why it
happens only on retina.

If I understand what's going on the node-editor "2d camera" zoom and
origin are not being scaled for pixelsize, which means mouse events must be
scaled for pixelsize before being used as coordinates to places new nodes.

I think this could be fixed in v2d.region_to_view, as you mentioned in your
other email. I've moved onto some other stuff, but if this doesn't get
fixed in a while I'll turn back to it.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] expectations about spline-handle type-toggle behavior...

[David Jeske]

On Tue, Jul 2, 2013 at 3:41 PM, Bassam Kurdali  wrote:

> Personally I like this mode, but I could live without it I guess - for me
> it isn't a bug, I often combine vector/aligned or free/aligned. the former
> is more obviously useful, the second only marginally so ( you get one
> handle that keeps the tangent, and only slides in line, and the other
> handle is free to go (it's almost like one is parented to the

other)
>

You're exactly the user I want to talk to then! Let's see if we can find a
no-compromise solution. I apologize in advance for the long email...

I do see the utility of the vector/aligned and free/aligned behavior. The
part that seems like a "bug" to me isn't the existence of those
combinations, but the reactions of the menu-options.

If I want to grab a handle and move it without affecting the other one, my
expectation, the docs, and the menu name "free" all suggest that I should
click that handle, choose "free", and be able to drag it independently from
the other. Today, this is not the case at all. In fact, I have to select
the OTHER handle (or the center-point), and tell that one to be free, even
though I don't want to move it at all. I found this rather non-intuitive..
in fact, I didn't really understand what was happening until I read the
code.  This is what my current patch changes.

Also, when a handle is "rotation locked" (i.e. the aligned side of
align/free), IMO getting it 'unlocked' is very non-intuitive. In fact you
have to pick the OTHER handle and set it to "align", which is very
confusing. Again, I didn't understand this behavior until I read the code.

Now, let's see if we can keep all the possible spline behaviors while
making the above a bit more intuitive!

One change which is sort-of like the current align/free, align/vector
behavior is adding the ability to scale just a single handle. Currently we
can only scale both handles together by selecting the midpoint. I plan to
add this regardless because I think it'll be useful. I understand this will
not prevent accidentally moving the handle with grab.

* Do you think just the ability to explicitly "scale only one handle" is
enough to remove the need for these align/free and align/vector states?

If we would like to preserve the "parent locking" like behavior of the
current align/free and align/vector, the smallest change I can think of is
to add an additional menu option called "constrain". This would be used to
create the align/free or align/vector state. With one handle selected,
"constrain" would rotation-lock that handle by creating the align/free or
align/vector states -- while the "free" and "align" menu items would create
free/free and align/align respectively. I don't like adding the complexity
of an additional menu item, but I think this would be a *much* simpler user
model.

* Do you agree this will keep today's align/vector and align/free behavior?
Do you see how it's more direct and intuitive, because you choose a handle
and an "verb action" to take on that handle -- rather than having to select
the OTHER handle?

One wrinkle of causing "constrain" to work within the current handle-states
is that constraining both handles will not act as expected. In this case I
would expect both handles to be frozen (something you can't achieve today),
but in fact they will both be draggable as in align/align today.  This can
be fixed by also introducing an additional "constrained" state for each
handle.. this state is like align, except that align/align is movable,
while constrain/constrain is completely locked.

* Do you think it's worth-while to add the ability to lock both handles
with constrain/constrain? Would you use this?

If it is valuable to keep the constrain/free, constrain/vector, and
possibly constrain/constrain states.. I think it would be worth making this
a little clearer with some super-minimal visuals. My thought is to make the
constrained handle look like a small "T" instead of a dot. This would help
visually indicate that you can linearly drag but not rotate it.

* Do you think this visual would be helpful? Too busy?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] expectations about spline-handle type-toggle behavior...

[David Jeske]

...and one more quick question...

Do spline users miss the inability to do a standard "mirrored" spline,
where both sides of the spline keep the same length? I don't see a way to
get this behavior out of Blender's spline handles (though I could just be
missing something).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Regarding the current usage of proportional edit

[David Jeske]

Here is a semi-dev related followup...

I figured it should be possible to cause a keypress to bring up the
context-menu to select a specific proportional editing mode. I tried to
replace the "shift-o" keybinding
to wm.context_cycle_enum(tool_settings.proportional_edit_falloff) to a
direct reference to tool_settings.proportional_edit_falloff (which is what
it says in the tooltip for that popup menu). I expected it to make a
context-menu when I hit the key, but it didn't work. I also tried
ToolSettings.proportional_edit_falloff.

It looks like it's resolving something in the keybind panel.. Why doesn't
this work?

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

Re: [Bf-committers] Regarding the current usage of proportional edit

[David Jeske]

> import bpy
> km = bpy.context.window_manager.keyconfigs.default.keymaps["3D View"]
> kmi = km.keymap_items.new("wm.context_cycle_enum", 'O', 'PRESS',
oskey=True)
> kmi.properties.data_path = "tool_settings.proportional_edit_falloff"

When I do this, I get the same behavior as the current. It cycles through
the options. I want it to pop-up the menu of all the proportional editing
options, like it does for "delete" when a vertex is selected in edit mode.
Did I do something wrong?

> It doesn't work because the rna path is used as an operator name.

I admit I don't understand enough about RNA, Python, and keymaps to know
what this means.

 As a "naive user" in this situation, I would really like it if I could
hover-over a control, look at the RNA/Python path, and type that directly
into a keymap to trigger the menu. I don't understand why I can't do this.
Heck, I'd like to be able to "right click" on the control and choose "make
shortcut" and get a nice panel to set it up. Any advice on how I make that
work?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] tooltips on python created operators?

[David Jeske]

Any particular reason there isn't an argument for adding custom tooltip
text when adding operators via Python with  ?

UILayout.operator(operator, text="", text_ctxt="", translate=True,
icon='NONE', emboss=True)

I want to add tooltips to lines that look like this:

 row.operator("curve.handle_type_set", text="Auto").type = 'AUTOMATIC'
 row.operator("curve.handle_type_set", text="Vector").type = 'VECTOR'
 row = col.row()
 row.operator("curve.handle_type_set", text="Align").type = 'ALIGNED'

Obviously the generic "handle_type_set" operator tooltip isn't
appropriate.. because these have parameters.

Unless you have some objection, I'd like to add an optional paramater
"tooltip", which allows the definition of a custom tooltip for this item...
and punch it up into C land into the tooltip. Any objection?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch [#36029] improvements to spline behavior with a SINGLE handle selected

[David Jeske]

After hashing it out with a few artists/users who LOVE the current spline
handle behavior, I think I have a patch which will make single spline
handle-set more predictable/understandable, while retaining 110% of current
functionality. (not a joke, I added functionality by fixing bugs)

http://projects.blender.org/tracker/index.php?func=detail&aid=36029&group_id=9&atid=127

Summary:

This patch improves the usability of the spline handle set menu behavior
when a SINGLE spline handle is selected. It does not change the behavior of
spline handle modes or how splines are interpreted.

It also...

- adds a visualization for a rotation-constrained spline handle, and fixes
a couple bugs in working with single spline handles.

- allows any single spline handle to be scaled along the spline axis with
no fear of rotating the spline (no matter what mode the spline is in).
Previously this was only possible for both handles together.

See the bug for the nitty gritty details...
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

This patch alters the window-editor-type-selection menu to a new 4-column
layout, based on the multi-column Modifier selection design.

The new design:
- keeps the "primary" editors very close to the menu-button in both
orientations
- makes it SUBSTANTIALLY easier to find and remember the locations of other
editor types in the menu
- provides an ordered grouping of editor-types, with a meaning that can
help new users understand the software

http://www.pasteall.org/pic/show.php?id=54986

http://projects.blender.org/tracker/index.php?func=detail&aid=36028&group_id=9&atid=127
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Regarding the current usage of proportional edit

[David Jeske]

On Fri, Jul 5, 2013 at 7:54 PM, Campbell Barton wrote:

> Ah, I misunderstood, in that case use "wm.context_menu_enum"
>

I see. That makes sense now that I see it, but I'm not sure how any
reasonable user or casual dev would be able to figure that out. Which
brings me back to


> >  As a "naive user" in this situation, I would really like it if I could
> > hover-over a control, look at the RNA/Python path, and type that directly
> > into a keymap to trigger the menu. I don't understand why I can't do
> this.
> > Heck, I'd like to be able to "right click" on the control and choose
> "make
> > shortcut" and get a nice panel to set it up. Any advice on how I make
> that
> > work?
>
> At the moment you can't do that but of course it could be made to work.
>

I've added it to my TODO list after some other stuff.. If you have any
pointers on good ways to do it, they are appreciated. Otherwise I'll figure
it out.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Regarding the current usage of proportional edit

[David Jeske]

I'm confused about your repeated mention of the o toggle.

On my stock 2.67b build.. O toggles proportional edit on and off already.

You should be able to use Campbell's script to setup a hotkey to pop-up a
menu with the list of proportional editing modes to select from. I admit
that doing this is super confusing, and I have it on my list to fix that.

As far as I can see, these are both of your suggestions and you can do them
today.

If I'm missing something, feel free to reply privately and you can clarify.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

Of course there are many possible groupings, headings and orderings. You
can see some of the others I considered here..

http://lists.blender.org/pipermail/bf-funboard/2013-July/005283.html

Did you read the grouping definitions on the tracker entry? ...

+ /* Workspaces - author new data directly */
+ /* Tools - alternate editing views on the data being created in
workspaces */
+ /* Asset Management (Tools) - browse, manage, load, mix, and process
assets for use in workspaces */
+ /* Scripting - Script 3d objects, the UI, and the BGE. */

By these definitions

Movie clip editor/tracker does not author new data. It extracts it from an
asset.

NLA editor is not an alternate view and editor of data being edited in 3d
view. It "packages" animation data into an asset, removing it from the 3d
view, and allows mixing and composing those assets.

-- --

Which is not to say the definitions are "correct" or the only definitions.
However, to discuss alternate groupings, it would be nice to have alternate
definitions which make sense.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

The current editor-type menu flipping is a byproduct of Blender trying to
solve a tricky problem in UI design, which is allowing header-menu-bars to
live on the top or the bottom. I think Blender's flipping menus work
acceptably for text-header-menus, because a particular menu type is
accessed from only one direction. (aka, the user probably buts all 3dview
headers on the bottom of 3dviews).

However, the window-editor-type-menu is often and repeatedly used from both
orientations. This flipping ruins consistency. It not only makes it harder
for new users to recognize it as the same thing (because it's upside-down),
but it hurts experienced users by ruining their ability to build muscle
memory for the menu.

The multi-column layout is objectively a better solution to the two
competing goals. Items can be kept in a consistent position, making the
menu easier to recognize, learn, and use. Frequently used operations can be
kept close to the start-point by keeping the menu vertically short, making
those operations fast to reach from either orientation. It is simply a
better solution to the problem.

it is dramatically easier to remember where things are in *larger* modifier
and constraint menus, because they have a non-flipping multi-column layout.

--

Which brings us back to "preferences" 

There is no question there are many possible groupings, headers, and
motivations for those groupings. In fact, if the small amount of feedback
I've seen so far is any indication, 50 blender users designed multi-column
layouts, we would probably see 50 different solutions. I'd like to respond
to this with three main points.

1) *ANY* non-flipping multi-column layout is better than the current
solution as long as it keeps commonly used items close to the start-point.
Objectively, -mathematically- it achieves the two optimization goals
better. It works better for UI design. It works better for humans trying to
find things. It's just better.

2) Because different users have different preferences about where things
should be in this menu, user-preferences don't help us converge on a single
layout. My model for resolving this "abundance of preferences" is to try to
use a mix of utility and logical structure.

@Brecht - The proposed "WTAS" grouping does have logic behind it, but I'm
not at all saying it's the best. The main goal was trying to determine
which views in blender could be "standalone programs in their own right"
and put those into the workspaces section...Blender is useful for a heck of
alot more than the 3dview, but that functionality is dizzyingly hard to
find because those "top level program views" are mixed among views like
"properties" and "graph editor".

I'd love to hear some more detailed feedback about grouping structure and
headings, either here, or on the bf-funboard thread...

Here is an easier-to-view review of the better groupings I've tried so far..

   http://dj1.willowmail.com/~jeske/Projects/Blender/ETS.html
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

>
> Maybe something like this, with 2 columns:
> http://www.pasteall.org/43817
>
> Not saying this is ideal, but I think trying to fit everything in
> columns with a single title per column constraints things too much.
>

I think any of these non-flipping layouts would be a big improvement. The
reason I'm going wider is to keep the common views within mouse-reach when
menu opens "up". Below is a reachability comparison.  I think the
difference in everyday usability would be significant. (Keeping 3d-view
close is one of the justifications I hear for today's "flipping" menus)

http://www.pasteall.org/pic/show.php?id=55034

As for the headers, we could just drop them. They are not a very important
part of layout waypointing, memory, or everyday usability. They are mostly
for new-users to get some idea what the categories are. However, if there
isn't enough ontological correctness they confuse more than help.

What do you/folks think about this 3 column layout? .. with no headers

http://www.pasteall.org/pic/show.php?id=55036

It's the same as your ordering, except I put Node-Editor with the "main"
stuff on the left because I think the compositor is as good a "main view /
start-point" as the other things over there. (ignore the kind of nasty
extra space below "Editor Type".. it's a byproduct of the current menu code
and could be fixed)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] RNA-gen question...

[David Jeske]

When doing grep/searches tracing things from python-to-C, I sometimes have
a lucky keyword that matches something in the rna-gen "extern prototypes"
 which are repeated in every rna__gen file. They look like this...

extern StructRNA RNA_BlendTexture;

Is there a reason these are generated into every rna-gen-c file, rather
than being generated into an "rna_prorotypes_gen.h" that can be included by
every rna-gen-c file?

For example, like this...

http://www.pasteall.org/43828

Is there some reason that's bad or not done?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36029] improvements to spline behavior with a SINGLE handle selected

[David Jeske]

FYI - After much deliberation about feedback on BA, I've decided to take a
different route than I did with Patch [#36029]. I am going to create a NEW
version of this spline-fix-patch which fixes the tooltips, bugs, and adds
"rotation constraint" visuals -- while leaving the current behavior
untouched -- where handle-set always affects only selected handles. I will
also fix the wiki documentation to match the current behavior.

Why?

I created this patch because I want the documentation, tooltips, behavior,
and visuals to all match -- it doesn't matter to me which way it works, so
long as it's clear. When I started, the only thing that I understood was
the documentation, partially because the current behavior is not documented
and partially because bugs in the visuals make it confusing. Now that I
fully understand the (intended) current behavior, I see a way to fix the
tooltips, docs, and visuals which will be (mostly) consistent with the
current behavior.

Some factors in my thinking:

- While using patch [#36029], I have seen that 90% of the confusion with
the current system can be eliminated simply by showing visuals for
"rotation constrained" handles.

- I can see the desire for handle-set behavior which only "touches" the
state of the handle(s) which are actually selected.

But mostly:

I've realized that the "behavior inconsistency" is not possible to
eliminate with *either* approach without breaking file-format compatibility
-- something which I don't think is worth it at this point. That
inconsistency is the overloading of "align" and "constraint" behavior, such
that an align handle in align/free is rotation constrained, but in
align/align is not rotation constrained. The overloading also has the
side-effect that there is no way to rotation-constrain both handles. Other
features which have been requested are also not possible without some
amount of file-format conversion/confusion.. including rotation
constraining both handles, and length-mirroring both handles.

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

[Bf-committers] int vs enum use?

[David Jeske]

Is there any particular reason (besides legacy) that many parts of the code
still use int/#define, instead of using enums?

Even though C-compilers don't typecheck enums, there is a documentation /
readability benefit to using enums. Using enum-forward declaration avoids
any header nastiness.

For example ...

void BKE_nurbList_handles_set(struct ListBase *editnurb, int mode);

void BKE_nurbList_handles_set(struct ListBase *editnurb, enum
eHandleSetModes mode);

The latter is much easier to understand and investigate.

I'd personally like to make patches which simply add the proper enum types
to help document things for myself and others. Any reason not to do this?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36029] improvements to spline behavior with a SINGLE handle selected

[David Jeske]

I have uploaded the ALTERNATE patch ...

I *strongly* urge people to try both patches. Using it makes the difference
more apparent than thinking/talking about it. Set a handle-pair to "align",
then choose one handle to "free" and see the behavior difference
(summarized below).

BOTH patches fix issues working with single-spline handles:
- add tooltips to the handle-type-set menu
- fix a visual bug where selected spline handles are highlighted incorrectly
- add a (subtle) visual for a rotation-constrained spline handle
- introduce a safer eHandleSetMode enum (necessary to make the tooltips
work)

BOTH patches have exactly the same possible spline handle behaviors for the
same handle states.

The DIFFERENCES between the patches can be understood somewhat by
considering the tooltips and options in the handle-type-set menu...

Patch [#36029] - match docs, fix behavior   (IMO, much more intuitive)

http://projects.blender.org/tracker/?func=detail&aid=36029&group_id=9&atid=127

"Free" - allows the handle to rotate independently from the other handle.

"Align" - aligns the handle with the other handle

"Align + Constrain" - aligns the handle with the other hand and constrains
it's rotation


Patch  [#36048] - keep behavior, fix docs

http://projects.blender.org/tracker/?func=detail&aid=36048&group_id=9&atid=127

"Free" - Align the handle(s) to the other. If the other handle is Free,
Vector, or Auto, this will cause the handle to be rotation constrained.

"Align" - Allow the handle(s) to freely rotate. To allow the handle to
rotate independently, set the other handle to Free, Vector, or Auto.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] int vs enum use?

[David Jeske]

On Sun, Jul 7, 2013 at 3:53 PM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> One reason is that you can't do forward declarations of enums in
> header files [in ISO C] like you can do with structs.


I see my confusion. gcc has a non-standard extension to support forward
declarations of enums, so it worked fine for me. However, it's not ISO
standard, and as far as I can see MSVC doesn't support it.

http://stackoverflow.com/questions/7480217/c-forward-declaration-of-enums
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

I think the visual dividers are a big help, and agree with Michael they
could be a bit dimmer.

I'll patch this and see if the dividers are enough (subjectively) to get
over the flip-flopping confusion.


On Sun, Jul 7, 2013 at 9:17 PM, Harley Acheson wrote:

> Short of a big overhall, there are also simple things we can do.
>
> The following shows the current menu on the left. On the right there
> has been some margin added to the left of the icons so they are not
> scrunched against the left. The separators are made a lot less invisible,
> and are not extended to the edges.
>
> http://www.pasteall.org/pic/show.php?id=55110
> ___
> 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] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

@Sean - The test program you describe would tell us about new-user
usability, but would not tell us about expert usability. While I would
value these results, I suspect they would not be very convincing to
existing users. Expert/everyday data can be gathered by putting
usage-tracking/timing directly into the application. Then we can visualize
frequency/timing of use over any users submitting usage data. This might be
worth doing, as it's generally just small hooks inside some core menu code.
However, to learn much about comparative designs, you then need to do A/B
testing, where different users get different UIs (randomly or selectively).
Our userbase is a bit small for this, and I think basic automatic
crash/usage reporting would be a better/simpler first step.

@Gaia - My concern is not only for myself, but for general "default ui"
usability. Adding customization does not change usability for most users. I
also think other areas of the UI are more ripe for customization, such as
the header-bar controls, particularly the info-header.

@ any unconvinced - I highly recommend you *try* the proposed 3/4 column
menus for a couple days before you draw a conclusion about which you would
prefer. It's quite alarming how much easier it is to find things (even for
expert users) once entries stop moving around.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: Panel Show Triangle

[David Jeske]

On Tue, Jul 9, 2013 at 9:02 PM, koil .  wrote:

> People do argue that a indicator is required, to show if the panel is open
> or not.
> That is why the patch has the option to show the triangle, and by default
> it is set to show.
> So adding this patch, wouldnt change anything to the default appearance of
> blender.
> This patch adds the option, in user preferences theme, to not show the
> triangle, if desired.
>

Seems like we could try to spend some time trying to come up with a style
which is less cluttered (aka removes the triangle) but also provides clear
feedback on whether the panel is open or not -- and avoid an unnecessary
user-setting. Let's chat about it on bf-funboard.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: Panel Show Triangle

[David Jeske]

On Wednesday, July 10, 2013, Sean Olson wrote:

> I see user settings and theme options as completely different.  Less user
> settings is a good thing - sane defaults are awesome.   More theme options
> is also a good thing - themes are for those wanting to customize to their
> hearts content.  Having more control over this customization is not a bad
> thing.


I like this reasoning in general.

However, there are many more issues with the property-panel visuals than
just the triangles, including the out-of-alignment section-checkboxes, the
busy diagonal drag-handles, and unclear panel disable indication.

Rather than one-offing just one of these issues, it's worth the effort to
make a clean and consistent refinement proposal which fixes them all. If
the triangles are still an issue, we can think about a theme setting, if
not, we don't need it.

Harley and I are working on property-panel visual refinement proposal based
on some of his previous mockups. We expect to post something to bf-funboard
soon. If folks like it, we can leapfrog. If not, perhaps something like
this stopgap triangle disable may make sense.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: Panel Show Triangle

[David Jeske]

On Jul 11, 2013 12:14 PM, "koil ."  wrote:
> So far i see no reason why this patch should not be committed.
> This patch is progress towards the UI designs on the thread.

You make a fine point..

Would you consider updating your patch to align the header titles when the
triangles are removed?

The lack of header alignment is the bigger issue there.. It is hard to fix
well with the triangles in place but easy once they are removed. Harley can
send you a mock if its needed.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: Panel Show Triangle

[David Jeske]

On Jul 12, 2013 11:50 AM, "koil ."  wrote:
> I guess they would look something like these.
> http://www.pasteall.org/pic/show.php?id=55461

Only panels 2 and 3... There is no need for an additional toggle...  align
titles anytime triangles are hidden.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Embedded Bfont violates GPL

[David Jeske]

I agree with TomM on points one and two.

IANAL, but IMO the GPL "further requirements" is to *prevent* burdens being
added on the code and distribution. Anti-naming is not a requirement on
distributed code but an overly explicit statement of Trademark law (and
community convention). Whether we write it or not, there is a legal
requirement that Linux not be called "Microsoft Windows". If we wrote that
into the license, it would merely seem nonsensical, not a violation of the
GPL. It also shall not be named "Mickey Mouse" or "Apple Computer".

The third clause, however, looks like a clear violation of the GPL.. for
the GPL will not allow this restriction to the font-code.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Embedded Bfont violates GPL

[David Jeske]

Looking through the GNU GPL Info, the situation with fonts is quite murky,
partially because the copyright of fonts is quite murky.

http://www.gnu.org/licenses/license-list.html#Fonts

"The Open Font License (including its original release, version 1.0) is a
free copyleft license for fonts. Its only unusual requirement is that fonts
be distributed with some computer program, rather than alone. Since a
simple Hello World program will satisfy the requirement, it is harmless.
Neither we nor SIL recommend the use of this license for anything other
than fonts."

..which sounds somewhat like they think it's a harmless clause for fonts as
it relates to the GPL. That isn't quite the same as saying it's okay to
include them, but it certainly doesn't seem clear there is a problem with
including such fonts.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Import Mesh with VertexColor?

[David Jeske]

it looks like this is a known limitation/bug in the current code.. this bug
was filed-and-closed with a note that it's not implemented.

https://projects.blender.org/tracker/?func=detail&atid=498&aid=35090&group_id=9
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Embedded Bfont violates GPL

[David Jeske]

On Wed, Jul 17, 2013 at 11:20 PM, IRIE Shinsuke wrote:

> Apache 1.1 license is incompatible with the GPL for the similar
> restrictions (The derivative works are prohibited from using "Apache"
> names without prior written permission).
>
> http://directory.fsf.org/wiki/License:Apache1.1


FWIW, GPLv3 seems to specifically allow renaming clauses under section
7.(c,e)

7.Additional Terms.
...
Notwithstanding any other provision of this License, for material you add
to a covered work, you may (if authorized by the copyright holders of that
material) supplement the terms of this License with terms:
...
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be *marked in reasonable
ways as different from the original version*; or

e) *Declining to grant rights* under trademark law for use of some *trade
names, trademarks, or service marks*; or
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] sculpt mode wireframe display issue and question

[David Jeske]

I'm trying to fix a bug in sculpt mode display and could use some input...

User problem...

With edges enabled but draw-all-edges disabled, edges between coplanar
faces are hidden. In sculpt-mode, as the user-sculpts (no dyntopo), the
co-planar status of edges is not re-evaluated. This means that as edges
which started hidden remain hidden even as the sculpt brush causes them to
no-longer be coplanar. --- This is pretty undesirable, because the user
can't see their work without flipping to edit mode and back.

Obviously the user can turn on draw-all-edges.

If that's the only way sculpt mode visuals work, it probably makes sense to
just force draw-all-edges during static sculpt -- like is already done in
weight-paint, and dyntopo sculpt.

If that's a good enough fix, I'll make a patch, and you can all skip the
rest of this email.

If not, read on, as I could use some advice..

Why it happens and possible fixes...

Sculpt mode (no-dyntopo) draws object wireframes with the same rules as
object-mode. This means if wireframe is enabled, but draw-all-edges is not,
it uses the ME_EDGEDRAW status to show/hide each edge. This (basically)
means that coplanar edges are hidden (see bmesh_quick_edgedraw_flag).
However, as far as I can see ME_EDGEDRAW is only setup during bulk-convert
of a BMesh into a Mesh for display.

In theory, I think the "best" solution would be to recalc the ME_EDGEDRAW
flag status only for edges of vertices which are moved by a static sculpt
brush. However, if I'm reading the code correctly, there isn't (currently)
any quick way to correlate the BMEdge edge structure with the MEdge entry
that contains the flag... -- am I reading that right?

If I got that right, some paths to fix this might be...

1) have static-sculpt build a BMEdge to MEdge hashmap so it can efficiently
update edge-draw flags for moved edges and their neighbors (more memory
usage, but should be very little performance hit during sculpt)

2) force recalc of the MEdge list when co-planar edges are moved. (only
costs something when coplanar edges are moved, but that cost is
proportional to mesh size so it could be large)

3) ... and of course, as I mentioned above -- force draw-all-edges during
sculpting (more draw cost to draw all edges, depending on model)

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

Re: [Bf-committers] sculpt mode wireframe display issue and question

[David Jeske]

@Sergey - Another way to consider the question is -- does anyone thinks
it's worth the effort to properly fix hiding-of-coplanar edges in
non-dynamic sculpt mode? or is the simpler solution, forcing all edges to
display like dyntopo, sufficient?   It sounds like you think forcing all
edges to display is the right choice. It would be great if you could ask
other artists if they agree.

@Ronan - I see. Did explicit wire-control work much better than the current
"optimal display"? (which as far as I can tell means "draw only base-mesh
edges") I'll take a peek and see where that feature went.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch [#36296] object->display-properties subpanel layout cleanup

[David Jeske]

https://projects.blender.org/tracker/index.php?func=detail&aid=36296&group_id=9&atid=127

This patch is a small cleanup to the layout of the
object->display-properties subpanel.

The main result is visible in this comparison display.. though note that
the wording "Maximum draw type:" was used instead of "Limit draw to:" in
order to match the name of that menu-widget and the tooltip.

http://www.pasteall.org/pic/show.php?id=56188

See path for more details.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] sculpt mode wireframe display issue and question

[David Jeske]

... another small related question.

Is it desirable that sculpt mode uses full selection color wireframes,
rather than using something more subtle like the weight paint wireframes?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] sculpt mode wireframe display issue and question

[David Jeske]

>
> In 2.49, multiresolution was not a modifier. The feature was lost while
> 2.5 interface changes when multi-resolution became a modifier.


I see. Just glancing at it, it looks like "optimal display" marks edges for
display which correspond to level-0 edges. I don't see why the same
technique couldn't work to revive the "edges:#" feature from 2.49, but I'll
have to dig a little deeper to see if I'm understanding this correctly.


> Yes , it is desirable to have it little more subtile but not too much.
> It should still show wireframe more obvious than just a flat shading.
>

My proposal is to use the same alpha-white lines as weight paint mode
You can see the difference here..

   http://www.pasteall.org/pic/show.php?id=56387

I think it's more subtle, and shows up clearly in more situations. It
becomes invisible with a pure-white object, just as the current orange
selection color becomes invisible with a selection-color object.

If this is preferred, I think the right thing to do is make this an
additional theme-color (sculpt-mode-wireframe). Weight paint doesn't theme
this white-alpha color, but it knows what color the weight paint surfaces
will be underneath.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] sculpt mode wireframe display issue and question

[David Jeske]

On Sun, Jul 28, 2013 at 2:31 PM, Sergey Sharybin wrote:

> Talked to artists and the way to go here is to draw all edges in sculpt
> mode (both dynamic and non-dynamic topology).Meaning you'll just need to
> change a way how non-dynamic topology edges are displaying in sculpt mode.
>
> - Would rather have patch which draws all edges in sculpt mode commited
> separately.

- Making more global changes could harm ongoing viewport draw changes GSoC
> project.
> - Need to use feedback from module-owner-artists. Making UI change decision
> relying on feedback only from this ML could easily lead to not so much
> correct decisions.
>

Thanks. Sounds good...

The module owners page lists says Sculpting is Nicholas Bishop, Brecht Van
Lommel, Sergey Sharybin

Any input from any of you on switching wireframe display in sculpt mode to
always draw all edges, to resolve the bug described earlier in this thread?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Avoiding regressions, changes to the release cycle.

[David Jeske]

On Mon, Jul 29, 2013 at 7:26 AM, Brecht Van Lommel <
brechtvanlom...@pandora.be> wrote:

> I don't think we need to freeze trunk for that however, we could just tag
> the
> new release and open up trunk for development again. Then any critical
> fixes found can be ported to the tag which would be released after
> e.g. 2 weeks or longer even.
>

+1

This is a very typical way I see releases stabilized. I'm only just exposed
to the details recently, but it seems like the pressure to push the RC too
fast happens specifically because trunk is frozen. If you branch the RC,
then trunk won't be frozen, the RC can be tested in due-time, and necessary
fixes applied with care.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch [#36029] improvements to spline behavior with a SINGLE handle selected

[David Jeske]

ping... now that 2.68 is out can I get some feedback on this?

I made two alternative patches here. They both fix the same set of bugs in
spline-handles..

- add tooltips to the handle-type-set menu (yay!)

- fix a visual bug where selected spline handles are highlighted incorrectly

- allow (S)cale to alter the length of a single handle without changing
it's rotation, just like double-handle scale does for two handles.

They both also add a small visual. I know this visual isn't perfect, though
it seems not terribly offensive, and it visually clarifies behavior which
is currently invisible. Open to suggestions about better visuals.

 http://www.pasteall.org/pic/54987

The above changes are included in this patch, and I think they are rather
conservative..

http://projects.blender.org/tracker/?func=detail&aid=36048&group_id=9&atid=127



-

I also made another patch which includes all of the above, but goes a bit
further. It makes a change to spline-handle set which makes it's behavior
match the documentation, the English definition of the word "free", and IMO
makes it more intuitive. However, the small amount of user feedback I've
been able to collect about this has been mixed, with some users preferring
it and some users preferring the current behavior.

I understand if this change is less preferred..

http://projects.blender.org/tracker/?func=detail&aid=36029&group_id=9&atid=127
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Avoiding regressions, changes to the release cycle.

[David Jeske]

On Tue, Jul 30, 2013 at 7:43 AM, Ton Roosendaal  wrote:

> That's why we added the 'BCon' cycle, where the last 2 cycles were meant
> for everyone to stop coding new stuff for 3+ weeks, and focus on
> stabilizing and fixing and testing of trunk (and *not* work on branches).
>

... or you could consider using the scheme most commercial projects use..
which is to freeze a tag/branch, build a binary, make the binary widely
available for whoever does testing as a binary. When regressions are
discovered, their fixes are committed to trunk, and before RC2
release-master cherry-picks those bugfixes into the release branch and
makes a new RC2. This iterates until the RC## stops getting show-stop
reports, then it hits release.

RC1 *binary* after being tested with devs, could be put on the website for
a week or two, letting entheusiasts test and report bugs so the next "real"
release doesn't have them.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] BGE: Removing Singletexture Mode

[David Jeske]

why not have the legacy rasterizer use the transitional GLSL 1.2 instead of
multitexture? is there userbase out there with pre opengl 2 / glsl 1.2
hardware?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [59791] trunk/blender/source/blender/ editors/space_view3d/view3d_fly.c: tweaks to fly mode

[David Jeske]

i for one would be happy with a fly mode that was not a game engine, had no
movement over surfaces, but was free of the momentum driven movement. i
just want it to. more easily reposition cameras.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Generating icons overwriting files in SVN.

[David Jeske]

sounds like this is fixed for now..

in the future, another possibility is to slightly extend the svg to png
generation to bit compare the png pixels, and if they are the same, just
touch the old instead of overwriting the new.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] cycles GPLed or BSD?

[David Jeske]

On Fri, Apr 29, 2011 at 10:11 AM, Ton Roosendaal  wrote:

> Had meeting with Brecht on this today; the API is currently rna-via-c+
> +, similar to python api but much faster. How to make such an API
> "BSD" or define license exceptions for it, I honestly don't know yet.
> A working bypass is to just code it via pipe() though, basically only
> data has to be passed on anyway.
>

The widespread interrpetation is that it's not legal to link GPL code into
the same address space as non-GPL (propritary) code. If allowing non-GPL
projects to use the renderer is important, one common way to solve this is
to put the entire codebase under the LGPL. The LGPL is basically like the
GPL for the library itself, but it allows linking an embedding that library
into other codebases without requiring those codebases be GPL.

It's also fine to leave it GPL, but like other GPL code, it will not be
something commercial software can link into the address space. It will
require a network/filesystem interface API so as to talk to it without being
in the same address space.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updated BMesh Merge Proposal

[David Jeske]

Getting my 2 cents in on an old thread...

On Dec 2, 2011 3:29 PM, "Campbell Barton"  wrote:
> There are many options here, I was going to list all the ones I could
> think of but most have some fairly annoying drawbacks.

You missed one of the best ones imo...

New '2.6' is made 3.0 beta, including a new .blend3 file extension which
has a different file association and header so old blender versions
wouldn't even try to load it. Users can manually export legacy .blend files
from 2.6 (3.0) with various caveats.

Writing files which people will think should work but will just crash old
blender seems like a 'colosally bad idea'. It will only further cement
blender's status as an unreliable amateur hobbiest tool. Blender should
never crash.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender App Central / Add-on Manager

[David Jeske]

On Jan 10, 2012 8:18 AM, "Yousef Hurfoush"  wrote:
> i think the problem isn't in the wiki or bf-extensions or a new app center
> it relies on the scripters theme selfs to submit to these repositories,
> maybe finding some one to do the missing job as a solution would be good?

Centralized repositories that allow easy seach/install tend to motivate
devs (scripters) to publish. Google chrome extension publishing is probably
a good demonstration for a more 'scripter friendly' appstore. Chrome itself
contains the tools necessary to wrap up and package an addon, making it
easy for scripters. Addons remain self contained custom-extension zip
archives even when installed, making management easier.

HOWEVER, keep in mind that centralizing an addon 'appstore', especially one
that is accessible directly within a product like blender.. creates an
increased security responsibility. Blender addons are python, and thus they
can do anything to your computer when run. Existance in a centralized
appstore tends to imply trust that is not deserved. If submissions are
open, malacious addons can be registered. Android/chrome have security
models trapping addons into sandboxes to attempt to control this potential
vulnerability. (I.e. a google chrome addon is not allowed access arbitrary
files on your computer)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender UI state

[David Jeske]

I'm glad to see this UI discussion getting organized on the wiki.

I'd like to add that I think with respect to UI changes, a picture says
ten-thousand words. Creating a wiki page which clearly documents the
current state, the motivation for a change, and a visual change proposal is
a really good way to get buy-in and something implemented. Often the
implemention of UI changes is actually much simpler than the actual buy-in
or approval process. I'd really like to see Blender Foundation get more
actively involved in structuring and "approving" UI change proposals to
streamline this more.

Here is an example of a visual change proposal (really a bug fix), I made a
while back related to outliner selected/active highlighting. Visually
illustrating the problem clearly made it easy to get agreement and get it
quickly fixed. Putting a little effort into this kind of organized set of
micro-screenshots can really help streamline the UI proposal/change process.

http://wiki.blender.org/index.php/User:Jeske/Active_Selected_Visuals_Cleanup_Proposal_Completed

http://wiki.blender.org/index.php/User:Jeske/Active_Selected_Visual_Cleanup_Proposal





On Mon, Jan 23, 2012 at 10:26 AM, Jorge Rodriguez
wrote:

> Thanks to those who have provided feedback so far. Please sign your posts
> on the discussion page or it will quickly become illegible. I hope to see
> more discussion about the new user experience.
>

http://wiki.blender.org/index.php/User:Vino/New_User_Experience
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

I understand I'm following up on a discussion from last month. I think it's
an important one. There were many good points raised about the license
requirements for extensions. I hope these additional thoughts are a well
received.

I think it will benefit the Blender community if commercial companies can
use Blender as a replacement for commercial tools. In order to do this, it's
often necessary for them to link propritary code in as extension modules,
and make use of them deeply in their rendering and/or asset management
process. This discussion brought up the point that it's "probably fine" to
write propritary extension modules, especially if it's done in the privacy
of a company. However, please understand the conservative environment of
corporations. All corporate council I'm aware of will advise against
linking proprietary code to GPL code as a potential GPL violation. This will
make it an un-viable corporate risk. Or put differently, the legal safety of
commercial alternatives is simply worth too much. Which means they will use
commercial tools instead of blender. Which is a lost opportunity for the
adoption of excellent users that would help advance blender.  "truly free"
open source tools like Python are more accepted in corporate environments
for this specific reason.

I think it will benefit Blender's adoption substantially if the Blender code
licensing is structured in a way to make it very safe and indisputable that
it's okay to build closed-source extensions with proprietary code.   I
understand it may be important to draw this line carefully. In my opinion it
will be worth the effort.

I don't know the blender community or blender foundation position on
for-sale binary extension modules for Blender, and I understand this may be
a tricky issue. However, regardless of the stance on this, I think it will
be of great benefit if companies feel safe in linking their own code with
blender inside their own environment. In my experience, this is not
generally accepted as a valid thing to do with GPL code and the current
interpretations of the GPL.

I understand this also may not be the biggest priority at the moment, but I
think it's an important issue that deserves some serious consideration.

Thanks again to all of you for helping to make Blender such a great
success!
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

I think my post was mis-interpreted. I'm not trying to discuss the point of
commercially distributed binary extensions.

I am sharing the information, that at least in Silicon Valley, companies I'm
aware of DO NOT feel comfortable linking their propritary source to GPL even
if they plan never to distribute it. Whether this is a correct interpretion
of GPL is not relevant. It may be that these companies wish to operate
"beyond any chance of license infringement", or that their lawyers are just
too paranoid, or that they feel they ultimately can't control these types of
nuances enough to assure code they are using never gets released. However,
the facts are the facts. If you doubt this fact, I encourage you to talk to
employees of larger silicon valley companies that would be the type to use a
tool like Blender. It doesn't take long to discover specific situations
where they have made choices to avoid this kind of GPL-contamination risk.

Please avoid the temptation to jump into a debate about whether this is a
correct interpretion of the GPL. We are not lawyers, and the GPL has never
truly been tested this way in courts. More to the point, the answer to this
debate is irrelevant. If companies don't feel comfortable because of
_percieved_ GPL contamination risk, then they don't feel comfortable.

Users producing content within these companies make up the majority of
potential users for a tool like Blender. If companies could not use Linux,
gcc, Mysql, or other similar tools without this fear, those tools would not
have succeeded as they have. Fortunately for those tools, the conservative
interpretation of the GPL provides enough functionality... That is... if you
don't link with it, and you don't depend on it's behavior specifically, then
you are safe.

Let's consider another open-source component that does require people to
link with it. libc. It is specifically licensed under LGPL to prevent this
kind of contamination risk. Any changes to libc must be shared, but users
are free to link without fear of GPL contamination. By building an LGPL
licensed "extension api", users would be free to link, without fear of
contamination.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

>
> > I don't see any benefits for Blender if it would be "easier" for Silicon

> Valey guys to link their proprietary code with Blenders code.


If companies can use blender in their creative pipelines, then it will mean
more blender users and more blender developers. In the 3d community blender
is a promising project, but it's a footnote when compared with
Maya/Max/Lightwave/etc. Linux effectively replaced commercial Unix. MySQL
has dramatic marketshare vs Oracle, MS-SQL, and others. Both while remaining
open-source but by making it VIABLE for companies to use them. Blender has
the potential to do the same by making it viable for companies to use it.

I hope that one day Blender is a real competitor to Maya or 3dsmax. I hope
that one day 3d job requisitions might ask for Blender skills. I hope one
day 3d art and gaming studios that make commercial moves and commercial
games, make use of Blender as they are today using Linux and MySQL, and
countless other open source tools. Because when that happens, Blender will
be an excellent and first class 3d tool that is open-source and freely
available to all.

That day can only come if it's viable for companies to use Blender in the
ways they use Maya and Max without fearing a violation of the GPL. The
licensing today does not allow this.

> "IF IDENTIFIABLE SECTIONS of that work ARE NOT DERIVED FROM THE PROGRAM,

> and can be reasonably considered independent and separate works in
> themselves,
> > THEN THIS LICENSE, and its terms, DO NOT APPLY TO THOSE SECTIONS WHEN YOU
> > DISTRIBUTE THEM AS SEPARATE WORKS."
>
> I'm not a GPL expert or a lawyer, but I think that the important sentence
> is
> "and can be reasonably considered INDEPENDANT and SEPARATE works".


> Currently, if you write an extension/addon that uses any part of blender,
> or relies upon any part of blender, even just the python interface which is
> included with blender, then it can not reasonably be considered independant
> and separate, and thus it is subject to the terms of the GPL.
>

Exactly. AFAIK, the current legal interpretation is that if you don't link,
and you are not dependent on behavior, then you are "independent and
separate". Everything else is a grey area and depends on the paranoia of the
parties. Most I've talked to feel that writing an extension for GPLed
software which is dependent specifically on a GPLed API requires being under
the GPL. Which means you basically don't do it unless you are happy with
GPL.

Don't make the mistake of thinking that "doing it in secret" is a good
enough answer for a company.








>
> I do not think there is any reasonable way around this.
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Sun, Nov 14, 2010 at 6:29 PM, Martin Poirier  wrote:

> > Don't make the mistake of thinking that "doing it in secret" is a
> good enough answer for a company.
>
> It's not a matter of secret or not. The GPL is a distribution license, if
> you don't distribute your modifications, you can do whatever you want.
>
> That means any company can start modifying Blender and using it internally,
> as long as they don't distribute the modifications externally, licensing is
> not an issue.
>

I see that a few here believe this interpretation. My main goal in entering
this conversation was to educate and explain why this is absolutly not the
case in practice.

In the real world, no company I'm aware of will link their propritary code
with GPL code, because it creates too much risk. I respect the folks here
who believe it's not important to cater to corporate usage of Blender. I
don't agree with that perspective, but I respect it. However, folks who
believe that because of their 'layman's read of the GPL' that most software
companies will link their own propritary code with GPL code are simply
ignorant, misinformed, or both.

Companies are made up of individuals, and it's not easy to always keep a
watchful eye over everything that happens. It is easier to have a safe rule
like "don't link with GPL code" than it is to assure that GPL code never
accidentally gets linked into a distributed binary, thus triggering some
legal requirement to GPL and release company source code. What little
courtroom time the GPL has seen comes in the form of the Tivo cases, and
companies don't wish to be on the other end of this fight. They simply steer
clear of it.

If you don't believe companies using Linux and MySQL helped those tools
become successful, or you don't feel that the same cycle is important for
Blender, I can see why this issue wouldn't be terribly important to you.
However, if you think corporate usage of Blender is importantant, don't pass
off this as a non-issue simply because your personal read of the GPL tells
you so. If you don't take my word for it, talk to corporate council for a
medium size software company. They will explain to you why they recommend
against linking with GPL code.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

I apologize in advance for the long post.

(1) @ Ton : this is not a perception issue, this is the current legal
interpretion of the GPL. It is not legally okay to write, use, or distribute
binary code modules that links directly with, and is dependent on, GPL code
without triggering a need to GPL that code. In addition, doing so implicitly
licenses all applicable patents to the community. In short, it's not legal
to write a closed-source extension for a GPLed package such as GIMP or
Blender. I believe this will hurt Blender's long-term prospects for
adoption. I don't know what solutions are possible (if any), but I think
it's important to figure out. Carving out an LGPL extension API (something
that would not require relicensing of existing code) might fix this.

This Blender "faq" is naively incorrect and should be fixed...

*Can my organization use Blender internally without giving up our valuable
changes to our competitors? The GNU GPL does allow your organization to use
a modified version of Blender internally without offering the source-code as
long as you do not distribute it outside your company or organization.*
*
*
There are many problems with this interpretation, both legally and
practically. I'd like to stay out of a huge legal debate about the GPL, so
I'll just point out the practical problems. The practical realities of
"distribute" and "organization" are too constraining.  Companies today work
with contractors, third parties, outsourcers, etc, which are technically not
part of the "organization" but which help produce the work. People are not
puppets, and companies do not have enough control to assure that nothing is
ever "distributed", thus triggering the need to GPL and open-source. Which
causes companies to refuse to accept any GPL code into their source-control
or development pipeline.

These and many other factors mean this should read:

*Can my organization use Blender internally without giving up our valuable
changes to our competitors? 3d models and data produced by blender can be
output in a variety of formats and may be kept under any license the author
chooses. Changes to blender source code are governed by the GPL and must be
distributed as required by that license. *

This gets blender out of the situation of being wrong about interpretion of
the GPL, as it simply defers to the GPL.

(2) As Lorenzo excellently explained. This is not a discussion about
allowing commercial companies to use blender code in their own products.
This is a discussion about allowing commercial companies to use Blender,
become part of the community, and contribute.  John Grant very eloquently
explained the issue in the form of his specific example. I'd like to quote
his words here to reinforce them..

*"Because there is no protection for companies that want to extend Blender,
I can not recommend we use Blender in our work processes.  Since we can not
develop tools that integrate with Blender, we have been forced to integrate
with Autodesk tools.  Our clients are familiar with the Autodesk tools and
are happy about our choice.  The Blender community has lost a chance to
introduce itself to our clients."*
*
*
As an interesting datapoint. GIMP is under the GPL, and has these same
limiting issues (no commercial extensions), and yet companies are "selling"
gimp for their own profit, because nothing about the GPL disallows this.
They simply package and sell it, source included. Being under the GPL does
not prevent this.

(4) Linux is not entirely built of GPL code as it would lock out commercial
involvement. They smartly use LGPL and draw boundaries so the community can
still build a healthy ecosystem of open-and-closed source tools around
it. In fact, using Blender on Linux is in part practical because xfree86 is
not under the GPL, facilitating binary 3d drivers from NVidia to be used on
Linux.

A 3d tool like blender is not like gcc. It is not an isolated tool that
exists without in-address-space extensions. In order to make good use of 3d
tools in a pipline, software is frequently built and intergrated with it as
extensions.

(5) Several folks here have brought up the point that it may be difficult
(or impossible) to do anything to alter Blender licensing, even if there is
a good alteration that could be made. I understand this point, and will
offer that it will only get harder as time goes on. I revived this
discussion because I'd really like to see Blender become a tool on-par with
Maya, 3dsmax, and others. I don't believe this will happen unless commercial
companies can use proprietary code in extensions without legal fear of the
GPL -- because that positive feedback cycle will bring more professional
users and developers to Blender.

(6) To followup on Lorenzo's excellent suggestion for specific examples...

Pixar authors the Renderman rendering engine. They also have their own
modeling/animation tool called Marionette. They use Maya and Max as well. It
would be very scary for them to link renderman int

Re: [Bf-committers] extension clause

[David Jeske]

My large previous post was focused around the reasoning behind my position.
I didn't want my suggestions for how to improve the situation to be lost in
it. Here are a few concrete suggestions. Note that in making these
suggestions, I'm not attempting to judge what would be required to make
these changes, simply suggesting alternatives that I believe would be better
than the current state:

(1) switch Blender entirely to the LGPL

The LGPL license is used for libc, and is written to require source
modifications to the code to remain free and available like the GPL.
However, it allows for "combined works" that link directly into the address
space of the LGPL code, without requiring that code be under any particular
license. This would allow closed-source extensions, as well as allowing
blender to be compiled into closed-source combined works. All improvements
to the blender code would need to be released, but the closed-source pieces
built around or inside blender could remain closed.

This would allow, for example: (a) games written using the blender game
engine to be distributed without releasing the entire source. Any
improvements or modifications to blender or the blender game engine itself
would need to be distributed. (b) extension modules which were build
specifically for blender to be distributed as closed source.

(2) create a section of LGPL code to handle the extension API

This is a compromise intended to acheive the same as (1) without changing
the license of existing code. There are some issues however. Doing this may
violate the GPL, as it is linked with the main blender code and thus should
be under the GPL, not the LGPL. Further, it's hard to imagine how an
extension API could insulate an extension from the details of blender
without encompasing most of RNA and anything related to touching
data-model.

(3) create a special provision for extensions, either as a carve-out
addition to the GPL, or an alternate "Blender-GPL" modified form of the GPL.

While I believe the LGPL was designed for and handles this case very well,
it may be easier for the community to agree on approving a small license
addition carveout for extensions while keeping the GPL in place as-is.

... again, I'm not attempting to start a debate on the viability of making
one of these changes. I'm attempting to discuss and build concensus about
the benefits of doing so.

Because Blender Foundation did not establish a process for copyright
assignment, a change like this would involve auditing copyrightholders and
either obtaining their permission, removing their code, or resigning the
change as unviable. Any discussion about whether or not this is feasible is
simply speculation.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Mon, Nov 15, 2010 at 1:58 PM, Dan Eicher  wrote:

> There's actually two issues being discussed here, the ability to use GPL'd
> software *in house* and the ability to distribute non-GPL'd extensions.
>
> The first needs no license change at all, companies just need to be careful
> not to release their (presumably extremely valuable) software into the
> wild.
>

I've stated why my experience strongly disagrees with the above statement.
Rather than state something as true which some here (myself included) feel
to be patently false, perhaps you could provide some examples of companies
that have gone down this path and how they arrived there?

Perhaps this example will help you understand why the constraint to "be
careful not to release" is not acceptable to companies.

If an employee acts improperly and releases copyrighted code to a
competitor, copyright law will prevent that competitor from using the code.

If an employee acts improperly and releases a binary which contains both GPL
and non-GPL code, the GPL says the source code must be released. There are
no provisions for "withdrawing" the distribution. The moment it happens, the
company is infringing the GPL and can face legal action. Further, if source
code were improperly distributed, rather than be able to use their copyright
of their own code to prevent it's use or distribution, the world can use the
fact that it "is not independent and separate" from GPL code to argue that
the entire code must be GPL and thus be free. This is too great a risk for a
company to operate under.

Again, in my experience, companies find it is not legally acceptable to link
GPL code with closed-source code, for any reason. If you believe otherwise,
I'm interested to hear examples of when you were in that decision making
situation, and how you arrived at the decision to link GPL with propritary
code "in secret". Anything else is just speculation.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Mon, Nov 15, 2010 at 5:59 PM, Campbell Barton wrote:

> @David Jeske, at least twice you point to The GIMP, as an example of
> software that is limited by the GPL.
> This in-fact is incorrect. The GIMP has already resolved this by
> providing a LGPL libgimp which closed source plug-ins my link to.
> Incidentally, does anyone know if this has helped the GIMP?, or know
> of any commercial plug-ins on the market for the GIMP?.
>

I wasn't aware of this license split in GIMP. At face value it looks like
exactly the sort of "LGPL api" that has been brought up by myself and some
others. I found a decent overview of the gimp components and
licenses<http://gimp-plug-ins.sourceforge.net/gimp2/doc_components.html>.
 I will do some research and see if I can learn anything about commercial
comfort with this license situation. Unfortunatly, gimp may not tell us much
about the viability of this scenerio, because as I understand it there are
many other factors that make gimp a challenging tool to adopt vs photoshop.

* As for a GPL exception, I'm not against this but expect its
> difficult to do this. Id also be fine with a LGPL python api but this
> uses internal blender libraries which I think will complicate things.
>

Looking at the gimp lgpl vs gpl diagram, there are substantial portions of
gimp which seem to be lgpl to enable this type of split. To mirror this
structure, I suspect RNA would need to be part of this LGPL'ed layer.


> * Along similar lines to Matt, I'm more interested in blender linking
> with closed modules, this would allow us to have a FBX importer (like
> Wings3D can do because they are BSD), it would also allow integration
> with commercial rendering plugins without having to mess with external
> processes.
>

I'm with you on this goal.

@Alex Combas - That certainly is a creative interpretation of the system
library and library-permissions clause. The spirit of that clause is very
different than the manner in which you are attempting to apply it. The
intention is to allow for the base-case that GPLed software written for a
commercial operating system (such as windows), is obviously going to link in
a bunch of non-GPL system-library code, and if the GPL attempted to assert
GPL requirements on that system-library we'd all probably consider the GPL
flawed at a fundamental level and reject it.

The wording here, even in the case of a manual exception, refers to the
non-GPL code as a "library" and implies it's existance before the authoring
of the program. Something which was authored before the GPL program
shouldn't have any dependencies of the program in it, making this entire
concept redundant with the "indepdenent and separable" test. An
addon-library which is authored after the GPLed program, and which is
obviously dependent on an API established by the GPLed program seems like a
different beast entirely and not at all synonous with the concept of a
'system library'. Further, the exception would need to not be for a specific
library, but an entire class of library (any addon).

We'd need a lawyer to render an opinion, and even moreso, only time would
tell whether that interpretion would be reasonable. It's unclear if this
would provide enough comfort, until the situation was tested by a court or
disagreement. That said, it is a very creative suggestion, and we should
consider this as it might be a decent route for the idea of carving out an
addon-exception.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

I think this mechanism Alex brought up is an important one to consider. In
addition I've referenced some additional FSF documentation about GPL vs
LGPL.

On Tue, Nov 16, 2010 at 2:22 AM, Alex Combas  wrote:

> > The wording here, even in the case of a manual exception, refers to the
> > non-GPL code as a "library" and implies it's existance before the
> authoring
> > of the program.
>
> It does not say that. I think you are bringing in your own interpretation.
>
> The way the document describes it there are only two classes of libraries:
> system, and non-system.
>
> You indicate that you think that certain libraries would automatically
> be disqualified by the FSF depending upon their date of authorship or their
> purpose or utility.
>

That's not the source of my interpretation. The GPL refers to a "system or
non-system library" which implies it exists and can be named. If the library
does not exist at the time of the exception, how can it be named? In my
view, we're not proposing to name an exception "library" but a "class of
libraries". I see no provision in the GPL for a "class of libraries" or a
"set of libraries conforming to an API".

Further, some might also argue that the accepted computer science definition
of "library" (system or non-system), implies that it is developed and
compiled independently. If are to consider an addon a reasonable case of
'library', that code still must be compiled/linked independently, and so any
headers it's compiled/linked with would need to be at least LGPL to prevent
GPL contamination.

I do think this "library exception" may be the opening that allows the GPLed
GIMP code to make exception for the LGPL gimp extension library. Without
this exception, it might be a violation of the GPL for gimp to link with the
LGPL extension library.

-

This rider at the bottom of the GPL seems to pretty clearly advocate an LGPL
path for code which intends to allow incorporating (linking) propritary
code.

The GNU General Public License does not permit incorporating your program
> into proprietary programs. If your program is a subroutine library, you may
> consider it more useful to permit linking proprietary applications with the
> library. If this is what you want to do, use the GNU Lesser General Public
> License instead of this License. But first, please read <
> http://www.gnu.org/philosophy/why-not-lgpl.html>.


..and further, on the linked philosophy about gpl vs lgpl...

Using the ordinary GPL is not advantageous for every library. There are
> reasons that can make it better to use the Lesser GPL in certain cases. The
> most common case is when a free library's features are readily available for
> proprietary software through other alternative libraries. In that case, the
> library cannot give free software any particular advantage, so it is better
> to use the Lesser GPL for that library.


Even though a 3d modeler is an "application" the way it is commonly used it
is also a "library" because extensions and modules are built and linked with
it.

This is why we used the Lesser GPL for the GNU C library. After all, there
> are plenty of other C libraries; using the GPL for ours would have driven
> proprietary software developers to use another—no problem for them, only for
> us.


..which seems analagous to our situation. There are plenty of other 3d
modelers which allow extensions. Using the GPL drives propritary software
developers to use another -- *which is no problem for them, only for us*.

I understand that some may be sympathetic with the other messages in that
lgpl vs gpl philosophy. Namely ...

We free software developers should support one another. By releasing
> libraries that are limited to free software only, we can help each other's
> free software packages outdo the proprietary alternatives. The whole free
> software movement will have more popularity, because free software as a
> whole will stack up better against the competition.


I am not oblivious to this argument. To reuse the rationale made in that
document...At least one piece of extension code will probably be released in
the GPL that would not have been if Blender remains fully GPL. However, I
believe the entirely free-and-open-source code of Blender will stack up
better against the competitors if proprietary software developers (and
companies) can use it as a replacement for those products. A situation which
is very analagous to libc. Being fully GPL, removing Blender as an option
for companies, really *is not a problem for them, only for us*.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

I think this discussion may have run it's course, as I think both sides have
expressed their views. I have a few closing comments. If there are next
steps, I think it's really up to Ton and the Blender Foundation to consider
and propose them, because it is likely only through their action that
something would occur.

On Wed, Nov 17, 2010 at 5:11 AM, Ton Roosendaal  wrote:

> In discussions at Siggraph with some people working in studios, they
> mentioned to have solved it by creating a fully separated "open
> domain" for software, vs their own "closed domain". The code in these
> domains are never allowed to be mixed up. The open domain is not
> allowed to use or link to anything from the closed domain, however the
> closed domain can link to modules in the open domain (but without
> copying any code).
>

This contradicts the information I see in the industry, and both the legal
and my laymen's understanding of the GPL.  Is there some company that could
publish a case study about how they feel it safe to build closed-source
extensions to GPL code?

In my experience, closed-code is not allowed to link to GPL code, because of
the GPL would then require the closed code to be under the GPL. The issue of
it being allowable without distribution is not useful, because distribution
to contracting shops and other third parties is typically necessary.
Further, a 3d modeling tool can't be adopted at a game or VFX company
without this ability to link with closed source.

Yesterday I shared the details of this topic with a friend in engineering at
a major game studio (which I'd prefer not to name). He re-confirmed what
I've heard many times from him in the past on this topic. Aside from the
other issues that affect their choice of 3d modeling tools, in his opinion
they would be unable to even consider using a tool that they
couldn't safety link with closed source.

Blender is an incredible tool for Internet hobbyists, education, and
open-projects, and it will remain an incredible tool for those situations
whether this issue is addressed or not. Further, industry tools are so far
ahead, and community lock-in is so pervasive, that even if this issue
of safety linking with closed-source was addressed, it still would be an
uphill battle for Blender to make headway against Maya, Max, Houdini, or
custom developed in-house tools (something Blender once was!). This same
pattern is evident in the GIMP community, where despite having tried to
address linking with closed-source, it's still not a serious alternative to
Photoshop for most companies.

That said, I think it's important to consider whether it is a goal of
Blender to be a "professional" 3d tool that can compete in the community
against Maya, Max, and others. If the answer is "yes", then I believe we
must enable linking with closed-source extensions. If the answer is "no",
then Blender can freely proceed to be the best open-source-compatible 3d
modeling package it can be. I believe it is false-hope and a mis-alignment
of goals and action to believe that Blender can make any headway in the
professional 3d community without enabling the ability to link with
closed-source.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Wed, Nov 17, 2010 at 2:24 PM, Dan Eicher  wrote:

> > This contradicts the information I see in the industry, and both the
> legal
> > and my laymen's understanding of the GPL.  Is there some company that
> could
> > publish a case study about how they feel it safe to build closed-source
> > extensions to GPL code?
> >
> > Seems like y'all are talking about two different things (again).


> They aren't making 'extensions' to GPL code but merely linking *to* the
> GPL'd code from their 'closed domain'. They would also (presumably) take
> into account this *linking* when distributing their code to 'contracting
> shops and other third parties'.
>

I don't see two different things, perhaps I can clarify and you can explain
why you believe this to be the case...

When I write "extension", I mean: "an add-on which is compiled against and
dynamic loaded into the address space of another program, but normally
distributed separately."

To write a "closed source extension add-on" you have to "link to GPL code
from a closed source domain (the add-on extension)", you have to "depend on
details of the GPL code specifically in closed-source", and you have to "run
closed-source code (which is not a system library) in the same process as
the GPL code".  -- All of which are prohibited by the GPL as far as I can
see.

Any code which links to (in process) and depends specifically on details of
GPL code must be under the GPL. Even if it's a DLL/dso, it still needs to be
under the GPL. That's the purpose of the license. This is the reason glibc
is under the LGPL, because if every program that linked to glibc had to be
under the GPL, closed-source programs could not be built with glibc.

I think this interpretation of the GPL is fairly accepted. If you don't
think this is the case, I encourage you to work with the FSF to see if they
will release a position statement explaining how closed-source DLL/dynamic
modules may be built to run in-process and be dependent on details of a GPL
codebase. I don't think they believe this to be valid, but if they do,
writing a position statement should clear it up.

I've heard a few people mention this loophole related to the definition of
'distribution', where if a binary is distributed only within an
organization, then that's not really 'distribution' and so the closed-source
code does not need to be moved to the GPL and released in source form. I've
explained why this loophole is not practically useful, both because it's not
universally accepted, and because companies must often distribute the
binaries outside their organization to get work done.

Which part of Blender will an extension use?


It seems like today's extensions use the UI, operator stack, and RNA/mesh
data. This is probably the minimum set.


> If it just has access to an API which provides user data (mesh data,

materials and such) and a way to return some processed data to Blender so

this extension is independent work.

If it doesnot use some or Blenders internal libs (render calls, modifier

code, ...) it depends of the data and not Blender itself.

And the data is not GPL... so where is the problem?


The problem is that according to the GPL, if you do that in the same address
space, your code has to be GPL as well. Doing this legally as closed-source
either requires building an out-of-process network based API (as Campbell
mentioned), or building an LGPL API shim in the middle (as GIMP did).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Sat, Nov 20, 2010 at 5:50 AM, Campbell Barton wrote:

> And regarding this making companies paranoid - this is conjecture, But
> if some group choose to be ignorant & paranoid then this is their own
> foolishness.
>

That depends on who needs who. The companies don't need Blender. There are
plenty of alternatives out there (which today are much better anyhow). The
commercial cost of these alternatives is irrelevant compared to labor costs
(at least in the west).  When I recently talked to one of my game-studio
contacts about this discussion and why they don't touch GPL stuff with a ten
foot pole, he also reminded me some of the other reasons Blender wouldn't be
good enough today even if the license was fixed.

On the flip side, Blender would be much better with these professional
users. Users that could embrace, improve, and contribute to blender. In the
words of the FSF:

http://www.gnu.org/licenses/why-not-lgpl.html

This is why we used the Lesser GPL for the GNU C library. After all, there
> are plenty of other C libraries; using the GPL for ours would have driven
> proprietary software developers to use another—*no problem for them, only
> for us*.


libc, Linux, MySQL, Python, gcc, and many other pieces of popular free
software reached their current state because of a virtuous cycle of being
good for users, allowing users to make them better. The ones that are able
to do it with the GPL (linux-kernel, gcc, mysql), can do it because they
don't need users to link directly into their stuff to get work done. The
ones that do need direct linking (python, libc) have done so by not using
the GPL.

It doesn't do Blender any good to call commercial companies "wrong" for
being concerned about the GPL and avoiding it. Blender will still be out the
users. Maya and 3dsmax will still be the most popular animation tools. I'm
beginning to feel like a minority in wanting Blender to one day become a
real disruptive open-source alternative to these commercial tools.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Sun, Nov 21, 2010 at 1:13 PM, Dan Eicher  wrote:

> On Sun, Nov 21, 2010 at 9:09 AM, David Jeske  wrote:
> > ...I'm beginning to feel like a minority in wanting Blender to one day
> > become a real disruptive open-source alternative to these commercial
> tools.
> >
> > And why does Blender need to change it's license to do this?
>
> You seem to equate 'success' with blender having a secondary
> 'proprietary plugin' market and a bit of FUD over the GPL thrown in for
> good
> measure.
>

I equate "success" with Blender having users, and a stable product.

My comments on the GPL are not FUD, they are reporting the reality of the
decisions companies make today. FUD would be trying to convince them to stay
away from GPL software. Arguing that it's theoretically possible for them to
be safe linking their closed code to the GPL is sort of an irrelevant point
in this discussion if most of them choose not to do it -- regardless of the
reasons.

I believe it's important to many users (especially, but not limited to
corporate users) to have a secondary 'proprietary plugin market', because
they get benefit from being able to buy those plugins and use them to get
work done, instead of waiting for a community to author them, or trying to
sink lots of their own resources into developing them. The open source
community would eventually do what it always tries to do, and copy the
commercial plugins, which is totally fine. The commercial companies have to
keep innovating to stay ahead of 'free and open source', and open-source
gets better all the time. This virtuous cycle doesn't happen if they can't
even start.

Oh, and friend who says 'Blender wouldn't be good enough today even if the
> license was fixed'.
>

We all know this to be true. Is there someone who thinks differently? I want
to see a world where Blender is good enough to replace Maya.


> I suppose it would be different if these studios could make and distribute
> their own changes (to make Blender 'good enough') without having to give
> these changes back to the community?
>

That's not what I'm suggesting at all. What you are describing is more like
the BSD/Python/artistic licenses, which are a free-for-all. I'm advocating
the LGPL.

The LGPL requires any changes you make **TO THE CODEBASE** to be
distributed. It simply allows you to link your own binaries into the same
address space, depend on material details, and distribute those binaries to
other parties without requiring you to distribute source for YOUR code. In
other words, I could make a DLL/so by linking against blender.h and
distribute my binary, to run in the same address space, without releasing
source for my binary. Moreso, as a company I could be comfortable linking
this code with my closed code, because LGPL code can be linked into
commercial products without releasing the entire commercial product. For
example, if I made an interesting game using the Blender Game Engine, I
could sell my game as a binary with my only obligation to release the source
to all components of the Blender Game Engine I used, as well as any
improvements or changes I made to that code. My game-code could remain
closed and sold as a for-profit binary.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Sun, Nov 21, 2010 at 3:30 PM, Dan Eicher  wrote:

> >
> > I believe it's important to many users (especially, but not limited to
> > corporate users) to have a secondary 'proprietary plugin market',
>


> > That option has been discussed and all but approved, the only hitch is
> the
> plugin writers also have to write and maintain the BSD (or whatever) api
> shim code.
>

How is legally viable to make a capable BSD licensed API with the code under
the GPL? The shim would be dependent on material details of the Blender
design and internals. It would probably expose many of those details (such
as UI panels, RNA) As a result, the shim should be under the GPL, and as a
result, the extensions should be under the GPL.

During this discussion we talked about the license extension exception. This
applies to Blender embedding Python, effectively making it a 'library
exception'. Python was a pre-existing library which is not-GPL, and thus is
covered under the GPL library exception clause. Python does not depend on
any details of blender. In fact, it's the other way around, Blender depends
on Python.  If I understand correctly, in order to apply this license
exception, the authors of all those details (UI, RNA) would need to approve
the 'exception' of the shim-library, and they would need to depend on it's
details, not the other way around.

It's interesting to note that if Blender wanted to be non-GPL, and Python
was GPL, it wouldn't be legal to embed it into Blender. One of the biggest
benefits of Python is that it can be linked with anything without license
restriction. It's shown up in all kinda of software, free and commercial,
and been a stronger open-source project for it.

Ton wrote
> Basically there are two cases we can investigate:
>
> 1) Allow anyone to extend Blender, linked dynamically with scripts or
> libraries or plugins
> 2) Allow anyone to dynamically link in Blender libraries in their own
> programs
>
> The LGPL will only allow the latter. For the first we have to devise
> an extension clause (if we want to stick to GPL).

The LGPL would allow either. In order for someone to write a non-LGPL
plugin, their code must depend on details of the LGPL code, and "link
against" the LGPL code, both of which are allowed by the LGPL.

When you say "extension clause" are you referring to authoring a
unique-to-Blender extension clause which deviates from the GPL? or using the
GPL Library Exception provisions?  As I wrote above, in order for the
library-exception clause to allow closed-source extensions, Blender would
need to carve bunch of existing code into a "ui and rna" library, which is
put under a a less restrictive license and is then becomes the library
exception. This is the route GIMP took. They used the LGPL for that library,
since the LGPL allows you to link it into closed source without
contamination. Using a less restrictive license would obviously also work.

I don't see solid comfortable legal ground for claiming that "all 3rd party
extensions" are "after the fact" library exceptions, using the GPL's library
exception clause. If this is the route you intend, it would help
substantially if you could get FSF to publish a specific position on this
direction.

It's kind of funny how people/companies are willing to contribute code to
> (and use) Linux more than all the BSD put together yet Linux has a more
> restrictive license. You'd think they would all be scared away from the GPL
> and go towards a license where they don't have to worry about having their
> code 'virally' infected or 'lost' if they (accidently or otherwise)
> distribute it. But they don't which IMHO says a lot.
>

Linux can be extended by writing applications. Those applications do not sit
in the same address-space as the Linux kernel, and they compile against
glibc and other libraries, not the kernel itself. No GPL contamination.  All
that is required for the community to adopt a solution is for that solution
to have critical mass and have a license compatible with them building and
distributing anything they want, with any license they want. Linux provides
this. A GPL Blender does not.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Mon, Nov 22, 2010 at 10:40 AM, Dan Eicher  wrote:

> > How is legally viable to make a capable BSD licensed API with the code
> under
> > the GPL? The shim would be dependent on material details of the Blender
> > design and internals. It would probably expose many of those details
> (such
> > as UI panels, RNA) As a result, the shim should be under the GPL, and as
> a
> > result, the extensions should be under the GPL.
>
> The same way the (BSD licensed) ofx api can load proprietary code/libs.
>

BSD Licensed code can do anything it likes. BSD license does not attempt to
control the license of other code it links to like the GPL does. This is not
a valid example.


> Blender can link to the header files and the *users* load/link to the
> non-gpl compatible external code (which also links to the BSD'd header
> files)... everyone gets what they want and no copyrights are violated.
> Drinks for everyone!!!
>

Although the BSD above is confusing the example, I agree that by my read of
the GPL, an open-source GPL blender extension can load/call to a third-party
closed-source binary code library under the GPL's "library exception". What
this means is that any extension UI, code that touches RNA, any code which
touches any detail of blender would need to be open-sourced under the GPL.
While the "core algorithm" which must not be at all dependent on or link
against blender details, can be closed-source.

This is unlike extensions for tools such as Maya or 3dsmax, where the entire
extension, including UI and data-manipulation may all be closed source. I
believe this means some types of commercial extensions are viable (such as a
file format reader/writer), and some types of commercial extensions not as
viable (a UI extension or addin based on data-transformation within
blender). I'm undecided whether this is enough. A company considering
releasing an extension for blender may find the idea of having to
open-source a chunk of the extension is unfamiliar, which might prevent them
from doing it. However, it looks like that chunk would merely contain
glue-code that doesn't reveal their proprietary invention. I'll need to
think about this some more and consult some contacts in the industry to form
an opinion. This is an excellent point (which I think has been mentioned
before, but I didn't quite see it this way until your paragraph above).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Mon, Nov 22, 2010 at 4:05 PM, Dan Eicher  wrote:

> On Mon, Nov 22, 2010 at 12:51 PM, David Jeske  wrote:
> > Although the BSD above is confusing the example, I agree that by my read
> of
> > the GPL, an open-source GPL blender extension can load/call to a
> third-party
> > closed-source binary code library under the GPL's "library exception".
>
> *Users* are the key here, the only way the gpl applies is if they try
> to bundle their extension with blender proper (or use gpl'd libs). You
> can take your copy of blender and link it to whatever you want (as in
> the 'internal tools' example given previously) and developers can
> release their independent code under whatever restrictive license they
> chose.
>

I don't think it matters who does the linking, except for the exception that
a user can do whatever they want with code they author, and are not forced
to do anything as long as they don't distribute it.

I think what's most important is the direction of dependence and linking. If
a third-party closed source library does not depend on any blender details
(i.e. imports no blender headers, links against no blender libraries), it
obviously can't be forced into the GPL. You can write a GPL open-source
blender extension which depends on the closed library, that closed library
is part of your "library exceptions" for the extension code.

You can wrap that all up on a CD (including blender) and ship it directly to
a customer. You are required to release the source code for blender, and for
your excention that includes blender.h and links directly to blender.
However, that extension is free to access any system libraries and any
library exceptions, including your closed-source third-party library (again,
just so long as the third-party library did NOT link against blender).

The proprietary extension links to BSD headers and implements the
> 'external' interface, Blender links to BSD headers and implements the
> internal interface and the user does the 'aggregation' in the privacy
> of their own home. Easy peasy...
>

Sure, that's the other way to do it. Add GPL code directly to blender to
depend on an external library under any license, and simply list is as a
'library exception'. The BSD middle ground isn't even necessary.

The wrinkle with all of this, is that all that code that DOES touch
blender.h (or whatever), and DOES depend on blender details, MUST be
open-source. This might not be desirable if a company is going to write lots
of code like this to make a really cool extension.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] extension clause

[David Jeske]

On Mon, Nov 22, 2010 at 11:10 PM, Knapp  wrote:

> http://en.wikipedia.org/wiki/PyQt
>
> PyQt is developed by the British firm Riverbank Computing. It is
> available under similar terms to Qt versions older than 4.5; this
> means a variety of licenses including GNU General Public License (GPL)
> and commercial license, but not the GNU Lesser General Public License
> (LGPL).
>

Right. In both of these cases they are using the GPL to provide a free
version to the community for only GPL software development, attempting to
assure closed-source software development must license their commercial
version.

Remember that while GPL software can "incorporate a closed source library as
a library exception", the GPL makes no such provision for a piece of
software to "incorporate GPL code without becoming GPL". If you depend on
details of GPL code and link against GPL code, then you must be GPL. Since
PyQt is a development framework, it's impractical for you to use it as a
development framework without depending on it's details and linking against
it.

Relating this to our discussion... Someone could write a GPL open-source
application UI which depended on the GPL PyQT, but which called out to a
closed-source library which did some special functions. All code which
depended on GPL PyQt would need to be GPL, but the closed-source library
would be independent and depend on no details. For some commercial
applications, this would mean a huge amount of their code would be
open-source (i.e. if they are mostly UI), and if the company didn't want to
release all that code, they would need to license the commercial PyQt to
keep it closed.

This is analogous to GPL Blender today. As long as all pieces of code that
depend on blender details (UI, RNA manipulation, operator implementations)
are all GPL open-source, you're fine. Core-algorithms (such as something
that takes an array of points and modifies it in some way), can be closed
source. As the code which depends on blender details becomes substantial,
companies are less happy open-sourcing that part of the code.

If PyQt were offered under the LGPL, it would negate their attempt to use
dual-licensing as a revenue model, as any company would be free to link the
LGPL code into their closed-source code and distribute. The LGPL would
merely require them to release the complete source to the version of PyQt
they used, including any modifications or improvements. Their code built
around PyQt could remain closed under any liecnse they desired.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers