Question I want to point the particle's angle to a point in the world coordinates.

I've been working on this for about 3 days now and keep failing, so I need help.

I tried to implement a mechanism that spawns penlights as particles on a simple mesh like a live concert venue and directs the penlight's angle in the direction of the performer.(However, height is ignored.)

We tried to implement a mechanism that spawns penlights as particles on a simple mesh like a live concert venue and directs the penlight's angle in the direction of the performer.

To implement, the direction is obtained from the difference between the two points and normalized to
angle between the direction of the particle and the direction of the particle is calculated.
Finally, the direction of rotation is calculated from the result of the outer product and the angle is assigned to Set Angle.Y in the initialization block.

However, what we actually get is a strange state where the particles disappear depending on the position of the FocusTarget.
I found out that the particles disappear when the NaN result is passed. However, it is unclear to me where the NaN is generated.
Can you give me some hints?
An image of the VFX graph is attached.

 

I forgot to show the vfx without rotation processing. Here it is.

 

I can't investigate the whole graph right now, but you think it might be fault of NaN, then there are candidates:
1. Normalization - this should not happen as you check zero distance, but this is not god way do it, what if you have coords (-0.7,0.7)? It's valid vector, but the sum is 0.
2. Cross product is not used, but just you know it produces Nan for colinears in Direction mode
3. Square root - again can't happen as it's not possible for input numbers to be below 0
4. Division by 0, but it should not produce NaN I guess

This means there is no place for NaN to be generated (or at least I am not aware of any other way). How do you know that NaN is passed? I recommend you to break the problem, for example try to disconnect some part of the graph and see if problem still happens, also if you really can't make it work you can attach your graph as it will increase the chance that someone can help you.

 

Thanks.
I did not confirm with this graph that NaN is produced." I just found the information from the sea of internet that "if it is NaN, it disappears". Sorry for the confusion.

1.I was completely blind regarding the Normalization section. This will be improved.
2.Can I ask for more information about DirectionMode? Direction,position and Vector are after all 3 axis values and I didn't think it would change the way they are calculated, but maybe I am very mistaken.
And...
To be honest, I don't really understand why there are different types of Transform nodes as well. I think I have a basic knowledge of matrices, but I have never heard that they behave differently depending on the vector type.
3.yes
4.yes
I cut vfx out of the project.
I would like someone's help.

 

I am not sure how to reproduce the problem. Although I opened it in URP, so maybe it gives different results somehow.
Or maybe you mean this flickering?

I meant this:

Standard cross can't produce "invalid" results, but looks like there is normalization added in direction, so for zero length vectors this will not work.

 

Sorry. The test project was not correct.
I need to make sure that the direction is also calculated in the update so that it is easier to check.
Also, I've changed the check if the distance is zero from add to multiply to avoid this.
Another finding is that the behavior changes when the graph is open. Possibly some of the debugging work I've done so far has come to nothing lol.
Regarding the Gif, I am happy that it is showing up, but perhaps the penlight does not wave its light at the target. Even if it did, it would swing in an inexplicable direction.
For now, I will try to debug some of it by opening the package I gave you in a new project to isolate it.

 

The previous sample did not lead anywhere in the calculation results... Sorry.
The calculation results are reflected in the UPDATE.
When opened, it probably generates a vfx with the arena audience turned off. (strange)
If you open the graph, the behavior changes even more.

 

Well, in my console there is rain of warnings:

I had no clue pow can't handle negative values and when I added absolute (what is not good idea I think) it worked.
In your case it's easy, you can replace it with multiply a*a and it's done, however I am unable to explain why in game view it disappears, my wild speculation is it has something to do with compilation. Maybe compiler replaces power with a * a and this is why it works when window is closed, no clue, maybe some dev can answer this.
Does it help/solves the problem?

One sidenote about penlight - it is huge waste to use such detailed mesh to render 3 pixels on the sreen, while it could be handled with single opaque quad facing camera. Obviously I assume you can't see audience from very close distance.

 

I see. I don't know why no error on my part, but I'm surprised about the pow spec, I'll replace it with multiply.
I'll do some more testing.
About the penlight.
Thanks for the advice about performance.
I will consider that pattern as well.

 

Again, as part of the reply was missing due to translation.
Indeed, I would like to ask vfxgraph or unity engineers about the specification part.
Also, this is another question.
a. Put GetPositionAttribute in the position node and make the input from L to W.
b. Connect GetPositionAttribute to Transform(Vector or position) and transform it with LocalToWorld matrix.
Is it safe to assume that a and b do the same thing?

 

It's a long story, but it seems that there is a problem with the acquisition (or definition) of the forward vector for each particle.
The first image is treated as NaN. But in the second image, everything is displayed.

 

Finally, we can take the next step...
Now that the particle disappearance phenomenon has been resolved, we can focus on solving the problem of the wrong direction of the particles with respect to the focusPosition.

 

I don't think anyone has seen this already, but I finally got it all sorted out and am happy to report it.
1. changed to ChangeSpace node instead of transform using WorldToLocal.
2. there was an error in determining the angle using the outer product. It was using the outer product of the particle's front vector (0,0,1) and the focus direction and multiplying the result by the angle calculation result using acos, which was incorrect. In fact, it was necessary to split the process according to the result of the outer product and determine whether to use the angle as it is or subtract it from 360.
As a result, everything is working as expected.
I am so glad we were able to solve this problem, although it took some time because we were moving on to other tasks. Thank you for your support.

 

thx Qriva