Single-handle 3d rotation gizmo?

[HiGreg]

Is there a 3d rotation gizmo with a single handle?

[mawa]

I don’t think so, but you could create one (your own). I recall I recently did misread a request and started to work a button attached to the edge boundingBox of the mesh to perform transform (such as scale, rotation, etc…). Turned out the interface was for a sticker/decal (LOL) … But at least, it gave me the opportunity to sketch and assess that this is do-able

[HiGreg]

I think so as well. I’m trying to work out the geometry.

At first glance, a single-handle 3d rotation gizmo seems unlikely because you have a pointer in 2d screen space. However, you can define a plane through that line and related to the center of the object, either 1) plane through the center, or 2) plane normal throught the center.

I can’t work out how the 2d motion of the pointer would convert into 3d motion. Dynamically, I would want to move the 3d point anywhere in 3d space without using pointer up. In the current 3d rotation gizmo, pointer down defines the orthogonal plane and you have to pointer up before selecting a different plane.

I have a few ideas, but need to solidify them a little to enumerate them logically.

[mawa]

Could you draw/draft an example of the desired (visual representation). At this point I’m not sure if you want to rotate on just one axis or a full rotation in the 3D space?

Else, the approach I was (about to) take (before I realized my work was useless because it was a sticker ) was the same as you state here: From a 2D space to 3D. Because I was actually using the 2D GUI for mesh for the buttons and was thinking to capture the pointer move (after click and hold) in the 2D space and apply it to the mesh… Didn’t make it to this stage before interrupting…but yes, that was basically the idea (which should work… might be a bit of a bother with maths. I’m not very good with Maths

Edit: This the link I was referring to. As I said not relevant in that it happens to be for a decal… however, there’s still a mention (and a logic) to apply changes from a 2D space to 3D. As always, Patrick’s insight is a good reading to help clarify things

Moving and resizing objects more intuitively

@acero, in looking at the example site you showed, a couple of things strike me. When I created the skateboard customizer, it was done to illustrate an advanced usage of dynamic textures. I opted to go with simple GUI interactions for placement to keep the playground simpler since they are one monolithic block of code to sort through and adding too many features into one demo makes it hard to follow. But what you are looking to do can be achieved by Babylon it’s just not a one-click solution. Lo…

And I recall, other topics discussing this matter of translating 2D pointer moves to the 3D space. Would just need to find’em

[HiGreg]

I want to move to any orientation without pointer up.

I’m thinking through how it should work visually well. My tentative thoughts are that 2d movement towards the object’s center (projected on 2d screen space in the plane of the camera) should be 3d movement towards the object center from the “current 3d position.”

I’m not sure if it is useful thinking about this “3d position” or if it is more useful to think about 2d motion abstractly related to rotation around an axis. And of course, which axis?

[mawa]

@HiGreg

I’m not sure if it is useful thinking about this “3d position” or if it is more useful to think about 2d motion abstractly

As I said, never did this before, but… I would assume that if you are using the 2D space for rotation, then the 2D space click origin would become the origin for the transform (and the offset applied to the 3D mesh for whatever origin it has).

[HiGreg]

Glad you posted that! It leads directly to a candidate for first test:

• save initial click X & Y, “R or Q” flag, object initialR (or Q), and rotScaleX & Y
• flag uses same logic as babylon to use either mesh.rotation or mesh.rotationQuaternion
• rotScale based on canvas or scene min(width, height)
• on pointer move:
• rotX = (currentX-initialX)*rotScaleX
• rotY= (currentY-initialY)*rotScaleY
• rotation = initialRotation followed by rotateEuler(rotX,0,rotY) // rotate in world space using Q or R based on QRflag

Adjust sign of rotX & Y based on positive screen coordinate directions (e.g. +X = left, +Y = down).

[mawa]

Sound like a plan I’m actually quite eager to see that in real… If you fancy posting the result of your finding (i mean, just the base without discarding your project)? Would luv to put my eye (and hands ) on that.

Meanwhile, have a great weekend

[HiGreg]

Prototype works!

Babylon.js Playground

A couple of problems I need help with:

• maintain screen size of rotate hit point
• hit point not super reliable, lower half sometimes doesn’t activate for me
• doesn’t work when physics is enabled (with line 11 uncommented)

A few future improvements I want to make:

• Implement IGizmo
• Optimize for a lot of meshes ((thin?)instance the hit point, use single observer with single pick call)
• test on gizmoLayer

[mawa]

WoW . That’s amazing progress and already works pretty well.
I have to admit, it took me some time to figure how to ‘make it work’. You know, like all the part in your post where you’re saying:

@HiGreg

• save initial click X & Y, “R or Q” flag, object initialR (or Q), and rotScaleX & Y

For the understanding of simple people like me and those who wouldn’t read the text from the post , might be great to add just a few helpers in the scene (or simply an information TB for how to operate or in other words, what to look at/for?

@HiGreg

A couple of problems I need help with:

I’m afraid I won’t be of any help for the remaining issues . Looks more like a challenge for experts to me. May be at this already advanced stage, @Evgeni_Popov could kindly have a look at this and share his insight. Or may be @sebavan ?

Meanwhile, again, congrats for having done already all of this and… have a great Weekend

[HiGreg]

Babylon.js Playground

Updated to include:

• emissiveColor (preparing for IGizmo)
• using event.offsetX and .offsetY for scene.pick(), not sure why those work but it fixed the hotspot issue.
• added visual arrow to indicate hotspot, created with manually-tweaked inputs to GreasedLineTools GetCircleLinePoints and GetArrowCap.
• visual is in renderGroupId 2 so shows in front of other meshes using the default (0).
• fixed physics with disablePreStep, but it’s still not working great as it spins WAY too fast when physics is enabled.

Biggest current problems:

• not fully functioning with physics
• no IGizmo
• no preserveScale
• no configurability

Edit: would also like to rotate around world Y and world X. Currently using local Y and X.
Edit2: tweaked spin rate per drag distance. Also reduced spin rate by a constant factor when physics is enabled. Still not great with physics, but better (try it by uncommenting line 11).

[HiGreg]

Babylon.js Playground

• Rotation with physics enabled is working now. I had been saving initial rotation as a reference pointing back to the changing object rotation.
• Added physics enable/disable button.

[mawa]

Wow, this is getting neat. I’m amazed it’s actually working that well (thanks for sharing ).
May I suggest you would make the rotation button better ‘isolated’ from the models. Use layer masks for the GUI, make it an opaque or slightly transparent ‘button’. May be it shouldn’t be linked in the center of the mesh? May be it should be in the half of the boundingBox (top, bottom, right or left?) Though, this would add more complexity to it since the button cannot reposition when rotating (else would be a mess). UI in a 3D space is always kind of a bother, isn’t it?

[Evgeni_Popov]

@Cedric is the king of physics AND gizmos, so maybe he will be able to help, though I don’t know if you still have problems?

[Cedric]

You can turn pretty much anything into a gizmo thanks to CustomMesh.
For a single handle, I’d use a planeRotationGizmo. Moreover, once the observers are bound,you can control pretty much anything.

[HiGreg]

This is an awesome tip. The mesh and observers is all my code is now. Sounds like there’s very
little work to get the rest of the gizmo code attached: use an existing one!