The video script for those who likes to read:

Hello! In this video, I am excited to present to you the new version of NeutrinoParticles Editor, where effects now operate with full GPU acceleration. This means that both updating and rendering are fully executed on the device’s GPU, freeing up the CPU for other tasks. Most of this video will focus on the differences between this editor and the previous version, where effects were updated on the CPU.

So, in short, this is the same editor that works on Windows, Linux, and Mac OS, but it has:

• A revamped internal renderer, with all effects now operating with full GPU acceleration.
• A new approach to particle generation and a revised set of generators for the Emitter Scheme.
• Updated blending modes.
• Updated particle sorting modes.
• The ability to export effects only as GPU files (shaders), which are compatible only with GPU renderers and won’t work with previous versions of renderers.
• A new full-screen bloom effect, where colors brighter than one start to glow.

Now let’s take a closer look at each of the changes.

In the preview window, you can immediately see the effect running with full GPU acceleration. This new technology was developed specifically for NeutrinoParticles and has no analogs, as it can run on any device—desktops, mobile devices, and even browsers, including mobile browsers. This technology allows using up to 100 times more particles in effects compared to versions where updates happen on the CPU. [For example, in this effect, you currently see 500,000 particles running on a laptop with an integrated GPU. We can easily increase the count to 1 million, and the effect will still run smoothly.] The maximum number of particles you can use in projects depends on the target devices. In mobile browsers, this can range from 5,000 on very old devices to 400,000 on the latest models. Therefore, it’s best to group devices and create different effects with varying complexity for each group.

The particle generation system has been changed. Now, all rates in the generators are specified as a percentage of the emitter’s capacity. So, if the rate is 50% per second for an emitter with a maximum of 200 particles, that will be 100 particles per second. This is designed to encourage designers to be more mindful of the maximum number of particles in an emitter, as memory is allocated for all particles, and even dead particles consume some computational power. An additional benefit of this approach is that by changing just one parameter, you can adjust the intensity of the effect without needing to change the emitter’s capacity.

There are now four types of generators available:

• GenApproxRate - generates particles with a natural irregularity and an approximate rate. You can also change the rate during the effect's runtime.
• GenApproxDistance - similar to the previous one, but generates particles based on the emitter’s traveled distance.
• GenEvenPeriodic - generates particles uniformly but has some rate restrictions. The total generation period must be greater than the maximum lifetime of a particle in the emitter.
• GenApproxManual - generates a specified number of particles at specific times set by the designer.

Let’s take a closer look at each of them.

By default, new effects use the GenApproxRate generator. It has a corresponding section in the Emitter Guide. This generator produces particles irregularly, creating a natural variety in generation. [If we change the total particle count in the emitter, you’ll be able to see this irregularity.] The advantage of this generator is that you can change the rate during the emitter's lifetime. There is a time limit available, but no limit on the number of bursts. This generator is well-suited for large numbers of particles or when random deviations in rate and irregularity are needed.

The second type of generator, GenApproxDistance, is very similar to the first in terms of characteristics but generates particles based on the distance traveled by the emitter. It also has a section in the Emitter Guide. It’s useful for creating particle trails behind moving objects or other particles. The rate for this generator is set as the distance the emitter must travel to generate 100% of the particles relative to the emitter’s capacity.

The following two generators are currently only available for the Emitter Scheme and do not have sections in the Emitter Guide.

GenEvenPeriodic is a generator that uniformly generates particles at a specific period. It offers a rich set of features, including time and burst limits, a delay before starting generation, and bursts where multiple particles are emitted at once. However, there are restrictions: all these parameters must remain unchanged during the emitter’s runtime, or unexpected behavior may occur. Additionally, the rate must be set so that the total generation period of all particles in the emitter exceeds the maximum lifetime of a single particle in the emitter. This might sound complex, but it’s actually quite straightforward. Particles are emitted sequentially: first, second, third, and so on, until the last one in the emitter. Then the first one is emitted again, and by that time, it must already be dead to be generated again. If it’s still alive, that burst will be skipped. To make calculations easier, there’s a "Particle max. life" field where you specify the maximum particle lifetime for the generator to consider, and the rate is automatically recalculated. [For example, if we change the particle lifetime to 1 second, we also need to recalculate the generator rate accordingly.] Note that this field does not define the actual particle lifetime; it’s just an auxiliary field for calculating the correct generator rate.

Similarly, the GenApproxRate generator has an auxiliary field that recalculates the average particle lifetime based on the rate, ensuring that all particles are used to their full potential in the emitter.

The last generator available is GenApproxManual. It allows you to manually specify when and how many particles to emit. You can set a working period with a set of bursts, indicating the local time within the period and the percentage of the emitter’s capacity to be emitted. You can also loop these periods and specify the interval between them. Additionally, you can set a delay before the first period.

[Right now, the particle lifetime is set to 1 second. Let’s make the working period 2 seconds with three bursts in the first second: 10%, 30%, and 60% of the emitter’s capacity. This will result in approximately 100% of the particles being emitted. Now we’ll raise the emitter’s capacity to 100 particles and set the particles to shrink during their lifetime. You can clearly see these three bursts, with the first having fewer particles, followed by increasingly larger bursts. All of this repeats every 2 seconds. We can also add a 1-second interval between periods, making the total cycle 3 seconds.]

As for blending modes, they are now set for the emitter rather than the constructor as before. The available modes remain the same: Normal, Add, and Multiply.

Particle sorting now works at the effect level and is also a parameter of the effect. There are two modes available: no sorting and depth sorting. When depth sorting is selected, the blending mode is automatically switched to Normal, as there’s no point in using this sorting mode with other blending modes.

Exporting in this version of the editor is only available as GPU shaders (codenamed GPU33, from OpenGL 3.3). These shaders can only be used in compatible GPU renderers, which you can learn more about on the website. Currently, there’s a renderer available for PIXI.js v7 and pure WebGL 2.0.

The last major change in the editor is the full-screen bloom effect for pixels brighter than 1. For example, if we multiply the default white color by 3, particles start to glow, especially in clusters. This effect works only in the Preview window of the editor. To add it to your application, you’ll need to modify the render pipeline so that the entire scene is rendered into a texture, which is then drawn to the screen with the bloom effect. Examples of how to add this effect can be found in the renderer documentation. If your application doesn’t use the Bloom effect, you should disable it in the project settings so that what you see in the Preview window matches what will be in the application.

These are all the differences in the new GPU version of the editor.

It’s time to try GPU effects. Download, create, and give us feedback—we’re always happy to hear your thoughts!