Official New Feature : Direct Link

Hello,

I would like to follow up on this thread and I think it’s more appropriate to centralize a message in a dedicated post.

We have some updates about these limitations, we recently added the support of “Direct Link” event (see this merge request if you are interested about the implementation details).

First thing first, this feature is mainly addressed to advanced users who want more control on spawn events. For instance, you can be a gameplay programmer who is triggering a really custom amount of particles or a technical artist feeding the Visual Effect with custom data (which can’t be expressed as a simple texture or a point cache). Some minimal scripts are required for these scenarios and it isn’t a common case for the Visual Effect Graph.

This feature has been available since 2021.2.0b2 with the embedded graphics packages and. The “Direct Link” is bypassing the spawn context constraints.

We are still working on a general rework of the spawning system but meanwhile, we are also unlocking the ability of sending multiple events within the same frame from a script when an event is directly linked to an Initialize Context.

Basic Usage
Let me introduce this concept with an example, here, we have a quite complex spawn context chaining :

Every 0.2 seconds, it triggers three Spawn Context emitting a random amount of particles between 2 and 8.

Now, let’s imagine the amount shouldn’t be random, but instead driven by the gameplay. In that case, the direct link is more general purpose for this kind of effect :

In this example, there is a MonoBehavior which is feeding the Initialize Context :

Code (CSharp):

1. //Spawn N Red
2. m_EventAttribute.SetFloat(s_SpawnCountID, Random.Range(2.0f, 8.0f));
3. m_EventAttribute.SetVector3(s_ColorID, new Vector3(1, 0, 0));
4. m_TargetVisualEffect.SendEvent(s_FireID, m_EventAttribute);
5. //Spawn N Green
6. m_EventAttribute.SetFloat(s_SpawnCountID, Random.Range(2.0f, 8.0f));
7. m_EventAttribute.SetVector3(s_ColorID, new Vector3(0, 1, 0));
8. m_TargetVisualEffect.SendEvent(s_FireID, m_EventAttribute);
9. //Spawn N Blue
10. m_EventAttribute.SetFloat(s_SpawnCountID, Random.Range(2.0f, 8.0f));
11. m_EventAttribute.SetVector3(s_ColorID, new Vector3(0, 0, 1));
12. m_TargetVisualEffect.SendEvent(s_FireID, m_EventAttribute);

In the end, even if the exact same effect was possible with the spawn event chaining, this new approach allows you to completely control the spawning from a script.

Best practice
Internally, the list of events will be aggregated into an array and sent to the GPU to finally be processed into a single dispatch. So, the best practice is always to limit the amount of SendEvent invocations.

Let’s imagine you want to spawn 32 particles on a sphere in different places controlled by script, this is a common scenario when you can reduce the workload of transfer from CPU to GPU keeping the same result.

The first naive approach would be to completely control the spawn by script :

With the corresponding code snippet :

Code (CSharp):

1. m_EventAttribute.SetFloat(s_SpawnCountID, (float)1.0f);
2. for (int source = 0; source < spawnSources.Length; ++source)
3. {
4.     m_EventAttribute.SetVector3(s_ColorID, spawnSources[source].color);
5.     for (int hit = 0; hit < number_of_particle; ++hit)
6.     {
7.         var particlePosion = spawnSources[source].position + Random.onUnitSphere * 0.5f;
8.         m_EventAttribute.SetVector3(s_PositionID, particlePosion);
9.         m_TargetVisualEffect.SendEvent(s_Solution_AID, m_EventAttribute);
10.     }
11. }
12.  

This solution is valid but it implies one unique event for every particle attribute.
We can improve this approach moving the Random.onUnitSphere to the VFX Asset:

With the corresponding code snippet :

Code (CSharp):

1. m_EventAttribute.SetFloat(s_SpawnCountID, (float)number_of_particle);
2. for (int source = 0; source < spawnSources.Length; ++source)
3. {
4.     m_EventAttribute.SetVector3(s_ColorID, spawnSources[source].color);
5.     m_EventAttribute.SetVector3(s_PositionID, spawnSources[source].position);
6.     m_TargetVisualEffect.SendEvent(s_Solution_BID, m_EventAttribute);
7. }
8.  

Aside from having a simpler script, this second solution has divided by number_of_particle the number of SendEvent invocations, it will lead to less copy on the CPU and less transfer of data to the GPU.

What do you think about this new solution ? Does it solve some pain points ?
Feel free to share your impressions and don’t hesitate if you have any additional questions or if something isn’t clear.

You can find all sources and assets used in these samples in the attached archive "vfx-direct-link-sample-master.zip", in can be opened with Unity 2021.2.0b2 or greater.

 

That's a good question, this behavior isn't really clear in documentation yet. In your case, only the last SetFloat will be taken into account, Unity isn't saving the whole property sheet between each event, and since all these events will be processed within the same dispatch, it's always a simple unique material property.

Let me clarify this with an example :

Code (CSharp):

1. //Using exposed property (fire_A)
2. m_TargetVisualEffect.SetVector3(s_ExposedColorID, new Vector3(1, 0, 0));
3. m_TargetVisualEffect.SendEvent(s_FireAID, m_EventAttribute);
4.  
5. m_TargetVisualEffect.SetVector3(s_ExposedColorID, new Vector3(0, 1, 0));
6. m_TargetVisualEffect.SendEvent(s_FireAID, m_EventAttribute);
7.  
8. m_TargetVisualEffect.SetVector3(s_ExposedColorID, new Vector3(0, 0, 1));
9. m_TargetVisualEffect.SendEvent(s_FireAID, m_EventAttribute);
10.  
11. //Using event attribute data (fire_B)
12. //Spawn 1 Red
13. m_EventAttribute.SetVector3(s_ColorID, new Vector3(1, 0, 0));
14. m_TargetVisualEffect.SendEvent(s_FireBID, m_EventAttribute);
15.  
16. //Spawn 1 Green
17. m_EventAttribute.SetVector3(s_ColorID, new Vector3(0, 1, 0));
18. m_TargetVisualEffect.SendEvent(s_FireBID, m_EventAttribute);
19.  
20. //Spawn 1 Blue
21. m_EventAttribute.SetVector3(s_ColorID, new Vector3(0, 0, 1));
22. m_TargetVisualEffect.SendEvent(s_FireBID, m_EventAttribute);

As you can notice, on the left, only the last SetVector3 with the value corresponding to blue is used.
On the right, we are using event attributes data which can be independent per event, there is no need to create a new VFXEventAttribute for each SendEvent, the actual content is copied.

You can find a package of this sample attached to this post.

 

If you are using "Direct Link" event, there is no way to override the spawn count before receiving it in Initialize Context. Maybe you could discard one of two particles in Initialize changing the alive state but this isn't very convenient, or you can separate events as you suggested.

If you are using several "Spawn Context" as usual, you can author the number of emitted particules with different burst but you are constrained by the Spawn Context limitation (which is only carrying one event state per update).

We are going to improve the support of this common scenario in further release of Unity (possibly with the Effect Instancing).

 

Thanks, I'm glad to know it will be used.

There isn't any way to synchronously trigger an update for a Visual Effect component, SendEvent and Simulate are always pushed to a queue in order to be processed afterwards.

However, the VFX.Update is actually processed right after the LateUpdate (see ExecutionOrder). In some cases, the authoring of the VisualEffect could be more appropriate in LateUpdate. For instance, the PropertyBinder is using the LateUpdate message to prevent the frame delay.

 

Hello,

Sorry for the late answer, and after discussing with the team, I confirm this note is very confusing, we are currently editing this VFXGraph doc mention with something more appropriate :

We also did a quick experiment to double check the expected behavior with this graph, it forces a particle to be visible only one frame :


I have a simple setup with a sphere position is driven by animation and another is driven by physics. I'm sending an event every frame
If you are sending an event during the Update to synchronize a position you can notice the delay on the animated sphere :


It's expected because the animation is applied after the Update (see ExecutionOrder), it can be easily fix using `LateUpdate` instead :


As mentioned before, the PropertyBinder is using the LateUpdate for this exact reason.

Let us know if you encounter any unexpected behavior.

Thanks for pointing this wrong documentation out.

 

The direct link addition is only a niche improvement which isn't dedicated to be a general purpose approach.
The scenario you described about several explosions could be addressed with the Effect Instancing, this feature will allow you to share the same simulation for several Visual Effect instances in the scene, it's a far more ambitious improvement.

Beside that, even if it doesn't appear on the productboard, we are still working on a general rework of the spawning system which will address some of the areas you mentioned.

Thanks for your feedback.

 

This feature won't be backported to 2021.2, the Unity release process is conservative. By the way, this improvement is still in development, we cannot provide an ETA at this time.

To elaborate on this, right now every visual effect instance is independent and triggers a simulation dispatch resulting in inefficient GPU and CPU resources usage. In order to improve this, we are working on Effect Instancing which allows to batch instances of the Visual Effect asset. It's mainly a performance improvement which doesn't require any intervention from the user perspective.

We are still working on a general rework of the spawning system, and this kind of improvement is something we also want to adress but this is not related to the instancing card.

No, it's only available since 2021.2.0b2 and there isn't backport planned so far.

Yes, in that case, you always have to consider your bounding boxes while spawning particles but it isn't really related to the "direct link" support. However, we recently improved the bounds authoring, you can check out this documentation about this workflow improvement.

 

Hi, glad you found it! To make this easier in the future, if you can enable this option in the Preferences tab:


You can select any block and see what per-particle attributes, block-specific parameters, and source code the block is using / producing:

 

Hello,
Indeed, the direct link is way to avoid the current limitation from the spawn context behavior which can't handle multiple events within the same frame.

Actually, as previously mentioned in the very first post (see "Best Practice"), you can send a single event with a larger spawn count than one:

Code (CSharp):

1. _eventAttribute.SetVector3("position", position1);
2. _eventAttribute.SetFloat("spawnCount", 300.0f);
3. _explosionVFX.SendEvent("ExplosionStart", _eventAttribute);

I hope that helps.