3d Window Lagging

Please Help me, I have a program that displays fps in all OpenGL and D3D Process (Such as Counter-Strike, or in this case Hammers 3D Window). It says it's running over 100fps, but it still lags, it's not greatly annoying but still, it's not nice.

It still continues to lag on flat mode (orginally on texture mode), but the fps sores in 200's . As i said plz help!

Oh, i have AMD Ahtlon 64 3000+, Radeon 9800 pro and 512mb RAM (DDR 400, is the ram the problem?)

I think this might be because the number of visible solids is too high.
i.e the map you're trying to load is too large and complex, or it's
constructed really badly.

My suggestion would be to use VISGroups to cut down on the number of
objects visible at once. Just keep the area you are currently working
on in the view and hide the rest.

Sounds like some sort of strange incompatibilty problem to me... I never ever use vis groups and never have, and I never get that much slowdown. Just for the record, my PC isn't as good as yours!

The map im making is tiny, is it anything to do with my 64-bit processor?

Update your drivers, maybe.

its not a 64 bit issue, my 3d window works smooth. after the initial loading.

anything hammer related of this nature is usually driver related.

you may also have your undo's set to high, the default is 50, reduce it to 5. i never did figure out why anyone would need 50 :/

Maybe you can try to reduce the back clipping plane value to 3000 or lower, and model render distance to 500 (if you're using Hammer with model support). It helped me, I have an Athlon 64 2800+, 512 MB RAM DDR 400 and ATI Radeon 9600. This problem is caused by Hammer itself, not by the hardware at all. If this will not help, you can always use a different editor, such as Quark or Radiant.

P. S. Also try to use other FPS detecting program. :smile:

<DIV class=quote>
<DIV class=quotetitle>? quoting Orpheus</DIV>
<DIV class=quotetext>its not a 64 bit issue, my 3d window works smooth. after the initial loading.

anything hammer related of this nature is usually driver related.

you may also have your undo's set to high, the default is 50, reduce it to 5. i never did figure out why anyone would need 50 :/

</DIV></DIV>

Trust me, do a lot of huge mapping for a long time without compiling, then get an ALLOCBLOCK: FULL error.

50 undos is your best friend at that moment.

if you mapped so long, and failed to compile that you might need to back up 50 turns, then thats your own fault.

personally, i cannot remember 50 turns back, so it would be useless to go back to that point. :/