Re: [Flightgear-devel] Reducing AI Model complexity
Rob wrote: However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) A much bigger problem are those aircraft (like my 744) that are split into several models, for easy maintenance/development. Wings, fuselage, gear area all seperate models, with seperate animation files... Cheers, Gijs _ Download gratis emoticons voor Messenger http://www.rulive.nl/aspx/emoticons.aspx-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart Buchanan a écrit : Providing a higher granularity of control would be tricky but not impossible - I guess you could define a list of model names that are to be loaded completely... could it be done per callsign, like the ignore chat message check box, with maybe a command line option to set specific callsign in the load detailled group? In case of formation flight (or dual control) we know the others callsign we want to have detailled planes, and not to load others models is sometimes good for the (not) induced lag, this can make possible formation aérobatics without too much lag from model loading. my two cents... jano -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Gijs de Rooy wrote: A much bigger problem are those aircraft (like my 744) that are split into several models, for easy maintenance/development. Wings, fuselage, gear area all seperate models, with seperate animation files... I wasn't aware that we had any aircraft split up this way. However, having thought about this a bit more, I think there's a straightforward solution, which is to have a tag on the model to force sub-model loading for that model irrespective of the global setting. This could be set for the 747 and the dual-control aircraft. This would also remove the need to provide a separate list of aircraft to be loaded completely. The downside is that it brings us back to square one if everyone is flying the F14 ! -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
On Sat, Apr 3, 2010 at 3:30 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Rob wrote: However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) A much bigger problem are those aircraft (like my 744) that are split into several models, for easy maintenance/development. Wings, fuselage, gear area all seperate models, with seperate animation files... Cheers, Gijs I'd like to second Gijs' concerns here. I build my models in sub-units partly to facilitate ease of maintenance and development, and partly for easy LoD range logic. My model units tend to be: airframe, external details (antennae, etc), external lighting rig, cockpit, instruments, cabin, propellers. IIf I understand the proposal right, I would be concerned about losing the propellers in an automatic AI implementation. I wonder if the proposed implementation might benefit from a new optional element within models that allows the developer to specify that the AI scheme must load the sub-model. For example: ... model nameCockpit/name pathAircraft/Goose/Models/Goose_Cockpit.xml/path /model model nameExternal Lights/name pathAircraft/Goose/Models/Goose_Lights.xml/path /model model namePropellers/name pathAircraft/Goose/Models/Goose_Props.xml/path force-ai-importtrue/force-ai-import /model ... This might solve Gijs' problem as well. Just a thought. -Gary aka Buckaroo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
jean pellotier wrote: Stuart Buchanan a écrit : Providing a higher granularity of control would be tricky but not impossible - I guess you could define a list of model names that are to be loaded completely... could it be done per callsign, like the ignore chat message check box, with maybe a command line option to set specific callsign in the load detailled group? In case of formation flight (or dual control) we know the others callsign we want to have detailled planes, and not to load others models is sometimes good for the (not) induced lag, this can make possible formation aérobatics without too much lag from model loading. my two cents... That's an interesting idea. However, without looking at it in detail, I suspect that we set the callsign for the other aircraft after the AI model has been loaded, at which point it is too late. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Gary Neely wrote: I'd like to second Gijs' concerns here. I build my models in sub-units partly to facilitate ease of maintenance and development, and partly for easy LoD range logic. My model units tend to be: airframe, external details (antennae, etc), external lighting rig, cockpit, instruments, cabin, propellers. IIf I understand the proposal right, I would be concerned about losing the propellers in an automatic AI implementation. I wonder if the proposed implementation might benefit from a new optional element within models that allows the developer to specify that the AI scheme must load the sub-model. For example: ... model nameCockpit/name pathAircraft/Goose/Models/Goose_Cockpit.xml/path /model model nameExternal Lights/name pathAircraft/Goose/Models/Goose_Lights.xml/path /model model namePropellers/name pathAircraft/Goose/Models/Goose_Props.xml/path force-ai-importtrue/force-ai-import /model ... This might solve Gijs' problem as well. Just a thought. Good thought :) My proposal above was something like this: force-ai-importtrue/force-ai-import model nameCockpit/name pathAircraft/Goose/Models/Goose_Cockpit.xml/path /model model nameExternal Lights/name pathAircraft/Goose/Models/Goose_Lights.xml/path /model model namePropellers/name pathAircraft/Goose/Models/Goose_Props.xml/path /model but that would load all the sub-models, while your suggestion would limit it to just the submodel selected. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
On Sat, 3 Apr 2010, Stuart Buchanan wrote: However, having thought about this a bit more, I think there's a straightforward solution, which is to have a tag on the model to force sub-model loading for that model irrespective of the global setting. This could be set for the 747 and the dual-control aircraft. Hi, If we are heading towards a solution that require the models to be updated is not better to go one or two steps further and try to devise a more satisfactory LOD mechanism for model loading? My suggestion would be a range animation that defers loading of it child model until it is within range. This animation node could be automatically inserted as the root of a AI/MP aircraft model to implement a selectable range for loading the model but could also be used within the model XML files to implement hierarchical LOD model loading (like our current range animation can be used for LOD control during rendering). Btw. some multiplayer features depend on that Nasal modules for a particular MP/AI aircraft is loaded at a larger than visual range, e.g. MP-Carrier, so defering model loading until the player is within the view frustum (as we did early on after the OSG migration) is also not a suitable solution. (Just in case we were heading back towards that.. :) Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Jason Shepard wrote: As far as what you have written here: 1) As I understand this, it basically does exactly the same thing as going through the individual model files and removing the cockpits/interiors/etc., correct? Correct. a) Would this work on single-player? Yes, but there's unlikely to be much advantage as most of the AI models used in single player (tanker, AI aircraft) are already low-poly models. However, it does affect the Nimitz carrier, which is quite a detailed model, so would benefit those seeing low FPS with the carrier. b) If so, would we still have to maintain the AI model files or, with this patch included, would the AI aircraft be able to be read from the standard models folder thereby eliminating the needs for an AI branch on the FG tree? There is still a place for the AI Models - this doesn't do anything about the complexity of the main model, nor does it scale any textures. However, it means there's no real need to create AI models for everything. 2) I don't 100% understand how LOD works, but if I get it basically correctly, LOD reduces the resolution of a model based on the distance from your viewpoint that it is? If this is the case, would it not stand to reason that there should be several different stages of LOD? For example, a model made with 2048x2048 textures would be at full resolution within 5nm. From 5.1nm-10nm, it would be rendered at 1024x1024. From 10.1nm-20nm, it would be rendered at 512x512. Or am I way off-base here? Is this even possible? It is possible, but requires significant work on the part of the modeller. In this case, the LOD means the range at which and aircraft will become visible. At the moment this is hardcoded to 50nm. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Csaba Halász wrote: Generally I prefer proper LOD and getting rid of specialized AI versions. I want to see AI/MP aircraft in full detail when I am near one - or even inside. Ideally I want to see all the instruments properly working when I hitch a ride using model+cockpit view. In the long run, I hope we will be able to couple animations to MP protocol, so that the required properties (and only those!) would be transmitted automatically as dynamically determined by the current LOD. I prefer proper LOD as well, but it requires effort from modellers, and there is still the overhead of loading the entire model, and keeping the model in memory. This approach simply allows a user to choose whether they want that overhead or not. To be perfectly honest, this is just a speculative piece of work. On my new system, I don't have any problem handling KSFO on a busy day, but I think it should help those on lower powered machines significantly. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: A number of people on the forums have mentioned performance issues on lower-spec system on MP, particularly due to loading complex models for other aircraft causing stuttering. In an effort to help with this I've been looking at two fixes: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. I am in LOVE with any idea which reduces unnecessary lag time when flying over the multiplayer network. However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Csaba: I want to see AI/MP aircraft in full detail when I am near one - or even inside. Perhaps a range-test of 1-2nm (or even better, a configurable distance) on submodel loading? Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Hi All, On Friday 02 April 2010 09:19:45 am Stuart Buchanan wrote: Yes, but there's unlikely to be much advantage as most of the AI models used in single player (tanker, AI aircraft) are already low-poly models. However, it does affect the Nimitz carrier, which is quite a detailed model, so would benefit those seeing low FPS with the carrier. b) If so, would we still have to maintain the AI model files or, with this patch included, would the AI aircraft be able to be read from the standard models folder thereby eliminating the needs for an AI branch on the FG tree? There is still a place for the AI Models - this doesn't do anything about the complexity of the main model, nor does it scale any textures. In general, I'm in favor of Stuart's proposed patch, as long as it continues to play nicely along with the existing AI branch (I'm happy to help testing / committing in this respect). Just to add some additional thoughts, the current scheme of using a separate AI branch was added back in the plib days, when LOD wasn't easily accessible, after I found out that the then current version of FlightGear wasn't able to handle the impact of 100+ aircraft placed in a scene by the traffic manager. If I understood correctly, one of the major advantages of OSG over plib is that it can do very clever LOD management, which -if effectively applied- could by itself reduce the amount of pausing due to aircraft model loading considerably. So, if done correctly, we could happily use the regular aircraft models, also for AI /Multiplayer purposes, because most of the time, only the lower LOD versions would be active. This would probably give better performance than we currently have. In addition to that, we could also make more effective use of the incredible collection of liveries made by Brett Harrison, which quite a few magnitudes better then the rather bleak ones I made for the AI aircraft. My own experience is that the AI/ Traffic Manager code in itself runs quite efficiently, but that the rendering of the AI models has a huge impact. Currently, for the AI code, the model isn't made visible until it gets close to the current visibility limit. Once that happens, and the AI models are set to become visible, that's where I usually notice quite a frame rate drop. Relatedly, when flying away from a busy airport, I notice quite an increase in performance, even though the AI aircraft are then still within visibility range. This actually makes me wonder whether there is something in the AIModels core code that makes the current rendering of AIModels rather inefficient. I'd be interested to hear one of our OSG experts' opinion on this. Cheers, Durk -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Rob Shearman, Jr. However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) I would expect that the wing flex would be an animated component of the main model, just like flaps, gear etc. usually are. However, if they were submodels, they wouldn't be visible. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Me: However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) Stuart: I would expect that the wing flex would be an animated component of the main model, just like flaps, gear etc. usually are. Ah, okay -- I got my terminology confused for a second there. Disregard. -R. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Csaba: I want to see AI/MP aircraft in full detail when I am near one - or even inside. Well, the only 2 ideas I have regarding this would be selectable options within the FGRun GUI and/or the command-line: 1) An option to enable/disable the LOD capabilities of the program 2) An option to select either AI Models (simple) or AI Models (advanced). a) AI Models (simple) would be AI Models which always appear without their interiors/cockpit installed. This would be effective for those people who do not hitch rides or who want best performance at all times. b) AI Models (advanced) would AI Models which appear fully detailed at the closest LOD limits. This would be the best choice for those who like to see their AI aircraft in full detail and jump onboard occasionally, like Csaba. Durk: So, if done correctly, we could happily use the regular aircraft models, also for AI /Multiplayer purposes, because most of the time, only the lower LOD versions would be active. This would probably give better performance than we currently have. In addition to that, we could also make more effective use of the incredible collection of liveries made by Brett Harrison, which quite a few magnitudes better then the rather bleak ones I made for the AI aircraft. As I have only recently noticed, there are only certain aircraft in my AI Models folder - and not even close to the same number as I have downloaded and installed. This leads me to believe that only certain aircraft make use of the AI Models directory and either a) those are the only AI Models that you can have unless you create your own files or b) the other Models are rendered as AI Aircraft from the original model files anyway. If it is Option A, then I believe a solution to re-route our current AI Models directory structure to our original models directory structure should be implemented along with Stuart's control option to make it so that separate AI Models would not have to be generated and stored separately. This would reduce the overall size of FG (although probably not by much), but it should also have the side benefit of simplifying some of the code (since there wouldn't be 2 directory structures to do the similar actions), correct? If it is Option B, then we already have the file structure in place to use Stuart's proposed modification to auto-create AI Models which would make the AI Model tree unnecessary, correct? Which would also mean that ALL of our models would also be capable of being AI Models instead of only a limited few. Thanks, Jason -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Stuart Buchanan a écrit : In an effort to help with this I've been looking at two fixes: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Comments? When using dual control like in Anders c172p-dual-control and ZLT-NT blimp, or the f-14b-bs, the copilot is actually flying in an AI model which needs all the eavy stuff we would like to disappear in most other situations. There is also a big demand of visual details and eyes candy from a important part of FG users and we can't neglect that. Now, this leads effectively to a huge waste of h/w resources and anyway much of all this eye candy stuff is not visible at more than 50ft. LOD animations works well for saving fps and the work spent on it worth it. The problem remains at AI aircraft load time and I think a majority of user doesn't need to wait for the Tomcat to load each minute or so. In any case we should have the ability to choose what level of detail we want. In a dream world this would be user definable and on a per aircraft basis. This could be something like: use only light AI models by default or define somewhere a list of aircrafts you prefer to see a high level of detail. In the cases like dual-control, modelers could add at run time the needed models to this list. Alexis -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Jason Shepard wrote: Stuart: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Csaba: I want to see AI/MP aircraft in full detail when I am near one - or even inside. Well, the only 2 ideas I have regarding this would be selectable options within the FGRun GUI and/or the command-line: 1) An option to enable/disable the LOD capabilities of the program 2) An option to select either AI Models (simple) or AI Models (advanced). a) AI Models (simple) would be AI Models which always appear without their interiors/cockpit installed. This would be effective for those people who do not hitch rides or who want best performance at all times. b) AI Models (advanced) would AI Models which appear fully detailed at the closest LOD limits. This would be the best choice for those who like to see their AI aircraft in full detail and jump onboard occasionally, like Csaba. That is indeed what I'm proposing :) I should have been clearer in my original post - by having a control I meant adding an entry in the property tree to toggle whether submodels are loaded or not. Similarly I am proposing setting the AI LOD distance from a property as well. You can then set the property from the command-line, FGRun, or in-sim (though it would only affect models loaded from that point). -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
Alexis Bory wrote: When using dual control like in Anders c172p-dual-control and ZLT-NT blimp, or the f-14b-bs, the copilot is actually flying in an AI model which needs all the eavy stuff we would like to disappear in most other situations. There is also a big demand of visual details and eyes candy from a important part of FG users and we can't neglect that. Now, this leads effectively to a huge waste of h/w resources and anyway much of all this eye candy stuff is not visible at more than 50ft. LOD animations works well for saving fps and the work spent on it worth it. The problem remains at AI aircraft load time and I think a majority of user doesn't need to wait for the Tomcat to load each minute or so. In any case we should have the ability to choose what level of detail we want. In a dream world this would be user definable and on a per aircraft basis. This could be something like: use only light AI models by default or define somewhere a list of aircrafts you prefer to see a high level of detail. In the cases like dual-control, modelers could add at run time the needed models to this list. My proposal is to allow the user to select (via a property) whether they want to load the entire model or not, so there's no loss of function. So, I would envisage that those wanting to use the dual control options would want to set this off. In fact, as it's a property (say /sim/rendering/load-submodels), it could be set in the -set.xml file. Though this goes against our general principle that the user has control over features rather than the aircraft, I think in these special cases where the dual-control simply won't work, we could make an exception. Providing a higher granularity of control would be tricky but not impossible - I guess you could define a list of model names that are to be loaded completely... -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
For those interested in trying this out, I've uploaded a simple patch to http://www.nanjika.co.uk/flightgear/ai.diff It's not suitable for committing in it's present form - at the very least the properties should be loaded from the FG tree rather than SimGear and I'm not sure that the SGReaderWriterXMLOptions object is the correct container for the switch. To disable loading of submodels, set /sim/rendering/load-submodels=0 You can also set the LOD range for AI aircraft (though I haven't tested this) by setting /sim/rendering/model-range-m to the required range in m. Note that neither of these settings are dynamic - they only take effect for any new models that are loaded. So, they are best set from the command-line. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Reducing AI Model complexity
Hi All, A number of people on the forums have mentioned performance issues on lower-spec system on MP, particularly due to loading complex models for other aircraft causing stuttering. In an effort to help with this I've been looking at two fixes: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Note that this is generally better than having a LOD node on the cockpit, because it doesn't even get as far as loading the file, nor does the cockpit take up any space in the scenegraph 2) A control to set the LOD for AI aircraft. Currently this is hardcoded to 50nm, which is probably too far for most purposes. I've got basic patches that allow these controls to be set by properties at runtime, but which I think requires a bit more work before submission. Comments? -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
As far as what you have written here: 1) As I understand this, it basically does exactly the same thing as going through the individual model files and removing the cockpits/interiors/etc., correct? If that is the case, I find this to be an excellent replacement for having to depend on each individual modeler to create an AI model file for every plane they generate. This should significantly increase the framerates within the MP environment. My questions are these: a) Would this work on single-player? b) If so, would we still have to maintain the AI model files or, with this patch included, would the AI aircraft be able to be read from the standard models folder thereby eliminating the needs for an AI branch on the FG tree? 2) I don't 100% understand how LOD works, but if I get it basically correctly, LOD reduces the resolution of a model based on the distance from your viewpoint that it is? If this is the case, would it not stand to reason that there should be several different stages of LOD? For example, a model made with 2048x2048 textures would be at full resolution within 5nm. From 5.1nm-10nm, it would be rendered at 1024x1024. From 10.1nm-20nm, it would be rendered at 512x512. Or am I way off-base here? Is this even possible? -Jason On Thu, Apr 1, 2010 at 5:52 PM, Stuart Buchanan stuar...@gmail.com wrote: Hi All, A number of people on the forums have mentioned performance issues on lower-spec system on MP, particularly due to loading complex models for other aircraft causing stuttering. In an effort to help with this I've been looking at two fixes: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Note that this is generally better than having a LOD node on the cockpit, because it doesn't even get as far as loading the file, nor does the cockpit take up any space in the scenegraph 2) A control to set the LOD for AI aircraft. Currently this is hardcoded to 50nm, which is probably too far for most purposes. I've got basic patches that allow these controls to be set by properties at runtime, but which I think requires a bit more work before submission. Comments? -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
On Fri, Apr 2, 2010 at 12:52 AM, Stuart Buchanan stuar...@gmail.com wrote: Hi All, In an effort to help with this I've been looking at two fixes: 1) A control to disable sub-model loading for AI aircraft. This effectively stops the model loader from recursing into model tags, and therefore stops it from loading any sub-models such as cockpits, instruments, pilots etc. Note that this is generally better than having a LOD node on the cockpit, because it doesn't even get as far as loading the file, nor does the cockpit take up any space in the scenegraph 2) A control to set the LOD for AI aircraft. Currently this is hardcoded to 50nm, which is probably too far for most purposes. Generally I prefer proper LOD and getting rid of specialized AI versions. I want to see AI/MP aircraft in full detail when I am near one - or even inside. Ideally I want to see all the instruments properly working when I hitch a ride using model+cockpit view. In the long run, I hope we will be able to couple animations to MP protocol, so that the required properties (and only those!) would be transmitted automatically as dynamically determined by the current LOD. Speaking of stuttering, another issue reported on the forums and also experienced by me, is periodic (~1s) stutter even with plenty of FPS. That is with AI traffic (both kinds) and replay turned off, single-player. I couldn't determine the cause yet. Anybody have an idea? -- Csaba/Jester -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
