Rework transform align property and promote it to GeometryInstance3D

[QbieShay]

Describe the project you are working on

GodotEngine and VFX.

Describe the problem or limitation you are having in your project

There's one too many ways of doing billboarding right now, and one too many proposal.

This proposal should supersede:

• rotate_y overrides align_y in 3D particle system godot#56068
• Add a Preserve Orientation billboard property #5591
• Rework BaseMaterial3D billboard modes for greater flexibility #3968
• ZBillboard particle align doesn't work with particle material angle godot#49766
• Rethink transform align modes for particles #7634

And complementary to:

• Expose custom vector for all drawable objects #8364

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Billboarding/Transformation (TransformAlign) is promoted as a property of GeometryInstance instead. It enables the following behaviours

1. rotate around a local axis via custom.x (cannot be done in process material)
2. billboard around one axis (normally y, but configurable)
3. billboard but preserve a given axis on screen (so basically project the axis on screen, take the angle, then use it in a regular billboard)
4. normal custom.x driven billboard
5. Choose between camera position billboard or view plane billboard

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Offer the following options on GeometryInstance

• RotateAround: None, X, Y, Z
• BillboardReference: Camera Position, View Plane
• Billboarding: None, 3D, Screen
• RotationSource: None, Custom.x, Custom.y, Custom.z, Custom.w

Previous section cases would be implemented as follows

Case 1.
RotateAround: (any), RotationSource: Custom.x

Case 2:
RotateAround: (any), Billboarding: 3D

Case 3:
RotateAround: Y (assuming we're using a quad), Billboarding: Screen, RotationSource: None

Case 4:
RotateAround: None, Billboarding: Screen, RotationSource: Custom.x

We can also consider adding presets for normal particles, world-particles (align Y + Billboarding3D), trails.

NOTE: these modes will not be on by default unless converted from the particle's TransformAlign property.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It solves inconsistencies in the engine

Is there a reason why this should be core and not an add-on in the asset library?

It solves inconsistencies in the engine

[reduz]

Unlikely from my point of view, it needs to happen on CPU every time the objects are drawn. Additionally, as it happens on CPU, it won't work for particles.

[Calinou]

Unlikely from my point of view, it needs to happen on CPU every time the objects are drawn. Additionally, as it happens on CPU, it won't work for particles.

Billboarding currently happens on the GPU using BaseMaterial3D's billboard property and GPUParticles3D's transform align property. I'm curious why it would need to happen on the CPU. While more flexible, wouldn't it be much slower to do on the CPU when you have large numbers of instances?

[QbieShay]

Sorry, my bad for being unclear in the proposal.

The proposed interface is on a user level. On an implementation level, we should have different implementations depending whether it's a multimesh/particle (here it should happen on the gpu like it already does) and it should happen on cpu only for meshinstance.

[Calinou]

By the way, how would compatibility be handled? Would existing billboard properties remain functional but deprecated? Would they be hidden from the inspector if set to their default value?

[QbieShay]

We can leave them there for now, then hide them from inspector later, i suppose

It will however be a pain with standard material + particle animation ..

[clayjohn]

We discussed this extensively in today's rendering meeting but didn't come to any firm conclusions. Here are some of the major points we discussed:

1. Performance tradeoff of exposing billboarding to GeometryInstance: Doing this would require a compute (or transform feedback) pass prior to rendering. Either to modify the vertices (like skeletons) or to modify the instance transform (like particles). In either case, we need to add new, per-instance data to GeometryInstances and add the overhead of the extra compute shader pass. Technically this is doable, but we might not want to go this route
2. The sought after billboard modes can be made to work with the existing billboard modes exposed by the GPUParticles3D node. We can add additional modes to cover the needed use cases
3. We can also add new billboard modes to the StandardMaterial3D to cover the use cases as well (but exposed differently, instead of driving angle by CUSTOM.x, we would use a uniform)
4. If we do 2 and 3, we are still left with an awkward workflow for VFX users with custom shaders (they have to implement all the billboard modes themself still)
5. In other engines, the awkwardness is not there since all VFX exist within the particle systems (shurikan, VFX graph, Niagara, etc.). Essentially, all VFX are particles. But in Godot we use particles when you want multiple instances, and MeshInstances when you just have a single instance (and tight control over parameters). This divergence is painful for VFX artists
6. We discussed adding a VFX node again, that would essentially be a particle system where you only have a few particles. It would be designed for giving the user maximum control when keyframing properties, but would otherwise act similar to particles. Such a node could be used to solve the workflow problems, as it could expose the billboarding modes (and take on the consequent overhead).

[QbieShay]

Would it be okay to start and implement this proposal for particles only and in the copy shader?

[clayjohn]

Would it be okay to start and implement this proposal for particles only and in the copy shader?

Absolutely!