Particles
These settings affect the calculation and display of particles created with the particle simulation system introduced in Cinema 4D 2024.4. Particle systems that use legacy Emitters or components of the XPresso-based Thinking Particles system are not affected by these settings.
This also has to do with the fact that only with the new particle system do you also have the option of having this simulated via the GPU, which is usually accompanied by extreme speed advantages. Therefore, when using the new particles, please also note the CPU and GPU settings in the Scene tab of the Simulation Scene presets.
Here you will find an option list of the most important properties of particles, such as their color, radius, speed or orientation. Only the properties activated here are actually calculated and evaluated within the simulation. This also means that, for example, conditions or modifiers that access or influence these properties may no longer have any effect if the corresponding option in this list has been deactivated. The advantage of properties that are no longer used is that no memory needs to be reserved for them, which can be an advantage for simulations with a large number of particles.
If it is unavoidable for the function of a simulation at some points to have to calculate with a property switched off here, these default values are used as a substitute:
- Properties that are described by floating point values, such as age, radius or distance traveled, are interpreted with the value 0.
- Properties that can only be described by vectors, such as speeds or colors, are interpreted with the zero vector or the 4D vector (0,0,0,0).
- Properties based on quaternions, such as the alignment of the particle axes, are set to the standard unit qu.
- Group links are automatically set to the root group. The particles are thus interpreted as groupless.
Note that there are also properties that are interdependent, such as speed and distance traveled. In this case, deactivating the speed automatically deactivates the calculation of the distance traveled.
The options can also be switched on and off while a simulation is running. When switching off, the corresponding memory area is released; when switching on, the memory area is reserved again and filled with the corresponding default values of the property.
In order to ensure that the particle system functions in every case, not all properties can be deactivated manually. The properties for the position, the unique ID of the particles and the group are therefore always active.
Particles can also be given their own additional values via this Add Custom property button, which can be read or written using these modifiers and conditions:
- Base emitter (write only)
- Mesh emitter (write only)
- Spline emitter (write only)
- Reproduce emitter (write only)
- Condition (readout only)
- Color Mapper modifier (read only)
- Data Mapper modifier (read and write)
- Math modifier (read and write)
- Switch Group modifier (write only)
- Align modifier (write only)
- Blend modifier (read and write)
- Flock modifier (write only)
- Hunter Prey modifier (write only)
- Collide modifier (write only)
- Spline Follow modifier (write only)
- Pyro Advect modifier (write only)
- Stick modifier (writing only)
- Surface Attract modifier (write only)
- Particle Node modifier (readout only)
It should be noted that custom properties also have a data type that should be compatible with the selected operation or function of the respective modifier or condition. A property defined as a particle group link can, for example, only be read within a Condition and compared there with another particle group, for example.
Other properties based on floating point values, on the other hand, can be used in a more versatile way and can be interpreted, for example, as radius, airspeed or age.
The same applies to vectors, which can be used to describe a color, the direction of flight or a position, for example.
However, it is also the case with Node circuits that attempts are made to convert different data types in a meaningful way when exchanging data. This means that integer values can also become floating point values or, for example, a vector. Depending on the type of conversion, however, this can also result in value changes, e.g., when a floating point value is converted to a bool value or a vector is converted to an integer number. It therefore generally makes sense to select the data type so that it corresponds to the values that you want to manage with this user property.
When creating a new particle property, various setting options appear, as shown in the following illustration:
In the left-hand column you will find an option to switch the respective user property on or off. Conditions or modifiers that access a deactivated property can then no longer function and are deactivated.
The Name text field to the right of the activation option contains the name of the property. You can enter this yourself here. Note, however, that some property names are already in use, such as color, radius or position. These names can therefore not be used again.
The name of a user property can also be changed at a later date, if necessary. The capitalization of a name is irrelevant for subsequent use. However, when subsequently changing names, please note that this change must also be made manually wherever this variable is used within emitters, conditions or modifiers.
Use the Type menu to select the data type for your user property. The following data types are available and must be selected to match the values that you want to save and process with the corresponding property. The values transferred to the user properties from the particle system are not converted and therefore always expect the same data type with which this data is also used within the particle system.
- Integer: This can only be used to manage integer values, such as those used to count collisions on a Collide modifier.
- Index: Each particle can be identified by an integer number, the so-called ID or index. This data type is specifically intended for storing this information.
- Boole: This data type only knows two states, true(i.e., true) and false (i.e., false). This makes it possible, for example, to save whether a particle has just been born or should be deleted. For example, the Base emitter allows you to save the Born status of the particles in a user property that uses this Boole data type.
- Group linking: This can be used to save particle groups. For example, the Switch Group modifier offers an option to save the previous group of a particle in this data type before changing it. A Condition can be used to read a group link.
- Floating point: This is a floating point value without a unit. This can be used, for example, to save a color component or whenever no value is to be saved with a unit.
- Floating point - meters: This floating point number can represent a radius or a distance covered, for example, and is automatically displayed with a distance unit such as meters, centimeters or inches, depending on your units defined from the Preferences settings. Because a distance unit is included, this value is automatically subject to automatic adjustment by the project scaling, for example.
- Floating point - degrees: This floating point number is intended for storing individual angles.
- Floating point - time: This floating point number is intended for storing times and time intervals, such as the Age or Lifetime properties.
- Floating point percentage: This floating point value is intended for passing on percentage values, such as the Age Percentage property.
- Vector: This is a 3D vector without a unit. These can be UVW coordinates, for example.
- Vector - Meter: This is a 3D vector with a distance unit that can be used, for example, to transmit positions or flight directions. Because a distance unit is included, this value is automatically subject to automatic adjustment by the project scaling, for example.
- Color A: This is a 4D vector format that can be used to manage the RGB color values and the alpha value.
- Quaternion: This special format is for storing the orientation of a particle system.
On the various emitter objects (base emitter, spline emitter, Mesh emitter and Reproduce) you will find a list of all user properties created with corresponding color or value fields. You can also assign individual start values to all properties so that, for example, a color property directly receives the desired color value. All subsequent conditions and modifiers can then continue to work directly with these initial values of the properties. This also ensures that all user properties are always defined and contain a value.
By activating the Auto option, an automatic change of the user property can be activated. However, this is only available for the data types integer, bool and Floating Point time. The saved Integer value is automatically increased by 1 in each simulation image. With a floating point time value, an increase by the time period elapsed per simulation image (delta time) takes place in each simulation image. The boole data type is automatically reset to 0 or false in each new simulation screen.
Finally, the Remove button also allows you to delete a user property that is no longer required. However, all conditions and modifiers that used this property will then no longer work and must be reconfigured. To temporarily deactivate individual properties, you can also deactivate the corresponding Used options instead.
Additional user properties can be added at any time using the Add custom property button, which can then be used by the emitters, conditions and modifiers mentioned above.
Note that the user properties for the particles are always managed by the active simulation scene of your simulation. You can therefore also add these properties directly to a simulation scene object (see Simulate menu in Cinema 4D) and then only make them available to the subordinate simulation elements there. The normal Scene Presets (see Edit menu in Cinema 4D) and their particle simulation presets are responsible for all particle elements that are not subordinate under a separate Simulate Scene object.
The custom particle property values can also be used directly as maps, e.g., to control colors or the emission on a Pyro emitter tag. Here you will find explanations and examples.
Usage example for user properties
Some emitters and modifiers already offer a selection of particle properties that can be passed directly to user properties. For example, you will find an option to write the UVW coordinates of the emitter shape in the output area on the Base emitter. Let's use this to color the particles.
To do this, first create a new user data property for particles in the Simulation > Particles area of the scene presets by first clicking the button for Add custom property and then entering e.g., EmitterUVW in the name field. Select Vector as the type, as we are dealing with three values without a unit for the UVW coordinates.
Then create a Base emitter and use it to activate the cube as the emitter shape, for example, to create U, V, and W components. With 2D emitter shapes, the W component would otherwise always be 0. In the output settings of the emitter, you will find two data sets that can be transferred from the particles to your own particle user data. We activate the option for the UVW coordinates there. To the right of the text input field for the name of the user property, you will find an arrow icon which you can use to open a list of all available variables (see orange frame in the following image). Simply select your EmitterUVW variable from this list. Alternatively, you can also enter the name EmitterUVW directly in the text field.
From now on, the emitter will automatically write the UVW coordinates of each newly created particle to the EmitterUVW user property. We can then read these out using Math modifiers, for example, and pass them to any other property of the particle, such as the color of the particle. The following figure illustrates this.
Using three Math modifiers, we transfer the stored U, V and W components (since the UVW values were stored as a vector, these can be extracted from the X, Y and Z components of the vector) to the R, G and B components of the particle colors. Also pay attention to the multiplier of the Math modifiers, as this is set to 0 by default. To convert UVW coordinates directly to RGB values, this multiplier should be set to 1. The right half of the figure above shows the result.
The particles will be calculated internally with the animation frames. This can lead to some problems. Think, for example, of very fast-flying particles that need to be checked for collisions with thin objects. Viewed in the animation, a particle can still be in front of the object in frame 59 and already behind it in frame 60. The division into full animation frames therefore will not always work reliably enough.
For this reason, you will find the Continuous option on the particle Emitters, for example, which also generates particles internally in the period between animation frames. Otherwise, the effect you can see in the following video will occur. On the left you can see an Emitter with fast particles that are created with the Continuous option disabled. Gaps between the particles will become visible there. To the right, an Emitter with the Continuous option enabled can be seen for comparison.
This Substeps value can be used to control the calculation cycles of the particles even if they have already been generated and are subject to forces and Modifiers. This defines the additional calculation steps for particles within an animation frame. An increase in the value will lead to a mathematically and physically more precise behavior, with the acceptance of a correspondingly longer calculation time per animation frame.
Field Sampling Variance[0..1000%]
Particles can be influenced by fields, e.g., within Force objects, Conditions or Modifiers. To do this, samples of the values of the fields must be taken along the particle trajectory. Particularly in the case of fast-moving particles, it can be useful in such cases to be able to adapt or increase these samples specifically for fields. The effect can be seen as an example in the following video. There, particles are guided through a cube-shaped Random field, which is used within a Field condition to cause particles to bend sideways. Both emitters use the same settings and fields. The only difference is that a Field Sampling Variance of 0% is used on the left and 100% on the right. It can be clearly seen that more particles are sorted out on the right side of the field and turn off to the side. The scanning of the Random field is more precise there.
Here you can define the calculation accuracy of the simulation scene. As a rule, you will use 32 bits here. A lower bit depth can lead to mathematical rounding errors, which can cause the behavior of the particles to deviate from the expected result. However, a low bit depth can also have advantages, e.g.,, the storage of caches for large particle systems. This means that these files can be kept somewhat smaller compared to the same simulation with 32-bit precision.
Initial Capacity[256..2147483647]
A buffer size can be selected here, which will be used internally as memory for replaying the particle simulation. The defined value will be automatically increased internally to the next higher power of two.
This setting influences the optimization of the particle data in order to enable smoother calculation and playback and at the same time optimize the memory requirements. For example, particles often have to be removed from the simulation once their lifetime has expired. The corresponding memory areas must be cleared and released again.
The percentage value represents the ratio between deleted and active particles at the end of each animation frame (particles that have just died/particles that are still active).
If this ratio is smaller than the threshold value, the memory area for the particle simulation will be optimized.
The particle simulation can be specially prepared for processing by the GPU and then often calculated correspondingly faster compared to the calculation on the CPU. You make this decision in the Scene tab of the Simulation Scene settings. However, this can also lead to disadvantages, as not all Generators that can then access the points in a Particle Group, for example, will also be executed on the GPU. In such cases, the particle data must also be copied back from the GPU to the normal working memory to which the CPU has access.
This step is carried out automatically in the Auto setting in order to keep the Particle Group object as up-to-date as possible, e.g.,, when a Generator accesses it. There may be situations where there are problems with this automatic update. In these cases, select On to force an update of the Particle Groups of the particle simulation for each animation frame. In the Off setting, the Particle Groups will not be updated.
This setting is only relevant for the calculation on the GPU. When using the CPU, the Particle Groups will automatically be updated in each animation frame.
This function is very helpful for directly recognizing which particles are contained in which Particle Group even without changing the display of the particles when changing groups. You can see a simple example of this in the following image. There, particles were moved into different groups based on their percentage age across different conditions. Since all particles retain their color and size, it would be difficult to identify which particles are managed in which of the three groups.
However, as can also be seen in the illustration, all particle representations that are not contained in the currently selected Particle Group will now be desaturated. This makes it immediately clear that in this example, only the end of the particle stream will be contained in the third Particle Group.
These settings only affect particles that have not been assigned to a group. This can happen, for example, if you simply delete a group already filled with particles in the Object Manager or simply remove a group link from one of the Emitter objects, for example.
Particles that do not belong to a group will not be automatically deleted, but can no longer be specifically addressed via Forces, Conditions or Modifiers, for example. It is also no longer possible to assign a Redshift Object tag or link these particles to Generators or Fields. Groupless particles can also not be rendered.
For this reason, an unique appearance and an unique color scheme can be defined here for these groupless particles so that they immediately catch the eye in the Viewports.
Particles that do not belong to any of the Particle Groups in the scene will only be displayed if this option is active.
Here you can select how the particles are to be displayed in the views. Various complex shapes are available, all of which can be individually adjusted in the display size using the separate Draw Size value:
- Points: The particles will be displayed as points or slices.
- Ticks: The particles awill be re displayed as four-point stars.
- Arrows: Arrow-shaped representations will be used, which start at their wide end at the position of the particles. The arrowheads will always point in the direction of flight of the particles and the length of the arrows represents the speed of a particle relative to its neighbors.
- Lines: This mode is similar to the Arrow display in terms of information content. Instead of arrows, however, simple lines will be used here that have a darker and a lighter section. The darker end of the line starts at the position of the particles and points with its lighter end in the direction of the particles' flight. Here, too, the respective line length represents the relative speed of the particles. Particles with short lines will be slower than particles with longer lines.
- Handles: Axis systems whose origin lies on the position of a particle will be drawn in here. The axis directions reflect the orientation of the respective particle axis system.
Particles have a Radius property that can be used, for example, to define the size of the particle display during rendering. This property can also be displayed as a circle by activating this option. This circular representation always corresponds exactly to the Radius property of the particles and cannot be adjusted individually by using the Font Size setting.
This value can be used to define the display size of the particles individually. Only the optional radius display will not be affected by this, as it always shows the exact Radius property of the particles as a circle.
By default, the displayed color of the particles is defined directly by the Emitter of the particles or by special Modifiers, such as the Color Mapper Modifier. However, you can also use this setting to overwrite this color evaluation, e.g.,, to make the group change of particles clearer by using a different color in the views. The following options are available:
- None: The actual color of the particles will also be used for their display in the views. As a rule, this is also the color with which the particles will be rendered. The color of the particles is defined directly by the Emitter when they are created and can then be changed using Modifiers.
- Constant: In this setting, the inherent color of the particles will be suppressed for the display and replaced by the Overwrite Color (Display).
- Direction: The flight directions of the particles will be broken down into X, Y and Z components, which will then become the red, green and blue values of their new display colors. Blue-colored particles mainly fly parallel to the Z-axis, green-colored particles travel in a vertical direction and red-colored particles fly parallel to the X-axis. Mixed colors indicate the corresponding mixing directions.
You can configure your own color for the Constant Overwrite Mode (Display). Click on the color field to open a separate settings dialog with the typical color sliders. Otherwise, you can also click on the small arrow to the left of the color field to open the color sliders and define exact RGB or HSV color values, for example.