I haven't really been following this thread closely... are the "tracers" basically occludes? Are they completely opaque?
One possible optimization for the cloud rendering would be to use polygons that closely follow the outline of the sprite instead of quads; this saves on fill costs. Also, I'm pretty sure you don't want two-sided lighting for the tracers. Tim On Wed, Oct 24, 2012 at 8:53 AM, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote: > > I've managed to get a test implementation for the idea of filling the depth > buffer early by clouds by inserting tracers into some of the cloud calls. The > tracers are in essence just opaque white sheets marked with a top shade > factor of 0.0 (black - no real cloud can ever have that low a value). There > follow then two passes for cloud rendering - the first one does just the > tracers and basically passes by all real clouds, the second pass does not > consider tracers. During the first pass, depth buffer is written. Since > there's one tracer per 10-50 sprites and the operations done on the tracer > are bare minimum, the additional workload caused by tracer rendering is small. > > This has some quirks (the tracers become visible while the layer is drawn, > although they are normally hidden by the real clouds, tracers at the edge of > the range flicker,...), but it works... halfway. The depth buffer filled by > the tracers does have a notable effect on other clouds, but not on the > terrain. In numbers - in my benchmark situation I am halfway between a 2000 > ft high Nimbus layer and the terrain. I get 20 fps looking straight at the > horizon and 23 fps looking 30 deg up through the layer. With tracers I get 24 > fps looking straight and 38 fps looking 30 degrees up, i.e. I am doing way > faster to render the layer only. > > However, going above the cloud layer looking down, my framerate never > changes. Even if I render only the tracers and zoom in so that only a while > sheet is in my field of view (and no terrain pixels at all would have to be > done) my framerate is still the same as without the tracer. In other words, > the tracers in the depth buffer don't seem to work for the terrain, although > they do work for other clouds. I've tested that I am not vertex-shader > dominated by discarding half the pixels of the terrain in my field of view - > that gave a noticeable framerate boost, so there's something else. I attach > the effect xml for the additional first pass below. I'm not completely sure > about all the aspects, but... it does the job on clouds, so it can't be that > wrong. This should be done in render bin -1, i.e. before terrain. Very > similar code for trees does have an impact for terrain rendering, i.e. an > early tree pass does fill the depth buffer with effect on the terrain. > > What am I not seeing? > > <pass> > <lighting>true</lighting> > <material> > <ambient type="vec4d">0.5 0.5 0.5 1.0</ambient> > <diffuse type="vec4d">0.5 0.5 0.5 1.0</diffuse> > <color-mode>off</color-mode> > </material> > <depth> > <function>lequal</function> > <write-mask>true</write-mask> > </depth> > <render-bin> > <bin-number>-1</bin-number> > <bin-name>RenderBin</bin-name> > </render-bin> > <texture-unit> > <unit>0</unit> > <type>2d</type> > <image><use>texture[0]/image</use></image> > <wrap-s>clamp</wrap-s> > <wrap-t>clamp</wrap-t> > </texture-unit> > <program> > <vertex-shader>Shaders/tracer.vert</vertex-shader> > <fragment-shader>Shaders/tracer.frag</fragment-shader> > <attribute> > <name>usrAttr1</name> > <index>10</index> > </attribute> > <attribute> > <name>usrAttr2</name> > <index>11</index> > </attribute> > </program> > <uniform> > <name>baseTexture</name> > <type>sampler-2d</type> > <value type="int">0</value> > </uniform> > <uniform> > <name>range</name> > <type>float</type> > <value><use>range</use></value> > </uniform> > <vertex-program-two-side>true</vertex-program-two-side> > </pass> > > > Some other idea: If I extend the Nimbus layer all the way to 75 km visibility > distance, I eventually become vertex-shader dominated in which case tracers > are no longer a good strategy. It occurred to me that there's a fairly simple > scheme we could try for this situation: > > We assign a random number [0..1] to each of the sprites such that all four > vertices of the quad get the same number and pass that as attribute. Inside > the shader, we dynamically compute a threshold based on distance (or perhaps > better view angle) and check the random number against the threshold, so that > say for 50 km distance we render a quad only if its random number is above > 0.8, for 70 km only if its number is above 0.95. This would allow to > dynamically dilute the clouds as we go further out, the checks inside the > shader are computationally light and the visual effect should not be > pronounced as we see the clouds under a very shallow angle at large > distances. For very thin clouds which we don't want to discard, we can bias > the random number distribution at creation time. > > Stuart, is this feasible? There seems to be one free slot in the attribute > vectors. > > Thanks in advance for any additional insights. > > * 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 ------------------------------------------------------------------------------ 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
