Can it be done? I''m shadowing a single high-polygon object using the 2-pass technique outlined in Lesson 28. When casting shadows, my frame rate gets locked at 60fps...it doesn''t matter if I significantly up the poly count, drop the resolution, or whatever. I''ve checked my FPS timer as best I can and, to my knowledge, its fine. I''m running a T-bird 800 w/ a GF2-MX (original), and my buddy has the same exact limit running on a T-bird 1000 w/ a GF2-GTS. When the object isn''t on the screen, FPS jumps to ~120. Any ideas? I know there''s a 1-pass method some people have been talking about, but I haven''t seen a really good example of how it works yet. Any help would be very appreciated!!

60/120 FPS ? VSync. Turn it off. Problem solved

/ Yann

I can't disable VSync b/c this is going to be a stereographic presentation, but my monitor maxes out at 120hz (at 800x600, the screen res I'm using). I'm using the RivaTuner hack that forces screen modes to the max refresh, too, so that shouldn't be a problem. And when shadows/stencil buffer are disabled, I get ~100 FPS. As far as I can tell, its definatley in the shadows...

[edited by - safe_haven on April 8, 2002 5:57:54 PM]

If your refresh rate is eg. 120Hz, then your app might at 120 fps without shadows. Now, if you activate shadows, the framerate might perhaps drop to something like 119fps. But because of vsync, it will resynchronize to 2 refresh cycles (since 119fps are not high enough for a single 120Hz cycle: 119 < 120), and you'll end up with 60fps (120Hz / 2 refresh cycles = 60fps).

If you *need* vsync (eg. for stereo glass synchronization), then this is not fixable. You'll have to live with the 60fps or try to optimize your 3D engine, so that it goes just over 120fps with active shadows.

/ Yann

[edited by - Yann L on April 8, 2002 6:06:36 PM]

When did 60 fps become a bad thing, anyways?

Yann: Yiii, I didn''t realize the system was that limited. That puts things in a better (though very depressing) light. This could get ugly...

Anon: One of the joys of stereo presentation is that it cuts the effective framerate in half, since you have to render the scene twice. So with the VSync limitation, I guess I''ll have to push the spec to 120fps just to get 60...and since the whole point of this program is to be quasi-VR (in a veeeeeery limited sense) I want to keep the frame rate around 40-50, which translates to 60 now. Woo-hah!

Thanks again Yann..

quote:

---

Yann: Yiii, I didn''t realize the system was that limited

---

Well, I wouldn''t call it a limitation. That''s the way vsync works. If you want retrace synchronisation, then that means that you simply can''t draw more than one image per refresh cycle. You have to wait until the electron beam finishes the previous image, and since it does that at a fixed rate, you can only get frame times being multiples of the refresh time.

You could perhaps try out triple buffering, under certain circumstances this can decrease the impact of the vsync limitation.

Now you know why ''real'' VR systems (aka SGI) advertise a minimum refresh rate of 240Hz (and they have an additional framebuffer queue that replaces the normal double-buffer, so they aren''t that prone to vsync locks)...

Good luck

/ Yann

Another idea:

Run your app in mono-mode, without vsync. See how many FPS you get with shadows. Say, it''s something like 103 FPS.

Now, turn vsync on again, and *reduce* your refresh rate at the highest value that is just *below* the framerate your measured before. In this example, reduce your refresh rate to eg. 100Hz.

Now the refresh rate will be under your frametime, and you will get full 100 FPS, or 50 FPS in stereo mode.

Sometimes it can be beneficial to reduce the refresh rate, when dealing with vsync...

/ Yann

Actually, what I''m going to try to do today is put a check at the beginning of my render cycle to see if I''m ahead of/behind where I should be to maintain a rate of over 120 or so...then have it drop frames if I''m behind. That way I should keep my maximum FPS without crippling any better rates I might be able to squeeze out at a given point. How feasible does this sound?

An idea would be to use the color buffer instead of the stencil buffer to do the stencil calculations; then you''re able to reduce the resolution to save fillrate (if you''re fillrate limited, that is). In some situations it can be up to 3 times faster than the "standard" stencil shadow algorithm.

Y.