Re: [Flightgear-devel] Shader optimization
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 ... In the Northern hemisphere ;-) Quite so - but once you have a north-pointing vector, the rest is trivial because you can pass geographical location as uniform and use that to compute the magnitude and sign of the bias in a one-liner... * 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
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 06:43:32 Renk Thorsten wrote: 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 ... In the Northern hemisphere ;-) Quite so - but once you have a north-pointing vector, the rest is trivial because you can pass geographical location as uniform and use that to compute the magnitude and sign of the bias in a one-liner... * Thorsten vec3(1.0,0.0,0.0) seems to be a pretty good aproximation. In my tests dot(normal.xy, vec2(1.0,0.0)) worked good enough. (for N hemisphere) Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. -- 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
Re: [Flightgear-devel] Shader optimization
Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera altitude as uniform and computing absolute vertex altitude from camera altitude and the vertical difference. :-) The current point seemed to be that Mathias says we _should_ not rely on that even if we evidently can. * 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
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 07:58:14 Renk Thorsten wrote: Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera altitude as uniform and computing absolute vertex altitude from camera altitude and the vertical difference. :-) The current point seemed to be that Mathias says we _should_ not rely on that even if we evidently can. * Thorsten Hint... I already knew that ;) -- 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
Re: [Flightgear-devel] Shader optimization
Hint... I already knew that In which case I'm puzzled by your remark that I wouldn't be interested in supporting custom scenery anyway when you know that I've cooked up a scheme which does just that. But maybe I'm simply too tired. * 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
Re: [Flightgear-devel] Shader optimization
Hi Thorsten, Renk Thorsten wrote: FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera altitude as uniform and computing absolute vertex altitude from camera altitude and the vertical difference. :-) The current point seemed to be that Mathias says we _should_ not rely on that even if we evidently can. Maybe it would be better next time to ping some more people and notify them about problems in the scenery toolchain. Emilian did it (http://code.google.com/p/flightgear-bugs/issues/detail?id=888) and we fixed the bug, which means that your additional calculations are unnecessary now for the official scenery anyway and for future builds as well. Chris -- 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
Re: [Flightgear-devel] Shader optimization
Maybe it would be better next time to ping some more people and notify them about problems in the scenery toolchain. Emilian did it (http://code.google.com/p/flightgear-bugs/issues/detail?id=888) and we fixed the bug, which means that your additional calculations are unnecessary now for the official scenery anyway and for future builds as well. Well... I only wrote three or four messages discussing precisely that problem on this list. Since I don't know who is working on what in scenery, it's a bit complicated to target that more specifically. Also, given the stance several folks take with regard to custom scenery, it's not clear to what extend asking to fix a problem specific for custom scenery would have met a warm reception. In any case, since the 'additional computations' are subtracting one number from another number, I can just about live with the performance degradation caused by the operation, given that it provides backwards compatibility to existing scenery. :-) * 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
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 08:58:43 Renk Thorsten wrote: In any case, since the 'additional computations' are subtracting one number from another number, I can just about live with the performance degradation caused by the operation, given that it provides backwards compatibility to existing scenery. :-) * Thorsten And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance -- 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
Re: [Flightgear-devel] Shader optimization
And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance A uniform float doesn't have a matrix transform. I thought you'd know that. * 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
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 09:31:27 Renk Thorsten wrote: And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance A uniform float doesn't have a matrix transform. I thought you'd know that. * Thorsten I'm talking about the ep ... which is done for each vertex, everytime -- 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
Re: [Flightgear-devel] Shader optimization
I'm talking about the ep ... which is done for each vertex, everytime ... and the relevance of that observation to the ongoing discussion is...? It's needed among other things to construct a sun/horizon coordinate system for the lighting computations, so the ep has to be computed regardless if we need a snowline or not (and the horizon has a special role in the later fog computations, so we can't do this easily in eye coordinates). Could you please make an effort to understand the scheme before criticizing it? Thanks. * 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
Re: [Flightgear-devel] Shader optimization
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
Re: [Flightgear-devel] Shader optimization
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 ... In the Northern hemisphere ;-) Regards, -Fred -- 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
Re: [Flightgear-devel] Shader optimization
Thanks for writing this up. I have a couple of comments, nitpicks really. On Mon, Oct 15, 2012 at 9:43 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I thought it might be a good idea to write up a few things I've tried recently and not seen in widespread use - so that either others know about them as well or I can find out what the pitfalls are. Basically this is about reducing the number of varyings, which is desirable for at least two reasons. First, their total amout is quite limited (I think 32?). Second, they cause work per vertex and per pixel, so their load scales always with the current bottleneck. Their actual workload is just a linear interpolation across a triangle though, so the optimization I'm talking about here is maybe all together 10-20% gains, not something dramatic, and it's not unconditionally superior to save a varying if the additional workload in the fragment shader is substantial. Also, the techniques are somewhat 'dirty' in the sense that they make it a bit harder to understand what is happening inside the shader. * making use of gl_FrontColor and gl_BackColor - gl_Color As far as I know, these are built-in varyings which are already there regardless if we use them or not. So if we don't use them at all because all color I don't think that any varyings -- except for the fragment coordinates -- are mandatory, except perhaps on very old hardware. Generally the total shader program is optimized to remove any unnecessary computations. However... computations are in the fragment shader, they can carry four components of geometry, if we use a color but know the alpha, there is one varying which can be saved by using gl_Color.a to encode it. I agree that using a coordinate in a varying that you already need is a good trick, better than assigning a new varying. One can assume that a vec4 varying is no more expensive than a vec3. By the way, we only encode the front/back facing info in alpha in order to get around shader language bugs. The prime example is terrain rendering where we know that the alpha channel is always 1.0 since the terrain mesh is never transparent. In default.vert/frag gl_Color.a is used to transport the information if a surface is front or backfacing, but in terrain rendering we know we're always above the mesh, so all surfaces we see are front-facing, and we do backface culling in any case. ... * light in classic rendering Leaving Rembrandt aside, the direction of the light source (the sun) is not a varying but actually a uniform. In case we need this in world space in the fragment shader, doing a lightdir = normalize(vec3(gl_ModelViewMatrixInverse * gl_LightSource[0].position)); in the vertex shader and passing this as varying vec3 is quite an overkill. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call world space the earth-centric coordinate system in which the camera orientation is defined. Due to the complexity of the coordinate system of the terrain, it's not clear to me how to get the world space light direction really into a uniform, but we do have it's z-component (the sun angle above the horizon) as a property and can use this as uniform. Since light direction is a unit vector, it means that only the polar angle of the light needs to be passed as a varying then, saving two components. We could include per-tile uniforms as state attributes in the scene graph if we decide that we really want them.. In particular for water reflections computed in world space, passing normal, view direction and light direction in world coordinates from the vertex shader (9 varying) is really not efficient - the normal of water surfaces in world space is (0,0,1) and not varying at all (we do have formally water on steep surfaces in the terrain, but we never render this correct in any case since in reality rivers don't run up and down mountainslopes and foam when they run really fast on slopes, and to worry about getting light reflection wrong when the whole setup is wrong is a bit academic), the light direction is really just the polar angle, since we later dot everyting with the normal we really only need the z-component of the half-vector, and that means just two components of the view direction - so it can in principle be done with 3 varyings rather than 9. I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values. On the other hand, if you can back all the lighting info into one varying,
Re: [Flightgear-devel] Shader optimization
One can assume that a vec4 varying is no more expensive than a vec3. (...) I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values I dunno... Just counting the number of operations, mathematically the best case scenario for interpolating a general vector across a triangle is in Cartesian coordinates where each coordinate interpolates as an independent number, so the cost of a vec4 would be the same as the cost for 4 floats. In any other case, like curved coordinates or Minkowski space, a Jacobian comes to bite and the vector is more expensive than just 4 scalar numbers. Now, what I don't know if there's some fancy hardware trick which makes a Cartesian vec4 as cheap as a float. In this case, we could use this by combining every four varying float into one varying vec4 and get the same job done for 25% of the cost. But... ... the thing I did try is that in adapting the urban shader to atmospheric scattering I ran out of varying slots, I needed two more varying float. I solved this by deleting one varying vec3 (the binormal) and computing it as the cross product - and that gave me the two slots I needed (and presumably one left, but I didn't try that). So this would suggest that indeed each vector component counts the same as a varying float. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Okay, I didn't know that... But pretty much all weather and environment-dependent stuff (ground haze functions, the wave amplitude for the water shader, overcast haze for the skydome,...) makes use of slowly but continuously changing uniforms (I think gl_LightSource is technically also a uniform), so it doesn't really make sense to have this old machine friendly code in one place in the shader but not in other places in the same shader. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call world space the earth-centric coordinate system in which the camera orientation is defined. gl_Vertex is in some coordinate system which I've usually encountered as 'world space' in shader texts as opposed to gl_Position which is supposed to contain the vertex coordinates in 'eye space'. I realize that gl_Vertex is *not* in the global (xyz) coordinates of Flightgear Earth, although I don't know how the two relate. Somehow once in the shader world, z is always up... Just a matter of semantics? I don't think that any varyings -- except for the fragment coordinates -- are mandatory, except perhaps on very old hardware. I remember at least one text claiming that once you use ftransform(), gl_FrontColor and gl_BackColor get values as well - but that source or myself may be mistaken. Cheers, * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Tue, Oct 16, 2012 at 12:05 PM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One can assume that a vec4 varying is no more expensive than a vec3. (...) I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values I dunno... Just counting the number of operations, mathematically the best case scenario for interpolating a general vector across a triangle is in Cartesian coordinates where each coordinate interpolates as an independent number, so the cost of a vec4 would be the same as the cost for 4 floats. In any other case, like curved coordinates or Minkowski space, a Jacobian comes to bite and the vector is more expensive than just 4 scalar numbers. Yes, I acknowledge that interpolating a vec4 requires more operations than interpolating a float :) Now, what I don't know if there's some fancy hardware trick which makes a Cartesian vec4 as cheap as a float. In this case, we could use this by combining every four varying float into one varying vec4 and get the same job done for 25% of the cost. But... That's the crux of it. I thought the answer was obvious, but it very much depends on the hardware. For a very long time graphics hardware has had to rasterize, i.e., interpolate, multiple values across screen space: depth, color, alpha, texture coordinates I just assumed that it would be no more expensive to interpolate vector values. However, this very good web page, http://fgiesen.wordpress.com/2011/07/10/a-trip-through-the-graphics-pipeline-2011-part-8/, contains this quote: Update: Marco Salvi points out (in the comments below) that while there used to be dedicated interpolators, by now the trend is towards just having them return the barycentric coordinates to plug into the plane equations. The actual evaluation (two multiply-adds per attribute) can be done in the shader unit. So the cost of interpolating values is indeed incurred as operations in the (prolog of the) fragment shader. 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. You can examine the assembly language for shaders if you want to see what's actually going on. I do recommend that web page and the others in the series; they are quite interesting. ... the thing I did try is that in adapting the urban shader to atmospheric scattering I ran out of varying slots, I needed two more varying float. I solved this by deleting one varying vec3 (the binormal) and computing it as the cross product - and that gave me the two slots I needed (and presumably one left, but I didn't try that). So this would suggest that indeed each vector component counts the same as a varying float. They do at the OpenGL API level, which doesn't necessarily correspond to the hardware implementation. One reason to pass this as a varying is that on old hardware, GeForce 7 and earlier, it is very expensive to change a uniform that is used by a fragment shader. It forces the shader to be recompiled. So, this is actually a well-known optimization for old machines. Okay, I didn't know that... But pretty much all weather and environment-dependent stuff (ground haze functions, the wave amplitude for the water shader, overcast haze for the skydome,...) makes use of slowly but continuously changing uniforms (I think gl_LightSource is technically also a uniform), so it doesn't really make sense to have this old machine friendly code in one place in the shader but not in other places in the same shader. True. Also, I want to point out that, in your example, lightdir is in the local coordinate system of the terrain, if in fact you are shading terrain. I would call world space the earth-centric coordinate system in which the camera orientation is defined. gl_Vertex is in some coordinate system which I've usually encountered as 'world space' in shader texts as opposed to gl_Position which is supposed to contain the vertex coordinates in 'eye space'. I realize that gl_Vertex is *not* in the global (xyz) coordinates of Flightgear Earth, although I don't know how the two relate. Somehow once in the shader world, z is always up... Just a matter of semantics? I think more usual usage for the local coordinate system is model coordinates. The model matrix transforms those coordinates into world coordinates; the view matrix transforms world coordinates into eye coordinates. In OpenGL, even in pre-shader days, we tend not to talk about world space much because there is (was) only one matrix stack, which contains the concatenation of the model and view matrices. z is always up is a matter of convenience. Z is up only at the center of a tile. The tile
Re: [Flightgear-devel] Shader optimization
On 16 Oct 2012, at 13:38, Tim Moore wrote: The tile data on disk is actually stored in a coordinate system that is aligned with the earth-centric system, so Z points to the north pole. We rotate the coordinates back to a local coordinate system because that provides a much more useful bounding box for intersection testing and culling... and also lets you program snow lines in shaders :) Uh, are you sure about that? My understanding is that the BTG coords on the disk are in 'tile local' coords, i.e 'Z is up' James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Tue, Oct 16, 2012 at 2:54 PM, James Turner zakal...@mac.com wrote: On 16 Oct 2012, at 13:38, Tim Moore wrote: The tile data on disk is actually stored in a coordinate system that is aligned with the earth-centric system, so Z points to the north pole. We rotate the coordinates back to a local coordinate system because that provides a much more useful bounding box for intersection testing and culling... and also lets you program snow lines in shaders :) Uh, are you sure about that? My understanding is that the BTG coords on the disk are in 'tile local' coords, i.e 'Z is up' James https://gitorious.org/fg/simgear/blobs/next/simgear/scene/tgdb/obj.cxx#line925 I don't have access to a local copy of the tree at the mo', but I remember that this was introduced by Mathias when he added BVH. Tim -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
De: James Turner On 16 Oct 2012, at 13:38, Tim Moore wrote: The tile data on disk is actually stored in a coordinate system that is aligned with the earth-centric system, so Z points to the north pole. We rotate the coordinates back to a local coordinate system because that provides a much more useful bounding box for intersection testing and culling... and also lets you program snow lines in shaders :) Uh, are you sure about that? My understanding is that the BTG coords on the disk are in 'tile local' coords, i.e 'Z is up' BTG are in cartesian coordinates and are rotated at load time here : http://gitorious.org/fg/simgear/blobs/next/simgear/scene/tgdb/obj.cxx#line923 Regards, -Fred -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
Hi, On Tuesday, October 16, 2012 15:17:04 Tim Moore wrote: I don't have access to a local copy of the tree at the mo', but I remember that this was introduced by Mathias when he added BVH. Yes. That is to align the bounding volumes boxes as well as the drawables bounding boxes to the earths surface - which makes most of them smaller on average. But never rely on something like this in a renderer. Mathias -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
