Hi Stuart, I like the 3dclouds, so i took a look at them. This is a patch for you and maybe some brave developer. It's really not usable. First, some notes. Please excuse the telegram-like prose, I can barely read them myself now ------------------------------------------------------------- UFO # calls to void CloudShaderGeometry::drawImplementation(RenderInfo& renderInfo) const after X frames ------------ circles, diameter aprox one cloud square, i guess:
130k in
80k try resort
50k resort
50/130 ratio: 30%
------------
straight, v 900
136k in
5k try resort
4k resort
4/136 ratio: 2,9%
------------
straight, v 240
127k in
1.8k try resort
566 resort
566/127k ratio: 0,44%
-----------
drawable.updateCallback has the same problem,
too many calls per frame (aprox 19440) resulting in a 10ms update time.
Normal low is <1ms.
Curiosly the draw callback, which is done at the same frequency per frame
takes less time (approx. 6ms or less) which may indicate a heavy overhead
from
the scenegraph walking.
drawImplementation is called approx 163 times per frame (v=0), the
drawable/CloudshaderGeometry.updateCallback 19440.
The cloudshadergeometry sets are repeated in a 3x3 grid, that explains the
9x
factor (2160x9 = 19440).
drawImplementation is called only for culled (visible, non-culled) clusters.
options to use display lists:
- update callback to pre-sort, dirty display list in update callback
-> has excessive update callbacks (unculled stuff gets called).
- implement part of the display-list logic in drawimplementation
-> same number of callbacks as before, must set
_geometry->usedisplaylist = false
-> relatively small gains, can hiccup
-> i expect performance to be strongly dependant on driver revision
VBO:
- static vertex data, dynamic index -> resort only index array
- update dynamic data on dirty (sorting changed)
- ? use a single VBO for all clouds in all CloudShadersGeometry
-------------------------------------------------------------
Let me try to translate the telegram from mars:
I did a quick performance on the resorting behaviour. UFO, flying at
different speeds or in circles.
After N frames i checked the hit-counts on the breakpoints. Then some
sort-hit ratios were calculated.
It seemed like a display-list could be useful, seeming not too often are
clusters resorted.
1st try (is in the patch, but disabled) was to sort in the update traversal
and use the default
display list implementation (overriding virtual
Drawable::drawImplementation). This lead to an
impressive performance drop. Update callback is called for each cluster
attachment in the graph.
Each cluster is attached an extra 9x. I guess 2160 is the static cloud field
size. So instead
of only getting called on non-culled visible clusters it was called on each
cluster, 9x each :)
Same thing is happening in CVS right now: SGCloudFogUpdateCallback is called
19k times per frame
to update a single stateset. One time per frame is enough, this drops my
update time from 10ms to 1ms.
I noticed that there were some periodic rises in the draw time (clouds
callback), adding a random jitter:
skip_info->skip_limit += rand() & 3;
seems to take care of that part. In the patch it's in the wrong place, it
should be inside the if-block above it.
Next i implemented a display list (#define CSG_USE_DISPLAY_LISTS).
Results were unsatisfactory. Draw time increased. Even when just calling the
display list
the draw time is higher. This is disconcerting considering _geometry is
drawn with a display
list by default (AFAIK). Display lists are only regenerated after a
non-resort after a resort to avoid
the costly regeneration of the display list every consecutive sort.
I considered maybe it was a fill-rate problem. The patch does attach the
cloud fields twice.
Once it's rendered front to back, only the opaque part, no blending, normal
bin. Then it's
rendered back to front with blending (as usual). Performance was similar
(Radeon 3870).
I then avoided the call to _geometry->draw, suspecting something was costly
there.
I used some simple glVertex calls to generate similar, smaller, quads. Same
results, not faster.
I'm confused about these results. I must have made some programming error,
but even then
display lists could be faster than pure glVertex. The next approach should
be to set up
a VBO with all the vertex data and attributes for the whole cloud field and
only update the
index array when resorting. Less data to transmit to the GPU and 1 single
opengl call
per cluster or even per layer. The VBO changes are bigger than what I'm
willing to
do right now. Sorry.
Parts of the code are "#if 0 #else #endif", i use that to quickly try out
different combinations.
The display list part is not compatible with opaque pre-render, #if 0/1 out
as
apropiate. Ignore the changes to the GLSL programs.
Anyway, some of this code (fog update, jitter) could be integrated. The rest
could be useful
for your experimenting. The patch comes directly off my working copy and
contains a bit
of noise, please excuse that.
Oh, and all my clouds are black, so I guess this patch is messing something
else for good :)
HTH, greetings,
yon
On Sun, Nov 30, 2008 at 11:36 PM, Stuart Buchanan <
[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Attached is another clouds patch. This does the following:
> 1) Puts the 3D clouds in a cloud rendering bin, to reduce the transparent
> edge problem. Viewing 3d clouds against a 2D layer _above_ it now blends
> correctly. There is still a problem when viewing a layer below the 3d
> clouds, and I'm not sure if/how I'll manage to solve that. Thanks to Tim for
> pointing me at the correct code (again).
> 2) Performance improvement by calculating the Bounding box when the cloud
> is generated rather than ever time it is requested.
>
> Could someone please apply it to CVS.
>
> As always, please let me know of any (new) bugs you find. I'd also be
> interested if anyone sees a major performance improvement with this patch -
> I got a decent improvement with it (30 -> 35fps)
>
> I am aware of bug causing chess-boarding on stratus layers. I've still to
> track that down.
>
> -Stuart
>
>
clouds.patch.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
