Talk:North American P-51 Mustang: Difference between revisions

Jump to navigation Jump to search

Talk:North American P-51 Mustang (view source)

Revision as of 15:57, 11 August 2014

75 bytes added ,  11 August 2014
m
Headings; indentation
mNo edit summary
m (Headings; indentation)
Line 1: Line 1:
== Performance issues on non-high end computers ==
Congratulations!<br />
Congratulations!<br />
This is a really good looking and very detailed aircraft. Though it's unusable on not close to high-end systems. It's cutting FG's frame rate to 10 to 15 fps where it normally has more than 30. Even worse, it not even has a downgraded version in AI/Aircraft. If some other pilot shows up on MP with the p51d my FG suffers from the worst lags ever, making it completely unusable.
This is a really good looking and very detailed aircraft. Though it's unusable on not close to high-end systems. It's cutting FG's frame rate to 10 to 15 fps where it normally has more than 30. Even worse, it not even has a downgraded version in AI/Aircraft. If some other pilot shows up on MP with the p51d my FG suffers from the worst lags ever, making it completely unusable.
Line 9: Line 10:
:Compared with commercial sims like X-Plane and FSFX vertice numbers and details are even in a similar range. Nethertheless, some optimations is always appreciated.
:Compared with commercial sims like X-Plane and FSFX vertice numbers and details are even in a similar range. Nethertheless, some optimations is always appreciated.
:What are your computer specs?  
:What are your computer specs?  
--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 15:24, 10 August 2014 (UTC)
:--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 15:24, 10 August 2014 (UTC)


:: Hi Heiko, thanks for the reply.
:: Hi Heiko, thanks for the reply.
Line 47: Line 48:
:: Also I experienced a lot of issues with the Blender to ac3d exporter and one of these has to do with parented objects not being correctly exported (IE. the export moved and rotated these objects in what appeared to be random ways).  As a result, currently, the objects involved in the livery stuff are not correctly parented.  I know that this has some performance implications.  I would like to figure out a good way to fix this but so far have not been able to locate the information needed to do this is a way that is not a huge amount of work (to redo work that I already did).  This could have a significant impact on users with low end systems but on my system it seems to impact how long it takes to start up the sim and how long it takes to switch liveries.  There is a rumor that the solution to this issue was talked about on the dev list but I have not been able to locate this information.  If anyone knows how to solve this issue please let me know.  
:: Also I experienced a lot of issues with the Blender to ac3d exporter and one of these has to do with parented objects not being correctly exported (IE. the export moved and rotated these objects in what appeared to be random ways).  As a result, currently, the objects involved in the livery stuff are not correctly parented.  I know that this has some performance implications.  I would like to figure out a good way to fix this but so far have not been able to locate the information needed to do this is a way that is not a huge amount of work (to redo work that I already did).  This could have a significant impact on users with low end systems but on my system it seems to impact how long it takes to start up the sim and how long it takes to switch liveries.  There is a rumor that the solution to this issue was talked about on the dev list but I have not been able to locate this information.  If anyone knows how to solve this issue please let me know.  


--[[User:Hvengel|Hvengel]] ([[User talk:hvengel|talk]])
:: --[[User:Hvengel|Hvengel]] ([[User talk:hvengel|talk]])


:::Hi, sorry, but you are falling in the same trap the 777 modeller did, although one order of magnitude lower. I'm not saying your work isn't great (or the 777), I'm saying it's not ok for ''realtime'' rendering, while it would be a killer asset on a CG movie set, or in a 3d-printing shop. You've so far fallen in the huge texture trap while they fell into overly heavy vertex counts and "over modelled details that never end up visible" trap.
:::Hi, sorry, but you are falling in the same trap the 777 modeller did, although one order of magnitude lower. I'm not saying your work isn't great (or the 777), I'm saying it's not ok for ''realtime'' rendering, while it would be a killer asset on a CG movie set, or in a 3d-printing shop. You've so far fallen in the huge texture trap while they fell into overly heavy vertex counts and "over modelled details that never end up visible" trap.
Line 69: Line 70:
:::P.S. The Extra500 is a very special case, and its performance issues have nothing to do with a detailed model on old hardware (like some would like you to think), but there the nasal beast rears its ugly head and starts biting ;) (it runs just as bad with a cube replacing the 3d-model)
:::P.S. The Extra500 is a very special case, and its performance issues have nothing to do with a detailed model on old hardware (like some would like you to think), but there the nasal beast rears its ugly head and starts biting ;) (it runs just as bad with a cube replacing the 3d-model)


::::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)''
::::and how much is the impact on RAM? I remember that random buildings at their beginning had been very dense and framerate had been really good- but RAM usage was horrible.
::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 14:30, 11 August 2014 (UTC)
:::::With only trees and buildings (no "grass") RAM usage tops in the 2.3-2.4GB range (with --prop:/sim/tile-cache/enable=false, in very detailed areas of EU). But the changes I was talking about are not a 'refactoring' of the code, just enabling some options/flags on the generated geometry, so the code is the same as the current one. The old random buildings were a completely different approach.
:::::The example was to illustrate that the underlying technology FG is using is old and can be handled by that "antiquated" hardware just fine, and the "modern" hardware only (partly) masks un(der)optimized stuff.
::::: [[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 15:00, 11 August 2014 (UTC)
== Download link not working ==
Hm... looks like the download link does not work...
Hm... looks like the download link does not work...
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 13:59, 11 August 2014 (UTC)
--[[User:Jarl Arntzen|Jarl Arntzen]] ([[User talk:Jarl Arntzen|talk]]) 13:59, 11 August 2014 (UTC)


::::@Jarl Arntzen: look into current FGData (gitorious.org)
:@Jarl Arntzen: look into current FGData (gitorious.org)
::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 14:30, 11 August 2014 (UTC)
:--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 14:30, 11 August 2014 (UTC)
 
:::::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)''
:::::and how much is the impact on RAM? I remember that random buildings at their beginning had been very dense and framerate had been really good- but RAM usage was horrible.
:::::--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 14:30, 11 August 2014 (UTC)
 
::::::With only trees and buildings (no "grass") RAM usage tops in the 2.3-2.4GB range (with --prop:/sim/tile-cache/enable=false, in very detailed areas of EU). But the changes I was talking about are not a 'refactoring' of the code, just enabling some options/flags on the generated geometry, so the code is the same as the current one. The old random buildings were a completely different approach.
::::::The example was to illustrate that the underlying technology FG is using is old and can be handled by that "antiquated" hardware just fine, and the "modern" hardware only (partly) masks un(der)optimized stuff.
:::::: [[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 15:00, 11 August 2014 (UTC)
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/74961"

Navigation menu