mhagain:

You understood me bad - I am loading from .obj just initially after I model some thing in Cinema4D and export it. Then I have a function in my engine that already saves a map in my own format, which saves every number as bytes, plus there is also space partitioning saved in that file. I dont know what exactly you mean with memory-mapping a file, but from name it sounds that it would only work for static arrays of classes, and not for linear linked list of dynamically allocated classes as I have. I like .obj cause its intuitive and readable and there is no reverse engineering about format specification.

PVS are really good idea, I like it. I will definitely try it. I am thinking of making special class for that, which is some box area and list of other box areas that are potentially visible. In map editor, the user will choose these manually so there will be no need to make some extra complicated code that determines what is visible from where (even if THIS is exactly the point where occlussion culling would be useful...) and also no need to compile a map like this after every change.

dpadam450:

Comp where it was tested is Asus X751L. Has Nvidia GeForce 820M, Intel Core i7-4500U 1.8GHz, 12GB RAM. I think hardware should be enough OK.

And yes I am using vsync, thats why I get 60fps. Previously I heard that 25fps is OK, but truth is that you feel subliminaly that something is wrong. I choose 60fps. The texture of triangles was just 32x32. When I put there some 256x256 texture, framerate is same (so there is so far no need for mipmapping).

Your image looks nice, I even see you have some shadows. Perhaps I could make similar benchtest like that and test on it.

I got next idea that I will implement some multithreading (theoretically less then 4x speedup when done correctly). Do you guys use it in your games?

I choose 60fps. The texture of triangles was just 32x32. When I put there some 256x256 texture, framerate is same (so there is so far no need for mipmapping).

Any other good reasons for this ? Actually you might not see any differences, but maybe later, you will notice a performance drop, and you'll spend days (and certainly a lot more) to detect that this is due to the fact that you don't use mipmapping. One big reason for this is that you currently use vsync. So as long as your GPU can afford things, you'll have 60 fps, but once it won't, you won't get 59 fps or so, you'll end up with 30 fps...

Mipmaps is just a factor of few more lines in your code.

Of course, it (almost) double the memory requirement for all your images. But except if you really target to use most of your VRAM for your geometry (and other buffers), I don't see any real good motivations by not using mipmapping.

Mipmapping is not only a performance thing; it's also affects image quality

Right. But one could notice aliasing effects more easily. Aliasing on a textured object could probably means a texture issue (or depth issue, right). But a sudden FPS drop can have many reasons.

Mipmaps don't use almost double the memory - they use one-third extra.

Right too. I'm still wondering how I could reach such a result...

How much faster should be VBO compared to glBegin/glEnd?

Cause with glBegin/glEnd I got 41fps and with VBO like 43fps in same point. So yes, it IS faster, but honestly I expected more improvement, since its one of main tips people give you on optimization of displaying. The speedup will probably vary depending on type of rendered stuff, but I dont know where it helps most. Another 2 problems (minor problems, I can survive these) is ugly syntax compared to glBegin/End and fact that when you create VBO for some object that changes geometry, the VBO doesnt change with position of vertexes, so you must reupdate positions that are previously copied into the data buffer.

the VBO doesnt change with position of vertexes, so you must reupdate positions that are previously copied into the data buffer.

The best thing, as far as you can do it, is to let the vertex shader do these calculations.

How much faster should be VBO compared to glBegin/glEnd?

It depends on many things. And this might be related to the fact that you update the VBO each frame with new vertex positions.

If you want/can live with GL immediate mode, then why not. But you must be aware that immediate mode is deprecated since GL 3. For example your code won't work on Apple machines, and on mobile devices neither.

Recently I have done the networking and tested it by first deathmatch ever. But the performance on other comps than mine is still one of big problems. I figured out, that when I replace item models with simplified ones, I get OK fps, but thats a wimpy solution.

Also - mipmaps have been implemented. Adjustable LOD bias has no effect on performance, even if set as high (like 9) that textures fade into single color.

It is sow really in glBegin/glEnd when switching textures. Texture sorting helped a bit, but not totally. So I packed all my textures to one big, and before compiling a map i will do just linear fix for texcoords to make their xy ranges in big texture. Trouble is that it will not repeat or wrap anymore, and I need that. Texcoords outside 0..1 will continue in big map through other textures, which is what I dont want. I was looking on Internet for solutions, but there is nothing. My idea is to somehow get into place in memory where texture is stored and manually hack width and height and starting pointer, to make it think that its actually just a region of itself. There will be complication with mipmaps, but thats not the immediate problem. Also textures will have to be stored not in image as I see it, but lineary after rows, so program could read it. I have dilema if I should go for it or no, cause maybe there is function like that - I just looked not enough. Anyone knows a functions that draws only region of texture? I care only about those WITH PRESERVED ABILITY TO WRAP OR REPEAT - the answer TexCoord2f(0.5,0.5) really is not what I am looking for :D