A few other tips:
If framebuffer bandwith is the problem, try reducing the resolution of
your viewport.
If texture bandwidth is the problem, try using simpler blending (not
trilinear/anisotropic) or smaller textures.
You should be able to figure out how much overdraw you have, then
calculate the amount of pixels/second and bytes/second your app requires
when zoomed in (slices * resolution * num read/writes (framebuffer +
texture)). Compare that to the specs of your hardware and see how close
you are to the limit.
I've also recently noticed that RenderAction::stop() calls glFinish().
This could perhaps affect the framerate if your application uses both
cpu and gpu heavily, since they won't be able to work in parallell
(glFinish() waits for all queued renderings to be completed, while the
cpu simply idles. It shouldn't really be called at all in a realtime
system, but it is used for statistics here.). Try commenting that away
or override stop() and see if that helps.
Regards,
/Marcus
Matthias Stiller wrote:
Not that my answer is helpful in any way, but you could shop for faster
gfx hardware (SLI maybe ?):)
Regards
Matthias
On Wednesday 23 November 2005 16:44, Thomas Beer wrote:
I think this is because of the alpha blending of all slices - it's
simply more pixels to blend when you get nearer. No idea how to make
this faster, though!
Vincent Honnet wrote:
Hello,
I have a question concerning the volume rendering: if the camera is
far from the volume the framerate is about 30 or 40 Fps, if the
camera is near of the volume the framerate decreases to 15 Fps. Is
that normal ? It could become a problem for me with stereoscopic
visualization.
Thanks a lot.
Vincent
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified
Today Register for a JBoss Training Course. Free Certification
Exam for All Training Attendees Through End of 2005. For more info
visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files for problems? Stop! Download the new AJAX search engine
that makes searching your log files as easy as surfing the web.
DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
