Re: [Flightgear-devel] Generating ground textures on the fly?
Hi Tom, sorry if I sound overly pessimistic, but... several of the potential issues are structurally not that different from problems I've encountered in painting terrain or setting up credible weather. it doesn't mean that I am in any way against your plan, but I want to see if you have any new solutions in mind or if we'd just run into more or less known problems. So, let me just pinpoint the main challenges I see. The basic idea would be: Based on landclass data and OSM roads, generate a unique hi-res texture for a few km out. (maybe using a base texture and overlays as you desribe below.) Gradually reduce texture resolution for terrain further out. (I did some rough estimate which indeed showed I need plenty of video RAM, but not several GBs.) Regenerate the textures as the camera moves. A LOD system always sounds charming in theory, but I haven't been able to really make a good one for clouds for instance. Shuffling data in and out of graphical memory is at the moment for me on a high-end machine (GeForce GTX 670M) the single identifiable source of uneven framerates. I get 60 fps like a clockwork, unless the system starts bringing in large chunks of terrain or new clouds into the scene. Currently we only do this once terrain is loaded, you would do it for every LOD stage - so while we might be able to keep the total memory occupancy sane, it is very likely that the flow of data in and out of memory is much increased, which might make this problem worse. Uneven framerates are, I've been told, a no-go for many on this list (personally I'm somewhat more tolerant in this department). Another problem of LOD systems is that you need to hide the LOD line very well - otherwise there's a ring around you where the terrain changes in some way. As for the generating the resolution levels, there are various ways how this could be done: 1) pre-computed LOD level textures shipped with the scenery + doesn't need much performance - needs much HD space, isn't very flexible 2) LOD-level loading time on the CPU + needs no harddisk space, can respect current environment conditions to some degree - creates a very uneven performance load dependent on airspeed, all textures cost the same memory as pre-computed textures 3) per frame on the GPU + needs comparatively little memory, has very even performance load, LOD-levels can be implemented fairly trivially (if you don't need it, don't compute it), can immediately adjust to environment conditions - eats plenty of GPU performance (but then, working with textures is what GPU fragment pipelines are built for, so there's plenty of hardware support for that) You seem to think of option 2) whereas I mainly work with 3). Terrain that is 100km out doesn't need 1m/px resolution. I'm certainly thinking of a LOD scheme here, so I won't need 11.000 unique texture sheets. Well, you don't need 11.000 hires texture sheets, but you do need 11.000 unique texture sheets unless you want to have a graphical discontinuity where a default texture sheet is replaced by a completely different-looking specially-designed hires texture sheet. A texture 100 km distant can have a 100 m per pixel resolution, but it still needs to be an averaged variant of the later hires texture. That's my main problem with a cloud LOD scheme. I know how to create a very cheap to render cloud 100 km distant. I know how to create a nice-looking cloud close-up. What I don't know is how to replace one by the other without clouds suddenly changing the visual appearance completely. In other words, the problem is that the lowres LOD levels still need to know what is painted on the hires LOD levels, but you somehow need at achieve this without actually creating the hires version, because if you create the hires version in every instance, the performance gain is pretty much gone. Procedural texturing on the GPU can do that by simply filtering the hires structures out dynamically once they get smaller than a pixel. Textures do it by mipmapping. But how do you want to do it with a runtime-generated texture? Somehow you need to create the whole hires texture sheet, then mipmap it down to the resolution you need, and then throw away the hires information to free memory - but that is a very expensive scheme, as there are plenty of texture sheets to be generated to fill a ring 100 km out. I don't get this yet: why is blending the texture against the surrounding bad, and what's the problem with non-local information? Blending isn't a unique procedure. Taking a sand texture with 50% alpha and a rock texture with 50% alpha usually works in a credible way and gives me the appearance of sand-covered rock, but blending city texture with 50% alpha with forest texture with 50% alpha looks plain silly, if you want to create a rough stand-in for a park-filled city, you need to create noise at the size scale of the parks, and then use the noise value
Re: [Flightgear-devel] Generating ground textures on the fly?
Hi James, Thank you for your input! I wasn't aware there is such thing as fgviewer. It's definately a good starting point, I will have a look at it. Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be delighted to discuss what you've done and a whole range of possibilities :) If by what you've done you refer to the OSM building generation: I haven't done rocket science yet. Just a couple of python scripts and some facade and roof textures. Clustered the buildings as you suggested on the forums and added a LOD animation, and now I get decent frame rates with impressive building coverage. I know there's a perl script around which does the same -- but I'm just not a perl guy. Cheers, Tom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generating ground textures on the fly?
Hi Thorsten, Thank you, too! This becomes a performance issue eventually - see Paris (France). Random buildings scale well for memory and performance because they're numerous instances of the same building, so just the various positions need to be stored separately - a city full of unique buildings needs to store each building uniquely. The basic idea doesn't really scale well. It looks impressive, and scales well enough on my machine, which isn't really high end: i5-2500k, GT640TI. The basic idea would be: Based on landclass data and OSM roads, generate a unique hi-res texture for a few km out. (maybe using a base texture and overlays as you desribe below.) Gradually reduce texture resolution for terrain further out. (I did some rough estimate which indeed showed I need plenty of video RAM, but not several GBs.) Regenerate the textures as the camera moves. I have no idea if current CPUs/GPUs are fast enough for such a scheme. Or if there's a better way to achive this. This is why I'm asking you guys. This isn't as impressive as you think - the kind of graphics card that can deal with 11.000 unique terrain texture sheets in the scene (you need something of that magnitude, see the numbers worked out here http://wiki.flightgear.org/Procedural_Texturing#Photo_texturing ) is also the kind of graphics card which can go through millions of vertices. Terrain that is 100km out doesn't need 1m/px resolution. I'm certainly thinking of a LOD scheme here, so I won't need 11.000 unique texture sheets. + shared models with an individual piece of ground texture Well, but how does FG know how this is supposed to look? Obviously, if you would do it manually, you would blend the individual ground texture against the surrounding. This is exactly how I'd do it. Which is bad, because it means you need non-local information to get the task done. I don't get this yet: why is blending the texture against the surrounding bad, and what's the problem with non-local information? You'd also want to generate different patterns in Europe, the US, Asia,... Yes, I'd be happy to generate different patters for different countries. If the code supports it, artists will step in here. No, resolution will in fact go much down because of the memory limit. In the current scheme using a finite set of terrain textures with procedural overlays, we can achieve cm-sized resolution on ground features. Great. Can we have overlays for a finite set of buildings? In the end, if I could make a wishlist how to design the scenery rendering, I would probably separate hires sharp features like roads out and describe them via vertices and pass the informtion on landclass distribution via a meta-texture with relatively coarse resolution and build the actual textures procedurally everywhere based on the relative distribution densities of features coming from the meta-texture. Unique buildings would then need to be registered on the meta-texture in the scenery generation stage, the actual procedural terrain cover would be generated runtime on the GPU. Sounds like a good plan to me. As for the Intel graphics argument, I'm with Gene. Cheers, Tom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generating ground textures on the fly?
I've been playing with populating my home airport's area with buildings derived from OSM floorplan data. I think having many buildings in the correct place greatly improves realism over the current random buildings/sparse static models, especially when you know the area. However, now the buildings obviously don't match with ground textures or random trees. Any bright ideas how to achieve this? I know I could follow the photoscenery approach and pre-render special materials and masks for a couple of cities, but that just doesn't scale. I wonder how x-plane 10 does this? Could we generate the texture on the fly? Based on landclass and road data? I could see a number of advantages/disadvantages here as compared to our current, generic textures: + much better autogen scenery possible: many textured streets/railroads without additional scenery vertices + shared models with an individual piece of ground texture + get rid of sharp landclass borders + possibly improved resolution - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM) - probably totally incompatible with the current terragear toolchain I know C/C++ and would be happy to start tinkering with this part at some point. But I know next to nothing about OSG, OpenGL, and shaders. Graphics gurus: is there any better way to do this? Cheers, Tom -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generating ground textures on the fly?
On 11 Mar 2013, at 20:37, Thomas Albrecht ra...@web.de wrote: I've been playing with populating my home airport's area with buildings derived from OSM floorplan data. I think having many buildings in the correct place greatly improves realism over the current random buildings/sparse static models, especially when you know the area. However, now the buildings obviously don't match with ground textures or random trees. Any bright ideas how to achieve this? I know I could follow the photoscenery approach and pre-render special materials and masks for a couple of cities, but that just doesn't scale. I wonder how x-plane 10 does this? Could we generate the texture on the fly? Based on landclass and road data? I could see a number of advantages/disadvantages here as compared to our current, generic textures: + much better autogen scenery possible: many textured streets/railroads without additional scenery vertices + shared models with an individual piece of ground texture + get rid of sharp landclass borders + possibly improved resolution - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM) - probably totally incompatible with the current terragear toolchain I know C/C++ and would be happy to start tinkering with this part at some point. But I know next to nothing about OSG, OpenGL, and shaders. Graphics gurus: is there any better way to do this? Hi Tom (another Tom!) A very interesting idea - so interesting I thought of it and discussed it with some people last year :) The summary answer is, it should be possible, it would have pretty much the benefits and drawbacks you mention (especially the VRAM consumption), and it would allow nice LoD and solve some other issues. Especially it avoid the nasty clipping issues we have with surface data in TerraGear, since you just paint into the texture, no need to clip all the linear data. The big problem, I was told, is that this kind of texture generation (and regeneration, as the camera moves) is very unfriendly to OSG. Not to say it's impossible, since osgEarth does it, but as you noted, it's a very long way from our current scenery system in terms of technologies. If you were starting from clean, you'd probably do this using GLSL to render the textures, and potentially require OpenGL 3. My suggestion is, if you want to pursue this (and I think it would be worth trying, for sure), do it as a fork / clone of 'fgviewer', which is our standalone viewer client. I.e copy how that program talks to the main FG process, and the replace whichever pieces of the render you need(like, all of it?), to make your approach work. Along the way you will have to learn quite about OpenGL, shaders,and OSG, but there are people here who can assist with that. There's a larger issue here, that 'soon' (likely during the summer) I want to start restructuring the codebase into multiple processes, so we can support different rendering architectures (and use multiple CPUs) better. That's Mathias Fröhlich's HLA/RTI work, and indeed he has done the recent work on extending fgviewer to test changes to the current terrain system. Oh, and if you can do IRC, I'm sure the guys in #fg_scenery would be delighted to discuss what you've done and a whole range of possibilities :) Regards, James -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
