thank you all for the performance hints, as far as i have understood you, i
should try to move from a "geode->addDrawable(createSingleTreeSprite)" to a
"geode->addDrawable(createMultiTreeGeometry(Cell)).
with that approach also different tree geometry (width/size) should be possible
without per
Hi Cristian,
For best performance clumping geometry together into a smaller set of large
tree clusters would be best. As Roland says the osgforest example does
flesh out all the different approach that one can use, and misses some that
provided the best performance such as clustering lots of tree
> VBO's are better for dynamic geometry, but do have a higher CPU overhead than
> display lists.
Remember that display lists are deprecated in OpenGL 3.0 and moved into an
extension in OpenGL 3.1. The advised path is using VBO's...
> refering to osgforest as example ...
I am not too happ
hi,
refering to osgforest as example, is a method like createTransformGraph, where
the different looking trees are based on the same (scaled) tree model better
from a performance point of view? i mean better than the two other fixed
pipeline methods in this example
thanks in advance,
christian
Hi Christian,
VBO's are better for dynamic geometry, but do have a higher CPU overhead
than display lists.
However, whether you are using VBO or not, you probably still don't want to
modify any geometry. It's far more efficient to updating vertex position
via vertex shaders. I know too little a
Hi,
i have a question about using VBOs and Display Lists in osg
according to my OpenGL book, both methods will optimize rendering due geometry
is moved to the graphics-hardware. it also says, a constraint when using
display lists is, that data can't be changed afterwards. so its great for
ren
6 matches
Mail list logo