-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Add Solid Particle System (SPS) Support to Node Particle Editor #17320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add Solid Particle System (SPS) Support to Node Particle Editor #17320
Conversation
This commit introduces several new blocks for the Solid Particle System (SPS) in the Node Particle Editor, enhancing the particle system capabilities. The following blocks have been added: - SPSMeshSourceBlock: Defines the mesh shape for SPS. - SPSCreateBlock: Creates an SPS with a base mesh. - SPSSystemBlock: Configures the Solid Particle System. - SPSInitParticleBlock: Initializes the update function for a specified range of particles. - SPSUpdatePositionBlock: Updates the position of particles. - SPSUpdateRotationBlock: Updates the rotation of particles. - SPSUpdateScalingBlock: Updates the scaling of particles. - SPSUpdateColorBlock: Updates the color of particles. - SPSUpdateVelocityBlock: Updates the velocity of particles. - SPSPhysicsBlock: Applies physics to particles. - SPSGetParticlePropertyBlock: Retrieves properties of particles. Additionally, the NodeParticleBuildState has been updated to include SPS context and delta time for physics calculations. The editor interface has been modified to accommodate these new blocks, improving the overall functionality and user experience of the particle system editor
This commit introduces several new blocks for the Solid Particle System (SPS) in the Node Particle Editor, improving the functionality and flexibility of the particle system. The following blocks have been added: - SPSMeshSourceBlock: Defines the mesh shape for SPS. - SPSCreateBlock: Creates an SPS with a base mesh. - SPSSystemBlock: Configures the Solid Particle System. - SPSInitBlock: Initializes particles with configurable parameters (position, velocity, color, etc.). - SPSUpdateBlock: Generates update functions for particle properties. Additionally, the connection point types have been updated to reflect the new Solid Particle System structure, and the editor interface has been modified to accommodate these enhancements, improving the overall user experience.
This commit enhances the Solid Particle System by ensuring that the mesh is built and particles are initialized before rendering. The `buildMesh` and `initParticles` methods are now called during the setup process, improving the overall functionality. Additionally, the cleanup process has been updated to properly dispose of the mesh when the system is stopped, ensuring better resource management.
…SystemSet This commit modifies the initialization of the Node Particle System by changing the method from `setToDefaultSPS` to `setToDefault`, aligning it with the updated API and improving consistency in the codebase.
…icleBlock This commit introduces an `isStarted` flag to the Solid Particle System to track its initialization state, preventing unnecessary operations when stopping the system. Additionally, the NodeParticleBlock has been updated to allow multiple connections for input points, improving flexibility. The SPSUpdateBlock has been integrated into various components, enhancing the Node Particle Editor's functionality and user experience.
This commit adds a new internal property `_connectedPoints` to the `NodeParticleConnectionPoint` class, allowing it to maintain multiple connections. The connection and disconnection logic has been updated to handle multiple connections appropriately. Additionally, a new getter method `connectedPoints` has been introduced to retrieve the array of connected points. In the `GraphCanvasComponent`, the connection check has been refined to consider the `allowMultipleConnections` property, improving the connection management logic.
…functionality This commit enhances the Solid Particle System by streamlining the start and stop methods, ensuring proper initialization and cleanup of particles. The ISPSData interface has been updated to enforce required properties for SPS update data, while the SPSCreateBlock now defaults the particle count to 1. Additionally, the Node Particle Editor has been updated to introduce a mode selection feature, allowing users to switch between Standard and SPS modes, improving usability and flexibility in particle system management.
…ate logic This commit simplifies the particle initialization and update processes within the SPSSystemBlock. The logic for creating and managing connected points has been optimized, allowing for a more efficient retrieval of connected values. Additionally, the updateParticle method has been enhanced to directly utilize shape IDs for better performance and clarity. These changes improve the overall functionality and maintainability of the Solid Particle System.
…isposal and multi-connection support This commit updates the SolidParticleSystem to ensure proper disposal of the mesh when stopping the system, enhancing resource management. Additionally, the NodeParticleSystemSet has been modified to support multiple connections for input points, improving flexibility in particle system configurations. A new method, setToDefaultSPS, has been introduced to streamline the setup of Solid Particle Systems, further enhancing usability and functionality.
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
packages/dev/sharedUiComponents/src/nodeGraphSystem/interfaces/portData.ts
Outdated
Show resolved
Hide resolved
|
Building or testing the sandbox has failed. If the tests failed, results can be found here: |
|
Building or testing the playground has failed. If the tests failed, results can be found here: |
|
Graph tools CI has failed you can find the test results at: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/TOOLS/refs/pull/17320/merge/testResults/ |
|
Question for you: How does it integrate with current update nodes that take a particle as parameter? |
|
Ok @Soullnik the more I think about it, the more I struggle to see it working. My main problem is that we cannot share anything with the main blocks. Which blocks will work in both mode? I feel like we are stuffing spa in but it makes not a lot of sense. |
|
Lol sorry I'm thinking too much lol. I think all the nodes working on base types will work still. But all nodes working on particles needs to be hidden. Then it means we need to provide an update node for sps. Same way: update position, etc... |
i will check gradientBlock The second question was about architecture - I had to modify private _systemBlocks: (SystemBlock | SPSSystemBlock)[] = [];This union type works for now, but if we add more particle system types, we'd need: private _systemBlocks: (SystemBlock | SPSSystemBlock | GPUSystemBlock)[] = []; |
…y connection logic This commit streamlines the connection management within the NodeParticleBlock and NodeParticleConnectionPoint classes by removing the support for multiple connections. The `registerInput` method has been simplified, and the logic for handling connected points has been optimized. Additionally, the GraphCanvasComponent has been updated to reflect these changes, enhancing the overall clarity and maintainability of the codebase.
…agement This commit introduces the `unregisterInput` method to the NodeParticleBlock class, allowing for the dynamic removal of input connections. The method handles disconnection and notifies observers of input changes. Additionally, it removes commented-out code from the SPSCreateBlock and refines the input management logic in the SPSSystemBlock, enhancing overall clarity and maintainability of the particle system components.
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
…terface to simplify connection management. This change aligns with recent refactoring efforts to streamline connection logic across the node graph system.
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
I think that works. Other option will be to have a NodeParticleSystemSet |
…zation and update logic This commit removes the `isStarted` flag from the SolidParticleSystem, streamlining the start and stop methods. The ISPSUpdateData interface has been updated to make properties optional, enhancing flexibility in particle updates. Additionally, the SPSInitBlock and SPSUpdateBlock have been refactored to only assign update functions when the corresponding properties are connected, optimizing performance. The SPSSystemBlock has been improved to manage the SolidParticleSystem lifecycle more effectively, ensuring proper disposal and initialization of particles.
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
@deltakosh I’m running into an issue disposing previously created SPS instances. I see that _build inside SPSCreateBlock is called twice for different scenes. What’s the correct way to dispose the previouse SPS associated with the scene? |
…ck and enhance particle configuration This commit introduces the new SPSParticleConfigBlock for configuring particle parameters such as mesh, count, material, and initialization/update blocks. The SPSCreateBlock has been refactored to utilize this new block, streamlining the creation of particles. Additionally, the ISPSData interface has been updated to reflect the new configuration structure, and various blocks have been adjusted to improve their connection logic and overall functionality within the particle system.
- Added support for the `SolidParticleConfig` connection point type in the `BlockTools` class, enhancing the color mapping and type detection logic. - Removed obsolete connection point types (`Camera` and `Function`) to streamline the code and improve clarity. These changes improve the organization and maintainability of the node particle editor's block tools.
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/17320/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/17320/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/17320/merge#BCU1XR#0 |
|
Devhost visualization test reporter: |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU |
|
@deltakosh I think I have completed the basic implementation |
|
Hey there! just fyi that I'm out for a month so please bear with me and I'll review your updates in jan! Thanks a lot for your patience. In the meantime @VicenteCartas can help you in the interim |
|
|
||
| public constructor(name: string) { | ||
| super(name); | ||
| this.registerInput(`config-${this._entryCount - 1}`, NodeParticleBlockConnectionPointTypes.SolidParticleConfig); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we name it MergeBlock maybe? The neme seems off (like we already created the SPS)
| /** | ||
| * Block used to load a node material for SPS | ||
| */ | ||
| export class NodeMaterialSourceBlock extends NodeParticleBlock { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be a block. This could be set by code but not in the editor. We only have things in the editor that we can fully configure. Here there is a texture property but what if my nme has 5 textures?
This block should be removed
| /** | ||
| * Block used to generate update function for SPS particles | ||
| */ | ||
| export class UpdateSolidParticleBlock extends NodeParticleBlock { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to have some kind of parity with the particle mode. So instead of one big chunky Update all block I'd like to have one update per feature (like update position, update velocity, etc..)
| case NodeParticleContextualSources.SpriteCellEnd: | ||
| case NodeParticleContextualSources.SpriteCellStart: | ||
| case NodeParticleContextualSources.SpriteCellIndex: | ||
| case NodeParticleContextualSources.SolidParticleIndex: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need more contextuals like velocity, scaling, rotation.
| /** Mesh */ | ||
| Mesh = 0x8000, | ||
| /** Material */ | ||
| Material = 0x10000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Material should be removed. For mesh icon probably reuse the one from NGE :)
| /** Solid Particle */ | ||
| SolidParticle = 0x2000, | ||
| /** Solid Particle Config */ | ||
| SolidParticleConfig = 0x4000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove config here. The only thing that travels is the SolidParticle
| /** Direction Scale */ | ||
| DirectionScale = 0x0020, | ||
| /** Solid Particle Index */ | ||
| SolidParticleIndex = 0x0021, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See earlier, we need more contextuals
| case NodeParticleContextualSources.Lifetime: | ||
| return this.particleContext.lifeTime; | ||
| case NodeParticleContextualSources.Angle: | ||
| if (this.particleContext instanceof SolidParticle) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe have a boolean at the beginning of the file to avoid checking all the time?
| } | ||
|
|
||
| public setToDefaultSps() { | ||
| this.clear(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one must be far simpler. The default cannot be 2 screens wide like now :)
It must be the bare minimum to get a moving SPS. Plus it forces import of too many blocks so size wise it is not ok
| this._scene.ambientColor = new Color3(1, 1, 1); | ||
| this._camera = new ArcRotateCamera("Camera", 0, 0.8, 4, Vector3.Zero(), this._scene); | ||
|
|
||
| const sunLight = new DirectionalLight("sun", new Vector3(-1, -1, -1), this._scene); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the total particles and update loop strings are not updated in the SPS mode
| ); | ||
| break; | ||
| } | ||
| case PropertyTypeForEdition.String: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that if we remove nodematerial, there is no more need for string (Trying to keep things as simple as possible)
| @@ -0,0 +1,71 @@ | |||
| import * as React from "react"; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be removed
|
I am now looking at this PR. Please ping me here if you have any questions. |


Overview
This PR integrates Babylon.js Solid Particle System (SPS) into the Node Particle Editor, enabling users to create and manage SPS-based particle systems through a visual node graph interface. This brings the power of SPS (instanced rendering, shape-based particles) to the node-based workflow.
Important Note
This is a proposal for discussion and requires future refactoring. The current implementation is created for community discussion as I don't have sufficient knowledge of the node ecosystem architecture. The goal is to gather feedback on the best approach for integrating SPS into the existing node graph system.
Features Added
1. SPS Node Graph Integration
Technical Implementation
Core SPS Blocks:
Usage Example
Current Challenges & Seeking Solutions
1. Multiple Connection Architecture (Incomplete)
Challenge: SPS requires multiple
SPSCreateBlockinputs to oneSPSSystemBlock.Current Implementation:
allowMultipleConnectionsflagconnectedPointsarray to store multiple connectionsNodeParticleBlock.build()to traverse all connected blocksIssues:
Question: What's the best architectural approach for handling multiple input connections in the node graph system?
Questions
Multiple Connections Architecture: What's the best pattern for handling multiple inputs in the node graph system?
SPS Integration: Are there any SPS-specific considerations we should be aware of the implementation?
Future Extensibility: How can we make this system more extensible for other particle system?
The main goal is to bring SPS capabilities to the node-based workflow. Looking forward to feedback on the integration approach and suggestions for better solutions to the identified challenges!