[Feature request] Visible trajectory curve for bounces

[Cheo]

Hello, the visible trajectory curve for Throwable objects is a nice feature but it could go a step further by displaying bounces as well. The only example I can think of is The Evil Within, which had a surprisingly precise gizmo for this :

Since grenade throws are meant to be deterministic and predictable, I'm assuming the addition of those bounces, while requiring some additional work, should follow the same principles and take into account the Reflect Multiplier if there is one.

Hope this can be done, I'd really like to use this feature for some trick shot puzzles in my game Purple Eye !

 

[Cheo]

I took a look at V2 this morning and look at that ! I had completely forgotten that this awesome feature had already been implemented.



But I'm not seeing it in V3, or at least I don't understand how to use it out of the box. Could it please be indicated somewhere in the documentation if it isn't already, and added to the demo grenades ? Thanks in advance.

Edit : to be absolutely clear, I'd like to specifically request an int parameter for the maximum amount of bounces to display - for example, even if a grenade were destined to make 10 bounces, we should still be able to have only 2 or 3 bounces displayed if we want. This int value should be displayed right after Max Position Count in Trajectory Object's Curve foldout.

 

[Justin]

I've fixed this for the next update. You can change the number of bounces based on the movement and rotation settle threshold. The higher the value the less bounces you'll get (similar to when the object is actually thrown). Using a bounce count is a feature request that I've written down

 

[Cheo]

I'm glad to see this feature implemented again in 3.0.16, but unfortunately the curve suffers from some unsmooth refreshing starting from the first bounce. This issue is not framerate related. You can see it in this video here at 1:15.

 

[Justin]

That is a result in the slight idle movement causing the trajectory to be recomputed. You can increase the settle threshold to reduce the number of bounces.

 

[Cheo]

Of course the trajectory needs to be recomputed, but can't it be smoother than that ? There doesn't seem to be any performance issues here, it really looks like something's off with the bouncing curves, if you try aiming towards a wall and move the camera very slowly, the additional curves will follow the first one smoothly but then abruplty be repositioned, as if they weren't correctly calculated every frame and needed to catch up at some point. I'm no programming expert, but once again I can't think of an actual video game that had this issue, is there no way to fix this ?

 

[Justin]

At 1:15 the jitter that occurs against the crate is because of the capsule collider on the grenade projectile. The cap of the collider is hitting the crate and causing the angle to slightly change. You can prevent this from happening by using a sphere collider.

 

[Cheo]

I tested again this morning in 3.0.20 using a sphere collider, and the issue remains the same. Did you actually get smooth repositioning when using a sphere collider ? However, after taking a look at trajectory visualizer tutorials for Unity and Unreal on YouTube, it seems that that snappy repositioning issue is present there as well.

By the way, after trying out the examples from both videos, I can say that the performance is much better in UCC, as the fps easily drops when using a calculation count of about 50 in those two examples. The second one might still be worth taking a look at, the first and sometimes second bounces don't tend to be snappily repositioned, however it's using straight directions.

Once again I'm no expert, but I'm starting to think that there may be a Unity limitation, or perhaps just a natural one. Either way, if you can't find a fix for this, would it be possible to make some sort of test package to send to Unity ?

 

[Justin]

This issue occurs because of the slight change in direction of the camera. While you could cache the results to prevent the visible trajectory curve from updating when there is a small change, this would make the curve jitter more when the direction changes because it would be stepping through the directions. Everything is working correctly on this one.