pointToWindowCoordinates : function (modelViewProjectionMatrix, viewportTransformation, point)
None of these really “go” together and I think it may be better to get rid of Transforms altogether and move them elsewhere. For example, maybe the first 3 would be better to have on Ellipsoid. I think the last one is too low-level and doesn’t do much; it’s also only used in CentralBody. I think we should make it a private function there and replace it with a new high-level function on Scene that just takes a point in world coordinates. (the new function would work in all 3 scene modes).
On a related note, Matrix4 has a whole bunch of “compute” functions that are similar to the Transform functions, so if we don’t want them on Ellipsoid, that would be the next best place.
Funny, if we were to go through the history, eastNorthUpToFixedFrame was actually on ellipsoid long ago. I’m not sure that I’d put it back because (1) conceptually does it make sense for an ellipsoid to do these transforms and (2) it will require callers to explicitly have an ellipsoid instance unless we also make it a non-prototype function.
I wouldn’t put it on Matrix4 because, again, conceptually should a 4x4 matrix know to to convert from TEME to psuedo-fixed? It sounds like we’re putting something pretty high-level with something really low-level. The same could be said of the compute functions for projection matrices, etc., but considering this is a graphics library, the argument is not as strong.
From a graphics perspective, I suppose the way these functions go together is the first three are all reference frame transformations from a model coordinate system to the world, and the last function transforms from model to window coordinates.
I don’t feel strongly one way or the other, but perhaps we just leave it as is, and as we get more of these functions, if it makes sense to move them, we will (for example, what if it is a transform between two frames that does not require an ellipsoid? Sounds like Matrix4 is the right place over Ellipsoid in this case.). Let’s create an issue for pointToWindowCoordinates, so Dan and I need to continue to focus on the multi-frustum.
I’m perfectly fine with taking a wait and see attitude, so I’ll just clean up and document what’s there for now. I will mentioned that for me, it makes sense for those methods to be on ellipsoid, but I’m probably used to it because that’s how Components does it. Also, in the context of this discussion, all of the Matrix4.computeXXX functions seem out of place as well.