422
edits
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 01:51, 11 August 2014
, 11 August 2014no edit summary
No edit summary |
No edit summary |
||
| Line 47: | Line 47: | ||
--[[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. | |||
:::'''8kX8k''' textures are '''overkill''', unless they are a proper '''texture atlas''' and the whole model uses just that one texture. Keep in mind that that texture will be uncompressed (since the .dds format is effectively banned), then mipmapped (which makes it use 1.5x system/video memory than the original uncompressed texture) and it's a waste of system and video ram, not to mention the time spent on CPU to generate the mipmaps, which will cause huge freezes to any system when your aircraft joins any MP session. | |||
::: Before anyone comments, yes the global water depth-map is 16kX8k, but that was necessary to have proper detail, and it's only one texture used by any "Ocean" tile in the world. And now with Stuart's changes to the materials handling, splitting it into 4 textures becomes possible and worth investigating. | |||
:::OSG has its builtin LOD/Decimation, any individual "feature" that would be rasterized to less than 8px (default, could be set to an arbitrary size) will be culled away. Everybody's whining for LOD, but they forget one essential thing, LOD comes at a cost (roughly speaking 1.5x increase in memory usage, both system and video, so if your model is already 'heavy', LOD won't help, it will actually make things worse; either that or thrashing as you load LODs individually if you went that route). | |||
:::There are a few very "cheap" and effective strategies to optimize your model. Biggest wins come from merging all "static" meshes into one. Then clean up your textures, don't leave alpha channels in opaque textures (causes unneeded overdraw and depth testing, not to mention weird culling/transparency bugs; I'm talking about the diffuse texture, not the additional ones assigned/used by effects). Then you can look into optimizing vertex/tri count, and there you can start with removing faces that will never be seen. Then you can look into detail optimizing, like what features are easier and cheaper to do via a texture+normalmap vs. what can be modeled. It's all smoke and mirrors, and the fewer resources your result needs the better, even if that means that it's no longer 100% accurate (irrespective of what GPU it ends up on) | |||
:::BTW, minimal system requirements for fg are an OpenGL2.1/GLSL1.2 capable card, period. That's what it needs to run, until further notice (a port to OpenGL3.1+ will have to be done sooner or later). That means a generation 8xxx nVidia card or the ATI equivalent (I'm not even going to discuss the IGP solutions as they're not worth it). They're by far not current cards, but they can and should handle it very well, if things are properly optimized. (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) | |||
:::Please note that above I'm talking about 'optimization', and not about simplified/featureless models/textures/etc. for "low end specs". What you're doing with a "modern" GPU is simply offsetting the rather huge unoptimized part with raw "power", and that's not ok any way you look at it. (And yes, this optimization will help the higher end GPUs too, as they will be able to cram even more stuff in the scene, or do some extra interesting things without choking) | |||
:::As to the issue with parenting in blender. You have to reset your objects origins and make them all have a 0 offset to the parent. '''Shift+c''' to reset 3d cursor to scene origin (0,0,0). Select the parent -> '''Object''' -> '''Transform''' ->'''Origin to 3d Cursor'''. Then with the parent still selected-> '''Shift + g''' -> '''Children''' (to select all children objects). '''Alt+p''' -> '''Clear parent and keep transform''' (to clear the "wrong" parent relationship), then keeping all the children selected '''Object''' -> '''Transform''' -> '''Origin to 3d Cursor'''. Then with the children still selected, '''shift select''' the parent, '''ctrl + p''' -> '''Object''' (to reparent them). | |||
:::'''Do not''' parent '''glass''' and/or other '''transparent objects''' to the main parent. Also if using '''different effects''' on different objects, those with the different effect '''cannot be''' parented to the main parent (they will have their effect '''overwritten''' by the parent's) | |||
:::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 01:51, 11 August 2014 (UTC) | |||