Torque X Builder 3D Progress: The Axis Gizmo
by John Kanalakis · 04/21/2008 (7:14 pm) · 7 comments
Torque X Builder 3D is coming along very nicely. I have received a lot of great community encouragement and feedback. And as a part of that community, I'm doing my best to factor in all the feedback. I'm also limiting how much I "perfect" the tool in order to get it finished as quickly as possible. Today's focus is on the Axis Gizmo. Since the main goal of TXB 3D is to make Torque X 3D scene creation easier, the Axis Gizmo is a really big part of hitting that goal.
The problem is that creating an Axis Gizmo is not as easy as it sounds. I spent a lot of time researching differnt methods of creating an Axis Gizmo and the one thing I found is that there really is not much information out there about it (or I'm really bad at online researching ;) ). This becomes even more complicated when you need to work within the limitations of the XNA Framework, where simple rendering primitives, such as line and circle drawing, simply don't exist. So, what does one do? I broke the problem out into two smaller problems: rendering the gizmo and processing the user input. I naturally started with the easier problem.
Processing Input
Processing input is pretty straight forward in Torque X, since it just involves creating an InputMap and processing Move structures, just like any other Torque X game does. It took a little more to work to figure out the dragging functionality, and was implemented by tracking the mouse button states. The scene object movement is accomplished by setting the T3DSceneComponent position position by scaling the mouse input. The harder part to figure out was how to select objects in the first place. In short, you need to get the position of the camera, take the mouse's X and Y screen coordinate, scale the position to the view frustrum (accounting for FOV and Aspect Ratio), and then cast a ray forward into the scene and test which 3D shape's bounding box is hit. So, now that shapes are being selected and dragged around the screen, I needed to have some sort of visual representation for the Gizmo.
Rendering the Gizmo
I started out by creating one by hand. The following lame gizmo (shown in the last blog) was created by dynamically generating 3 tall and thin boxes. It was functional, but the Gizmo looked pretty bad as you can see here:
The biggest lesson learned was that the "implementing the Gizmo as a mesh" solution was working. Great! Now, it's a matter of getting it to look good. I received a lot of great community feedback to work with (Thanks James B. and Chris K.). So, I popped open my favorite 3D Modeling program and produced 3 models to represent the Gizmo in the three different functional states (move, rotate, and scale). I exported the models into the .FBX format (native to XNA) and used the T3DXNARenderComponent to render them on screen. The models are simple enough to scale them up and down to match the size of the object selected. Here's how they look in each mode:
Translation Gizmo Arrows
Rotation Gizmo Rings
Scaling Gizmo Blocks
The Gizmo meshes can probably be improved, but most likely won't for a while. Since they are working out well enough, I'm moving off to the next challenge. Again, I'm taking every possible shortcut to get this out as quickly as possible. I just wanted to take a few minutes and write about creating the Gizmo, because everything involved used stock Torque X code. This is just a testament to the power of Torque X that's already built-in... Great Job GG!
John K.
The problem is that creating an Axis Gizmo is not as easy as it sounds. I spent a lot of time researching differnt methods of creating an Axis Gizmo and the one thing I found is that there really is not much information out there about it (or I'm really bad at online researching ;) ). This becomes even more complicated when you need to work within the limitations of the XNA Framework, where simple rendering primitives, such as line and circle drawing, simply don't exist. So, what does one do? I broke the problem out into two smaller problems: rendering the gizmo and processing the user input. I naturally started with the easier problem.
Processing Input
Processing input is pretty straight forward in Torque X, since it just involves creating an InputMap and processing Move structures, just like any other Torque X game does. It took a little more to work to figure out the dragging functionality, and was implemented by tracking the mouse button states. The scene object movement is accomplished by setting the T3DSceneComponent position position by scaling the mouse input. The harder part to figure out was how to select objects in the first place. In short, you need to get the position of the camera, take the mouse's X and Y screen coordinate, scale the position to the view frustrum (accounting for FOV and Aspect Ratio), and then cast a ray forward into the scene and test which 3D shape's bounding box is hit. So, now that shapes are being selected and dragged around the screen, I needed to have some sort of visual representation for the Gizmo.
Rendering the Gizmo
I started out by creating one by hand. The following lame gizmo (shown in the last blog) was created by dynamically generating 3 tall and thin boxes. It was functional, but the Gizmo looked pretty bad as you can see here:
The biggest lesson learned was that the "implementing the Gizmo as a mesh" solution was working. Great! Now, it's a matter of getting it to look good. I received a lot of great community feedback to work with (Thanks James B. and Chris K.). So, I popped open my favorite 3D Modeling program and produced 3 models to represent the Gizmo in the three different functional states (move, rotate, and scale). I exported the models into the .FBX format (native to XNA) and used the T3DXNARenderComponent to render them on screen. The models are simple enough to scale them up and down to match the size of the object selected. Here's how they look in each mode:
Translation Gizmo Arrows
Rotation Gizmo Rings
Scaling Gizmo Blocks
The Gizmo meshes can probably be improved, but most likely won't for a while. Since they are working out well enough, I'm moving off to the next challenge. Again, I'm taking every possible shortcut to get this out as quickly as possible. I just wanted to take a few minutes and write about creating the Gizmo, because everything involved used stock Torque X code. This is just a testament to the power of Torque X that's already built-in... Great Job GG!
John K.
About the author
John Kanalakis is the owner of EnvyGames, an independent game development studio in Silicon Valley that produces games and tools for Xbox 360, Windows, and the Web.
#2
04/21/2008 (9:14 pm)
Looking like a sweet tool now! 
#3
04/22/2008 (9:48 am)
Great Job man 
#4
04/23/2008 (12:38 am)
John once again puts the "Uber" in Uber : )
#5
04/23/2008 (9:41 pm)
pure P I M P John
#6
John K.
04/24/2008 (11:21 am)
Thank you guys! I wanted to post my woes about creating an Axis Gizmo so that there is finally some useful information out there on the web for someone else interested in creating a 3D editor. I had the hardest time finding information, ultimately gave up and started experimenting. Anyway, thanks again for the support. John K.
#7
Great work so far. I'm currently catching up on all your posts on the 3D builder. So I'm not sure if someone has mentioned this already. For selection, I would use a selection buffer rather than doing ray to bounds testing.
Ray to bounds testing in editors break down when you get a lot of objects on screen. Designers will pull there hair out trying to select the objects they want and selection buffers are pretty easy to implement.
Really, to implement a selection buffer. All you need to do is assign a color to each object in your scene, then render each object to a texture (the size of your screen). Then all you need is the mouse coordinates and you can do a look-up into the texture to figure out what object you selected. There are obvious optimizations I won't go into here because I'm sure you will come to them easily.
This is how the editors at the two game companies I have worked at did it. And it gets you great results. Good luck and I'm looking forward to using this:)
-Troy
06/22/2008 (12:18 pm)
John, Great work so far. I'm currently catching up on all your posts on the 3D builder. So I'm not sure if someone has mentioned this already. For selection, I would use a selection buffer rather than doing ray to bounds testing.
Ray to bounds testing in editors break down when you get a lot of objects on screen. Designers will pull there hair out trying to select the objects they want and selection buffers are pretty easy to implement.
Really, to implement a selection buffer. All you need to do is assign a color to each object in your scene, then render each object to a texture (the size of your screen). Then all you need is the mouse coordinates and you can do a look-up into the texture to figure out what object you selected. There are obvious optimizations I won't go into here because I'm sure you will come to them easily.
This is how the editors at the two game companies I have worked at did it. And it gets you great results. Good luck and I'm looking forward to using this:)
-Troy
Associate Rene Damm