I am making an engine that is rendering an immense amount of objects, and it works well
However, to make the engine handle even more stuff, i need to lessen the amount of RAM i use, for example
And most of all I want to increase rendering times. Thankfully my computer is quite crappy, so its easy to know what works and what doesnt.
Here is a couple of things on my current situation:
im rendering using vbo’s OR display lists
display lists are faster atm
glDrawArrays (float u, float v, short x, short y, short z)
… to conserve memory, i can change xyz to float again if the information you provide me is more optimal than my current situation
Here is what I would like to know:
I have (eventually) 1024 different textures, or more
they are approximately 256x1024 in size, because i use the lower end for lighting shades using alpha blitter i wrote
Your eyebrow should be moving now
So, texture_array_2d? will that be much faster since i can hopefully just burst all data in one go, no need to even bindtexture?
Will VBO’s with shaders be faster?
The GTX 285 does not support all the features of OpenGL 4.1.
Also, you should use texture compression, actually the new BCx texture compressions produce excellent quality, however, AFAIK those formats are only supported by GL4+ compliant cards.
the bottleneck is currently the renderer, though its not too bad
what i really want to know, i guess, is how to proceed from display list, i simply want your thoughts on the matter
just keep in mind that my engine is already managing 1.2bn cubes in some way or another,
max faces on screen is theoretically 872,415,232
in current version it is averaging 40-60m
so far though, noone answered my question about texture array
or some other method of keeping texture ids in objects?
my last vbo implementation which is currently disabled i used bindtexture per vbo, which naturally was very slow, but i dont fully grasp what i can do to get this number down to (n_visiblechunks) vbos, instead of (n_visiblechunks, n_textures) vbos
I meant ensure you know where the graphics bottle neck is before optimising.
eg - could be raster/overdraw, fragment shader, vertex shader, vertex submit, CPU driver cost etc.
Texture arrays could be a win if you have the texture memory to keep all texture data resident and your bottle neck is the switching of textures. (or the splitting up of vbos based on textures) Basically I think you should just do a test with rendering everything with one texture and compare the performance difference.