Test my terrain engine, bug on NVidia cards
Author
I'm having a wierd problem with my geomipmapping terrain on Nvidia cards. If I switch to using glDrawRangeElements instead of glDrawElements, then on a Geforce 4 TI 4400 and a Geforce 4 400MX, the terrain looks like a really long horizontal strip. Its very weird. But if I switch back to glDrawElements, its fine.
Could you guys test it on your machines for me? Also, if it does run, what FPS are you getting?
Also, the heightmap is 1024x1024 and the texture is 2048x2048, both of which are taken from FarCry.
http://cs.selu.edu/~soconnell/geomipmapping.rar
this may be stupid mentioning, but i've been messing with indexed VBOs all day and came across this tidbit from nVidia: glDrawRangeElements use 16 bit ints so you could be going out of range or something.... glDrawElements use 32 bit ints.
hi,this demo could run on my machine with fps of 85 and patch count of 205.However,the terrain seems wrong,there is no texture on it.And the water appears and disappears with the rotation of mouse.
By the way,Have you use QuadTree to optimise your engine?
By the way,Have you use QuadTree to optimise your engine?
Author
Thanks for the info jm_hewitt, I am using a 32bit integer for the index, but I don't know why it wouldn't just convert to 16bits. I'll have to test it out.
winsoft2003, what type of video card are you using? The texture is about 20MB, cause its 2048x2048 and it creates mipmaps in video memory. Do you have enough memory on your card?
Also, the water disappears b/c I have fog enabled and the entire water plane is a single quad, so there are not enough vertices to calculate fog correctly.
winsoft2003, what type of video card are you using? The texture is about 20MB, cause its 2048x2048 and it creates mipmaps in video memory. Do you have enough memory on your card?
Also, the water disappears b/c I have fog enabled and the entire water plane is a single quad, so there are not enough vertices to calculate fog correctly.
Quote:Original post by oconnellseanm
winsoft2003, what type of video card are you using? The texture is about 20MB, cause its 2048x2048 and it creates mipmaps in video memory. Do you have enough memory on your card?
you could try without mipmaps. abusing your terrain and texture (btw. as compressed texture its just 2mb) it is stretched so much that not using mipmaps will still look fine (ie. its probably using the mag filter all the time anyway).
Quote:Also, the water disappears b/c I have fog enabled and the entire water plane is a single quad, so there are not enough vertices to calculate fog correctly.
shouldnt fog be applied per fragment? or am i spoiled by shaders and such? hm, dont think so, the ARB_fog_whatever options create weird results.
running well btw., just.. could one start somewhere else or at least move faster? it takes forever to get anywhere interesting on that map ,-)
Author
If you hold "Shift" you can run faster, and if you hold "SHift + "ALt" you run even faster.
Also, I'm only using linear fog at the moment and its per vertex, not per fragment.
I'll have to try it without mipmaps though, you think it will run faster or something?
Also, I'm only using linear fog at the moment and its per vertex, not per fragment.
I'll have to try it without mipmaps though, you think it will run faster or something?
Quote:Original post by oconnellseanm
If you hold "Shift" you can run faster, and if you hold "SHift + "ALt" you run even faster.
i need to play more ego shooters.. shift should have been obvious ,-)
Quote:
Also, I'm only using linear fog at the moment and its per vertex, not per fragment.
hm, strange. i would expect the fog coord to be interpolated/calculated per fragment for the blending. but then, at least on my ati fog is weird enough and producing the strangest results (i liked the stripped terrain though).
Quote:
I'll have to try it without mipmaps though, you think it will run faster or something?
not really, depending on whats really happening. if the texture is magnyfied 99% of the time it simply wont use the mipmaps anyway. if you run at say 1024x768 you would need to look straight down and half the terrain needs to fill less then the sceenwidth for it to use mipmaps. just experiment, compare the speed and check if the parts far away show disturbing flickering. it can safe some texture memory (though using compressed textures would safe more).
Author
Yeah I just changed it to using GL_LINEAR instead of mipmaps and there's no noticeable difference in the pixellation. Of course, when I change the detail texture you can see pixellation, so I just keep that as a mipmap.
But no speed improvement.
But no speed improvement.
Quote:Original post by oconnellseanm
But no speed improvement.
as expected. its still doing the same operations on the same data (except maybe trilinear filtering which all current drivers probably "optimize" away in this case anyway). you just save half the memory by not having the useless mipchain. if it WOULD have heavily used the mipmaps it might even have gotten slower.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
