Your right, I should profile it before making early judgments, but at the same time I have to watch out going down a path of refactors.  I am only assuming because there could be 20-30-40 different units in the same scene all animated.

I am trying to accomplish this type of system without actually doing a raycast, and trying to keep everything as 2D math.  I was thinking I could precalculate a tilemap(based on some floor mesh) for the entire level and store height for a x,y lookup and interpolate between tiles.  But this quickly runs into issues because the floor mesh that this tilemap is based on doesnt really guarantee the tilemap is proportional(same triangle face sizes), unless its built that way, which could be meticulous...

 Ill figure something out, thank you for the ideas and tips.

40 units is peanuts. I think you underestimate exactly how quickly modern CPUs can do math, especially simple math like a barycentric triangle interpolation. Trying to be too clever and doing something like replacing a simple calculation (fast) with something like a table lookup (likely slower due to cache miss or memory bottlenecking) is exactly why it is common to warn people against premature optimization.

Okay great! Actually I was assuming the raycast was starting from camera position (because I was thinking about Full Screen Quad Ray Marching).

One silly question for you...

In a nutshell I basically would be converting screen clicks into 3D Space, but exactly how do find the triangle i clicked, and most importantly the position i clicked within the triangle face?

9 hours ago, IndieGuyy said:

In a nutshell I basically would be converting screen clicks into 3D Space, but exactly how do find the triangle i clicked, and most importantly the position i clicked within the triangle face?

This is a totally different question and really deserves its own thread, but it is often called 'picking' if you want to google this.