[Bf-committers] Developer meeting minutes, 14 nov 2010

Janne Karhu jhkarh at gmail.com
Mon Nov 15 09:46:59 CET 2010

Yes I agree pretty much fully on what you've written. The whole particle  
system is still really quite crippled from the jump from 2.49 to 2.5 and I  
haven't even wanted to start reimplementing certain features over (such as  
effecting particle properties with particle time and reactor particles),  
since I want them to become much more powerful than they were before.

I too have high hopes for the node particles, but my proposal doesn't  
really change anything functionally for better or worse. It only give the  
users a bit more clarity on what the function of the "particle system"  
entry in the modifier stack is. I think this "clarity" will be needed even  
more for node particles, but even now you really want to be able to decide  
what point in the object's modifier stack is used for particles and other  
effects, no matter how the actual effects are calculated.


On Mon, 15 Nov 2010 05:38:25 +0200, Daniel Salazar - 3Developer.com  
<zanqdo at gmail.com> wrote:

> @jahka: I'm sure you know everything I'm about to say. Also this is of
> course my personal opinion.
>  Modifiers are limiting, as you know a much better design is going on
> on luka's branch, it's flexible enough to handle any kind of data,
> call it verts, particles, faces, etc. and let's you work with low
> level data as easily as with high complexity tools. Current modifier
> stack design is unreliable since the relationship between different
> objects with modifiers is fixed and undefined. This would be clear and
> manageable in a node environment.
>  A worst scenario is the particle system. Personally I find it easier
> and safer to code particle or object level effects in python from
> scratch than taking the *risk* of using the particle system and
> suddenly just hitting a limit in the design that won't let me do what
> I need. I feel like I'm not in control. What I'm saying is that any
> effect related feature is useless(?) if you can't tweak it/modify it
> to do the exact thing you are asked to do. As long as the system
> remains rigid in this sense every feature added feels so vain to me.
> I've placed my hope and interest in the node tree, it's already so
> close to being immediately useful but also exponentially powerful when
> it starts to merge currently separated systems into one unified
> environment where data can be passed around and converted from one
> type to another.
> Daniel Salazar
> On Sun, Nov 14, 2010 at 10:22 AM, Ton Roosendaal <ton at blender.org> wrote:
>> Hi all,
>> Short meeting todo, here the relevant notes:
>> 1) Current projects
>> Particle UI, Janne proposes to better organize Particle modifiers:
>> http://wiki.blender.org/index.php/User:Jhk#Modifier_Stack_proposal
>> 2) Blender 2.5x issues
>> - Bugfixing continues with full attention!
>> - Ton will do bug 'triage" and assign to developers. Developers who
>> have time please notify him.
>> - If you have bugs assigned, but you can't work on it for a period (2
>> months?), please find someone else or un-assign yourself.
>> - Wiki official maintainers list will be updated this week to get
>> formalized, will also help assigning reports, and cleaning up the long
>> list of svn committers (inactive devs will get removed).
>> - Nathan Letwory will work on updating development wiki this week
>> -Ton-
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list