(Not sure this is the right forum, but it seems the closest.)
Question: Does the order of objects in a map file have any impact on server performance?
Background:
I have code which helps me write maps: it used to place simple
objects, now I can define composite objects and move them around, etc. To facilitate this, I now keep a list of objects (either in a composite object, or in the entire map) and emit this to a map file after everything is defined.
I *could* sort this in any number of ways: by height, by object size, by quadrant, by distance from the origin, etc. If it makes a significant difference in the efficiency of rendering, it's worth it for me to write that code. (Of course, it's quite possible that object order does make a difference, but BZFlag may do this sorting on map readin.)
If the answer is "Yes, order does make a difference", I'd like to know whether it's a big difference or a marginal one. (If need be, I could just try sorted/unsorted files and try to quantify performance - so a related question is, are there any profiling tools build in to report, say, average rendering time?)
Bryan, "The Purple Panzer"
Optimizing maps
-
Purple Panzer, The
- Private First Class
- Posts: 8
- Joined: Wed Oct 01, 2003 2:55 am
- Location: Stonington, CT
- Contact:
-
julesthejackal
- Private First Class
- Posts: 37
- Joined: Wed Jul 23, 2003 8:59 am
- Location: Canada
ref.
Hi again
This link might be of some help to you,
http://www.shellshock.dutchrai.com/refe ... m#comments
Jules The Jackal
ps I love your Maps!
This link might be of some help to you,
http://www.shellshock.dutchrai.com/refe ... m#comments
Jules The Jackal
ps I love your Maps!
panzer,
not that i have experienced, although I have not paid that much attention. the biggest hits on preformance it seems are number of objects, number of overlapping blocks, and number of screw-ball coordinates.....ie "1.9899", instead of "2". Thats what I have hit.
patlabour22 has probably a developers view on this, and would be the optimal source.
not that i have experienced, although I have not paid that much attention. the biggest hits on preformance it seems are number of objects, number of overlapping blocks, and number of screw-ball coordinates.....ie "1.9899", instead of "2". Thats what I have hit.
patlabour22 has probably a developers view on this, and would be the optimal source.
.........you kids, get out of my tank...........
Map order dosn't mater, they are all sorted into lists based on each objects type when they are read in anyway.
Number of objects does mater. For each frame, each object is tested to see if it's visivble, regardless of it's size, order, or proximity to other objects. This means more objects = more time spent seeing what is visible, AKA Frustum Culling.
On most modern cards the actual drawing of the objects takes little time. On some systems/maps we spend more time culling then we do drawing. This is not optimal.
This method was set up because inital maps were small, and openGL implementations were not that fast ( software implemntations on windows ). So it was an acceptable solution.
So untill some sort of visiblitly system that does object grouping is implemented ( octree, bsp, portals, simple groups, whatever ), it will allways just be number of objects that make maps slow.
Faster CPUs will do this calulation better, not faster video card, as the card is not used in the visiblity tests. Since the entire point of the tests are to not send it to the card.
What you can do is, make sure each object counts. Don't use 2 short boxes where one long box will do. Make sure you don't have extra boxes inside things. If somone can't get to a place, and you have objects in there, they are probably a waste. Don't write your name in boxes somwhere off the map, it's just a waste. A good sign that you may need to do some box removal is when you see that "shimmer" in the texture when 2 boxes overlap. That is a place where you shold look at optimisaiton.
Hope that helps
Number of objects does mater. For each frame, each object is tested to see if it's visivble, regardless of it's size, order, or proximity to other objects. This means more objects = more time spent seeing what is visible, AKA Frustum Culling.
On most modern cards the actual drawing of the objects takes little time. On some systems/maps we spend more time culling then we do drawing. This is not optimal.
This method was set up because inital maps were small, and openGL implementations were not that fast ( software implemntations on windows ). So it was an acceptable solution.
So untill some sort of visiblitly system that does object grouping is implemented ( octree, bsp, portals, simple groups, whatever ), it will allways just be number of objects that make maps slow.
Faster CPUs will do this calulation better, not faster video card, as the card is not used in the visiblity tests. Since the entire point of the tests are to not send it to the card.
What you can do is, make sure each object counts. Don't use 2 short boxes where one long box will do. Make sure you don't have extra boxes inside things. If somone can't get to a place, and you have objects in there, they are probably a waste. Don't write your name in boxes somwhere off the map, it's just a waste. A good sign that you may need to do some box removal is when you see that "shimmer" in the texture when 2 boxes overlap. That is a place where you shold look at optimisaiton.
Hope that helps
JeffM