Hi, On Mon, Dec 15, 2008 at 6:00 PM, Heiko Schulz <aeitsch...@yahoo.de> wrote:
>
> Theory vs praxis ;-) I just tested it- no, more sprites = less fps
Are you testing with drawing off? Where do I change the number of sprites?
heh, so many .xmls
What is your CPU?
If you feel so inclined, try commenting out the part in
CloudShaderGeometry.cxx that does the draw and
measure the difference for say, doubling the number of sprites in a cloud,
or multiplying it by 10.
> Sounds very promising!
>
Attached. I saw some changes in pa24-250 and was, err, QA testing it,
yeah. Nice one.
OTOH bluebird was a bit uninteresting for me ;) I prefer unesco ufo.
Anyway, from some comments in ShaderGeometry.cxx:
--------------8<-----------------------8<------------------8<------------
//if enabled:
// no VBOs are created
// -> less RAM usage, a few less FPS
// -> more stutter
//if not enabled
// VBOs are created
// -> RAM usage explodes, easily noticed if tree coverage is multiplied
(obj.cxx)
// -> a few more FPS
// -> less stutter
// Notice that in both cases there is a memory penalty. The
// memory will be allocated, either for the display list, possibly
// in GPU memory, or in app RAM (and then copied to the GPU mem VBOs)
//best subjective stutter results are:
//VBOs ON
//export OSG_COMPIlE_CONTEXTS=ON (notice small-case l)
//export OSG_DO_PRE_COMPILE=ON
#define CREATE_OWN_DISPLAY_LIST
/////////////////////////////////////////////////////////////////
// Ignore, some random testing.
//#define USE_INTERLEAVED_ARRAYS
// Use with this->setUseDisplayList(true), it will deallocate the array
// after the 1st call (pre-compile or 1st draw).
// So not multi-context safe.
// If we manage our own VBO, we could use a single array
// that we would free after the 1st draw or more likely
// after it has been drawn/compiled on all GL contexts.
// If we can get a list of context and we know that list
// is static we can go this route and not suffer from RAM
// usage explosion.
// Also, if osgDB precompile was disabled (like in the Dec 15 2008 patch
// to OSG) the memory would not be freed. We should force
// pre-compile in that case to free the vertex-pack arrays memory
// allocated on osgDB load
--------------8<-----------------------8<------------------8<------------
So, play with "#define CREATE_OWN_DISPLAY_LIST"
This VBOs implementation will eat your RAM, specially if you
run with obj.cxx:
coverage /= 10.0;
//10.0 is forests, 4.0 is ok for testing, 1.0 is default
I was arriving at 3 GBs in 100km over forests (ufo). Alas, both with
DL and VBOs i was running at 150fps+ (fov 120).
Today's OSG patches disable pre-compile for osgDB objects. I suspect
this will generate more stutter. I run with the config mentioned in the
comments above, also, the default osgDB threads config (and the one
we run with) is 1 osgDB pager thread and 1 osgDB HTTP pager thread.
I sometimes run with the config:
OSG_NUM_DATABASE_THREADS=3
OSG_NUM_HTTP_DATABASE_THREADS=0
Also, im running with the osgDB threads priority set to MIN (dual-core
here).
In closing: the display list implementation could be trivially merged. The
VBOs
stuff is more for the coders. If we can get the number of GL contexts both
known
and static, we can control the RAM usage of VBOs.
greetings,
yon
trees-VBO-DL.patch.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
