I'm religiously preserving the OpenGL state around everything that I'm doing (glPushAttrib() and glPopAttrib() with GL_ALL_ATTRIB_BITS). Is there something more bulletproof?
Glad to know that FlightGear uses non-plib textures, too. Can you point me to a place in the source code where this occurs? To rephrase my initial question, is there a way to limit the "world" in which FlightGear operates to, say, 100 sq miles around my home airport and force it to load everything it needs up front (thus avoiding the '12 GB of data' consequence)? Thanks for the help. D ---- Original message ---- >Date: Wed, 26 Jan 2005 09:36:20 -0600 >From: "Curtis L. Olson" <[EMAIL PROTECTED]> >Subject: Re: [Flightgear-users] how do I disable 'dynamic' textures? >To: FlightGear user discussions <[email protected]> > >D Wysong wrote: > >>Can I keep FG from going back into plib and fiddling with >>textures once the sim is up/initialized!? >> >>I'm using a custom texture that I created using OpenGL >>directly (instead of via plib) and I'm getting HOSED when FG >>decides to go load new textures (... or when it does whatever >>it does when it starts making calls to ssgLoadTextures, >>ssgMakeMipMaps, etc., after the sim is executing). AArrgh! >> >> > >One thing you need to understand in OpenGL is "state management". >FlightGear is a complex program that needs to set different opengl >parameters (i.e. states) in a number of different places in the code. >If one section of the code isn't careful and doesn't reset things >correctly, or makes some other wierd changes, then this could cause >problems later. > >Think about it like someone giving you turn by turn directions. If they >don't tell you to turn at all the right places, and in the right order, >you aren't going to end up where you want to go. > >>Are there any reasons why plib wouldn't let me build/use my >>own textures? (... I posted a similar question on the >>plib-users list to see if I get any replies) >> >> > >This should all work fine. FlightGear has places where it loads or >builds it's own textures too. > >>Why does FG need to load anything once the sim is executing? >>Are textures not allocated/created by FG until they're needed? >>Can this 'load-it-as-you-go' behavior be replaced with a >>'load-everything' approach? >>What are the consequences? >> >> > >What are the consequences of loading 12Gb of world data and associated >textures and code all at once into main RAM? > >I would hunt for an opengl state management issue in your code. Also, >don't forget that you must do all your texture loading in the main >thread. If you mix opengl calls in different threads, they will get >mixed arbitrarily and sent to the single opengl context, and you will >get unpredictable results ... well actually you'll most likely get a >program crash. > >Regards, > >Curt. > >-- >Curtis Olson http://www.flightgear.org/~curt >HumanFIRST Program http://www.humanfirst.umn.edu/ >FlightGear Project http://www.flightgear.org >Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d > > >_______________________________________________ >Flightgear-users mailing list >[email protected] >http://mail.flightgear.org/mailman/listinfo/flightgear-users >2f585eeea02e2c79d7b1d8c4963bae2d _______________________________________________ Flightgear-users mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
