> Even the oldest hardware that > supports OpenGL programmable shaders implements vector operations, and > a vector multiply-add has, as far as I know, the same cost as a scalar > operation. On the other hand, the shader compiler might be able to > combine multiple scalar interpolations into vector ops.
... in which case we'd see a sudden jump in performance whenever we fill a new vector, so assuming the larges vector size is a vec4, having 6 or 8 varying float wouldn't make a difference but having 9 would require to start a new vec4 and cost extra. Should be easy enough to test... thanks for the explanation. > But never rely on something like this in a renderer. Well, we do need the local 'up' direction in the renderer badly (light, fog, snowline,...) so when we can't rely on z being up, we need to transmit that info in a different way. Any suggestions? Speaking of which - it'd be nice to have local north as well defined direction as well - that would allow for things like the snowline being higher on south slopes or different tree cover on north and south facing slopes. * Thorsten ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
