Add missing 'New' button to Particle properties #37998

Closed
opened 2013-12-30 20:15:21 +01:00 by William Reynish · 17 comments

The issue

Blender's datablock system has a consistent way to add new items, except for Particles, which is missing the 'New' button. Users can manually add a particle channel and create a particle system that way, but it's inconsistent with materials, which presents a large New button, even when there are no material channels.

It's a smaller issue, but inconsistencies like these add up to create unneeded confusion.

In Materials, you get this when there are no channels:
Materials_New.jpg

In Particles, you get this. Notice the lack of a New button:
Particles_New_missing.jpg

Proposed solution
Add the missing 'New' button inside Particles properties, like so:

Particles_New.jpg

Advantages

  • Consistency with other areas of Blender
  • The large button draws attention to the main task
**The issue** Blender's datablock system has a consistent way to add new items, except for Particles, which is missing the 'New' button. Users can manually add a particle channel and create a particle system that way, but it's inconsistent with materials, which presents a large New button, even when there are no material channels. It's a smaller issue, but inconsistencies like these add up to create unneeded confusion. In Materials, you get this when there are no channels: ![Materials_New.jpg](https://archive.blender.org/developer/F59264/Materials_New.jpg) In Particles, you get this. Notice the lack of a New button: ![Particles_New_missing.jpg](https://archive.blender.org/developer/F59266/Particles_New_missing.jpg) **Proposed solution** Add the missing 'New' button inside Particles properties, like so: ![Particles_New.jpg](https://archive.blender.org/developer/F59265/Particles_New.jpg) **Advantages** - Consistency with other areas of Blender - The large button draws attention to the main task
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @billrey

Added subscriber: @billrey

Added subscribers: @JonathanWilliamson, @brecht

Added subscribers: @JonathanWilliamson, @brecht

Agree, we should have this.

Agree, we should have this.
Andrew Buttery self-assigned this 2013-12-31 03:17:49 +01:00

Hi I would like to have a go at coding this if no one else objects...

  • andrew
Hi I would like to have a go at coding this if no one else objects... - andrew

Sure, go ahead.

Sure, go ahead.

Agreed this is needed. I might even suggest taking it a bit further and making the slot behavior for particles be the same as materials. For example, the behavior when pressing the + button.

In materials the + adds a slot. In particles it adds a new particle system, making it impossible to add a new empty slot (because you may want to use an existing particle system).

Agreed this is needed. I might even suggest taking it a bit further and making the slot behavior for particles be the same as materials. For example, the behavior when pressing the + button. In materials the + adds a slot. In particles it adds a new particle system, making it impossible to add a new empty slot (because you may want to use an existing particle system).

OK, had a look at this (and learnt a lot along the way...)

caveat: this is the first lot of serious programming I've done in 15 years and so I may make a few stupid statements along the way...

IMHO:
It's not as easy as it looks as by default when Blender opens there is a material and a texture for the cube and so there are values for object.active_material and object.active_material.active_texture which which are used by the Materials context and Texture context to pass to the 'C' Template_ID() function which then triggers the relevant draw functions depending on what information has been passed.

The same does not exist for Particle Systems. You can access object.particle_systems.active but if particle_systems = None then Template_ID() throws an error as the .active part does not have a valid pointer (i.e. there is nothing for it to work with).

BTW: The same error occurs if you try to access object.current_material.current_texture when you have deleted all materials. The texture context UI handles this situation by removing the material button above the texture list until at least one material slot has a material so a user cannot cause this error to occur.

Even though object.particle_systems = None, if you try to pass object.particle_systems to Template_ID() it errors as this is all the particle systems linked to the object (a "collection") not an individual particle system. Template_ID does not like collections...

So Options:

  1. Live with it as it is today...

  2. Simplest way is to extend the Python API to create object.active_particle_system and which would return the active particle system name or None if there aren't any. A few small changes in the properties_particles.py and some doc update. This may take me a while as it will be all new ground...

  3. Go with Jonathan's suggestion and implement particle slots. Off the top of my head I think would involve multiple Python API changes; larger changes to properties_particle.py; much doc update; updating the startup.blend file to have one empty slot to begin with and many other things that I'm sure will will jump up and bite me... ;)

  4. Mess around with Template_ID() so it can handle collections being passed to it that = None. I really think this is a bad idea as there would be a high potential to break something and tries to shove too much into one function...

I think #2 would be a good start but happy to give #3 a go if that is what we want...

 - andrew
OK, had a look at this (and learnt a lot along the way...) caveat: this is the first lot of serious programming I've done in 15 years and so I may make a few _stupid_ statements along the way... IMHO: It's not as easy as it looks as by default when Blender opens there is a material and a texture for the cube and so there are values for object.active_material and object.active_material.active_texture which which are used by the Materials context and Texture context to pass to the 'C' Template_ID() function which then triggers the relevant draw functions depending on what information has been passed. The same does not exist for Particle Systems. You can access object.particle_systems.active but if particle_systems = None then Template_ID() throws an error as the .active part does not have a valid pointer (i.e. there is nothing for it to work with). BTW: The same error occurs if you try to access object.current_material.current_texture when you have deleted all materials. The texture context UI handles this situation by removing the material button above the texture list until at least one material slot has a material so a user cannot cause this error to occur. Even though object.particle_systems = None, if you try to pass object.particle_systems to Template_ID() it errors as this is all the particle systems linked to the object (a "collection") not an individual particle system. Template_ID does not like collections... So Options: 1. Live with it as it is today... 2. Simplest way is to extend the Python API to create object.active_particle_system and which would return the active particle system name or None if there aren't any. A few small changes in the properties_particles.py and some doc update. This may take me a while as it will be all new ground... 3. Go with Jonathan's suggestion and implement particle slots. Off the top of my head I think would involve multiple Python API changes; larger changes to properties_particle.py; much doc update; updating the startup.blend file to have one empty slot to begin with and many other things that I'm sure will will jump up and bite me... ;) 4. Mess around with Template_ID() so it can handle collections being passed to it that = None. I really think this is a bad idea as there would be a high potential to break something and tries to shove too much into one function... I think #2 would be a good start but happy to give #3 a go if that is what we want... - andrew

OK - further discoveries starting with a wrong tool tip.

undefined

This should read Browse Particle Settings to be linked. Brecht I have submitted a .diff this morning to fix this. I believe it is in the right format this time.

Moving on... I think some of the confusion may be coming from assuming the IDBlock browser/editor for the particle settings relates to the UI list with the particle systems. As in:

undefined

If we were to follow the same setup as a material then it should look like this when you have created a particle system and a particle settings... perhaps a way to think of it is a particle system is like a material that can have only one texture (the particle settings)...

undefined

An alternative is to have this:

undefined

I think we should avoid setting it up so that when there are no particle systems that the IDblock browser/editor is to create a Particle System and when one is created the IDBlock browser/editor changes to Particle Settings... which is basically what was proposed initially by William.

In any option I still have to get the IDBlock browser/editor working for the Particle Systems (I don't think it exists at the moment) so I'll keep working on that...

 - andrew
OK - further discoveries starting with a wrong tool tip. ![undefined](https://archive.blender.org/developer/F60220/undefined) This should read Browse Particle Settings to be linked. Brecht I have submitted a .diff this morning to fix this. I believe it is in the right format this time. Moving on... I think some of the confusion may be coming from assuming the IDBlock browser/editor for the particle settings relates to the UI list with the particle systems. As in: ![undefined](https://archive.blender.org/developer/F60244/undefined) If we were to follow the same setup as a material then it should look like this when you have created a particle system and a particle settings... perhaps a way to think of it is a particle system is like a material that can have only one texture (the particle settings)... ![undefined](https://archive.blender.org/developer/F60254/undefined) An alternative is to have this: ![undefined](https://archive.blender.org/developer/F60256/undefined) I think we should avoid setting it up so that when there are no particle systems that the IDblock browser/editor is to create a Particle System and when one is created the IDBlock browser/editor changes to Particle Settings... which is basically what was proposed initially by William. In any option I still have to get the IDBlock browser/editor working for the Particle Systems (I don't think it exists at the moment) so I'll keep working on that... - andrew

Particles systems are not ID blocks and should not have an ID block browser. They can't be shared between objects so it doesn't make sense to choose them, you only have a list of them on an object.

The way I imagined this working is that you would have a object.active_particle_settings property, that when you set it to a value and there is no particle system, it creates a particle system, the same way it creates a material slot when you assign a material. It wouldn't be an actual property in the C struct, rather just an RNA property with get/set function that reads from or creates particle systems.

About @JonathanWilliamson's suggestion of creating an empty particle system when you press (+), we could do this but I think it would cause some user confusion and implementation difficulties. An empty material slot works ok but an empty particle system is problematic, it's much more than just a slot and doesn't function without one.

Particles systems are not ID blocks and should not have an ID block browser. They can't be shared between objects so it doesn't make sense to choose them, you only have a list of them on an object. The way I imagined this working is that you would have a object.active_particle_settings property, that when you set it to a value and there is no particle system, it creates a particle system, the same way it creates a material slot when you assign a material. It wouldn't be an actual property in the C struct, rather just an RNA property with get/set function that reads from or creates particle systems. About @JonathanWilliamson's suggestion of creating an empty particle system when you press (+), we could do this but I think it would cause some user confusion and implementation difficulties. An empty material slot works ok but an empty particle system is problematic, it's much more than just a slot and doesn't function without one.
Author
Member

@brecht:

Particles systems are not ID blocks and should not have an ID block browser. They can't be shared between objects so it doesn't make sense to choose them, you only have a list of them on an object.

Hmm.. You can share particle systems between objects. If you create a particle system called 'Fu' on Object A, you can pick the same 'Fu' particle system in Object B.

The confusing thing is that the name of the particle system is not reflected in the Particle system slot list. It currently works different from materials where the name of the material is reflected in the slot list too.

I think we should simplify this, at make particles work like materials. There's no need to be able to rename slots different than particle system data.

@brecht: >Particles systems are not ID blocks and should not have an ID block browser. They can't be shared between objects so it doesn't make sense to choose them, you only have a list of them on an object. Hmm.. You *can* share particle systems between objects. If you create a particle system called 'Fu' on Object A, you can pick the same 'Fu' particle system in Object B. The confusing thing is that the name of the particle system is not reflected in the Particle system slot list. It currently works different from materials where the name of the material is reflected in the slot list too. I think we should simplify this, at make particles work like materials. There's no need to be able to rename slots different than particle system data.

No, those are particle settings.

Some things can be shared, but edited hair, vertex groups, point cache, seed and a few other things are part of the particle system only, not the particle settings. So you can have the same particle settings multiple times on one object in different variations.

No, those are particle settings. Some things can be shared, but edited hair, vertex groups, point cache, seed and a few other things are part of the particle system only, not the particle settings. So you can have the same particle settings multiple times on one object in different variations.
Author
Member

@brecht: Ok, so it's like half the stuff in Particles it attached to the particle 'datablock', but the other half it attached directly to the object data?

That's pretty confusing :)

Anyway, we could solve it by removing the 'Name' field (Now we have the ability to rename via double click directly in lists), and then just putting the 'Settings' field underneath with a New button, like so:

Screen_Shot_2014-01-02_at_21.47.10_1.png

@brecht: Ok, so it's like half the stuff in Particles it attached to the particle 'datablock', but the other half it attached directly to the object data? That's pretty confusing :) Anyway, we could solve it by removing the 'Name' field (Now we have the ability to rename via double click directly in lists), and then just putting the 'Settings' field underneath with a New button, like so: ![Screen_Shot_2014-01-02_at_21.47.10_1.png](https://archive.blender.org/developer/F60614/Screen_Shot_2014-01-02_at_21.47.10_1.png)

Hi,

  1. This mornings update... getting there very slowly. But we are getting somewhere. Have added object.active_particle_settings... and when I use it for the Template_ID I get this (the world labels are some debug messages for me):

undefined

Need to work out why it is totally Disabled...

  1. Speaking of disabled - does anyone know why you can't delete a Particle Setting? The screen shots shows the X in the IDBlock browser as disabled...

undefined

  1. William, I believe the removal of the particle system name field change has already occurred - as you can see from screen shots it doesn't appear in my development builds (last updated 2 Jan). Though it would be good if someone could confirm this in case I've deleted it accidentally...
Hi, 1. This mornings update... getting there very slowly. But we are getting somewhere. Have added object.active_particle_settings... and when I use it for the Template_ID I get this (the world labels are some debug messages for me): ![undefined](https://archive.blender.org/developer/F60790/undefined) Need to work out why it is totally Disabled... 2. Speaking of disabled - does anyone know why you can't delete a Particle Setting? The screen shots shows the X in the IDBlock browser as disabled... ![undefined](https://archive.blender.org/developer/F60792/undefined) 3. William, I believe the removal of the particle system name field change has already occurred - as you can see from screen shots it doesn't appear in my development builds (last updated 2 Jan). Though it would be good if someone could confirm this in case I've deleted it accidentally...

You can't delete Particle Settings because a Particle System can't work without them, and generally datablocks don't have a delete button, only an unlink button.

You can't delete Particle Settings because a Particle System can't work without them, and generally datablocks don't have a delete button, only an unlink button.

OK, spent some time on the weekend trying to un-disable the particle setting ID Browser without any success. I suspect that until a particle system exists on the object particle settings will be disabled. Clearly the two are very closely linked and you can't really create/delete one without the other.

So, rather than spend more time chasing my tail here is a solution:

undefined

Unlike William's mock-up it doesn't have the particle setting browser icon on the the left of the button. In a way just having the New button is really correct as you aren't adding particle settings - you are adding a particle system (as per the tooltip). I have checked that the translations are working as well.

I don't think we are going to get much better than this in the short term, so I'll submit a .diff for this change.

 - andrew
OK, spent some time on the weekend trying to un-disable the particle setting ID Browser without any success. I suspect that until a particle system exists on the object particle settings will be disabled. Clearly the two are very closely linked and you can't really create/delete one without the other. So, rather than spend more time chasing my tail here is a solution: ![undefined](https://archive.blender.org/developer/F62499/undefined) Unlike William's mock-up it doesn't have the particle setting browser icon on the the left of the button. In a way just having the New button is really correct as you aren't adding particle settings - you are adding a particle system (as per the tooltip). I have checked that the translations are working as well. I don't think we are going to get much better than this in the short term, so I'll submit a .diff for this change. - andrew

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#37998
No description provided.