|
|
QSDK 1.1 Documentation |
|
|
Q provides a seamless, continuous, environment, suitable for producing immersive 3D worlds through its streaming technology. Before reading what follows, it is strongly advised to read the streaming notes. Until this section, all processes described earlier have been about authoring and producing data. At this point, all data required by the demo has been built. The demo may run with all individual Q files:
The processes described here are all about optimization and usually happen at the end of a project cycle.
The QStudio Mastering tool enables you to gauge the size on disk, and in memory, of the data needed to show/play a scene using Q. It looks at the data components and how they relate to each other, as well as the asset dependencies for all relevant entities. A summary is then produced of what gets loaded when. Using this tool is essential to profile and master the loading of the application. It shows exactly what will be loaded and what will not, how fast it will be loaded and how much memory it will cost. This is the information that will get put into the database at the mastering stage. Read the section on streaming to see how this information is used later on.
Open the QStudio Mastering tool and browse the resulting information to get familiar with the data. In particular, note how the asset dependencies of the entity types and those of the entity instances get put in the loading clumps. In the example shown below, the QAM clip switch_qam is loaded when zone_puzzle is in scope, as switches use it and several switches are placed in this zone.
Q files can be merged using the qdub command-line tool. Merging allows re-using shared data. This builds a large Q file image out of the individual Q files:
cp class.q all.q
qdub -k -o
assets.q fx.q chunks.q skrittle.q janseth.q margoss.q
pickups.q level.q weapons.q all.q
The demo could run directly from the all.q file.
Once Q files have been merged into one, it now is possible to optimize the layout. Clumping is the operation that gather all connected data together. It goes through and looks at how entity instances relate to each other and what their asset dependencies are. Then it organizes the data into be chunks by neighboring the related items.
Clumping works by pre-calculating all of the Objects required for a given Zone - i.e. the scene graph hierarchy of Groups, Instances and Geoms together with any marked up assets. It also calculates the differences in objects between all neighboring pairs of Zones. The qds command-line tool is able to pre-calculate this layout using its clumping command:
qds -c 'optimize clumps' all.q
Once the layout has been calculated, the last stage is to build the optimized Q file. Load performance can be further increased by arranging for all of the objects required for a Clump to be placed contiguously on the disk or CD so that they can be read in a sweep without having to re-seek for each object. The qdub command-line tool achieves such a task by taking the Q file and re-arranging its data into another Q file:
cp class.q qdemo2.q
qdub -k -o -optimize
all.q qdemo2.q
The resulting qdemo2.q file is the one the demo uses by default. It is the optimized database built for release at the final stage. Note how its size doubled. This is expected, as a large part of the clumping process involves database object replication. It is more efficient and allows the demo to transparently stream its data. You can compare the runtime behavior of the demo between the two modes: with multiple individual Q files and with the single qdemo2.q one. The first solution is more flexible but less effective. That is the one used for the authoring stage. The second solution is rigid but its performance is better and smoother: it is used for release.
|
|||
|
|
Qube Software Limited © 2000-2004
|
|