PDA

View Full Version : Need help deciding engine future



Kaptein
01-23-2011, 03:08 PM
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.

Screenshot 1 (http://dm.fwsnet.net/uberfpswhileworking.PNG)
Screenshot 2 (http://dm.fwsnet.net/optimizedmultisteplight.PNG)

I am:
* completely new to opengl and 3d in general
* 2 months into the project
* have read tutorials left and right
* have read the opengl manuals and references

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?

How would you do this?

skynet
01-23-2011, 04:55 PM
Is this minecraft?
Where in these screenshots do I see insane amounts of objects and where are those 1024 different textures?

sqrt[-1]
01-23-2011, 10:18 PM
Are you using texture compression?
What are the minimum specs of the video card you would like to use?

Kaptein
01-23-2011, 11:26 PM
]Are you using texture compression?
What are the minimum specs of the video card you would like to use?

no im not using compression, should i?
opengl 4.1, i guess
something that is a year old now :) i have a GTX 285, so i guess thats as far as i can go

aqnuep
01-24-2011, 05:02 AM
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.

sqrt[-1]
01-24-2011, 05:19 AM
Deciding to use texture compression should be up to you - you trade quality for performance and less memory usage.

Memory usage can be 1/8 or 1/4 of existing RGBA8 uncompressed textures.

I would make sure where your bottle necks are before optimizing however.

YarUnderoaker
01-24-2011, 07:51 AM
Just to inspire :)
http://codeflow.org/entries/2010/dec/09/minecraft-like-rendering-experiments-in-opengl-4/

Kaptein
01-24-2011, 09:22 AM
]Deciding to use texture compression should be up to you - you trade quality for performance and less memory usage.

Memory usage can be 1/8 or 1/4 of existing RGBA8 uncompressed textures.

I would make sure where your bottle necks are before optimizing however.

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

sqrt[-1]
01-24-2011, 05:04 PM
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.

Kaptein
01-24-2011, 11:55 PM
]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.

thanks much :)