Performance Tuning Airplanes

= Diagnosing Problems = Here are some tricks to find what is expensive...

1. Turn the texture res down to some INSANELY LOW value...do things get faster? Could be too much textures (the bandwidth from VRAM to GPU _can_ be a factor.)

2. These are all datarefs in the datarefs "art controls" section:

perf/disable_cockpit_readback

set it to 1, we won't rebuild the panel tex from the panel - if turning off panel tex readback increases fps, consider a smaller 3-d panel?

perf/kill_instruments

set to 1, we don't draw the insts (but do read back the panel texture) - maybe an instrument is slow? That would be a weird case!

perf/kill_click_3d

I think this stops hit-testing of your 3-d mesh for clicking - maybe too many triangles that are clickable? BTW this one will be a LOT faster in 930, so if that's your perf problem, 930 will help a lot.

perf/kill_texes

subs all texes to gray. If that gets fast - maybe it is tex limits, or maybe it is alpha blending. (If kill tex is FAST but low res tex is slow, maybe it is alpha!) To tell fps, set it back -- it takes a few seconds for the fps counter to roll back down to 19.

Other ideas:

Move around in 3-d view...in dataref editor stats, watch object/pln_obj_count -- move so your plane is out of view -- as the number drops, do fps go up? Could be your objs. Do you have to move a LONG WAY from your plane? MAybe the cull region is too big (e.g. the obj is off screen but we are drawing it). If the cull region seems big, report a bug!:-)

Put the word

DEBUG

on its own line in the end of the object -- the obj in memory is dumped to log.txt...is the command list a lot longer than what is in the OBJ file? Is the OBJ file's command list insanely long?

= Cockpits =

Too many mouse-clickable triangles (manipulatable triangles) can slow things down - use object/num_tris in the "Stats" datarefs to see how many are being clicked.

In 921 Use ATTR_manip_none after ATTR_cockpit or ATTR_cockpit_region to make panel texture that does not generate clickable regions.

(Kill_click_3d above finds this too.)

Having a large panel can cause performance problems. Try temporarily using a smaller panel background and compare performance.

= Objects =

Consider: Combine these facts and you can plan your object organization:
 * X-Plane culls objects that are not in view based on a bounding sphere.
 * The pilot viewpoint is at the front of the plane facing forward most of the time.
 * When an object is animated, the bounding sphere is made bigger to encompass the entire animation - this is necessary because the bounding sphere is computed once, it is not dynamic.
 * Try to keep object localized. If you need to use multiple objects, don't put the tail and nose cone in the same object - the tail would be culled normally but the nose cone will mean the whole object must be drawn.
 * If you need to use multiple objects, consider keeping animation separate. For example, an expensive high polygon count cabin might be culled.  But if an animated stairs object is attached to it, its sphere will become bigger.
 * Spheres can be poor approximations for your objects - beware of the effect of having very long thin objects with details at the end (an I or T shape). The sphere would normally wrap the long axis but will become extended by the details.

But overall, remember that object culling will only help if vertex count really is a problem!