[Flightgear-devel] Rendering passes question
May I ask yet another dumb question? In the first rendering pass of default terrain rendering, we use default.vert and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first pass since I had no real clue as to what it is for. Its purpose seems to be to establish that faraway scenery is not rendered in front of nearby scenery (I think Fred called this 'initializing the z-buffer'). My question is - why do we use shaders which texture and fog the terrain at this stage? Every texture2D() statement seems to cost me ~12% of my framerate. I've experimentally replaced default.vert and terrain-nocolor.frag by trivial.vert which is just ftransform(); and trivial.frag which is just gl_FragColor = vec4 (1.0, 1.0, 1.0, 1.0);, and apart from my ~12% increase in framerate I haven't seen any bad side effects - the z-ordering of scenery looks sane, fogging, texturing and colors work normal,... So, was there a reason we texture and fog during the first pass and should I see any unexpected side effects, or can I simply use the trivial shaders and get my 12% framerate? Thanks, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
On Wed, Jul 18, 2012 at 8:27 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: May I ask yet another dumb question? Yes, although this isn't a dumb question. In the first rendering pass of default terrain rendering, we use default.vert and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first pass since I had no real clue as to what it is for. Its purpose seems to be to establish that faraway scenery is not rendered in front of nearby scenery (I think Fred called this 'initializing the z-buffer'). This is an optimization to avoid running really expensive shaders on geometry that will be hidden from view. The GPU has an early Z capability and won't run a fragment shader if it knows the result will be discarded. Of course, to be effective the shaders run when the depth buffer is filled need to be fast :) My question is - why do we use shaders which texture and fog the terrain at this stage? Every texture2D() statement seems to cost me ~12% of my framerate. I've experimentally replaced default.vert and terrain-nocolor.frag by trivial.vert which is just ftransform(); and trivial.frag which is just gl_FragColor = vec4 (1.0, 1.0, 1.0, 1.0);, and apart from my ~12% increase in framerate I haven't seen any bad side effects - the z-ordering of scenery looks sane, fogging, texturing and colors work normal,... So, was there a reason we texture and fog during the first pass and should I see any unexpected side effects, or can I simply use the trivial shaders and get my 12% framerate? The main reason to render textures at this stage is that textures with transparency do change the fragments that are rendered. Calculating the fog color seems wrong, but I don't have the sources in front of me and gitorious is acting up. one texture2D() call - 12% framerate drop seems a bit excessive. What is the time difference in milliseconds? Hardware? Tim Thanks, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
The main reason to render textures at this stage is that textures with transparency do change the fragments that are rendered. Calculating the fog color seems wrong, but I don't have the sources in front of me and gitorious is acting up. So since we're not using transparent textures for terrain, it should actually be okay to drop the texturing as well? one texture2D() call - 12% framerate drop seems a bit excessive. What is the time difference in milliseconds? Hardware? The GPU is an nVIDIA GeForce 8600M. I usually do benchmark testing spawning with the ufo at given location and altitude and set visibility to a standard value. That produces very consistent results and reproducable framerates for me, so I can gauge the impact of a change. In this instance, I compared the simple haze scheme (with only the terrain texture) with the detailed scheme to which I successively added snow texture, detail overlay texture and mix texture. Since that slowed the code quite a bit, I started commenting things out while benchmarking, and most of the time is burnt by just looking up a texture even if I don't do anything with it. I don't have any precise timings for just the texture2D() call. Also, I should remark that for this test the framerate is completely determined by how fast the fragment shader executes, i.e. I have tested for relatively low vertex count and no clouds. The framerates (ufo in 1200x900 window) ranged between 49 and 31 fps, in real-case tests with the F-16 in 1920x1200 fullscreen mode between 20 and 11 fps. When I leave the texturing out in the first pass, at startup I get 22 fps instead of 20. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
So, was there a reason we texture and fog during the first pass and should I see any unexpected side effects, or can I simply use the trivial shaders and get my 12% framerate? The main reason to render textures at this stage is that textures with transparency do change the fragments that are rendered. Calculating the fog color seems wrong, but I don't have the sources in front of me and gitorious is acting up. For instance, drawing the bridges without textures will show a wall instead of the suspension chain, the strands and the iron structure. I had the same problem rendering to the shadow map. So you won't see a boat behind through the structure or between the strands if you don't render the alpha-tested transparency embedded inside textures. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel