constant object screensize

Hi,

I having difficulties to find which properties to access in order to efficiently resize gizmo line for example so that they get a constant screensize very much like the manipulation tripod when manipulating objects.

Thanks,

Jean

 

Transform your position into camera space, then set the z value to a certain constant like 0.5. Then build lines in camera space from that point, and transform it back into world space. For reference on how to do this, read up on the Camera class here: http://unity3d.com/Documentation/ScriptReference/Camera.html

Edit: Actually aras' idea is probably a lot better. camera.current should be Camera.current though.

 

bang on Aras, thanks

I might however have to build something like you suggest Yoggy because I'd like my gizmo to be visible at all time and not hidden by geometry ( which is another problem than the scaling), I haven't looked at camera rendering strategy to see whether I can draw my gizmo after everything tho, any thoughts on this?


Jean

 

Hi Aras,

I am drawing gizmo in the scene view for now, but it is very likely that I will need such feature in the game view as well since I am building technical applications not games.

your opinion on both implementation is welcomed!

Jean

 

Ok, that's doable then.

I am not good enough just yet to play with shaders, but when it will be needed I'll remember where to look.

Thanks again,

Jean

 

I dug into this subject, and here are my findings:
I made an optimized version of Unity's HandleUtility.GetHandleSize(), which (Unity's) implementation you can find here: https://github.com/Unity-Technologies/UnityCsReference/blob/2020.1/Editor/Mono/HandleUtility.cs
Here is my version which I made for my asset Curvy Splines. It does the exact same thing, but is greatly optimized:

Code (CSharp):

1.  
2.         /// <summary>
3.         /// Much like HandleUtility.GetHandleSize(), but works for gizmos
4.         /// </summary>
5.         /// <param name="position"> handle position in world space</param>
6.         /// <param name="camera"> the camera through which the object is displayed</param>
7.         /// <param name="cameraCenterWidth"> camera.pixelWidth * 0.5f</param>
8.         /// <param name="cameraCenterHeight"> camera.pixelHeight * 0.5f</param>
9.         /// <param name="cameraPosition"> camera.transform.position</param>
10.         /// <param name="cameraZDirection"> camera.transform.forward</param>
11.         /// <param name="cameraXDirection"> camera.transform.right</param>
12. public static float GetHandleSize(Vector3 position, Camera camera, float cameraCenterWidth, float cameraCenterHeight, Vector3 cameraPosition, Vector3 cameraZDirection, Vector3 cameraXDirection)
13.         {
14.             //inlined version of Vector3.Dot(positionMinusCameraPosition, cameraZDirection)
15.             float z = (position.x - cameraPosition.x) * cameraZDirection.x +
16.                       (position.y - cameraPosition.y) * cameraZDirection.y +
17.                       (position.z - cameraPosition.z) * cameraZDirection.z;
18.  
19.  
20.             Vector3 b;
21.             {
22.                 Vector3 camPosPlusDirB;
23.                 camPosPlusDirB.x = cameraPosition.x + cameraZDirection.x * z + cameraXDirection.x;
24.                 camPosPlusDirB.y = cameraPosition.y + cameraZDirection.y * z + cameraXDirection.y;
25.                 camPosPlusDirB.z = cameraPosition.z + cameraZDirection.z * z + cameraXDirection.z;
26.                 b = camera.WorldToScreenPoint(camPosPlusDirB, Camera.MonoOrStereoscopicEye.Mono);
27.             }
28.  
29.             float aMinusBX = cameraCenterWidth - b.x;
30.             float aMinusBY = cameraCenterHeight - b.y;
31.             return 80f / Mathf.Max((float)Math.Sqrt(aMinusBX * aMinusBX + aMinusBY * aMinusBY), 0.0001f);
32.         }

Some explanations and tips for further optimizations:

1. In my experience you can safely remove the Mathf.Max at the end of the function. It becomes useful only if the camera is ridiculously far from the object. I had to scroll for a minute to make the camera that far.
2. The function has a lot of redundant parameters that can be deduced from the camera parameter. Feel free to remove them. I kept them because I call this function up to tens of thousands times inside a loop. In those conditions, avoiding calling camera.transform.right at each call makes sense.
   
3. If you reaaaally need those extra milliseconds, use this after computing z:
   return z * 0.15f;
   This will give a good enough result. The problem with this method is that the handle size is unsatisfying when transitioning between Perspective and Orthogonal view, and when the scene view window is too narrow to the point that it changes the FOV of the scene view. Because of all the downsides, I am not using this implementation.

I hope this helps

 

You think it will help 13 years later?

 

If someone had answered with what I wrote until earlier this week, it would have saved me a day of work. So I have hope that this might save someone's else day in the future.

 

Fair enough

 

Hi,

Of course it helps throughout the years to update on topics, this is always welcomed.

Bye,

Jean