|
This is a very important function.
The Speed database is used to speed up rendering.
One of the most time consuming test for the engine is to determine in real-time which
of the polygons in the world are seen and which are totally hidden by other polygons.
The information in the Speed database will reduce the amount of calculations that are needed in real-time
in order to determine from each location in the world the polygons that are seen and those that are hidden.
The Speed database contains information for every possible area in the world. The information tells the engine which
polygons in the world are seen from this area. In order to keep the size of the Speed database reasonable it is needed to supply
to the engine a list of points that we would like to speed the rendering in the vicinity of the given points.
In order to create the Speed database it is first needed STATE_engine_load_world() with the flag OUTPUT_RENDER_LOCATIONS
Here is a summary of how to speed up the rendering
1) Call STATE_engine_load_world() with the OUTPUT_RENDER_LOCATIONS flag and walk trough your world. This will create the visited_points.txt
Try to visit every possible area inside your world. The direction in which a certain location is approached does not matter
All that mater is the visited location themselves. Areas that wont be visited wont benefit from the Speed database
2) Call STATE_engine_create_speed_database() Sit back and relax while the engine will create the Speed database.
Use the visited_points.txt you have created in step "1". The speed.pvs file that is created is the Speed database that will
speed rendering in real-time.
3) Run your application. Make sure that the speed.pvs file is located in your application working directory (the folder where you have your exe file).
If you encounter areas in the world that do not enjoy any speed up, it is usually because those areas were not
visited in step "1". In order to fix this there is no need to redo the whole process. Here are two ways you can edit the speed.pvs database.
A) Do step "1" again but visit only the locations where the speed optimization didn't take place.
Do step "2" but now call STATE_engine_create_speed_database() with reset_database set to NO.
The new information will be added to the original speed.pvs file.
OR
B) Add locations manually to the visited_points.txt file and then repeat step "2"
Please note the following facts:
1) The bigger your world is the more impact you will gain by using the Speed database.
On very small worlds you might not even notice the effect.
2) To increase the speed up by this process build your world in a way that a minimum number of polygon is visible
from every location in the world. The most perfect world for this kind of optimization is
an indoor world where one cant see from one room to another because the door leads to a corridor.
Here is an example of such structure:
--------
| Room |
| A |
| |
| ------
------ |
|Room |
|B |
|------|
Note that from Room A it is not possible to see room B and the other way around
Many games (like Quake ...) use this technique extensively.
Parameters:
visited_points_file_name: A file that holds a list of x,y,z points. This file is created automatically
when calling STATE_engine_load_world() with the OUTPUT_RENDER_LOCATIONS.
reset_database: should be YES or NO. If NO then the function will use the previously created speed.pvs file and will
add to it new information derived from the given visited_points_file_name
make_compact_database: YES or NO. If YES the database will be significantly smaller. In some worlds the compact database
will give a much smaller rendering speed up. In other worlds it will give better results then the
detailed database (none compact). One has to check both methods on the final world.
The best performance will be achieved when make_compact_database==NO and the points
in the visited_points_file_name are selected cafully so that there are not too many but
there are enough to represent all the location that deffer by the polygon visible from these locations.
for example, if there are two ajacent points that when the camera is located in each one of them
there are xxx visible polygons. So if from both location there are the same polygons visible
so one of these points might be ommited.
|