I’m currently attempting to spawn particles along polylines. I’m successfully generating a .pcache file of the positions where to spawn the particles, which works well if I manually assign it in my VFX Graph. However, in my project I have dozens of different lines, so creating dozens of Visual Effects is not an option.
I’m seeking for advice on what I could do to have one Visual Effect that can handle all my polylines. Is there any way I can expose a Point Cache as property, or assign it somehow using C#?
Mesh sampling is on its way which would allow you to assign the polyline directly.
In the meantime, the Multiple Position Binder approach is probably one of the easiest. To get around the particles spawning only on the vertices, you can do something like this:
In this example, we are randomly picking a value between 0 and the position, and are sampling the position texture once for the actual position, and another time for the position + 1 (i.e. the next position). Then it’s a simple matter of randomly lerping between the current and the next position. The result looks like this:
And as a last bit, if your shapes are easily represented with math (i.e. an octagon), it might be easier to just draw them directly in the VFX graph.
Thank you very much, @VladVNeykov ! With your help I was able to get my project’s polylines working the way I wanted. This was my first forum post and I have to say I’m positively surprised that I received such a nice response. Especially the fact that you work at Unity enhances my view of Unity and its community.
I have a follow-up question, though. I’m not sure if I should create a new thread for it, but its somewhat related to the solution I ended up using. The multiple position property binder to be exact.
In attempt to make it easier for my team to deal with said polylines, I tried to automate the “Targets” array of the multiple position binder. However, I was unable to access it in C# due to VFXMultiplePositionBinder’s protection level. To my understanding I could write my own property binder to solve this, but for future reference I’d like to know if there’s no need to write a custom one.
(Me and a couple of other people have argued that access control is applied over-zealously in a fair few places but we might be the heretics in this debate…)
Regarding this, the VFX package API is not public yet as it is subject to change and is not documented. I understand @andybak 's point on this, and it can be annoying having to resort to workarounds, but managing expectations is often kinder than potentially affecting adversely lots of user projects.
In short, I would recommend making your own binder. If you do however want to access the API (and are ok with the fact that it can change in future versions), you can create a folder in your assets and drop an assembly definition file which links to the VFX assemblies. You can see such an *.asmdef example here. All scripts within that folder will have visibility to the VFX API. As I mentioned though, use at your own risk
