New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI Handle overload with scaling #546
base: develop
Are you sure you want to change the base?
Conversation
Very nice! I had been thinking about this with a new This is missing two things I'd consider to be important:
|
refactor: bit flags for different movement types fix: ui push surface includes an optional scale vector
Thanks for taking a look! Thought I'd give an update on the latest changes before going any further:
I believe I addressed your first point, but I'm a bit unclear on the second point. I checked MRTK in Unreal and Unity and they perform this type of uniform scaling. However, 1:1 scaling sounds like it'd be tricky due to the starting pinch points having to relate to the bounding box. I'll take a crack at it, but I think it's nice to have the uniform scaling as an option as well. |
Definitely a good improvement! I believe you did actually get the 1:1 scaling mostly correct on this one, but in the UI scene it's hidden underneath a double scale. You're providing the scale to After that it still feels a little off. I believe this is because of where the scale is happening from, it's currently scaling relative to the I'm skeptical on The bit-flag thing crossed my mind when I first looked at it, but I feel like it was actually pretty nicely handled by just providing or not providing the scale value? Do you think the bit flag is necessary here, or improves the situation? Would love to hear an example where this is better than just omitting or providing the scale var :) Thanks for your work here, pretty exciting! |
fix: roll back to float for scaling args feat: demo bit flag transforms for damaged helmet
Just pushed most of your helpful feedback, thanks! Whoops there was a double scale in that demo, should be accounted for now. The UI demo turned into a placeholder for showing the different move types :) For scaling from the center of the 2 handed grab, is that scaling from the midpoint between the two starting pinch points? And the location is offset from there to be relative to that midpoint? If you could make a quick video, or pseudo code that'd be very helpful! I agree that a float would be better passed for scaling the UI surfaces. For the handle, allowing a Vec3 to be passed in for non uniform scaling might make the handle method take on too many tasks at once, so a different manipulation box component could be clearer. Now on the demo for the bit-flag change! Doing a pure rotation movement is a bit strange honestly, but I like the fact that I can scale without moving the model's position. Or completely forgo the rotation in some cases. Along with providing more transform capabilities, I found a neat trick. If you pass in the float to scale the UI surface, we can use that same scaled hierarchy without having to scale the object! It's a convenient way to scale a model as well as keep the same scaled hierarchy no matter the switching between move types. |
Hey Nick, I wrote a handle extension for scaling but noticed that you had previous and active pinch points in the source code, so I thought it could fit nicely here instead. I added the scaling to the clipboard for the DemoUI script for testing it out. Let me know what you think!