[Bf-committers] Blender developers meeting notes - August 2, 2015

[Sergey Sharybin]

Campbell,

Changes in the data structures which are used all over the place is surely
a subject for documentation. That being said, the changes around all this
looptri, modifications in the tangent space calculation, BVH changes (which
touching almost anyone working on Blender) is definitely a subject for
documentation. If you've got good explanation in the commit message, then
just copy-paste the information to the wiki.

Previous sentence also answers your question about to share this
information -- in the wiki. While the information in there can become
outdated it's at least _possible_ to change it (compared to commit message
which you can never change).

Can we just stop the discussion and consider all blender design solutions
are to be in the wiki? (not necessarily in the Dev section, might be just
some page under the user page).

P.S. The commits you've mentioned above are mainly implementation details
changes, they don't touch design as we know it. Only arguable thing is the
sculpt custom data commit, which on the one hand doesn't change anything in
the CustomData design and just makes it to use existing solutions form
there, but on another hand shows that our CustomData area is rather
mysterious area which you can't get into so much easy.

Joe + Antony,

You don't know a-priori if there's users of mesh outside of the viewport
and dependency graph wouldn't help with this at all. Think of sculpting,
changed in modifier stack, using snapping to a volume and so on. Plus, all
the objects are actually requiring having AABB.

I'm also not really convinced with deform modifiers being calculated on
GPU. Do you have some experimentation results or so?


On Mon, Aug 3, 2015 at 6:59 AM, Campbell Barton <ideasman42 at gmail.com>
wrote:

> > - Reminder: anyone who wants to add something that affects users or
> other developers (APIs):
> > always make a nice doc! *Before the commit* Even when you think it's not
> interesting (like optimizing).
> > Blender work is interesting to share by default! :)
>
> I don't want to quibble here but this statement makes it sound as if
> it should be obvious when to document development,
> to me this is way too vague/fuzzy.
>
> Optimization and general improvements happen fairly often,
> applying some common sense I assume the statement above means
> optimizations which users are likely to notice. Not the "~3% speedup
> on a good day" variety :)
>
> Even then, we've had improvements to low level code: hashing [0],
> optimizing allocations for slop-space [1, 2], merge-sort for
> linked-lists [3], misc BMesh improvements [4, 5]
> (not a comprehensive list, just to pick some from memory).
>
> Which ones of these would should be documented *before* committing, and
> where?
>
> Significant speedups are worth mentioning in the release log, but further,
> I'd prefer good high level explanations/comments in the code, and
> detailed commit-log if its needed.
> Instead of docs on the Wiki or developers own blogs which tend to get
> outdated.
>
> [0]:
> https://developer.blender.org/rBcfdd27381c6730dc0d8d4bb51c132b29337b8af5
> [1]:
> https://developer.blender.org/rBe220d3228f48d4cb3256b398b45b40bf6892e550
> [2]:
> https://developer.blender.org/rB19b7bb5975afdc2340538cb48d85e445828e9d7f
> [3]:
> https://developer.blender.org/rB867cd2048e0e8dd9f0552ac996bb1d352136b9a0
> [4]:
> https://developer.blender.org/rB65a95926600027814ef01ce5beaf711d3f41be55
> [5]:
> https://developer.blender.org/rB38eef8deee4261f0139d29eb81584131a862bf59
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin