Hi, I've created a manual object translate widget that looks like this: my problem is when I move the camera away from or closer to the widget, I'd like the widget size to appear the same, rather then looking smaller as the camera moves away or larger as the camera gets closer as is the normal effect. I've tried setting a custom projection matrix, and this does keep the size the same regardless of camera proximity, but when I pan the camera left or right, the widget moves in a different way then other meshes in the scene. I'm basically trying to emulate behavior like Maya with the move tool, I just need the widget to stay locked to whatever position it's in, but stay the same size. Is tweaking the projection matrix the way to go here? That's why I posted in the graphics forum, since I believe it's a matrix issue, I hope that is a correct assumption. Any help would be appreciated, thanks!

There would be a few ways to go about this, matrices included.
I took a simpler(perhaps even simplest) approach (...there I go again, being simple and lazy):

by manually changing (i.e.scaling) the position of the points (that make up the widget) by a proportion of the zoom translation value, as opposed to applying projections/modelview changes via the graphics pipeline.

but it depends on how you implement zooming e.g.


and whenever zooming occurs the length of the axe(s) of the tripod are changed manually:


Some pros, cons and other options:
There are very few vertices to modify, so any disadvantages of doing it manually like this (as opposed to down the other end of the pipe) are negligible.

Normally(i.e. more efficently?) we would send the appropriate matrices down the pipe for the server to apply them to our geometry. I suspect in our case, that would mean storing at least 2 other matrices (or parts thereof) somewhere: One to ensure the size of the widget remains constant(applied only while zooming, like your custom mat you mention), and another one to ensure transformations(such as the translation you speak of) occur correctly in relation to the actual current view(applied when not zooming). I started out doing it this way and it started getting more complex as I went (there is always a whole bunch of ways to tweak this and tweak that to get things behaving as expected, but for what, just to maintain a constant sized Widget?). I got to the point of suspecting I need to go back further in some of the values used to derive some of those elements in the matrices for a solution, then settled on the (simple and "potentialy" inefficient?) solution given above. I have no doubts it can be done via matrices (then improved further): it just takes a little more time (and hackery?). A matrix expert is what we need here(are you out there?), or as you experiment and continue researching a solution, an expert is what you will become (until you forget eveything you did)?

Overlaying another view (e.g. 2D viewport) of the widget is another option that works well for Orthographic views, and looks ho hum over Perspective views (as long as you don't look too closely at the widget on some angles to see that it is an Ortho layer on top of perspective!) But again this is more code/matrices and work than just manually scaling the tripod as the example shows.

One more note: I am willing to consider matrix manipulation may well be regarded by the educated as the more 'correct way' to go about a solution; and I am sure you will gain very intimate knowledge of manipulating the projection/modelview matrices on the way to a solution (share it with us if you go this path won't you?).
My suggestion above is quick, simple and effective ( and works well for us); the use of Matrices may be more 'correct', takes more work, time, knowledge, code and data (if that suits you). So at the very least hopefully I provided a viable option. Let us know.

Are you zooming differently to the sample above?