Translate Gizmo / Scale Gizmo Y-Axis

Started by
9 comments, last by Alundra 9 years, 2 months ago

Hi all,

I have a translate gizmo and scale gizmo working but I have the behavior on Y not good.

I use an intersection test with a plane of normal (0,0,1) which is the same as X-Axis.

The problem is when you are near of parallel or parallel that doesn't works.

A way to handle that correctly exists or a dot product is needed to disable the selection of axis when near of parallel ?

Is it better to use a plane of normal (0,1,0) and use dot product of intersection delta with forward (only X and Z) of camera to compute the delta on Y ?

Maybe easier option I have in head is to oriente the plane to always be front of the camera but up always up of the gizmo, maybe that's the best option ?

Thanks for the help

Advertisement

I'm a bit confused by what you're asking. Is this a translate/scale gizmo for a game object like in an editor? If so, what's the need for an intersection test with any of the world axes, I imagine that those transforms should be applied about the local basis vectors of the object.

What behavior is not working about the Y axis, translation or scale?

Perception is when one imagination clashes with another

The axis is selected using a ray-obb intersection then a ray-plane is made to compute the delta of last intersection with the current, this value is then sent to AddTranslation/AddScale using local or world to convert the delta on the good space. The problem is you can easily be parallel to the plane, that's why a way has to be found to avoid this case the most possible. The post is named for Y-Axis but with test, the problem is on the 3 axis. The only correct option I have in head is to orient the plane to always be front of the camera but always oriented on the up using the axis selected. If you rotate around the Y axis, the plane will always be oriented front of the camera but always has up axis to (0,1,0) in world space and in local space has the up axis of the last selected.

So the you create a plane about the axis selected, and then determine via the previous intersection and current intersection of the amount to scale/translate? What's the purpose of the plane for the axis, can't that delta be determined via how far the user has dragged their cursor / some sort of maximum amount per drag? Maybe I'm still misunderstanding the problem still.

That aside, you're not going to be able to determine intersections if the ray is parallel to the plane, so some sort of billboarding will be necessary. Though I think billboarding would defeat the purpose of this algorithm.

Perception is when one imagination clashes with another

Yeah that's the only way I see to have this working, compute one orientation of the plane based on camera like for particle system when you orient based on velocity.

This orientation has to be stored to compute the local version of the intersection which is sent to each actors.

I still think that calculating the delta should be much simpler, this approach seems very error prone.

Perception is when one imagination clashes with another

I am currently working on the same sort of system and was wondering how exactly did you got about checking for the intersection of the gizmo? I am doing a simple plane/ray intersection check and that part seems to be working fine. My issue is that I am not sure how to tell if I am colliding with the gizmo its self. I have tried to port over the code from LIbGizmo but I don't really understand a few portions of the code ( mainly related to the division of the screen factor.) Any suggestions on how to go about finding out if you are exactly intersecting with the gizmo?

Thanks,
Chaz H.

Thank you,
Chaz

Chaz,

If you were to place a bounding box around each of the axes of the gizmo and around the interior box. Then you should just perform ray to OOBB testing.

Perception is when one imagination clashes with another

I use the Ray-OBB to test axis of the translation/scale gizmo and ray-plane for the rotation gizmo.

For the intersection ray-plane works good but try when you are parallel of your plane and you will see it's impossible to move or scale or rotate correctly.

I don't know how you've modeled your rotation/scale widget, but you should be able to represent any area that you want the user to click in with some sort of volume, and if it's 3D, then it needs depth by definition. Otherwise you'll need to bill board it.

You could represent three rings around the objects center, test against thin OOBBs that represent each ring, and use that as the interface a la Unity.

Perception is when one imagination clashes with another

This topic is closed to new replies.

Advertisement