Catalanoic wrote in Mon Jul 12, 2021 3:51 pm:You are right, the problem is, some people (me too) tend to place unnecesarily good textured and high poly objects alltogether and in quantity so it can overkill most GPU/CPUs and eat most of your RAMs, even with high-end machines.
(This is more a wider topic now, and maybe the thread could be split?)
Yeah, it's tempting - there should be some guideline/examples/automatic warnings/rules, or scaling at runtime on older hardware (scaling should allow models to eb a bit more future proof as harware will get faster).
It's the textures sizes that need attention first/more. GPUs can handle a (reasonably) high polygon count. Vertices in AC files are in human readable text and don't take that much space in RAM/VRAM - they also compress well in TerraSync (if you want to reduce AC file size on disk it's possible to round off vertices to a 1cm or 1 mm grid in blender).
Higher res textures and more vertices won't affect CPU-side boundness (unless there's not enough VRAM and the GPU caches to RAM). They'll mostly cause GPU-side boundness. What causes CPU bound slowness and FPS drop in busy areas is having too many models, or too many state changes (maybe also if content in AC files is sub-optimally arranged by FG rendering - don't know if that's the case).
In any case, it should be fine to combine models in existing areas like KBOS into 1 or a few objects - as those are known to be reasonably well optimised in terms of textures (KBOS is CPU bound even on reasonably fast CPUs, and is a no fly zone for older/mobile systems).
Ideally as much of the geometry should be bundled together as possible. OSM2City happily bundles 4km meshes. Textures/lightmaps for buildings around a busy area like an airport should be combined, so it gets drawn in one call / with no extra state changes. In general the same 'type' of textured surface should be bundled in one object where possible. It's fine to combine things, even if it means doing different parts of buildings in an area as different objects. For example if parts of a airport buildings like the roofs has a light map and the rest doesn't it's possible to do roofs and walls/interiors of buildings in two objects, - or the fastest way would be to just use a small blank area of the lightmap for some parts of buildings and do everything in one object. If roofs of buildings have a separate specularity to walls/interiors doing those as 2 seperate objects is justified as it prevents a state change.
Catalanoic wrote in Mon Jul 12, 2021 3:51 pm:Experience and time organizing it so you can optimise keeping all your quality is what really difficult is but you know, most projects are made by individuals, not profi-ready teams. Hard to solve, but I think, if the infrasctructure was able to easier to modify and correct, like contribute to Wikipedia or any similar project, most of these problems would be already solved and the limits about these objects/textures further
With regards to textures - there are several ways of addressing the issue.
Firstly, With regards to VRAM and GPU memory latency - recent era GPUs have many GBs of VRAM, and higher end models have 8 GB+. In the coming 5+ years both VRAM memory latency and amount of VRAM will improve.
- First approach might be to reduce the size of texures on GPUs that ahve limited VRAM or have VRAM latency issues. Textures are already downscaled if a texture exceeds the GPUs max texture size. There could be options for downscaling depending on category of object. Example Object categories: aircraft (cockpit interiors need to be readable), environment (uses a reasonable amount fo textures so high payoff for leaving this turned up), 3d scenery objects (maybe a OSM category as OSM doesn't use much textures), airport objects and landmarks. Each category could just be a two settings, using a tick box (for recent era and older era GPUs).
- Second approach might be to have different categories of scenery objects with different specifications on how stretched out textures are. These could have different automatically imposed size limits, or just have different guidelines people could follow.
Categories of scenery objects could be identified based on filename - e.g. *-viewed-close (airports, helipads, carriers), *-viewed-close-clutter (airport ground clutter which could aslo be optional on slower machines), *-landmark , *-viewed-medium , *-prominent-medium-range (similar to viewed-medium for objects that stand out a bit because of colour or shape, or just because the terrain around them is barren), *-viewed-long (low textures for generic buildings that don't stand out and are numerous) .
It's possible to specify how stretched textures could be - e.g. 1 meter = x pixels. It's also possible to provide some example objects and textures that people could use as a guideline.
It's also possible to find a way of telling a modeller how stretched out the texture is when uploading and check it against different categories - blender can probably tell someone this anyway by some option or a plugin.
- Third approach would be for scripts to automatically combine buildings/objects in an area where possible - and have people do smaller objects. Something like this is/was planned for the next world build if I recall correctly? using STGmerge scripts. The different object categories and guidelines are still useful for reducing VRAM use / latency.
Kind regards