You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project
Currently visual particle shaders have two variants, a "normal" and a "custom" variant toggled by a "custom" checkbox on top of the shader graph.
2024-09-17_07-20-48.mp4
This is problematic for various reasons:
The graphs seem to be completely disjoint. if you build a larger shader graph in the non-custom variant and then notice you need the custom output node (because you want to write to CUSTOM), you need to start again or at least copy all your nodes over hoping that nothing breaks.
The output node of the custom variant only has Transform while the non-custom variant has Position, Scale, Rotation, but no Transform because it builds the transform for you. If you decide to switch you will need to change implementation to build a transform from inputs or inputs from a transform.
The custom checkbox has no help text and it's not immediately obvious what it does and why it is there which is confusing to the user.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Only keep the "Custom" variant because it is a superset of the non-custom variant. Provide two nodes that can create 3D/2D transforms from Position, Scale ,Rotation, etc. which make it easy to create a transform without having to build a lot of VectorXCompose nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The "custom" checkbox will disappear and we get a single output node for both use cases. E.g. for the "Start" function it could look like this.
We also have two new MatrixComposeXD nodes which can make a 2D/3D transform from inputs and put the numbers at the correct position in the matrix (the current TransformCompose node only gives us access to the raw transform matrix and requires the user to know about how the matrix is built up internally).
For migration, a migration script could detect use of the non-custom variant and automatically insert a MatrixTransformXD node before the output node and then reconnect all the connectors going into Position, Rotation, etc. into the new MatrixTransformXD node. The placement of this new node will probably not be ideal but this is something that doesn't break the shader and can be fixed by a human afterwards.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It can be worked around, one can choose to solely use the "Custom" flow and build the custom matrix compose nodes themselves using the extension point to build custom nodes.
Is there a reason why this should be core and not an add-on in the asset library?
I think the current behaviour is confusing to the user and having a simplified flow would both reduce implementation complexity in the engine and make the feature easier to use, so it's a win-win having this in core.
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
Any game using particle shaders
Describe the problem or limitation you are having in your project
Currently visual particle shaders have two variants, a "normal" and a "custom" variant toggled by a "custom" checkbox on top of the shader graph.
2024-09-17_07-20-48.mp4
This is problematic for various reasons:
CUSTOM
), you need to start again or at least copy all your nodes over hoping that nothing breaks.Describe the feature / enhancement and how it helps to overcome the problem or limitation
Only keep the "Custom" variant because it is a superset of the non-custom variant. Provide two nodes that can create 3D/2D transforms from Position, Scale ,Rotation, etc. which make it easy to create a transform without having to build a lot of VectorXCompose nodes.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The "custom" checkbox will disappear and we get a single output node for both use cases. E.g. for the "Start" function it could look like this.
We also have two new MatrixComposeXD nodes which can make a 2D/3D transform from inputs and put the numbers at the correct position in the matrix (the current TransformCompose node only gives us access to the raw transform matrix and requires the user to know about how the matrix is built up internally).
For migration, a migration script could detect use of the non-custom variant and automatically insert a MatrixTransformXD node before the output node and then reconnect all the connectors going into Position, Rotation, etc. into the new MatrixTransformXD node. The placement of this new node will probably not be ideal but this is something that doesn't break the shader and can be fixed by a human afterwards.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It can be worked around, one can choose to solely use the "Custom" flow and build the custom matrix compose nodes themselves using the extension point to build custom nodes.
Is there a reason why this should be core and not an add-on in the asset library?
I think the current behaviour is confusing to the user and having a simplified flow would both reduce implementation complexity in the engine and make the feature easier to use, so it's a win-win having this in core.
The text was updated successfully, but these errors were encountered: