Andy Ross writes: >> > Remember that the "slow" thing your trying to fix is the fill rate > penalty of rendering all the panel layers; the panel layers don't have > significant geometry to speak of, they're slow because of all the > texture reads. Fixing that problem with a fill-rate-intensive > algorithm won't give you quite as much of a speed up as you think.
I still think you are missing the main idea here which is The main speedup will come not from the method that the instrument texture is constructed but from the side effect in that most of the time most of the instrument textures will not need to be constructed at all !!! Your concerns about fidelity can all be taken care of with a little tuning of the 'delta' required to trigger a refresh for the texture, in any case an intrument's texture should never need to be reconstructed if that texture has not changed, which I am willing to bet is the vast majority of the time for most of the instruments . i.e As it is now every instument is recreated every frame in a manner that requires changing OpenGL state multiple times hence taking the card out of the 'fast track' ie each layer of each instrument requires a matrix push/pop and a polygon offset Note using the proposed method the entire Panel could be rendered within a single glList(). Of course this assumes that updating the resident texture for the Panel would be done in a separate step in a manner that wouldn't require any polygon offset calls. Cheers Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
