New PlaneRotationGizmo performance issues

Bugs
1

Hi BJS team

Wanted to point out that the new PlaneRotationGizmo system is pretty cool (it shows the angle difference), however it does impact performance quite a bit. The drawing of the angle diff is executed per frame via Mesh.createRibbon.
The implication is that it would cause significant frame drops in lower end devices, as it did for a laptop of mine.

Indeed, after a performance profiling on a simple scene, this function happens to be the biggest source for the total ‘scripting’ time, even more than rendering.

Wouldn’t it be better to use a shader instead?

image

1 Like
2

Pinging @davegould41 who created these great features, in case he has some ideas about this.

3

And adding @Cedric a guizmo Guru as well :slight_smile:

5

Thanks!!

Also some suggestions about the PlaneRotationGizmo code: would be really helpful to

  • expose the dragDistance as a public variable or getter
  • flag to not actually rotate the gizmo.

Developers may need know the drag distance while rotating a fixed gizmo. Another use case is rotating a node in global mode so that the underlying node rotates but the gizmo does not. I believe Unity is already doing this for global rotations/translations!

1 Like
6

Happy new year y’all! Anyone looked into this yet? @Cedric @sebavan :slight_smile:

7

Happy new year!

I can confirm the ribbon computation is pretty CPU intensive. When I lower the tesselation value it gets way faster but the edges are clearly visible. Can you use a custom shader or NME to fix that performance issue @davegould41 ?

flag to not actually rotate the gizmo.

Can you elaborate on this one? Can you just not disable the gizmo when you don’t want to rotation?

8

The idea is to drag the gizmo and visualize + obtain the drag distance, without actually rotating the underlying node

9

@davegould41 is busy so I’ll take care of it this week.

1 Like
10

I’m also very busythis week. I’ll do my best to do a PR beginning of next week.

2 Likes
11

And the PR is finally here !!! rotation circle shader by CedricGuillemet · Pull Request #9827 · BabylonJS/Babylon.js · GitHub

3 Likes
12

Amazing stuff! When can we test it! :slight_smile:

13

you’ll be able to test with the next nightly

1 Like
14

Hi Cedric,

Just tested out the latest gizmo, definitely more performant!!

Btw, there is a display bug: the angle display is actually moving to the opposite of the mouse drag!

Also, would it be possible to make the accumulated angle in this line of code as a public variable, so that developers using the gizmo can access it? :slight_smile: Cheers!!

15

can you provide a video for the angle display bug?

16

Created a PG: https://playground.babylonjs.com/#31M2AP#157
Try rotating the Y (green) gizmo (see attached screenshot: image

This is just one example, I’ve noticed it going the other way round at some times. Probably to do with the relative camera rotation to the node? Also using scene.userighthandedsystem = true. It was working fine in the previous build haha :upside_down_face:

17

I’ve tested with 4.2 and got the same issue.
same behavior with RHS or LHS
I’m investigating …

It was working fine in the previous build

Which one?

18

5.0 alpha-3 I believe, the build coinciding with the original post

19

Also is it possible to make the accumulated angle of the rotation drag as a public variable (a value that is agnostic to the relative camera position), so that developers using the gizmo can access it? That would be super super helpful!!
E.g. I move the rotation gizmo by 90 degrees, would be really cool grab this 90 degrees data from the gizmo during dragStart, drag + dragEnd

20

Noted! I’ll push it with the fix PR .

1 Like