[Flightgear-devel] Rendering passes question

2012-07-18 Thread Renk Thorsten

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

2012-07-18 Thread Tim Moore
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

2012-07-18 Thread Renk Thorsten
 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

2012-07-18 Thread Frederic Bouvier
  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