[Flightgear-devel] Issue list
Following a 'tradition', I'd like to remind of a few issues which I think should perhaps be sorted out before 3.0, partially have been discussed previously and involve me asking for some help on the C++ side. 1) rain layers still do not drift with the wind and will be eventually displaced from their cap clouds. I've discussed this previously with James who suggested that a generic way of spawning AI objects (which can get a velocity) from Nasal rather than the current way of spawning non-AI models from Nasal which can not drift would perhaps be a solution. I don't know what the status of this is. 2) runway and other lights do not appear in the effect framework, hence they get fogged inconsistently with what Atmospheric Light Scattering is doing. I think a cheap fix would be to fade them to transparent rather than to fog color, otherwise they'd need to appear in the effect framework and then I could write a consistent shader to treat them. I don't know what is preferable. The same issue persists with particles, although that isn't as severe in terms of showing realistic low visibility for IFR (it's a bit of a spoiler then the runway lights are always visible...). 3) the sun is currently pretty much always drawn, in particular also if it is below the horizon - which means that it shows inside the 'terrain' when the far away terrain is just painted onto the skydome. The sun also shows 'through' a cloud layer if the cloud layer is invisible because it is fogged. I think a property control whether the sun (moon) should be rendered would solve this. 4) exposing the moon phase somewhere as a property would be nice, then the moonlight night lighting could be made automatically - currently it's property controlled and one needs to edit the property by hand to see it 5) following a forum discussion about lightmaps for city and suburban terrain, my idea would be to use the urban effect for this (which has that functionality already) and run a version of the urban shader without the relief effect if random buildings are on. That appears to be working fine: http://www.flightgear.org/forums/viewtopic.php?f=47t=21059 FredB - is this a modification to the urban effect you can agree with? 6) there's still a 'crack' in the sky visible when the skydome shader is used. Based on the color of the crack which just shows the color of the default sunlight underneath (which the skydome shader can't possibly know), I believe this is really a fault line in the geometry and that it can't be fixed within the shader code. It'd be nice to be able to get rid of some of these eventually - please let me know if anyone is working on any of these and I can start picking up things from the other end. Cheers, * Thorsten -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
Recently I was told that some planes have liveries of so high resolution that you have to install low resolution versions to have a decent fps during multiplay. But doesn't FG use mipmaps for liveries? If not then are there plans to do so? Or should the livery be prepared in a certain way to trigger mipmap generation? Perhaps mipmaps should also be applied to interiors as sometimes you can see the insides through the window. Mipmaps for textures are pretty generic for the rendering process. If you would not mipmap textures, they'd create flickering Moire patterns whenever the texture resolution is higher than the screen resolution as (leaving antialiasing aside) the pixel color is determined from a single texture lookup, and the point for that lookup is ill defined when many texture pixels are mapped to a single screen pixel, i.e. the pixel color would flicker frame by frame (that is a problem for procedural texturing). Whenever a texture is loaded into the GPU memory, it is mipmapped if it isn't already. One advantage of dds is that it can contain pre-generated mipmaps - in this case the mipmaps can just be loaded with the base texture, otherwise the mipmap generation is part of the texture loading process. If uncompressed dds is used, the final result is the same - a mipmap tower resides in GPU memory, but the time to load the texture is shorter for dds at the expense of having a larger file. So non-dds textures may generate a short to long (dependent on system) frame delay, whereas dds works a bit smoother. dds can also be compressed, in which case it saves GPU memory, but since that requires proprietary graphics drivers to work, it is not considered an option for FG. The main difference between hires and lowers textures is not lookup speed (that's taken care of by mipmapping) but memory - if the GPU memory is full, system memory needs to be used (which is slower), if that overruns, virtual memory must be used (which is even slower) - I have managed at some point to fill the whole 11 GB of my combined GPU and system memory, and the performance degradation was quite substantial. Quite recently there was a discussion about 2048x2048 textures for scenery, and I'm sure they are mipmapped, otherwise it won't fly. A typical plane fits all of its exterior into at most a dozen hi-res textures, so the added cost of mipmapping those is negligible I think. Scenery textures are typically mapped to 2000x2000 m areas, so you get about 4x4 m per pixel with a standard 512x512 terrain texture, assuming a 60 deg FOV, you get a good graphical impression only for view distances of 2500 m and more. That's okay for airliner cruise altitude, but really lousy for low leve flight. Going to 2028x2048 improves the optimum view distance down to ~800 m, which starts to make it okay for private aviation in single-engine planes, but still lousy for low level flight. So for scenery, there's not only a need for high resolution, but it's also something that you tend to see quite often (almost all the time) at less than optimal resolution. And the whole scenery doesn't need more than two dozens of such textures at any given time - according to your calculation, that's just the performance footprint of two MP planes. In contrast, planes typically map to areas of 10x10m, so using a 2048x2048 texture gives you a 5 mm resolution. Assuming a FOV of 60 deg, you need to be closer to 4 m to the MP plane to actually get to see the hires texture. I think it's fair to say that you'll almost never reach that distance, so you're spending lots of memory on things which you'll never get to see in flight. Assuming you see MP planes from at best 40 m distance, a 256x256 sheet is quite enough. For the same reason, it makes a lot of sense *not* to render the plane interior of MP planes. So, not only would hires MP liveries be insanely expensive as compared to scenery if you just have a few planes in the scene, they would also be utterly useless because you can never get close enough. Hope that answers the question conclusively. * Thorsten -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
But several people reported that hi-res aircrafts break fps in MP, and downscaling liveries solves the problem (and this follows from Stuart's email). But if mipmap _is_ applied to liveries, then why we have to have lo-res liveries separately? Won't one of mipmap levels do the same? Note that people complain about fps drop, not some load delay or space issues. Full GPU memory leads to performance deterioration. If you load a hires texture, mipmapping doesn't automatically remove the hires maps from memory and keeps only the resolution level you actually need, it stores everything. Even if you effectively use a 128x128 mipmap, for memory and ultimately performance, it makes a difference whether this comes from a 128x128 sheet or a 4096x4096 sheet mapped down. Also the question to GPU gurus: I think most aircrafts that have hi-res liveries do so because of several small signs here and there. So does it makes sense to have a lo-res opaque texture that paints aircraft's body, and then a hi-res transparent one that places signs on top of the first? This way hi-res texture will be mostly empty - will it substantially improve GPU cycles and memory usage? I don't think so - that'd potentially only help if you would store compressed textures (see the dds issue), but we don't, and so it would just make memory usage worse. In addition, transparent bits are always more difficult to render. There's some clever things you can do with shader effects which save memory (and sometimes even end up being fast) - but that gets difficult to implement for aircraft creators. * Thorsten -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Which would in fact not make them random buildings at all :-) May I propose to think about something more ambitious? One thing which bugs me is that we have now well-working de-tiling strategies for terrain, but not really for city textures and agriculture. Forest is effectively de-tiled by placing sufficiently many random trees on top - but we still get huge tiling artefacts for large city areas or fields. Deterministic 'random' building on top of that will make the tiling problem worse, because you get repeating patterns now in both texture and objects on top, which wasn't the case with the scattergun. I think one could at least partially solve this by subdividing the terrain into individual coordinate cells and give each city texture inside the cell a random orientation of the texture. The template would be the sparse dot noise function introduced in terrain-haze-ultra.frag , but instead of creating the dot position and radius randomly, the routine would just create a rotation angle randomly. I believe this would improve city and agriculture, but for this to really work, the 'random' buildings and trees would have to be shifted by the same function - probaby at placement time. Would it be technically hard to design the system in such a way that this could be introduced? I don't have a function ready yet, but it's something I wanted to give a try at some point with running a distinct shader for 'random' and 'civilized' terrain which needs different types of overlay. * Thorsten -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures separation, cleanup
- a baseline texture set that is of adequate, but not high quality (e.g. max 1024x1024 size for landcover, or something else agreed to be good enough) to be included by default in the installers (this would also be friendly to people on older hardware with limited VRAM) - high res (and even, ultra-high res) sets, plus a DDS set for those who want it, which can be downloaded + updated later via terra-sync. (of course we can have discussions about if the default set should be really low quality or quite high - but the point is to have levels we can switch between centrally ) I think this is somewhat tied to the question of how the 3.0 default should look like. If the idea is (as has been suggested before) that ALS becomes the default rendering framework, then there are really no hires or ultra hires textures needed since the higher quality level build details procedurally down to cm-scale anyway, so we could have a limit of 1024x1024 textures in the package without any loss of visual quality. On the other hand, if ALS is not supposed to be default, I wouldn't save harddisk space by reducing the visual quality - we want to make a good first impression for the user. So I would get rid of redundant lowres textures which have a hires equivalent then. I suppose dds can be factored out in any case, as there seems to be a strong sentiment that dds cannot be default as it doesn't run on Linux systems with non-proprietary drivers. In general, I would definitely like to keep as many textures as possible in the devel version - when designing regional textures, I find that I really need material to work with, and many textures can be applied to a different purpose after a color transformation. Also, it's going to be rather difficult to package regional textures region by region as many of them are shared across different regions. Hm, I guess in the end I work too much with terrain textures to be really comfortable with a major change in the way we distribute them - I can see the redundant lowres bits go, and I can see that the dds set is easily separable, but I don't really see a grand design beyond. May be just my personal bias. * Thorsten -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Howto download aircraft - impressions on a new PC
Did a fresh install and needed all day to get ~7GB of aircrafts only to find that my most loved the IAR 80 has gone.- Who was ridden by hell to remove the best airplane? The author himself. But you've downloaded 7 GB of GIT repository, not 7 GB of aircraft, and the GIT repository contains all the commit history, so you can restore the IAR 80 from there if you like. * Thorsten -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and 3d cloud switch
..another test case suggestion: if you have a radeon card, pop that in and see how it looks with that, if you don't have a radeon card, try swap out nvidea for nouveau in your /etc/X11/xorg.conf and install your distro's nouveau and libdrm-nouveau2 etc drivers alongside your nvidea drivers and chk framerates etc there: arnt@celsius:~$ dpkg -l |grep nouveau |fmt -tu ii libdrm-nouveau2:amd64 2.4.46-2 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:1.0.9-2 amd64 X.Org X server -- Nouveau display driver Point being? It's well known that the noveau driver doesn't reach the performance of the proprietary driver (and I have a laptop - pretty hard to change the cards...). In any case, that doesn't have anything to do with the observation made by the forum user. * Thorsten -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance and 3d cloud switch
A report of performance dramatically improving for advanced weather when 3d clouds are switched off in the rendering menu (you still get to see 3d clouds) http://www.flightgear.org/forums/viewtopic.php?f=69t=16630start=30#p189983 I've played around with this, and I can't reproduce any significant framerate difference. It is true that the cloud effect file doesn't condition on the 3d cloud switch at all, so Advanced Weather generates 3d clouds no matter what you select here (it can't do 2d clouds at all) - which may be a little confusing, but I have no good idea how to handle this gracefully. Maybe the switch should go away from rendering to the Basic Weather GUI? But that's a side issue. I have no idea where any performance increase might be coming from though - as far as I know, the shaders are completely unaware of this. Can anyone reproduce the finding? Stuart, any idea where this could come from? * Thorsten -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] With best regards...
... to Vivian, the converted wake shader appears to be working http://users.jyu.fi/~trenk/pics/als_new_8_13_02.jpg (not sure when I will be able to commit it, but at least the work is done). * Thorsten -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
I propose pushing out the release by a month. I've got a bit more time available for FG right now, but not as much as I did 12 months ago, and it sounds like James and Thorsten R are similarly time limited. I think it will take longer than usual to address any issues found in the RCs. If we are going to slip the release, we should only do so once :) Agreed - in case there are any problems in my department, I won't be able to react till Sep. 7th - I've two trips scheduled between now and then. * Thorsten -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On the risk of making myself really unpopular, but would now be a good time to defer the release? It seems James is caught in the middle of moving, Stuart indicated some other private things piling up, I have the maddest travelling schedule I've ever had in my life this fall, and I haven't seen a number of other folks around for a while, we don't have release candidates out which will have impacts on bugfixes, assuming there'd be anyone around capable of doing bugfixes,... It seems we've hit a fluctuation where pretty much everyone is occupied with something else at the moment (?) - if that's the case, should we still go ahead? * Thorsten -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog 2.12
On a related note there's also the question of the mouse modes to consider. I no-longer use the old-style mouse modes, instead using the right-click-to-pan-view mode instead. Should that be available through the GUI (in which case I've got to re-write various parts of The Manua) I'm a mouse only pilot, and I'm still using the old mode for two reasons: First, the new mode requires tab to change mode, which you need to do frequently without a joystick, and that key is mapped on some planes (the ufo or the Lightning come to my mind) to other functions which leads to trouble. Second (and that's less relevant) - old mode is quite a deep habit, and if I just fall back to what I was used to while in a helicopter, I end up being so dead and crashed. I think in general the new style is superior, especially if you're a joystick user - so I would tend to make the new behaviour default, I think mouse-only control is a minority position and doesn't need to be default as long as we keep the old style optionally. * Thorsten -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tupolev 154 goes GPL
This is terrific news. Big thanks for the hard work, and especially for going for GPL in the end! This will easily be one of the showcase planes of FG. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grass airfield texture distortion in ALS
1. I noticed some distortion in the texture placement in grass airfields when using the ALS. Here are some snapshots: --basic shader: http://imageshack.us/f/15/p917.png/ --ALS: http://imageshack.us/f/196/9lcl.png/ --Rembrandt: http://imageshack.us/f/839/4ll1.png/ The shots are from ESSZ, although I see it in other grass airfields as well. Version: latest GIT simgear/FG/fgdata (2013-06-30, 20:30UTC). The distortion was there before I upgraded to today's Git... Difficult to see if the others are distorted or not, seems to be just to be a homogeneous color where no distortion could be seen. This is probably related to what I'm seeing with the runway shader effect. I haven't touched either shader code for at least 6 months, so... something has somehow happened to the process creating the runway uv-mapping (normals? tangents?) which screws up the shaders specifically on runways. Now, since not everyone sees it, I first suspected some hardware specific quirk, but James is running pretty much the same hardware and apparently doesn't get any problems. Thus, the next culprit which I can think of is that I compile under Linux against OSG 3.0.1 rather than latest, and it appears that OSG specifics can also throw the other shaders off track as reported during the last days. So my current suspicion is that we're dealing with some OSG change here where dependence on OSG devel versions has somehow crept into the FG/SG code and leads to problems with runways when compiling against OSG last stable. Beats me why this is runway specific, but I would observe if it goes away once the OSG issues are tackled. 2. I also noticed in ALS, that the Mie Factor slider is locked in 0.005, and the other two slider do just nothing when changing their values except from momentary flashes in the sky. This was not happening before today's update... Should they be doing anything? Rayleigh, Mie and density factors should now be controlled by Basic Weather as well as Advanced Weather after Stuart's work on making Basic Weather run ALS better - so as far as I know the sliders should in fact be obsolete. Maybe Stuart can comment? Definitely they should be non-functional (or even absent) when Advanced Weather is running. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.12 RC Broken ?
I am seeing the same(NVidia GT450, Windows 7) . All runways are black. If I set shader options – generic to minimum the runway is restored. It happened within the last few days. I've had a different sort of problem with the runway shaders since a few weeks on my up-to-date Linux version which were showing a checkerboard pattern. This hasn't shown on my 5 weeks old Windows version. I've also seen that the higher level runway shader is affected, whereas the minimum shader works correctly. I wonder if this is related. I assume Ahmad is seeing this under Rembrandt. I am seeing this under ALS (which is a rather different shader code which isn't even doing the same things). Alan - which rendering framework are you using? It bugged me that the problem crept in without me doing anything on the shader code, so I suspect it's not a shader problem, but something that creates problems for the shaders. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Having thought about this a bit more I'm going to propose we do 2.12.0 now and pre-announce 3.0 as the Feb 2014 release to give us just a little more time to prepare and make the 3.0 as polished as possible. After all, it'll be the third major release in 15 years :) . Okay, works for me as well. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grain texture for models - a demo
That would be appreciated. Emilian already reminded me of the normalmap feature, so it'd be interesting to compare the two and see which one I prefer. I don't know if Emilian gave you the notion that these would be competing options or not, but the notion isn't correct. You're not technically restricted to having either a normalmap or a grain texture, the shader allows you to have both, and they also do very different things, so it makes even sense to have both. Think of color variations in smoothly polished wood - these have no distortion of the normal, so you wouldn't do them with a normalmap, but a grain overlay works just fine. You might want to use a grain texture for details which are too small to be explicitly simulated by a normalmap as just color variations (because that's computationally and momory-wise much cheaper to do), but basically if you have surface structure on the size scale of your standard texture, you'd not normally use a grain texture to model them. Cheers, * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Grain texture for models - a demo
Since the idea hasn't really caught with modelers yet, I've tried to get a more practical demo of the virtue of a grain texture and tried to put a grain effect on the Vinson flightdeck (I've always felt that the homogeneous grey color doesn't justice to the details of the model otherwise). Here's a comparison http://users.jyu.fi/~trenk/pics/vinson_with_grain.jpg http://users.jyu.fi/~trenk/pics/vinson_without_grain.jpg In my personal view, this makes a hell of a difference. I'm not getting any visible framerate difference, and the GPU memory has to hold just a single 512x512 texture more. If you want to do the same detail level using conventional texturing, you need a texture resolution of 25600x6400 (I'm guessing no GPU can even process this). There's (unfortunately) a catch - the screenshots are taken on the landing strip where the uv-mapping is very homogeneous, but to my surprise I discovered that the rest of the flightdeck has a rather inhomogeneous uv-mapping, i.e. to make the Vinson really make use of the grain effect, the uv-mapping of the Flightdeck would have to be redone. Vinson crew - anyone interested? I'm happy to send the effect definition and the grain texture. We can use this whenever a model has a large crufely textured surface and just should get some hint of metal surface (or any other structure - we can do concrete or wood just as well) - it's tremendous texture resolution for cheap. But I'm a coder, not a modeler, for me things like changing the uv-mapping take unreasonably long, so I would really hope to get folks from modeling interested. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grain texture for models - a demo
I looked at this possibility already. The carrier deck is made up of a number of odd-shaped areas, for historical reasons. I don't think that a complete rebuild of the flight deck is worth it for this very nice eye-candy (just too much work). Alexis might think differently. Do you really think it has to be rebuilt? My impression was that you just need to map the odd-shaped area to a grey base texture without distortion (now it's mapped to a distorted grey patch) using the same magnification as for the main strip. All the shader effect wants is the same ratio of physical size to texture coordinates all over the deck, it doesn't care about odd shapes otherwise. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Grain texture for models - a demo
Interesting! Any way we can see this example live? I'd love to experiment with it in the 744's cockpit, but that'll have to wait till after next weeks exams... I'll be happy to let you have the files - but the Vinson can't go to GIT because it doesn't really work due to the uv-mapping, and even if I get it to the point where it does (I'd have to see if I can get the ac3d license transferred to my new computer, just copying the directory isn't enough...) it's not my model and I have no business modifying it. If it's just about studying from a working example, I can also give you the extra lines for the Citation Bravo with hires stains, that's perhaps more instructive as it combines grain with other effects. Just let me know what you need. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Hi Stuart, Ah yes. I remember you mentioning this before, me saying I'd add it to my TODO list, and then failing to do so. Sorry. I've now added it to my wiki TODO list so I don't forget again. Are you thinking about the sprinkling of lights that we put over the terrain, the VASI/PAPI lights, or the approach lights. Or all three? :) I think none of the lights are ever processed by any shader code, so they would all get some default non-shader fogging and never fog correctly. It might be as trivial as just running them through model-default.eff, but I can also write a dedicated shader for lights as they won't need any ambient of diffuse light computations. It might also be much cheaper to simply fade them to transparent and use the fog color from whatever is behind rather than to comnpute the actual fog color (which is moderately expensive). This strategy seems to be working well for heavily fogged clouds. Certainly all the runway lighting sticks out worst, because it make the runway outline visible through very dense fogging, which sort of defeats the point of dense fog obscuring the runway. I could probably live with VASI being seen from a larger distance, I guess they're pretty powerful lights, and fog fading of a light source must be a function of the light intensity (and direction - and aerosol size... and...) in reality. I don't think it's a major hold-up, but it would be nice to get it resolved. I'll be travelling next week - hotel rooms have often been the location for major code development, so I'll try to get the wake shader done then. If we agree that this doesn't constitute a novel feature and can be added despite the feature freeze. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Referring to the version number discussion, I've been given to understand here http://www.flightgear.org/forums/viewtopic.php?f=19t=20137#p185619 that there have been already core developers referring to the next release as 2.12 a while ago who would now be obviously pretty annoyed about it [i.e. me arguing for 3.0]. It hasn't been my intention to annoy anyone by opening an already closed discussion, neither do I have a particularly strong opinion on the point, just an opinion. I do not know if the statements quoted above are correct, if there is really a generally accepted set of goals for 3.0 or not, or whether people feel annoyed or not. I took TorstenD's post As of today, the set of new features should be complete. The usual question at this point is: What version number will we give to the new release? Are we ready for a 3.0 or is it 2.12? for a genuine question indicating that the issue would be open, in response to which I summarized by opinion and stated my case. Since I am not aware of any other occasions where project milestones are publicly discussed, I attach a fairly high importance to these discussions hoping that a picture emerges of what is going on. I am well aware that such discussions are not always pleasant, but in my opinion having unpleasant discussions is still better for project coherence than developing in fractured groups which talk only among the group but do not participate in public discussions. In case this wasn't meant as a genuine question and I missed a hint from somewhere, I would like to apologize for needlessly opening an issue which is apparently already settled. I would also like to clearly state that I regard version numbers as an essentially minor issue (with some PR value attached to it). In comparison to 2.0, I see several novel systems leave the experimental stage and reach maturity, which in combination now lead to a quite different user experience, and that's what drives my opinion. If there are already other criteria defined and generally agreed upon, I apologize for missing the point. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Benchmark matrix
It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage. If this could be automated in some way it would be much easier to capture, and then submit, consistent data. Let's think this from the end. What would we like to know? I'm usually interested in very specific before/after questions. For instance, I can push some shader code into a conditional clause and benchmark this to run faster on my system. I'd like to know - does it generalize? I've learned that optimization seems to generalize across nvidia hardware, but I'd like to get feedback in a before/after situation from a Radeon user. Or, system dependent optimizations. Stuart has introduced a cloud LOD system and has some framerate gain from it in overcast layers. I've been playing with it and couldn't get much clear difference in performance, so I just switched it off completely. What I'd be interested in is - for what hardware do we see framerate gain, and what LOD distances would people typically select in order to get a good balance between visuals and framerate. Or would they prefer to vary cloud density, or cloud visibility radius? If we would know what most people select if given the choice, we could set reasonable defaults and structure the GUI accordingly. In the present case - take my suspicion that I'm running something wrong because I have the gut feeling Rembrandt should be running faster - what I really would like to know is if I am indeed doing something wrong (James, please let me know if you find anything...). It's difficult to see how a performance benchmark test would answer the question unless you code in all possible causes of low performance already. For these questions, a standardized benchmark isn't so terribly useful, because I'm at least partially after how users would adjust a balance if they start on it, or I have a very specific question evaluating a specific change. A standardized benchmark would be, if we get enough data, be more of a general warning system - suppose we regularly monitor performance on 50 different systems, and after some commit we see 20% performance drop on 35 of them - that's indicate that the commit might be in some way problematic. But for this, we would require a regular time history - basically the monitoring script should run and report after every update of either FG or the drivers. Well, that's what I would like to know - what kind of information would others like to have? * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
I guess the professional you are has done statistics about the FG users world, thus you are able to be more precise about those unfortunate users who are getting only the single frame per second, which hardware? which operating systems ? Strangely enough I have (you might have noticed by now that I only open my mouth when I have some data to back it up). Unlike other people who assume all users are like themselves, I hang out a lot in the forum, talking to disappointed users and explaining how rendering taxes the hardware and trying to come up with solutions. While Vivian has pointed out that this may not be a representative sample of users as disappointed users tend to be disporportionally represented in the forum because they need help, I would counter that it is certainly more representative than not talking to any users. For instance some Mac laptops seem to show single frame per second Rembrandt (not all of them though). Typically laptops with integrated Intel graphics chips don't fare any better, but then they can't seem to render much OpenGL in any case. Since, sorry at the moment your feeling ( only feeling ) does not convince me. Sorry to say, but whether you're convinced or not is irrelevant for the outcome as long as I am supposed to do the work implementing ALS features under Rembrandt. It's me who needs to be convinced here. But hey, since you think I don't know anything anyway and just pretend to be smart here, why don't you go looking for a different and really smart person to code you what you like. Or better yet, do it yourself. Because I have enough of this - I'm suspending my offer to help merging Rembrandt and ALS features for the time being. I didn't sign up for being insulted, I'm not personally interested, the only reason for me to do this is because others would like it. Find someone else who takes your attitude and still goes doing the things you like. We had at the beginning ( 2 years ago) a nice sky which was working for me and for the others friends. Yes, this has been explained to you at least three times now (I think even once by Emilian in case you have a problem accepting it from me). A sky without a matching terrain shader doesn't work properly and creates horizon artefacts. Do you have any special problems understanding that point or is there any other particular other reason you bring this up over and over again? * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Pushing in front your supposed to be know how is not an argument , usually the more person' s know how is great the less they are pretending to have it. Please stop to pretend to be the best. So you mean to say that actually having written all the ALS code has not in any way given me an understanding of what the code does, where it burns performance and what the bottlenecks are? That sounds like an ill-considered position to me. Don't tell the FG feature can't be improved with Rembrandt by exposing some similar eye candy you are getting with your ALS, That wasn't what I was telling you at all. I was telling you that it probably can be done, but that it's going to be slower than either Rembrandt or ALS, so it won't run for you, and I asked if you still wanted to have it under these circumstances. Have you thought about the Rembrandt lights functions, and others effects. Yes, sure. I'm not quite as stupid as I appear - obviously they require extra computations and will make rendering slower than not having light functions, everything else being equal. For sure the way you have been developing has created a big gap, thus it would be difficult to mix both systems. I remember writing a few times that it would _not_ technically be horribly difficult to port some eye candy, as for instance pixel postprocessing and procedural texturing happens in the fragment shader only and that my assessment is that it can be more or less copied. I also remembered offering to help anyone working on Rembrandt doing just that. There was just zero response to my offer. Anyhow the GPU CPU systems is less significant, than the programs which are developed, and the way they are using the resources. Given that there are users for which Rembrandt renders with a single frame per second, I would assume that hardware is a consideration for them. Admittedly I am a bit tired of arguments 'You must make this faster, surely there must be a way.' I would ask you to demonstrate my ignorance to me and to demonstrate that you can actually make the algorithm run faster. Why don't you sit down and get your hands dirty, find out where the rendering burns most performance and figure out a way to do the computations faster? Maybe you'll come to appreciate hands-on knowledge better then. Best, * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
- ALS now works much better with the random trees. I think there's still work to be done with other shaders (presumably the wake shader has still to be ported?) Yes (if that is really a major holdup, I can probably do this within the next weeks if it makes Vivian smile :-) ...). A more significant problem in my view are the lights which apparently don't go via any shader, so they fog wrongly, and the visibility of the sun below the skydome-drawn horizon or through dense fog - from Fred's answer I gather that they would require some source code work. Also, note that aircraft only show effects if they used the ubershader to generate them - there is no equivalent of 'just the reflection shader', you have to use the ubershader and switch reflection on - so there'd be no legacy support for the older model effects - I'm not sure how widespread the use of old effects is. Not sure if we're missing any other major thing. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Referring to my poor experience with these two computers , i conclude , i can accept a decrease of performance, without loosing any FG facility. I'll be far from the single frame per second your are talking about. First of all, there are people who get a single frame per second with Rembrandt and have said so on this list or in the forum, the fact that you get decent performance doesn't mean that everyone does so as well. We're not developing FG for you personally, there are other users as well. Kindly take note of that. Second, according to what you wrote here on this list, ALS is unusably slow for you. That won't change when you run it under the Rembrandt rendering framework because you have to run pretty much the same operations, just inserted into different stages of the rendering process. Thus, if the algorithms of ALS are unusably slow now, they will remain so if you run them under Rembrandt. Despite of what you may think, Rembrandt is not a magic tool making everything run faster - deferred rendering has specific advantages over the default (e.g. for multiple light sources for instance) and specific disadvantages (e.g. no acceleration due to interpolation across triangles for a coarse mesh as for terrain). Please go back and read what I wrote and try to understand how deferred rendering works before continuing this discussion, otherwise it's a waste of everyone's time. Hum, Given your answer, you have probably some personal memory leak. I'd appreciate if you could refrain from any more insulting language if you want to continue this conversation. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
What version number will we give to the new release? Are we ready for a 3.0 or is it 2.12? Looking through my list of goals for the last coding period: * Get a high-quality model shader running under Atmospheric Light Scattering This is now available, working for random buildings and for several aircraft. A reminder to aircraft creators using the ubershader - normal mapping requires to declare tangent, normal and binormal generation airplane-side. These need to be also declared as vertex attributes in a numbered technique - in order for this to work, the technique n=4 matching the model ubershader effect in model-combined.eff for ALS has to be added, otherwise normal maps do not work and the model receives incorrect lighting. * Implement a scheme for generating autumn colors procedurally The scheme exists and generates autumn colors in central Europe. Since the majority of feedback for this was rather skeptical, I have not pursued the idea much further or extended it to tree autumn coloring, but Stuart has implemented his tree work in a nice way that trees shed all leaves in late autumn, so it's not as good as it could be, but reasonably plausible. At least I like changing the colors a bit. Since autumn coloring doesn't work correctly everywhere in the world (I've mainly adjusted Europe and the North Atlantic Islands), I would regard it as experimental. * make clouds render faster Stuart has done the main work on this one with a LOD scheme dropping sprites beyond some distance. Since this mutilated faint clouds which have just 1-2 sprites to begin with, I recently pushed a way that these clouds are not treated by the LOD system at all. I'd say we need feedback from users playing with the LOD distance if it improves framerates while keeping the visuals or not. We now have overall cloud density, draw distance and the LOD distance to configure the framerate impact of 3D clouds - is this enough? In what form should this best be exposed to the user? What are reasonable defaults? * Improve cloud appearance from high altitude This is mostly done - I've introduced three quite sophisticated cloudlet placement scheme, and it does miracles from high altitude. There are still the rather blocky 8/8 cover scenarios remaining when clouds tend to cover the whole square tile - I wanted to do something to the edges, but haven't gotten around to doing so. Not sure if this qualifies as a bugfix or a novel feature, but I think it's harmless. * The 'ultra' terrain shader This is done - at highest landmass and transition slider setting, the terrain shader renders details to a quality that you can park your helicopter in the scene and have a nice ground resolution (the smallest details are cm-sized, and they move with the wind). From my side, this would be the main selling point for a 3.0 release. The water shader also has received upgrades with color and reflectivty variations of the water and a trick to generate surf at steep coasts. Also drift ice and be procedurally drawn on the water. In arctic regions, we have drifting icebergs by default now. * Regional texturing Since the last release, I've added Indonesia, Madagascar, North Atlantic Islands (Greenland, Faroe, Shetlands,...) and Middle East and Vivian added UK definitions. Combined with Hawaii, Iceland, Caribbean and tropical South America which we've had previously, this is already a substantial variation to illustrate how FG can look like. Especially Hawaii can serve very well as a showcase scenery now. * Atmospheric light scattering and Rembrandt There hasn't been a volunteer to help me look into this from the Rembrandt side, and so according to the plan there has been no development. Based on my current test results, my computer doesn't seem to be able to get Rembrandt fast enough for this to make any sense, although I don't understand this finding. While things can always be better, from my side that's a clear vote for 3.0. With the hires terrain shader and wind effects on terrain and vegetation, combined with the pixel post-processing effects, we can offer much higher resolution visuals on the terrain than before (and I understand with the autum color effect or drift ice some genuine novel effects which are in no other flightsim). * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
A nice list and it's all worthwhile improvement, but it's all tinkering around the edges of existing stuff. There's no step change which would justify 3.0 IMO. For that we need something major, like new terrain (850) or Rembrandt as the default. *shrugs* This would depend on if you're a Rembrandt user (in which case you'd like to have a major step in Rembrandt) or an ALS user (in which case you'd expect a major step in ALS for a 3.0). From my perspective, it's not tinkering around the edges. In terms of code, ALS has about doubled the number of lines. In terms of features, ALS has now all the features that it could theoretically serve as default rendering scheme if so desired without major gaps like missing trees or model effects - this wasn't the case last time, which is why I didn't vote 3.0 last time but why I do now. If you're not a user of these features, they obviously won't impress you much, but they are there nevertheless. The way I see it, waiting for a dramatic step will not ever give us a 3.0, because if some dramatic new feature is introduced, we'd first want to test and observe it, so it will be experimental for a while (so with Rembrandt, ALS and Advanced Weather which all didn't prompt a new number before the decimal), and then the next release will obviously only see progress on existing things, not dramatic new stuff. So, from that perspective, also Rembrandt has by now reached a stable and well tested state and featuring it no longer as experimental would also argue for a 3.0. Right now we have Terrasync partly broken in Win 64, which will probably not be fixed until after the release. We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. I'm not sure I follow you that selecting a screenshot directory from the GUI is a major advance justifying a 3.0, but a detailed terrain shader is not. I'm also not sure why Terrasync partially being broken argues for not releasing 3.0 rather than fixing it before the release. But 3.0 is only my (certainly biased) impression. I agree that it would be terrific to have new terrain. But I don't really see a date, and at some point it seems to me we have added so many features beyond what used to be in 2.0 that it's now 3.0 - which is, from my perspective, now. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
3/ To wait for better development reaching the target to have REMBRANDT and ALS working well all together, and definitively included within FG. (...) The basic content remains the same, some Aircrafts are flying with Rembrandt not with ALS , others are flying with ALS not with Rembrandt Much has been said about this already. So I'll be brief (by my standards...). Please consider: The framerate you get to see depends, with full eye candy on and on modern CPUs, almost exclusively on how fast the GPU can process the shaders. Shader execution speed depends measurably on the number of operations performed. I've now had three years to gain hands-on experience benchmarking shaders what runs how fast - I believe I do have a good understanding of what's going on by now. You seem to imagine a 'best of two worlds scenario' here. Just looking at the operations which the GPU needs to perform for ALS+R and comparing with ALS or R alone, the following is far, far more likely to happen: * The framerate of ALS+R will be a bit slower than the minimum of the framerate you get in Rembrandt now and the framerate you get in ALS now. You say you can't run ALS on your machine right now - you'll also be unable to run ALS+R, because it will be even slower. * I have yet to see a plane in which the normal mapping is properly declared fails to render properly under ALS, but assuming for a moment it exists - for a plane to render under ALS+R, it would have to render now under ALS *and* under Rembrandt. Which is to say, if it doesn't run under ALS now, it won't run under ALS+R, if it isn't Rembrandt compatible, it also won't run under ALS+R. So the number of planes which renders properly for you will be even smaller. * As a result, we would be advertizing features which almost no one can run. You won't be able to run it because ALS fails to be fast enough for you, I won't be able to run it because Rembrandt fails to run fast enough for me, so we'll end up creating a major PR disaster with endless user complaints about abysmally low framerates and posts all over the place 'But I can run insert 3d game here without any problems, so Flightgear must be really badly written.' So all problems which the individual rendering frameworks have now will be worse. You will also combine the features of course, so you could render gorgeous sunset scenes with long shadows cast by mountains - but what's the use if that happens at 10 fps? I have yet to see any real argument why this shouldn't happen. I have test data how much you save by perfect z-buffering as used in deferred rendering, and that will mitigate the problem but not solve it. Frankly, I'm not keen to spend half a year coding something just to create a stream of complaints about unusable framerates. All tests I have done so far back me up. So - are you sure you would want it even if less planes work and you get less framerate than now? Because asking for features just costs a few lines of typing, implementing them is a lot more expensive. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt performance
It could help you to understand why you are getting that poor performances with your pretty fast beast GTX 670M. Thanks, though I remain mystified. There are few differences I can spot: * you have tree density to 0.7 in the shots, I had it at 2.4 - since there's lots of trees in the scene (it's tropical forest), that would be expected to have an impact * you have cloud density set to 0.4 whereas I have set it to 1, and also in vaguely remember seeing a bit more clouds * you have dds textures used, I have used the regional set - my understanding was that this should affect texture loading times and available resolution, but not really runtime performance, but this needs to be checked - So I have 4 times the number of trees in the scene and 2-3 times the number of cloud sprites. I'm not completely sure how Rembrandt manages trees, but it could be that since they're semi-transparent they're like the clouds taken out of the deferred rendering approach. Multiple cloud sprites in a row are a significant drain on both vertex and fragment shaders as you may need hundreds of texture lookups - so the available performance for Rembrandt-specific tasks isn't quite the same. My gut feeling is that this can't account for a factor 4 in framerate though, especially since there is still the pixel number working the opposite way this time - I will have to test this. In addition there's the question of having two GPUs. I wonder if they're both utilized for the job - if so, maybe one needs such a setup to get above 30 fps with shadows? It would be helpful if a few other Rembrandt users could give some indication of what framerates they usually get and what the main framerate killers are. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Rembrandt performance
I've had a my first short go with Rembrandt on my new machine yesterday. The test case was a small airport in Sulawesi (Indonesia) (WAAJ) where I'm discovering a very nice scenery. There are no static or shared models to speak of, there is some forest around, and that's basically it. I chose fair weather, i.e. a modest cloud cover. The aircraft was the PAF team DR-400 in the latest version. All Rembrandt functions work out of the box very nicely. I started with a dawn scene and tried the landing light illumination first. This gave me a good 30 fps. I then switched to noon and tried shadows. I have to say that since I am more the VFR virtual pilot, I almost never fly at night, lightmap for internal illumination work fine for me, and so shadows are the main selling point of Rembrandt which attracts me. The initial shadows coming up by default were rather ragged and flickery (the last is a problem for me, I tend to get headache when looking at some sort of flickers unfortunately), so I played with shadow map size, cascade ranges and filtering till I had a nice result. To my dismay, at this point the framerate counter gave me a mere 15 fps (no shader effects on at this point). For comparison, the same scene renders in Atmospheric Light Scattering with all details maxed out (including tree motion) with solid 60 fps. Am I doing anything wrong? Did I miss any optimization which makes the shadows run fast enough? Am I just unlucky and my system has some unspecified problems chewing Rembrandt? Does anyone else get significantly higher framerate out of shadows with filtering? I am running on an GeForce GTX 670M, which is usually a pretty fast beast. I mean, maybe it's just me, but this appears to confirm a suspicion I wrote earlier that trying to pack ALS functionality into Rembrandt will end up being way too slow. If I have a mere 15 fps before any shaders, then I can't reasonably apply 800 lines of extra computations and expect no performance impact. Does anyone have a semi-solid case which would argue that this would be fast enough? I'm sort of trying to make my mind up if I should focus on that before the next release (which is why I did the test), but it seems hopeless to me. It's okay and flyable as it stands, but I don't see how to cram lots of extra stuff in. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt performance
Which screen size ? With my old GPU Geforce 9600 GT at 1024x800 i never got less than 24 fps (usually 30 fps). It is when using FG 2.10. Decreasing on the fly the screen size increase the fps. Yeah, well, fragment shader load (and hence deferred rendering) scales with the number of pixels. My fullscreen is 1920x1080, which means I have about 2.5 times the pixel number of your screen, which means that if I scale your 24 fps to my screen, I would get about 9-10 fps. If I decrease that by the 30% you mention (since I run recent GIT), then I'd end up with 6 fps compared with my 15, which doesn't seem grossly out of place. But to render 2 megapixels isn't an unusual demand - that's about what the human eye can resolve from a normal view distance. * Thorsten -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Base fgdata
The primary increase seems to be in Textures.high/Terrain. In 2.10.0, the size of the folder was 181 MB, while in the current git version, the size of the folder is 300 MB. If no one has any problems with the autumn texture versions in any rendering scheme (i.e. nobody sees a semi-transparent texture when using the regional materials file under any rendering scheme) then we can remove the non-autumn textures which should free some space. Should we do this? I have added several textures for regional texturing schemes which can also account for part of the increase. The png versions of dds textures are, I think, part of the regional UK scheme by Vivian. So I would guess that a fair share of the increase is actually connected to added features. (Compared with phototexturing, I think our scheme is actually fairly cheap in storage space even with all the regional goodies...) * Thorsten -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Hires runway effect
After a fresh pull and recompile today (I've not had much time for FG the last weeks...) I've noticed that the hires runway effect of ALS appears to have been partially broken by something - I now see a checkerboard pattern when I look at runways and taxiways which hasn't been there before. Is anyone else observing this? Since I've not done anything for the last weeks, something other than the shader must have caused this (coordinate mapping? altered normal?). Can anyone perhaps shed light on this? Unfortunately I still don't have much time right now for a long investigation :-( * Thorsten -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering during nighttime and the Sun
By any chance, is this a bug when using atmospheric light scattering? Yes. The issue you see is that real terrain is drawn out to some draw distance set by visibility and LOD range, and beyond what appears as fogged terrain is drawn by the skydome code. And the sun is set to be always visible on the skydome - so it becomes visible through skydome posing as terrain. I'm not quite sure, the same issue should also appear in the default rendering scheme then, although the colors are less dramatic, the default scheme retains a lot more red light for the sun below the horizon. The problem is that the sun (moon,...) code is outside ALS and doesn't seem to run via a shader, so I can't fix it. A related issue is the sun shining through overcast sky (fog becomes so dense that the clouds are faded, in essence looking up you see the skydome drawn in grey, and the sun is never fogged. The sun rendering would have to be made to respect the angle with the horizon and some fogging settings better in order to address this properly. A cheap 'fix', as you realized, is to draw terrain further out. * Thorsten -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Stuart, sorry for the silence from my side, I haven't been able to start FG up for the last week or so, I am a bit swamped in work and family issues at the moment... I'm slightly surprised that Thorsten's new system doesn't support this, as evidenced from his screenshots. glxinfo claims that it does - I get several instances of GL_ARB_multisample or GLX_ARB_multisample shown in the resulting list (at least under Linux, maybe it's a bug in the Windows driver of the card only??? - I'll check next time I boot up Windows). 1) Forget the whole thing. Revert back to the previous model of having one texture for summer and one for winter, no support for snow-covered trees. I'd still commit changes to fix the black outlines and technique=4, so the effort won't have been completely wasted. With a 4096 texture sheet limit we'd be able to have 512x1024 individual trees. What about 1a) - reverting back to the previous model at low quality, but introduce a composite tree model (where bare tree and foliage and snow are separately read and rendered on top of each other) at high quality setting? I have yet to test how bad a second texture call is in the tree fragment shader, but if it works we could have the pre-selected season model (winter and summer) for the slower systems and a completely dynamical shader-generated season model for the faster systems. This would allow to color leaves in fall, and even partially shed foliage in late fall. And have 512x1024 maximal tree size which is really quite generous. 2) Support dynamic changing of snow-cover on trees, but not season changes. This means that to see a winter deciduous tree one would need to change the season and reload the scenery, loading in the winter material definitions which would include both the tree texture and general ground textures. Thorsten R. - what are your plans for ALS support for winter? I think you currently use the summer materials, correct? This would allow 256x512 individual trees. ALS doesn't _depend_ in any sense on what materials definition you use, it runs fine with dds textures last time I've checked. Only the procedural terrain definitions reside in the summer definitions, but imo it wouldn't make too much sense to have them in the winter materials as well, because the terrain is snow-covered anyway, so it doesn't really matter so much what procedural details you generate because you wouldn't seem them. 2) obviously doesn't mesh with any continuous season model for the terrain or the idea of snow as a shader effect. 3) Support dynamic changes of season, but have no support for snow-cover on trees in the texture itself. This is my probably my preferred option. While having snow-covered trees is nice, the actual circumstances when it occurs are fairly minimal as the snow is blown off the trees by the wind. This would allow 256x512 individual trees. I woud prefer this over 2), if only for the simple reason that it's no issue at all to add some white color sprinkles to the tree textures procedurally - snow is, after all, a pretty simple texture, white does the job remarkably well :-) 4) Accept the limitation of 128x256 individual tree textures. I'm not too happy about that limitation - I would prefer to have a novel scheme which is an investment into the future and which can easily be adapted to yet more powerful graphics cards 5 years from now. Hope that helps. * Thorsten -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree images for texturing
The package of tree photographs is here http://users.jyu.fi/~trenk/files/trees.tgz I will leave this online for about a week for grab. Let me know if photographs taken that way are useful or not, I am just trying out things. * Thorsten -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Air-air refueling
I finally got around to fly a few air-air refueling exercises with the revised system with configurable refueling envelope. I have tested the F-16 using a 3 m envelope and the F-14b using a 10 m envelope (I figured the hose allows a bit more flexibility than the boom - I'm not completely sure about the reality of AAR...). From what I can see, this is now very well done. With a tolerance of 3 m, one actually has to work for fuel rather than getting the tank filled while approaching the tanker - still this is doable. Trying to get the F-14b into the right position is a bit more challenging (it has larger lag between change in throttle and change in airspeed), but still doable. I started receiving fuel just in the position where I would have expected that. So - big thanks to Stuart - this is now much better than it used to be. * Thorsten -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.1
The downside is that I think it would require adding
an if()
test to the vertex shader, something I've been avoiding due to
(unfounded?)
concerns about performance.
General advice that I can find is that GLSL is designed as a linear
program:
conditionals and loops are best avoided:
From my own experience:
* conditionals on flags (say uniform int) are in general unproblematic and work
as intended
* conditionals on a varying are dangerous and only worth trying if you have an
expensive operation which you can avoid - but then they help.
Say, replacing
expensive = some_expensive_operation();
mix(cheap, expensive, x) ;
by
if (x0.0)
{
expensive = some_expensive_operation();
mix(cheap, expensive, x) ;
}
usually does help if x is zero for enough pixels/vertices. The exception to
this are texture lookups which are expensive, but must be evaluated outside of
a branch if the condition involves a varying
* nested conditionals might work for performance gain up to a depth of 2, never
any deeper - then you end up evaluating every branch
* conditionals of the form
if (x0) {do stuff();}
(...)
if (x0) {do_other_stuff();}
don't seem to be recognized as referring to the same condition - they need to
be merged into a single block to be effective for performance.
In general, I think one should stay clear of conditionals, but they have their
use for optimization as well.
* Thorsten
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Tree images for texturing
I have a series of tree photographs if anyone is interested in creating new tree textures. The images are 1200x1600 JPEG, taken on an overcast day in diffuse light, outlining the trees against the bright sky, isolated as good as possible against the background. I've experimented with different exposure times ranging from 1/60 to 1/200. I have bare birches and alders, as well as pine and spruce (= a typical central Finland selection). I have tried to get genuine forest trees, as trees growing in isolation have quite a different growth pattern (in forest trees, the lower branches tend to die off and only the crown is green), but this is tricky for obvious reasons. My impression is that some photoshop/gimp postprocessing is needed to create suitable textures - if anyone is interested in having a go, please get in touch for the package. * Thorsten -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New features for 3.0 (?) presentation
* Canvas instances can now be placed on scenery objects. This allows for example creating animated signs/monitors. I've started to create a Visual Docking Guidance System, which is not fully functionally yet but should be complete enough to be used for a screenshot (eg. azimuth guidance is missing) If I could get a screenshot from you, that'd be nice. If you want I can create a video of my work in progress C-130J making use of these animations. This sounds very neat! Hm, I guess one could make a video presentation of all animated features (like the trees moving in the wind, or the storm blows dust /leaves effect I'm working on), but maybe someone else should do that - video is not really my area of expertise... * Thorsten -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New features for 3.0 (?) presentation
I thought it'd be a nice idea to present one or two articles on the FG project page about things to expect from the next release (3.0?). These would be features which have appeared on GIT since 2.10 or are epected to appear before the release. Consider the articles as advertisement material, so they should be visual, exciting and be at the forefront of what FG can do. I have flagged for the purpose * tooltips and the gnome-themed new popup windows * Heiko's devel version of the EC-135 * Stuarts work on AAR with new tanker planes * improvements with regional textures and trees * (my own stuff on weather, light and hires procedural texturing) * (what about the linear texture work on roads and railways?) If you know of anything else which makes good publicity and can be explained in a picture and a paragraph of text, let me know or better let me have the picture and paragraph of text (preferably by the end of the week). * Thorsten -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
That's not quite right: you should be able to use one _effect_ across all rendering schemes, but under the hood different flavours of shaders do the work. (...) We have recently broken that principle with the grain effect - it only works in ALS. Oh, so Rembrandt-declared lights do work properly to illuminate cockpits also in other rendering schemes? Because otherwise it seems like there are rendering effects which are not supported in every scheme quite outside of ALS. Come on... First of all there is no stated principle that every effect must work in every scheme except in your messages, second that's not what Rembrandt does or ever has done with lightmaps vs. Rembrandt lights either. * Thorsten -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
There was so many wrong remarks , that i forgot that one: I am quoting you Only Rembrandt requires separate Rembrandt and no Rembrandt versions of aircraft. Are you unable or unwilling to acknowledge that point? Aren't you talking about stuff you don't know? An aircraft which has been modified to fly with Rembrandt ( like said only transparencies are involved) , can be flown without Rembrandt. Well, yes, in the case the aircraft didn't have emissive lights before and couldn't be flown at night that may be the case, but, to quote the Rembrandt Wiki page: * Rembrandt computes shadows = no more fake shadows in the model * Rembrandt computes ambient occlusion = no ambient occlusion baked into textures * Rembrandt has light = static lightmap are not needed, emissive color to see models at night is not needed and would interfere * Rembrandt has glow = incorrectly used emissive colors may blur displays and make some text unreadable. Light size may have to be adjusted (...) Again, please get your facts right before you continue the discussion. In the general case of lightmaps and/or emissive instrument textures used for night flights, you do need two versions (you can use auto-detection and conditional animations to hide that fact from the user though). Seems your aircraft don't have those then... doesn't mean no one else uses them. This really gets a bit tedious and I believe the topic is exhausted... would you mind carrying your grudge elsewhere rather than desperately trying to find any mistake in what I say? I think you have demonstrated your level of comprehension of the FG rendering internals sufficiently. Thanks. * Thorsten -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Sorry it is not ALS Compliant. I think we covered that one early on in the discussion last week. Quoting myself: You'll have noticed that the ALS ubershader (short of inserting the tangent, normal and binormal attribute for normal maps which I understand really _must_ be airplane-side) works out of the box without any action required in ALS. But reading what I write doesn't seem to be your main strength, does it? *sigh* This really really gets a bit tedious and I believe the topic is exhausted... would you mind carrying your grudge elsewhere rather than desperately trying to find any mistake in what I say? Thanks. * Thorsten -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Vivian: I don't want to download fgdata/fg/sg to find that I have to spend hours fixing up my work. I'd rather get on with my own stuff. Your actions don't match your words. You're the remaining maintainer of the water effect in default. Its environment interface still doesn't support Advanced Weather. When you implemented it, it had zero communication with Advanced Weather, I had to spend hours to figure out how it gets light and wind info and then code a hack for Advanced Weather to make it work. If this is a real concern to you - there has been a long weekend to get busy and change the interface. Looking at GIT, you haven't done so and we're still using the incomplete hack. Any plans to change that in the near future? I don't want to force developers to develop ac for one scheme/framework rather than another. As pointed out for the 3rd time now, that is a hypothetical problem in ALS. Only Rembrandt requires separate Rembrandt and no Rembrandt versions of aircraft. Are you unable or unwilling to acknowledge that point? I don't want to force users to choose between a nice atmospheric effects or shadows, or anything else. I think I have said about 5 times now that I am perfectly willing to contribute to this, but I'm not doing it all on my own. I haven't seen you volunteer to help out here. I haven't seen you arguing with Fred that he should take care to help out. Somehow, it seems to be my fault. Also - you can burn framerate only once, and I have stated my opinion on that as well. My personal view is that OpenSource is about freedom, and freedom implies choice. It's nothing bad to deliver a rendering scheme for low end GPUs and one for high end GPUs and let the user pick, and I don't even see you acknowledging that argument. I acknowledge that we probably have a fundamental split of philosophy here: I see more merit in offering different choices to the user (think Linux with KDE or Gnome - I see myself well backed up by OpenSource tradition here) than in pre-selecting to the lowest common denominator we can all agree on so that the user doesn't have to choose. You see this differently, and we probably won't ever resolve this. Vivian, I don't see this getting any more constructive, and I don't have the impression that this is about me explaining to avoid a misunderstanding. I don't see my arguments acknowledged, much less refuted. I don't see you willing to take any action making the framework which you maintain accessible. So I will not justify the reasons behind what I do to you any further, and unless I see a constructive turn, I will also refrain from doing so in the future. Henri: How could you say you're both not even users of the scheme ? Yes i had at the beginning done some screenshots with the Dome project, the period when i could use it without breaking others features. I was, even, able to combine the Effects with the dome by unlocking the conditions. To me the project was promising , until you engage to develop deeply. As explained several times over, when the skydome used the default terrain shaders, it produced glaring graphical artefacts. What I have done is the only possible series of changes which could have fixed this. I'm sorry you are unable to understand that point, but maybe ask someone who does to explain it to you in detail. Otherwise, when I say 'you are not a user', I mean that I have a mail in my inbox which is signed with your name from which I may quote the phrase introducing some unusable features like the atmospheric light scattering - which would appear to the English-speaking reader indicating that you don't use it. You pretend to be experienced and worry we don't use your know how, Emilian is experienced and you rejected his know how. Would you say everybody but you is stupid. I'm a scientist. I don't believe in persons. I don't believe in Emilian, TIm, Fred or Mathias - I believe in verifiable facts and solid evidence. I believe that each of these person knows much, but that likewise each of these can get things wrong, and when anyone raises an issue, I make up my own mind by thinking it through and testing it myself. I don't think everyone else is stupid, but I do think everyone else can make mistakes just like me, and I have a very long professional experience in recognizing and dealing with my own mistakes. To expect that I would take advice from anyone without looking at the hard evidence available to me is unreasonable. I'm not impressed by titles, merits and experience - I argue with Nobel-price winners just as with students if I think they're wrong (I have done so on occasion). You will be able to verify that in each and every case someone backs up his critique with actual evidence which I can verify, I usually change my position quickly. You will also see me in these cases publicly acknowledge that I was wrong and crediting the person who corrected me. You will also be
[Flightgear-devel] No shader compilation error messages
With the recent FG, both Linux self-compiled and Jenkins for Windows, I no longer get compilation errors from the shaders thrown to the console - badly formed shaders just don't work without complaining. This makes developing a bit awkward now and will make it close to impossible to trace problems of other users in the pre-release testing phase. I assume this must be FG related, as I didn't change my OSG version under Linux or the graphics card drivers on either Windows or Linux? Does anyone have an idea what may have caused this, and if so would it be easy to put the error messages back in? * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
However, one reason I didn't spend more time on it was that it didn't seem particularly useful from a sim perspective. If found that to see the effect at reason (30kt) winds you either need to be sitting on the ground or at quite low altitude when your attention is elsewhere. I think you would see it quite well with a glider when ridge-riding - you're moving comparatively slow, you're close to the ground and there is strong wind. Also, helicopter pilots would probably appreciate good terrain close-up scenes in general - nowadays I quite often take a heli to some mountaintop and back to the airports, just because it's so nice to explore the terrain. In a more general sense, I find it an interesting avenue to make FG more interesting for a user community outside flight as well. For instance: Here http://www.flightgear.org/forums/viewtopic.php?f=19t=19626 is someone using Unity3D to walk through hires terrain with the skybox showing FG-rendered terrain and weather to the horizon. What if this were directly running in FG (the terrain resolution we can get is quite competitive) - so maybe we could eventually have a mode of a walker going out of the aircraft and exploring the terrain a bit. Whenever I land in L'Alpe d'Huez, I would like to go and have a virtual cup of coffee before heading back... One could start in a briefing room in the carrier and walk to the aircraft... You name it. Here is Chris driving through virtual Innsbruck with a car: http://www.flightgear.org/forums/viewtopic.php?f=19t=19294start=60#p182039 apparently it's now good enough that this starts getting exciting in its own right. Do we perhaps get more of this? Just to be able to deliver an interesting scene from the ground might open FG up a bit more along these lines, and maybe draw some modellers in which contribute to the scene. Then there is the marketing argument - seeing the wind move trees and grass is cool - and we get often compared to e.g. Outerra in terms of scenes, so why not counter with some cool effects of our own? Reads well on a 'new features' list of 3.0... In practical terms, as you indicated, wind motion isn't excessively expensive - usually it's down to a few trigonometric function and some basic arithmetics, all of which runs very fast as compared to, say, getting a single noise frequency or computing an environment-map reflection. So while it's not immediately relevant for flight, I still think it has some reasonable gain for pain ratio, especially since we can implement it optional by checkbox. However bear in mind that the same constants would be used for both oaks and conifers, which I'd expect to move different amounts. You're right - same with the motion of grass and shrub... It's quite hard to come up with closeup motion that looks well on both corn and in the desert. We could pass stiffness constants as uniforms if we really like, but I think this would be over the top... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No shader compilation error messages
If this is the cause, it's been that way since January, and I assume you
would have compiled from source since then.
I still have the funny GPU problem under Linux that the GPU refuses to go to
high performance, so I don't actually develop shader code under Linux but use
it just to interface with GIT and do quick tests. I update the Windows much
more rarely, since it's a royal pain to do, so it is well possible that I
didn't spot it since January despite compiling under Linux a few times.
Is this what I'm looking for? Not sure which is which.
void fgOSOpenWindow(bool stencil)
{
osg::setNotifyHandler(new NotifyLogger);
//osg::setNotifyLevel(osg::DEBUG_INFO);
(...)
* Thorsten
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
How could you say you're both not even users of the scheme ? (...) which would appear to the English-speaking reader indicating that you don't use it. (...) Yes there not any contradiction ,since i said, quoting myself: To me the project was promising , until you engage to develop deeply. Where is your scientist mind? Note that in the English language the present tense 'you are not a user' has a meaning different from the past tense 'you were not a user' or the perfect tense 'you have never been a user'. Best, * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
That said - I don't see why an Atmospheric Light Scattering scheme should have embedded in it some ac modelling stuff. That serves to diverge the schemes. And it makes it look like ALS is your private sandbox. Offering new and different options is the whole point of having a different scheme. What would be the point of having Rembrandt if it were to look just as the default scheme and would not offer novel options? You think these options should be limited to the sky (and terrain?) - fine, I don't, I think they may well affect models, trees, all the visuals. Since Emilian accused me of wanting to rule FG anyway - just what would happen if I would start editing some new effects also into Rembrandt or default? Or if I would decide myself how Basic Weather needs to interact with ALS? Let me give you the answer: I would get the same accusations 10 times over - and (at least partially) rightfully so. It's not my call to make - it's up to the maintainers of Basic Weather (Rembrandt,...) to decide what to include and how. There's simply no pleasing some people - if I introduce new effect in my framework, you complain about diverging schemes, if I would do it everywhere you would be complaining that I can't simply make such decisions on my own. So in your book, I just shouldn't introduce any novel effects at all unless you approve? (You didn't say this, but it pretty much follows.) You can't be serious. Last time I checked, I designed or ported something like 95% of the code of ALS. Stuart did some work on the trees, Lauri did the original skydome shader before haze, Emilian contributed insights, corrections and tests to the ported model ubershader - and that's basically it. So I guess that makes me the current maintainer of the scheme. What you (and Henri) are really saying here that you guys should really have a vote on where the scheme is going without investing work into it (and ironically enough, you're both not even users of the scheme), and you should even be able to overrule my own judgement on what is important and how things get implemented and be able to tell me what I should be working on first. Just since when did we start doing things that way in FG? I fully accept that decisions which affect other subsystems, potentially disable them or require substantial action by others must be discussed and voted on, and that coding e.g. an explicit preference for one weather system over the other is a bad thing. So if the choice were that we can have either Rembrandt or ALS, we'd need to have a discussion and a vote. But that's not the case. Thus, you don't get to overrule me if I consider implementing wind effects more useful than the wake effect. You can bring up your case, you can ask nicely, we can have a discussion, but as long as you expect me to do the work, you'll have to live with my decisions and wait till your request reaches the top of my to-do list (in the case of the wake, I have already stated that it's on the to-do list - same with the rainbow). You can do it yourself if it has a higher priority for you (in which case I offered help and expect the customary amount of coordination with what I'm doing, same as if I would start working on one of your aircraft), you can convince anyone else to do it (in which case I'll also help), and that's how it works everywhere else in FG. If I want a particular feature for an aircraft, I ask nicely and try to be convincing, I don't go around claiming the aircraft is broken every time. Why is this mode not acceptable to you? You know, I don't want any special treatment here - I just want that the same standards are applied to me which apply to other people (specifically also you and Emilian). And I can't see that in what you say - I'm always held to much stricter standards. Vivian, for all your eloquence, I don't get the impression that all this is the real sticking point - what is _really_ bugging you here? You're not a user of ALS, I haven't seen it on in any of your screenshots. You're not affected personally by anything I do. I told you I will put the rainbow back and I will implement the wave, and we're in the middle between release periods, just when it's officially time to introduce new features with the idea to consolidate towards the release. So there can't be any serious concern at this point that users might not get to see and appreciate your work sufficiently. You argue against the hypothetical case that you might potentially have to adjust your aircraft for ALS even when this is not factually the case. At every opportunity, you speak up against the way Advanced Weather is done. You implemented, together with Emilian, an environment for the water shader which explicitly favours Basic Weather over Advanced Weather, in spite of the fact that I documented the lighting model of Advanced Weather in the readme, outlined it to you on this list, again in a mail to you and
[Flightgear-devel] (no subject)
If something exists and works in the default scheme, but is missing or does not work in a child scheme then that child scheme is broken or we might say that there is a regression. Which all would be relevant if it would be a child scheme - which it isn't. The solution was obvious - combine the Fresnel and Rainbow look-up textures into 1 texture. A few trivial changes - job done. Of more interest, we could, and probably should, do something similar for almost any complex math function. That depends on the complexity. To compute the rainbow is a rotation in color space - GPU's have hardware acceleration to do the job and this computes way faster than looking up a texture. A typical Fresnel curve can probably be parametrized by a polynomial - if so, again that'd be way faster than a texture lookup. In no test case I've studied so far was a texture lookup superior to function evaluation - exponentials, combinations of sine functions or even the generalized logistic function computes way faster than a texture lookup. Akenine-Moller 'Real Time Rendering' also confirms that on modern GPUs functions evaluate typically faster than texture lookups. Plus, you can evaluate a function only when needed, whereas you must evaluate a texture. Unless the function is an integral, I don't see the need to introduce yet more texture lookups. I have indicated my plan to replace this by a functionsfor better performance in ALS and will do so in the mid-term - you may disregard my experiences at your pleasure. Best, * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Hi Vivian, ALS is very impressive work, but things broken? Have you forgotten the flag shader (now fixed), wake effect and rainbow effect? I don't have a particular problem with these and hope that they will be fixed eventually, although I note that do you seem to have raced on to other things while leaving the wake effect unfixed for some time. I rather fear that that's just going to get lost in the noise and general excitement over the latest bit of eye-candy. That is what I tried to explain in length. My definition of broken is 'used to work, there was a change, now doesn't work'. What is yours? The wake effect used to work in default, and now still does. The wake effect never worked in ALS and now still doesn't. There's nothing broken here, you are talking about non-existing features and a feature request to implement them. Which is very different from breaking existing things. To give you the reverse example - procedural texturing works in ALS but not in Rembrandt - so does this imply it's broken in Rembrandt? Cloud shadows don't work in either Rembrandt or ALS - does that imply we've broken them? Nope - they never existed, and you can make a feature request to implement them. In the event, your feature request for the wake effect is noted, but not my top priority - I prefer to race on to the next bit of eye candy (as you put it) because the wake effect is a very localized effect, whereas I want to address some world-wide stuff which affects a few billion pixels more first. You're welcome to implement it yourself, and I'll be happy to assist you if that is needed. To call a non-existing feature with a feature request attached 'broken' generates a completely wrong impression and a sense of urgency which really isn't there. I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) This may be a question of philosophy, but I don't think OpenSource fares badly with this approach in general. As a Linux user I get a choice between Gnome, KDE and a host of other desktop environments - and I rather like that, I can pick what suits me best. As an aircraft developer, I can pick JSBSim or YaSim, whatever suits me best. So why should we not offer different rendering approaches dependent on what the user wants to burn the framerate for? I don't see this at all as a problem, I rather see it as a huge opportunity. We can ship one rendering approach for the low end graphics cards and are then not restricted in what we offer for the high end. How exactly is that a bad thing? As a developer I have only just finished making my models Rembrandt compatible, and I don't know if I will ever be able to actually make use Rembrandt facilities in all of them. You'll have noticed that the ALS ubershader (short of inserting the tangent, normal and binormal attribute for normal maps which I understand really _must_ be airplane-side) works out of the box without any action required in ALS. So there is no need to make your models ALS compatible, this is not a real problem, but a hypothetical one. The worst case by the way is not that the aircraft can't be flown as in Rembrandt, because you can't see out of the cockpit, the worst case is that your normal map doesn't work. As I understand it, ALS will include modelling facilities which will not work in the other flavours of FG. How is this meant to be used? Optionally. *sigh* When you and Emilian wrote the default ubershader, it provided new features. These were offered to the airplane developers as options - it was their choice to make use of them or not. Now ALS offers an ubershader which might get additional features. There are offered to airplane modellers as options. Just why is it okay if you do it, but problematic if I do it? Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, and real internal light sources which do not work in other frameworks. So not every framework has the same visuals. Why is this a problem? In an ideal world everything would work and be compatible with everything else. I don't see how any progress could be made that way. I don't see how Rembrandt could have been made requiring that it must be completely compatible with existing technology and aircraft definitions. We used to characterize the atmosphere by a fog density and a fog color. It's beyond me how one could make ALS by requiring the same thing. JSBSIm has updates, they break some aircraft, developers fix it - somehow I miss all the complaints about this (and JSBSim updates actually have the potential to break aircraft in the sense of rendering them non-functional, not in the sense of bumpmapping not working). Just imagine computers were required to be able to run DOS nowadays... Just
Re: [Flightgear-devel] Tree issues
Hi Stuart, this tree movement code is wonderful - how could you possibly not implement this? I've been looking out of the window, timing the movement of trees in our forest, and I think the time constant should rather be 1.7-2.0 and the amplitude about 2.5 times as large - all of which makes it more pronounced. Then I cooked myself a nice tropical storm and went in low level in rain over treetops - very very nice. I think I'll be putting this in at high quality and see if I can't get some wind movement of the hires noise to match the impression... // [top vert only] [time dependent movement] [seed so trees close together move together] position.x = position.x + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindN; position.y = position.y + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindE; Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. Since I see it reliably, I could have a try how I can make it go away - I think I understand how the tree shader works well enough... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. Just to provide some expectation management: Rembrandt (as deferred rendering) is very heavy on the fragment shader. ALS at low quality is currently rather balanced between vertex and fragment shader and at high quality adds all additional load to the fragment shader. An ALS implementation in Rembrandt will require that basically all light computations which are currently in the vertex pipeline move to the fragment shader as well. That's not a small workload, sunlight is about 100 times heavier to compute in ALS than in default or Rembrandt (that's what ALS burns framerate for). I'm currently running ALS at highest quality on a GeForce 670M which is a GPU on the top-end of the performance scale. With all settings maxed out, this pretty much guarantees me a framerate of above 20 fps, no matter the weather or the scenery (with very few pathological exceptions where it drops to 15). Rembrandt + ALS will be slower than any of them, because of all that additional stuff which needs to go into the fragment pipeline which will completely choke. My strong expectation is that even on a top-notch GPU, maxing out all settings will not work fast enough, so something will be lost if you actually hope to fly. The GPU to run that framework isn't sold yet... and I can picture the crowd of usual suspects shouting 'This is too slow! This is badly implemented!' once it's actually running. And I a so looking forward to that experience. (*irony*) * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
I don't think it's quite that bad. In a deferred shader like Rembrandt, the ALS would run in the deferred lighting pass. While it's true that the heavy work is done in a fragment shader, it only runs for each pixel on the screen, not for every rendered fragment. Yes - but you need to execute ~ 200 additional lines per screen pixel just to get the light at every point right in the scene. Then come ~150 additional lines to compute fog. As for the graphical goodies of terrain texturing, that's all in the fragment shader and contributes another 300 lines or so in total, and now that's only done per screen pixel, because I always use a trivial first pass to fill the z-buffer and render terrain only when actually seen. So the fragment shader will get ~650 additional lines to execute for every screen terrain pixel. Have you looked at terrain-haze-ultra.frag ? That has 720 lines of code in total, part of it subroutines which are called a few times. It is true that we currently render terrain obscured by the panel due to the near/far camera issue - but I have a crude panel masking code and a good feeling of how much this saves you. Also, in many cases the sky would take up a large portion of the out-the-window scene; is computing ALS for the blue sky as expensive as for an object in the scene? Not to mention that you don't need to run ALS in the cockpit... Yes, it does now as well. But you want the sim well-behaved not only in level flight, but also when you descend or do aerobatics. So you have to design for a clouded sky (which reverses the argument, looking at the sky then becomes very bad) or a steep descent when only terrain is visible - it doesn't do to have a framework which only runs when half the screen is sky :-) And you do have to use ALS light computations for the cockpit to get consistent light (you don't need fog or pixel postprocessing). In the end, I guess we'll see how bad it is... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
I've thought about if I really should comment on Henri or not, and I won't dignify most with a reply, but just this: I don't mean i don't like ALS, i mean i don't like your approach , instead of working on consistency with the existing valuable features which were implemented within FlighGear, ( and by including Rembrandt), you ARE WORKING on a other FlightGear. Please get your facts right. The first appearance of the skydome shader in the forum dates to Mar 07, 2011. The first appearance of Rembrandt in the forum seems to be Jan 04, 2012. Assuming that they roughly correlate with the time at which these features were first presented elsewhere as well, this means that the beginning of ALS _predated_ Rembrandt by almost 10 month (!). Thus, it is very clear what the 'existing' feature is, and who did not contribute to the existing technology - it's FredB and Rembrandt, not Lauri, me and ALS. Let me make it very clear that I have no issue whatsoever with that. I did not expect FredB to incorporate the skydome shader or anything that follows out of this. It is also very clear to me that FredB has no issue with Rembrandt and ALS co-existing, because he showed me how to implement the terrain shading in the effect framework and committed it himself after I had finished it. But your whole argument about not contributing to existing features simply applies to the wrong person. That's embarrassing, isn't it? Have a nice weekend, * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Hi Henri, However your approach is questionable. I can understand you are working on an other FlightGear variant for yourself. (...) It is not the Atmospheric Light Scattering, we want. Who is the 'we' you're claiming to represent? I look at the FGUK weekly flight screenshots in the forum, and pretty much everyone there is using ALS. I look at some recent scenery projects (Russia, New Zealand) - and I see people playing with the procedural texturing of ALS. So *you* may not want it, but you're not representing 'the community', you're representing yourself here. And you know what? You can simply never switch it on if you don't like it, and that solves it all. It's a bit beyond me how you could possibly be bothered by a feature you currently actively have to switch on. (And even if I were the only person interested in using it, it would still be perfectly legitimate for me to work on what interests me rather than the rest of the users - this is my spare time we're talking about.) You call it Atmospheric Light Scattering, you could call it Renk ALS I could at that, but it's handed out to the community under GPL, so it doesn't belong to me, it belongs to whoever adheres to GPL. We want, so far, a consistent flightgear system, any features should be compatible each other, and not breaking each other. First, you haven't read what I wrote: There is nothing 'broken' by ALS - everything you're using when ALS is off works just the same as if you would remove the whole framework (if you disagree, name me a single Rembrandt feature that doesn't work any more because ALS blocks it). The only implementation which actually prefers Basic Weather consistently over Advanced Weather (and hence in a sense breaks things, although one can to some extend hack around it) is the environment interface of the default (and Rembrandt) rendering framework - which is designed by the very person who brought up the idea that I would break things. Second, you're applying double standards here. Rembrandt (which you like) is massively incompatible with the default rendering framework at a much deeper level. It requires to modify aircraft to even see through cockpits, it requires likewise to re-write every effect and shader. You seem to have zero issue with this, but taking your argument seriously, you would have to be against Rembrandt. Of course you personally like Rembrandt but not ALS, so it's okay if Rembrandt is incompatible with the default, but not ALS - I don't have a particularly high opinion of such types of arguments. What about Rembrandt ? To reproduce the reality, isn't it the main tool which gives the best effect ? Won't the effort should done on that side ? What you're asking is really 'I like Rembrandt better, so why don't you work on it?' Let me ask you back - I like ALS better, so why don't you ask FredB to work on ALS instead? Makes just as much sense. As for Rembrandt being superior, Rembrandt is a different engine, not a set of different effects. As such, it has more potential, because it can potentially do the same things ALS can do and still add multiple light sources and shadows. As has been mentioned a few times, ALS can be ported to Rembrandt by re-writing the effects, but this isn't something I am personally so interested in that I would do it completely on my own, and unless a volunteer appears to do it with me, that's all there is to say. Currently I would claim that ALS delivers more realistic outside scenes at daytime and at sunrise/sunset, whereas Rembrandt wins for aircraft interior, close to the ground when shadows are important and at night where multiple light sources are important. I hope that the next Flightgear version will offer a consistent system and not several independents systems ( including your Flightgear) which won't be compatible each other. I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards (the integrated intels for instance) can use FG at all, and neither Rembrandt not ALS are compatible with default. I mean, what is this really about? You're seriously bothered by a framework you especially have to activate, which doesn't break any of the features you like to the degree that you blatantly ignore the significant group of users who uses ALS and claim to represent 'the community' and invent 'broken things' for which you can't give a single example'? And you expect me to... do what? Code what you like instead of what I like? Please... can we keep some basic fairness and decency here? * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app,
Re: [Flightgear-devel] Atmospheric Light Scattering
..yes, but we also need some patience with non-native English writers who _should_ include their French etc original so we don't get people wound up on questionable translations of things that may warrant discussion For the record, there is a repeating pattern here on and off list and I don't think I'm overreacting. I don't think you are ignoring the flightgear users community interest, features should be compatible each other, and not breaking each other or You call it Atmospheric Light Scattering, you could call it Renk ALS are particularly prone to mistranslation or are intended to mean something else. I'm not wound up about wording here. I'm wound up about 1) Repeated insinuations that I would 'break' things. Somehow, nobody can seem to come up with an example of what I have actually broken. So I think I'm not out of line in asking that people either say what they think I broke (and give me a chance to fix it) or shut up. 2) A complete lack of explanation why simply not switching on a completely optional framework which they don't like is not an acceptable solution to some people. 3) The inherent double standard in arguments that if other people do the same thing it's completely okay, but if I do it it's very bad. Could somebody who disagrees with me just spell out what I'm supposedly doing wrong, what I should rather be doing and explain to me why? Rather than insinuating, making vague statements, expressing unspecified concerns, hinting at some unspecified group which would be of the same opinion but never committing to any statement which can actually be investigated? Because I'd really really like to see that case reasoned. Thanks, * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atmospheric Light Scattering
It occurred to me yesterday that there seems to be a major misunderstanding in the way Atmospheric Light Scattering (ALS) is perceived by different people. So in order to avoid future misunderstandings, let me try to clarify my side once again. Vivian: Do we need to go down this road? We are breaking more and more for minimal gains. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? Emilian (a while ago): I have nothing about the core of the Advanced weather engine, I have an issue of how you interact with it, and how it interacts with other parts of the whole system... and in my view this is broken. I also have nothing against the idea of the atmospheric scattering, I have an issue with how it's done, which is suboptimal in my view... and again of how you can interact with it/ how it affects other systems, and how it's affected by other systems. The common theme here is the perception that something is broken, which is naturally not my perception. For instance, the fact that ALS doesn't have a wake shader effect indicates its brokenness the same way as the fact that the default rendering doesn't have procedural texturing working - which is to say, not at all. Vivian might correct me, but I think I finally understand where that notion comes from. I think it comes from the view that ALS is in essence just another way to compute fog and light for what the default rendering scheme does, and from this perspective, any effect that doesn't work is indeed broken. The original plan was indeed to implement things as just different fog and light, there is still the parameter 'fog-type' in the effects which would support such an implementation, and there was a 6 months window during which Emilian and Vivian had the opportunity to implement it that way. As this didn't happen (for whatever reason) I decided to ask for some help and Fred kindly told me how to implement it as a different rendering framework (i.e. loading a whole different effect rather than a different fog shader only). So, from where I stand, that decision is done and it is now a different rendering framework, which means clean slate, all effects have to be written from scratch, with all the pros and cons to that (which we might debate endlessly). So since this window of opportunity to start from scratch happened, I took the opportunity to address a few things I saw as shortcomings in the default rendering framework we had. Just to give a few examples: * Environment interfacing: Emilian's view that the way ALS and Advanced Weather interact with the rest is broken is... bold. Just to give an example for how he addressed the interface, for instance the water shader needs to know the amount of reflected light at the water surface in order to compute reflection. Emilian's and Vivian's version of the water sine shader solves this by passing the cloud layer configuration settings of Basic Weather to the shader and then compute in the fragment shader from that the amount of light. This means that a) Advanced Weather has no chance (even conceptually) of ever passing the correct information to the shader since it doesn't use the Basic Weather config properties to create clouds and my understanding is that it is even impossible to write these properties without actually generating visible clouds interfering with what Advanced Weather does, and that b) a quantity which changes in Basic Weather once a few minutes (when a new METAR comes in) is computed about 60 million times each second. I may not be a rendering wizard, but this doesn't sound like the way to implement an environment interface to me. My supposedly broken interface references a single property 'light reaching the ground' for the same purpose. That property isn't native to the weather system, it can be set by hand with the browser without affecting anything else but the shader or be computed by any weather system currently running, i.e. shader control parameters are explicitly and always separated from native weather system parameters. This means the computation can be done if and only if needed, and the interface doesn't prefer one weather system over the other. * Consistency I've witnessed quite a few forum discussions with people complaining that they didn't think selecting higher quality shader settings would give them higher quality visuals (usually this was about the crop and forest overlay texture effects which some like and some don't - I have my opinion which is irrelevant here). Likewise, snow and fog were not always consistent across landclasses (I believe this is fixed now). Starting from scratch offered the opportunity to organize quality settings with a clear idea in mind, using a consistently selected set of effects. Now, consistent doesn't necessarily mean superior, it just says it's all my idea of visual quality, not a mixture of different ideas. But then
[Flightgear-devel] Tree issues
Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I think so. The textures here are very small (512x512) so the difference between a 512x128 and a 512x512 texture would be miniscule while loading 4 textures rather than 1 from disk might be significant. IIRC Thorsten also did some experiments and found that having additional textures references in a shader had a significant performance impact. If you had two different texture sheets and would need bare trees high up and leafy trees down in the valley, you would have to look up both of them for each tree - which is not so optimal. I think Stuart's way trades GPU memory (you have 4 times the sheet size now) against speed (just a single lookup). We may think about not doing the two winter slots as a simple noise function with white color can paint them with snow as well, but I think eventually we'd like to have nice winter images with snow piling correctly on the branches, and this is close to impossible procedurally, so I can see the advantage of the scheme here. Stuart, is it possible to pass somehow the info what trees are deciduous? I've done some testing, and I can selectively pick 'green' hue in the shader and color-rotate these pixels to autumn colors, but this is not sensitive enough to key on the difference between leaf and needle - if we had that, we could have autumn colors in addition. Then fall and windy could be combined with particles (?) to simulate wind blown leaves and dynamically painting the foliage part of the texture with alpha to make leaves fall off on windy weather..? ;) Kinda special case and maybe not worth the effort but might be quite awesome jaw-dropper on the right moment.. ;-) Yes, let's forget about spending all the framerate for flight and do realistic vegetation - trees and grass should also move in the wind :-) (I like the idea in principle because it's just mad enough to be charming...) * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Actually, I had this working very nicely a couple of months ago - using a sine function on time multiplied by wind factor to shift the top texture coordinates so the top of the trees move. I even had a nice larger scale effect to produce the sort of wave affect you see across the tree tops However to be visible at normal ranges (500m+) the wind had to be absolutely howling and shifting the tree tops many meters, so it really didn't seem worth the minor computational cost. Oh, do you still have that somewhere? I would love to play with this implemented in an optional high-quality tree shader - I could probably also add some grass movement by translating the grain texture or the hires noise with time into the wind direction... * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Okay, I've pushed an experimental version of a grain overlay texture for the model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e. will be absent in the default rendering, which should make for easy comparison. For lack of texture units, I had to take the rainbow coloring of reflections out for the moment (again, only in the Atmosperic Light Scattering version). I can't visually spot a difference, and in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually. As far as I can see and test, this shouldn't take any framerate unless used. The grain overlay is configured pretty much like any other model effect in the ubershader - a model specific effect file needs to set the flags, which are * grain-texture-enabled: does what you think it does, needs to be 1 to work * grain-magnification : the texture magnification relative to the base texture - I think values between 10 and 100 would work here The grain texture itself needs to be declared as n=14. The grain texture should be largely transparent and seamless - I think unlike for the terrain tiling artefacts are not an issue for artificial patterns, they actually occur. For a quick check, inserting the following xml code into Aircraft/Citation-Bravo/Models/Effects/reflect.eff texture n=14 imageTextures.high/Terrain/grain_texture.png/image filterlinear-mipmap-linear/filter wrap-srepeat/wrap-s wrap-trepeat/wrap-t internal-formatnormalized/internal-format /texture grain-texture-enabled1/grain-texture-enabled grain-magnification50/grain-magnification gives me this effect for the hull of the Bravo which is now re-painted using the terrain grain texture at high resolution http://users.jyu.fi/~trenk/pics/overlay.jpg Looks a bit like a military version... So, please play with it - it's basically down to how well the grain overlay can be made. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Removing the rainbow effect spoils the highly polished aluminium effect on the b29 and the Lightning F1. As I said, I don't plan to remove it for good. Quoting myself: in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually I might add 'this will make it quite a bit faster, as it is a very simple function' - so I believe this should be done anyway everywhere the rainbow is used. I am working hard, but don't expect everything to be 100% on the first commit of a new feature. It is also incompatible with AO effects. Will this all work with non-nVidia cards/drivers? I believe I've seen screenshots of terrain overlay textures working just fine on ATI cards. Likewise, functions rather than texture lookups work just fine - what counts in the end is a number, the shader doesn't really care if this is calculated or read from texture. The four websites I have studied regarding conditional texture lookups agree that textures can be looked up conditionally on a uniform, not on a varying. Do you see actual reasons for concern, or is this just stabbing in the dark? Not sure why a grain overlay would be incompatible with AO - care to elaborate? My understanding is that we don't have any AO outside of Rembrandt, and a grain would not be intended to carry pre-computed shadows, that's what the base texture is for. The grain effect you proposed did not gain much if any support from developers. Do we need to go down this road? No, we don't have to. Like many things, overlay textures and the grain effect are just something I believe have incredible potential. The grain effect on terrain is awesome - without going dds or using huge textures, you can create 15 cm sized terrain resolution everywhere. So, let's give it a few months of testing, see if folks can not use it to good effect - the 5 lines are easily removed from the shader if the potential doesn't materialize. We are breaking more and more for minimal gains. I beg to disagree on two counts. First of all, this is a net acceleration. I think currently the ubershader isn't structured well since it unconditionally looks up lots of textures, most of which aren't needed if you use, say, reflection or normal map only - restructuring the shader to not read unused textures and to evaluate as function what can be evaluated as simple function will speed things up. Second, having a technique to achieve 25 times the resolution for 2 times the texture memory isn't a minimal gain. It's visually way more powerful than the rainbow. So we're actually getting more bang for the buck. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? Well, we never had it running in the first place, so there can be no talk about restoring it. Someone just has to write it. Presumably that someone will eventually be me, but I have to ask your forgiveness of I priorize things which interest me personally. I mean, it's not like there's something taken away from you... There's two rendering frameworks left in which everything works as you're used to, surely we can afford to have one of three going ahead and trying for a few experimental new features rather than re-doing every effect in the others? Cheers, * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Ive been thinking about this since since you posted, and now i'm curious to see it.My initial fear was more framerate drop, but if it can be truly disabled I think its worth a try I think one thing we have pretty consistently implemented in the effect framework is that all effects can be switched off. The whole model ubershader is implemented in such a way that it affects you only if you have a model shader on. The grain texture can be implemented such that it affects you only if you have the model shader on at high quality and your model has a flag set such that it is used. Water reflection used to have nearly zero impact on my framerate , now its unuseable over the ocean or large lake. Which one? We used to have two of them, a silvery one at lower quality and the sine wave variant at high quality. Even the high quality variant can be made to run almost twice as fast by dropping half the partial wave calculations (this is implemented in the lower quality version of Atmospheric Light Scattering). I haven't been following the shaders in the default framework so much, but if a shader suddenly eats up twice the performance, there usually is a reason worth understanding. Not sure why but the skydome shader had very little effect on my framerate when it first appeared , now it drops fps to 10 from 40 . Well this at least I know. When the skydome shader first appeared, it did this when you didn't have mountains on the horizon: http://www.phy.duke.edu/~trenk/pics/skydome1.jpg Your framerate has gone into fixing this problem by providing consistent fogging and lighting of the terrain under all conditions such that terrain matches with the skydome. And unfortunately, the terrain part is way more expensive than the skydome part (and if you run at higher quality, there's a gazillion of additional goodies). The skydome code itself is pretty much as fast as it used to be (and if you delete all skydome-switched techniques from terrain-default.eff and model-default.eff, you can get if back if you really like). * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
I'd say no , its easy enough to do without yet another shader, since each new shader 'improvement has me tweaking my aircraft to get back the frame rates I lost.But thanks for offering. Well, according to GLSL specifications and my experiments, texture lookups cannot be made conditional on a varying, but they can be conditional on a uniform integer. Which means that this can be implemented optionally without any performance overhead if the feature is not needed (that's not how the model ubershaders currently are written, they read textures regardless of the config flags, so I suspect they run slower on low quality levels than they really have to. I have been given to understand that this is because of Mac/ATI driver issues, but my medium quality terrain shaders read textures conditional on uniform int flags, and for me this gave a performance gain - seems to run fine on Mac and ATI as well, so it doesn't seem to be a nVIDIA exploit). I would follow the same opinion as Syd. I think Gimp/Inskape/Photoshop... are enough powerful to create correct texture. Well gimp is nice, but: Using 8192x8192 textures, with a 2x2 m cockpit size to texture, you get 0.25 mm resolution and have a 128 MB texture file. Using a 1024x1024 texture with a 256x256 overlay, you get pretty much the same resolution with 2 MB worth of textures. using a 1024x1025 overlay, you still have 4 MB textures only and can create 4 times the resolution. So there's that. The fact of the matter is that very few aircraft are textured in high quality (even a really good aircraft like the b1900d has lots of monochromatic surfaces on the panel) and if we had a library of a few overlay pattern, it would not require a photoshop artist but just a few lines of xml to fix that for good. The fact of the matter is also that once I turn my head and look away from the panel, the texture resolution in pretty much all aircraft decreases dramatically. But okay, I asked for feedback and I got it - point taken, feature not considered interesting from the modeller side. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
No ,Advanced weather forced 3d clouds on me even when i disable 3d clouds so i don't use it. Of course i could be doing something wrong , but Im not quite convinced yet to get a new computer. Looks like I'll have to pretty soon ;) Interesting, I thought the 3d cloud checkbox was a shader-disabling button and the 3d clouds would disappear for lack of a rendering technique. Anyway, yes, Advanced Weather doesn't support 2d clouds, so if you want them, you can't use it, and you're not doing anything wrong. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt and ALS combined or switchable
I was wondering if there is a future plan in uniting these two amazing attributes of FG... My development plan as outlined for the period between 2.10 and 3.0 (hopefully...) http://wiki.flightgear.org/User:Thorsten is still valid: After thinking about this for a while, I have decided that I am definitely not going to do this on my own. Being maintainer of one major rendering scheme and one weather system is quite enough to keep me busy, and it's not something which is very close to my heart. However, if there is a decision that there is going to be a team effort making this work, I will join it and do my part. I suspect the programming challenges must be more than easy, yet I assume we would all like to have these features together, without having to quit and edit config files for choosing one of them at a time. I'm not a frequent Rembrandt user, but my understanding is that you have to start Rembrandt with a certain set of commandline options, but don't have to edit config files. Can you elaborate? I was wondering, could a button between Rembrandt and Atmospheric Light Scattering be made in-game so that one can be turned off, thus allowing the other to be turned on?? Starting from the default rendering scheme, Rembrandt is a change in rendering architecture, whereas Atmospheric Light Scattering is merely (?) a change in effect and shader code. Which is to say that Atmospheric Light Scattering has to be largely re-written to work inside the Rembrandt architecture, and which is why one can switch in-sim from default to Atmospheric Light Scattering (because they use the same architecture) but not from default to Rembrandt. Maybe Fred can explain this better. I've been given to understand that the easiest way to implement things inside the Rembrandt framework is to make all computations in the fragment shader - this is now done, ubershader-lightfield.frag contains all the main operations of lighting and fogging in five distinct and well-structured code blocks. I assume they would be more or less run when just copy/pasted into their counterpart locations in the Rembrandt framework. So the current roadblock is that someone sufficiently familiar with the structure of Rembrandt needs to write a skeleton framework and move these bits where they belong and implement the xml logic to switch things on and off. Once such a skeleton exists, I could take over from there and modify and adapt it to get all the procedural texturing and other fragment postprocessing effects in. What I can't do easily is design the skeleton from scratch, because I know only for ~ 2/3 of the lines in effect files what they're actually for (to be able to modify an existing file is not the same as being able to come up with one from scratch, especially if that is supposed to work in a different architecture...), and I have no prior experience in Rembrandt, and 'would be nice to have' is not sufficient to motivate me to spend a lot of time learning all of this. The offer stands - if anyone does the skeleton using what's in ubershader-lightfield.frag and gets a minimal system running in Rembrandt, I'll do the rest. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
Thorsten suggested [1] separating foilage and trunk; is this what you have in mind? At the moment I'm simply using 4 separate complete textures ; one for each combination of summer/winter and clear/snow-covered. So I 'just' need straight pictures from summer and winter. Snow-covered would be a bonus, though that can probably be added later. With that I can display different textures above and below the snowline with no computational impact (well, a couple of additions and multiplications at the vertex level plus an additional Uniform). On my system there's no impact to frame rates. I've still to look at Thorsten's idea in detail (my code predates that discussion) and don't expect to have the time to do so in the foreseeable future. Just to be clear - if we had textures, this is something I would do the work for since I suggested it, I'm not expecting Stuart to do this for me :-) (This is not to imply that I would object against Stuart giving a try, but as long as I can follow up an idea I like myself, I try not to fill someone else's to-do list). The reason for separating foilage would be to allow continuous autumn-color shifts and 'shed' leaves by overlaying a noisy alpha-channel. I expect it to require additional texture lookup and some perlin noise at a minimum so the perf impact might be significant. Depends on the hardware I guess. On my old GPU, the fragment pipeline was the bottleneck, and such an addition to the fragment shader would have been a clear no-go. My new GPU is almost always vertex-shader limited if it doesn't go to vsync, with the chief suspects being clouds, buildings and trees. So chances are I wouldn't even see additional texture lookups and noise functions, because the vertex shading dominates the execution speed of the tree code. So I would suggest to implement this as a high-quality option for those who have the hardware to crunch substantial fragment shaders and leave the current implementation as a fallback. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft modellers - is a grain texture useful?
I have a question to aircraft/cockpit modellers: Would a shader effect with the equivalent of a grain texture be useful to you? For the terrain, the grain texture is a semi-transparent overlay pattern of grainy dots - which is superimposed on the normal texture at 25 times the nominal resolution (so while a usual pixel on the terrain might be 4x4 m sized, a pixel of the grain pattern is 16cm x 16 cm. This gives the appearance of a texture resolution which is much higher than it actually is: http://www.flightgear.org/forums/viewtopic.php?f=47t=18628#p173410 In cockpits, I often see many monochromatic surfaces. When I look at the panel of my card, the plastic is monochromatic but has a fake leather pattern imprinted. The roof of my car has a cloth structure. My computer has some rhombus pattern imprinted. Metal surfaces often have some brush stroke structure. All these things are literally screaming for an overlay texture, as they are artificial repeating patterns and there is in fact no tiling problem as in terrain shading - they can just be superimposed, creating sub-millimeter-sized resolution on cockpit details at the expense of a single texture lookup. Now, I would offer to code a slot for a grain texture into the high-quality model shader of Atmospheric Light Scattering, but since I am not a 3d modeller and I suspect there are some issues with the uv-mapping which are a bit different from the way terrain works, I would need someone from the model side who is interested in exploring this idea. Let me know if anyone is interested. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
@Erik: They are read from the ambient, diffuse and specular files in fgdata/Lighting. For the default lighting scheme these do get altered, but I think you already override that scheme completely. Um... as they depend on the sun angle, these appear to be the light intensity curves. I indeed override those. I'm interested in the reflection coefficients, which must be part of the materials definition - I know that for some landclasses diffuse and specular are explicitly defined, but I don't know what the defaults are otherwise. But I guess I found a viable solution yesterday. @Fred: I presume the balance between ambient and diffuse should vary with the weather. A clear sky gives harsh shadows and overcast sky with several layers of clouds gives barely any shadows (dull day in photographer speak). Your results (which are really pretty) are likely to be unrealistic with bad weather and perhaps a middle term as it is now will fit more situations if the balance is not adjustable. Luckily for me Advanced Weather already comes with a model how light intensity is changed by the cloud cover and the interface to the shader is already in place and being used to reduce diffuse light under strong cloud cover ;-) So that's solved already - to quote myself 3 lines in the shader including all the environment dependencies on cloud cover and sun angle (it doesn't do to reduce ambient light before sunrise for instance) - for moderate cloud cover, the effect goes back to what you're used to, for strong cloud cover diffuse and specular light pretty much go away. I think the actual effect is pretty much perception - the ambient light doesn't go away that much in clear skies, but the eye, having the contrast to surfaces illuminated by high intensity light, reduces shades surface to dark. So we could attack this also by simulating real light intensities and do perception reweighting later as well, but just reducing ambient light to make up for actual high diffuse intensity seems to do the trick nicely. @Stuart: Given that we've got a very limited number of tree textures and the same texture is used on a large number of objects, perhaps it would be worthwhile increasing the resolution? The regional Caribbean palm trees should have a higher resolution if anyone wants to have a look at the differences. We seem to have some forum users who are sort of committed to provide more variety and higher resolution tree textures which we can encourage. Personally I would like to have higher resolution trees after spending quite a lot of shader lines for terrain close-up rendering - but I have a lot of memory to spare, and I understand the argument that for many users trees will be something seen from a few hundred meters at best. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal props API relative path support
If you just want a quick and dirty way to read one property, we have getprop / setprop - for any other use, you should be doing what the API already supported; getting a props.Node object for the leaf, and then manipulating it with no further string/path handling. Using getprop on the one hand does not allow getting a property converted to a given type and on the other hand is tedious to use for more than one property, as one has to assemble the according property paths (which is definitely less efficient than using a relative method). If there is even a slight performance concern, the only justification I ever see for not using getprop() / setprop() is if you explicitly require to set a variable type. Assembling a property path by string manipulation may be in theory less appealing, but it is in practice 3 to 10 times faster than using the props module - I have made several benchmark tests, all leading to the same result. Large-scale property manipulation from Nasal is performance hungry and should be avoided if possible by using Nasal-internal variables instead, and if it needs to be done, getprop() /setprop() offer significantly superior performance. If you dig a bit in the mailing list archive, there should be a post with the actual benchmark test results. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shader changes - some feedback required
I've just pushed a few major modifications to the highest quality shaders of Atmospheric Light Scattering - the lower quality levels are at present unaltered. Please give some feedback so that I can decide what to do with the lower levels. * I've converted fog and snow overlay from tile-coordinate 2D noise to world-coordinate 3D noise (I think FredB is to be credited for the concept). This has the big pro that the noise is continuous across terrain tile boundaries and looks much more appealing. The cons are that the computation load to generate a noise frequency doubles from 2D to 3D noise and that on my hardware, the world coordinates are numerically somewhat unstable. This means it works fine for large wavelength noise where accuracy isn't an issue (for me 250 m and larger is fine) but gives an inacceptable jitter for high frequency. Thus, all noise patterns below 250 m size scale are still created as before as 2D noise in tile coordinates. I don't know if the 250 m are save for everyone - Emilian at some point said he was fine down to 30 m using world coordinates which I definitely can't do. Please test and let me know if this is a problem on other GPUs and if the performance drain vs. visual gain is worth the procedure - if yes, I will implement 3D noise on lower quality level shaders as well. * The mentioned shadow code is also in for the high-quality terrain shader. In order to see the shadows deepen, you need to use fairly clear skies and Advanced Weather (unless Basic Weather starts communicating light attenuation, it will always use default shading). Fair weather is usually fine, and morning as time of day works well. I have not yet pushed modified trees, so best don't look at tree-covered slopes. The difference in shade can directly be seen by toggling between highest quality (landmass and transition both to max) and any lower quality. Please let me know if you pick up grossly unrealistic situations, if not I will make this the default behaviour. * Water in addition got a variable density drift ice overlay texture to use in winter and some 3D noise based water color and reflectivity modifications - I think it looks much nicer than monochrome water - again, any feedback appreciated. I have a half-baked scheme to make water color also dependent on proximity to the coast (this could get a ride on the terrain sampler which Advanced Weather is running anyway), but that's not there yet. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain self-shading
Following a forum discussion http://www.flightgear.org/forums/viewtopic.php?f=47t=19693 I've done some experiments with terrain self-shading based on changing the balance between ambient and diffuse light. The results look fairly compelling and the illusion (even without a real shadow-map) is usually pretty good (in fact, one has to go looking for cases where it breaks, they don't usually stick out even in complicated terrain) http://users.jyu.fi/~trenk/pics/light_balance_new05.jpg http://users.jyu.fi/~trenk/pics/light_balance_new06.jpg Since it's not based on a shadow-map, it works still 100 km out http://users.jyu.fi/~trenk/pics/light_balance_new02.jpg It works by reducing ambient light in the terrain shader, and to compensate for the loss of scene brighness, diffuse light has to be oversaturated (is this problematic ?). One problem is that I don't know the default ambient and diffuse reflection coefficients of terrain, so I have to experiment. If anyone knows these, please let me know, then I could compute rather than experiment. I do know that full ambient light has an intensity of about 0.5 in each channel and full diffuse light has 1.0. Downstream, to preserve the illusion of shadows, I've had to alter the tree shader to purely ambient lighting based on sun angle above the horizon. But that seems to be a good idea in general - not only is this cheapter to compute, but also our tree sprites have flat suraces with a clear normal, so they have very pronounced directional scattering - real trees have random orientation of leaves and needles and a leaf can also transmit light, so I think real trees have much weaker directional light scattering and isotropic scattering is actually the better approximation. I'm describing this in detail because the change is rather small (3 lines in the shader including all the environment dependencies on cloud cover and sun angle) - so this is an extremely good bang for the buck, and I would perhaps suggest considering similar changes in the other rendering schemes. I'll try to push a test modification to the highest quality terrain shader and the tree shader on Monday, so that you can experiment a bit and make up your mind * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud detail range and faint clouds
Presumably making cirrus clouds after more sprites doesn't make for very realistic clouds because of the size of the cloud structures? Well, they are very faint - say an alpha of 0.1 or less. If we make 10 sprites, each of them needs an alpha of 0.01 in order to get the same visual impression, and that means every sprite gets thrown by the alpha testing. Also, the whole point of dropping sprites is to make clouds render more efficiently - so adding sprites to already rather efficient Cirrus clouds such that some can be dropped later appears a bit... counter-productive ;-) It occurred to me that the correlation of cloud thickness and altitude is quite good, so a quick fix could be not to drop any sprites for clouds above 6000-7000 m altitude (?). * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
Thanks Fred, this pretty much addresses all my questions. Light objects are built in simgear/scene/tgdb/pt_lights.cxx There effect is built in C++ in the getLightEffect function. It is not configurable as it is now. Ideally, this function should be replaced by a lookup in the material file to find a configurable effect. But I didn't thought about the implications of doing so. Okay, then I'm not going crazy and can't really address this from the effect/shader side without touching the core. Could I request implementing a lookup as a non-urgent feature request? This is needed to get true low visibility scenes rendered properly, but I think not among the most pressing problems. Precipitations use the OSG particle effect. I don't thing it is something configurable as the shader is coded in OSG C++ code. Maybe this is something we should try rewriting in order to make the lighting different. The implementation of the effect is in simgear/environment/precipitation.cxx Well... maybe let's just leave it as it is - personally I am not much bothered by the precipitation lighting, and this sounds like a non-trivial issue to fix. Problem : it consumes GPU memory even if the technique requiring the extra attributes is not selected Hm, I see Can a geometry shader potentially compute the curvature and pass it on? I mean, having a triangle with adjacency info must be good for something like this, right? Stuart: I don't think there's a sensible way to generate additional trees at 50-100m. With the changes described above, the overall memory occupancy of trees should go down, so perhaps it won't matter as much? I was thinking fern, grass, undergrowth,... - these would have a density ~100 times higher than trees, so even just storing the coordinate point if it is created at tile creation time would be a major drain, and the whole thing would only remain manageable if really only the close vicinity is stored - which means it needs to be created on the fly as you approach an area. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A collection of questions
If I may bother everyone again - here's my current list of open questions. Any help or pointers would be appreciated: * Where do the runway and taxiway lights enter the rendering scheme? They need to be fogged consistently with the rest of the scene, but I do not know where to set this - which effect are they using? Context: In low visibility scenes, lights remain visible to large distances because they go to the default fog color rather than the atmospheric light scattering fog color. See http://users.jyu.fi/~trenk/pics/catIIIb.jpg * Where does precipitation enter the rendering scheme? Context: I have received the suggestion to change the lighting of rain and snow to agree better with the environment lighting - but I don't know where the lighting for precipitation is defined in the first place. See http://www.flightgear.org/forums/viewtopic.php?f=69t=7358start=555#p176734 * Why are the runway and taxiway designation signs using the terrain shader? Can (should) this be changed? Context: The terrain ubershader at high detail assumes that vertical surfaces need to be rock. If a sign is rendered by the terrain shader, the shader consequently makes the sign vanish and replaces it with rock unless the rock texture is explicitly set to 'off'. This could be hacked around by just setting it off for every sign, but I am thinking that a better solution would be to render these objects with a model shader because the features of a terrain shader do not really make sense in this context. See http://www.flightgear.org/forums/viewtopic.php?f=47t=18999 * Can we generate more vertex attributes than tangents, normals and binormals? For instance, can we do components of the curvature? Context: Lots of vegetation patterns in nature are 'on the valley floors' or 'along a ridge'. In order to tag those with shader effects, one would need curvature. For instance, valley floors are defined by normal pointing upward and positive curvature, the ridges are defined by normal pointing upward and negative curvature. This would allow much more natural distributions of overlay patterns. * How difficult would it be to expand the tree generating system to a multi-tier system in which we can in addition generate a circle of vegetation in the range of ~50-100 m for high resolution scenes landing off airfields? Do we generate the memory load from trees at tile loading time, or at tree loading time? Context: Would be very cool to have ;-) * Just how are the LOD ranges defined in the view menu used? I am genuinely confused, I understand that LOD bare sets the terrain, but that's the limit. Does anyone know? Thanks in advance for any help with these! * Thorsten -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
I suspect they are just using the default terrain effect, if anything. They are generated from the C-code when the tile it loaded (IIRC simgear/scene/tgdb/obj.cxx though I'm not at my FG computer to check) If you want any changes I'd be happy to make them, though I'd expect it's the sort of change that you could make yourself with a little digging :). I guess the only way to fog/light these things correctly is to hand them to the right shader, but I only know how to do this for things which appear in effect files or which use one of the specified effects. I can certainly pick it up from there, but I had the impression that lights do not use terrain default, because I would have expected that to work consistent with the rest. Among other things, they would for instance get snow-covered or dirt-modified if they would use the terrain shader. So I think what I would need is the lights referencing some effect file if they're currently not sorted anywhere. FYI, I've got a list as long as my arm of FG things to do, and have struggled to find any time to spend on FG for the last month. Please no hurry - I'm just trying to get my mid-term plans together. I would think it would be straightforward to do this, but I don't know the perf/capacity impact of doing so. Probably on par with generating both tangents and binormals - it's down to looking up adjacent normals and computing how different their dot product with the local 'up' direction is. This shouldn't be outrageously expensive to do, but it would throw in some more non-local topology into the shaders. Thanks, * Thorsten -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - YASim model output data in txt file
In addition to what Heiko said, Nasal script loops can be used to print any properties or functions of properties under any set of pre-defined conditions with adjustible sampling interval on-screen. If you re-direct console output to a file, you also get something that is plottable with minimum manual postprocessing. I've used this in the past to check the environment simulation by plotting pressure or windspeed graphs. * Thorsten -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Kinect for pc for head tracking?
After all, head tracking is one of the most important aspect of flight sim. It's fine that people are interested in something, but could we please tone down the rhetorics and refrain from arguments 'I am interested in X, hence it must be one of the most important aspects of flight simulation'? Why reply like this? Just change the superlative most to very, or remove it altogether. The poster is obviously not writing in his native language, and you accuse him of starting an argument? All the unsuspecting soul did was to enquire about Flightgear interfacing with Kinect. In my eyes you are one of the most respected contributors to Flightgear, but do seem to be easily provoked. Um, Alan, why reply like this? I asked Zhitao to _please_ tone down the rhetorics (i.e. to remove the superlative, as I don't see it's needed), and you interpret that as me 'accusing' him to start an argument? Whenever did I say that? As for me being provoked, in the follow-up 'discussion' we get to read 'fool, idiot, ridiculous, pontificating about language skills,...' - does it strike you as strange that I, as supposedly provoked party, do not use that kind of language but say 'please'? Could you imagine that I might be motivated by something other than simply being provoked (for which I'd not have a reason in the first place)? Since you ask, here's the thought processes underlying my 'Why?' spelled out: I know very little about Chinese grammar and semantics, so I can't definitely rule out that we're dealing with a language problem here. In which case a simple 'Oh, sorry, simple misunderstanding' as a response would have solved the problem. Note that this didn't occur after the fact. But as I tried to indicate in my post as well, the structure of the argument X is important for me, so it must be important for everyone. or I use X a lot, hence X must be essential for flight simulation. is a fallacy which I get to observe quite a lot. This suggested a high probability to me we're not dealing with a simple language issue, but that he actually meant what he wrote. In which case, I would think it valuable pointing out that this is a fallacy and ask him to please not do it. What other way would you see to change discussion culture here and in the forum? (Well, maybe you see no need for a change, but I think it's rarely very constructive - of course the counter-proposal from you would be that this is because I am so easily provoked, to which I would reply as above,... In the event, I do see merit in your perspective - I can't honestly say that there's any evidence my post improved anything. So I'll just shut up here.) * Thorsten -- 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] Kinect for pc for head tracking?
After all, head tracking is one of the most important aspect of flight sim. It's fine that people are interested in something, but could we please tone down the rhetorics and refrain from arguments 'I am interested in X, hence it must be one of the most important aspects of flight simulation'? I've been interested in flight simulation for more than 20 years, but till today it did not a single time occur to me that head tracking would be one of the most important aspects of it. I naively assumed it had something to do with primarily simulating aerodynamics and solving equations of motion and secondary with providing a credible environment in terms of realistic instrument behaviour and more or less realistic visual cues (visibility, cloud coverage) and wind interaction with aerodynamics, and then all else. Might just be me. Here's a choice list of other things which have previously been claimed to be absolutely crucial / among the most important aspects / the reason for FGs demise if they're not implemented asap: * shadows cast by aircraft * space flight capability up to the moon * meter-scale exact synchronization of clouds over MP * real-time real air traffic * orbital maneuvering capable numerical accuracy of the MP protocol (...) Strangely enough, we still don't have all of them but FG is very much alive and kicking. Have a nice weekend, * Thorsten -- 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 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
[Flightgear-devel] (no subject)
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. 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. 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. Matching with ground textures - very problematic, as you would need to generate unique ground textures on the fly, see below. Matching with random buildings and trees - I think the feasibility of using exclusion regions for random buildings and trees around static models has been discussed. This needs quite a lot of distance tests, but may just be possible. 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 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. Custom Italy scenery has very high vertex-count roads and rivers - my GTX 670M GPU crunches these just fine up to the visibility where my combined 11 GB of memory are filled. If you think it through, it's much easier to fill memory with textures than with vertices - to fill 11 GB memory with unique terrain textures doesn't take all that much visibility and resolution. + 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. Which is bad, because it means you need non-local information to get the task done. You'd also want to generate different patterns in Europe, the US, Asia,... I've been working a lot with procedurally generated patterns on the terrain - I've devised overlay texture schemes based on Perlin and sparse dot noise, and I'm working on 2nd generation cloud-layer generating functions (you call a function and get in return the distribution of cloud sprites which corresponds to a Mackarel sky for instance). These are not trivial problems, but to procedurally generate a credible city/village/town/argiculture pattern, even if you know the location of some buildings, is a genuinely tough problem, and even if we can find a solution, it's probably rather performance-hungry. Which brings you (as usual) between a rock and a hard place - you can trade between memory usage and performance consumption, but there's no free lunch. + get rid of sharp landclass borders Essentially you're asking for photo-scenery, which would do that, except that the source isn't really an aerial photograph. So you get into almost the same pro's and con's of photo scenery if the scenery is pre-generated, and you get into significant performance and memory issues way beyond photo scenery if you want to do the generation runtime. + possibly improved resolution 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. If you want to do this with unique texture sheets generated by the CPU at scenery load time, you better bring a Petabyte-sized graphic memory. - eats much more video ram and CPU (but then I have 3 out of 4 idle cores ATM) Well, the memory really is the show-stopper. All else could in principle be pre-processed and shipped with the scenery. Or, if we had the memory to hold the raw data, the GPU could generate all relevant patterns (graphics cards are much better at this sort of thing than the CPU). But you can't implement any such scheme unless it's completely optional if you have to deal with integrated Intel chipsets with 512 MB of memory. - probably totally incompatible with the current terragear toolchain There's that as well. 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
Re: [Flightgear-devel] Keyboard bindings
Often airports are in or near very scenery-intensive areas and reducing visibility can help a lot in making the sim run usably for take-off, whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. This is applying a sledgehammer to a problem which asks for a screwdriver. Performance management with reducing visibility throws everything out - terrain mesh, static models, trees, random buildings,... As a result the load arriving at the vertex shader drops. First of all, this kind of performance management is bound to fail if you're not limited by the performance of the vertex shader - if the fragment shader is the bottleneck (as in the two more modern rendering schemes where we increasingly shift load to the more powerful fragment pipelines on modern GPUs) then you may change the number of vertices drastically, but the number of screen pixels covered by terrain and models changes insignificantly and the fragment load stays what it is. When I run Atmospheric Light Scattering on high detail, then my framerate is pretty much independent of visibility. I haven't tried it, but I am fairly sure the same is true for deferred rendering (Rembrandt) where the vertex stage of rendering is trivial and all the work is done per pixel. In fragment-dominated rendering schemes, the load of faraway models pretty much scales with the number of screen pixels they cover - so unloading them may free memory, but doesn't really change framerate. Also, if you're limited by cloud rendering performance (which unfortunately seems to be the case in many situations) changing visibility doesn't help you - only cloud draw range will do the trick. It may also be that the performance isn't limited by the GPU performance at all but by expensive Nasal (none of mine obviously :-) ) or terrain-probing features like a ground radar - in which case you can play with the visibility all day long and will not see any effect. So let's first note that performance management by visibility is only effective if certain conditions are met, likely to be ineffective in our modern rendering schemes and we should neither encourage it nor recommend it in general nowadays - performance scaling depends more often on the fine-print of what shaders you're running and what your GPU can do. If you nevertheless happen to be dominated by the vertex shader load, you'll notice that most of the load in scenery-heavy areas comes from models, not from the terrain. The fact that you need to get rid of models by drastically changing visibility indicates that the LOD range isn't configured properly, so what you actually need is a way to unload models at larger distance, not to increase visible fog and to unload terrain. I don't know if the LOD menu settings are honoured for static models and random objects (?) - but I'd give that a try before claiming that a visibility-changing key is needed for memory management. Of course, using a cheaper model shader may solve the trick equally well if models cause the main performance drain in the vertex shader. Before getting my current computer, I have had quite some performance limitations in the end and I've done a lot of tweaking of shaders and customizing my settings. The one thing I've never needed is adjusting visibility on the fly - it didn't ever help. All I needed is a safe limit to avoid going over the 32bit memory limit. whereas once you're up and away it's nice to be able to open the view back up again for cross-country flying. Well, but can't you do it from the menu (if you must do it at all) ? Maybe if that happened automatically somehow this would become unimportant, but for now I think a lot of people rely on it. Well, we can safely rule out all people running Advanced Weather (because the trick doesn't work), Atmospheric Light Scattering at high detail and possiby Rembrandt (because there the fragment shader gets the work and dropping vertex load is not really effective) and probably the majority of people using online weather (what's the point of using online weather if you cheat with the visibility later). I don't think that leaves a lot of people. I can't believe you're suggesting removing the FoV keybinding though! I've used that for zoom in 3d cockpits for about as long as we've had the things, completely essential in my opinion. I know it's not strictly speaking zoom but it works, and is very quick and natural to use, too. I actually agree with that, based on the reasoning that focusing on an instrument is something you can do in a real cockpit. Although personally I'm quite a fan of using the mouse wheel in view mode. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
Re: [Flightgear-devel] Iceland textures
Did you test your airfield grass with some of the newer generated terrain (LOWI in my case)? No, I didn't. Shouldn't make a difference for rendering purposes how you created it, at this stage it's all vertices and pixels and the shaders don't care where they come from or how they connect. Not sure about the airfield grass, but at least the concrete and tar surfaces for taxiways and apron use a different mapping. If i remember correctly 1 x 1 meter in the new scenery builds. I'm not sure I understand the problem. After the scenery generation process, you have vector data of the terrain mesh, but textures are mapped at tile load time using materials.xml - so here we find that a 512x512 sheet of terrain is mapped to, say, 2000x2000 m. This is done independent of how the vector resolution of the terrain mesh is and has nothing to do with how you generated the scenery. You're also usually not free to change the mapping as you like - texture sheets depict real-world structures with a real-world size, and showing 1000 m sized houses on the texture just doesn't do. Shader effects add noise and overlay textures to the base texture mapping, and here is where it gets tricky: * Overlay textures inherit the uv-mapping of the base texture sheet for lookup purposes (you can't look them up in world or local cartesian coordinates), and read the overlay texture at a fixed fraction of the base texture uv coordinates. Which means that if you shrink the base texture, normal maps, heightmaps and overlay structures shrink proportionally. This makes sense - imagine the urban effect in which you change the scale of the base texture but not of the heightmap - suddenly random bits of the base texture show the relief. * Procedural noise is usually generated at fixed scale in world coordinates or local cartesian coordinates - this needs to be so because you need to be able to fade it out at a given distance to avoid Moire patterns and flickering, and also because the noise often stands for some fixed-size phenomenon (rocks lying around, ocean waves...) So texture size mapping declarations and shader-internal noise mappings can in general not be varied arbitrarily or independently and need to be considered together. It would be possible to code shaders in which overlay textures are also done at fixed physical sizes - but you'd need a lot of extra parameters to do that and I'm not really sure in improves usability. If that's what you're doing, i.e. you're changing the mapping of a base texture to a physical size, my recommendation is just to undo these changes or to map your airports to a different effect in materials.xml. The reason is that we have a balance between what details we want to generate procedurally and what details need to be on a texture. Some structures (grass for instance, agriculture patterns, buildings) need to be on the texture sheet because the functions to generate them are very expensive, other more random structures can more cheaply be generated by evaluating a function. So in the case of fields we use a top-down approach - the fields which we can't do by function are shown in the texture, the local grainy detail structure is done in the shader. The airfield grass uses a bottom-up strategy - the grass which isn't easily generated by a function is done by a hires texture mapping, this leads to tiling when seen at larger scales, so shader-generated noise is used to de-tile the effect. If you come with a different idea of the base texture size, you may need to change the whole approach from top-down to bottom-up or at least the balance between what detail scales are on the texture and what detail scale you add procedurally. I admit that it's not exactly convenient that all these things need to be taken into account when doing texturing together with effects, but it's very hard to write an effect like the airfield grass or the runway that will work with any base texture you could come up with - the issues listed above are not going to go away easily. I don't know if that is the issue, but perhaps the explanation makes sense (?) * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
This feels like a moderately large issue to me, because out of the box, we select basic weather, and hence we're going to get bug reports about clouds not appearing. We could make basic weather drive the real visibility based on altitude, but then we're moving away from 'basic weather does what you set'. We could give basic weather sea-level and altitude visibility and interpolate between them, which I guess is what advanced weather does? Well, the problem arises because a number of issues have so far been handled in a peculiar way: * Basic Weather 'out of the box' assumes, when driven with METAR, that the reported visibility has no altitude dependence (I think) - which isn't particularly realistic in the first place * clouds, unlike practically all other objects, do not really respect visibility the same way as other objects (they are fogged in the default rendering scheme at twice the nominal visibility, so a similar issue exists outside Atmospheric Light Scattering and clouds disappear before their rendering cutoff hits... * ... but Atmospheric Light scattering, unlike the default scheme, gives you always a rather clear skydome once you clear the ground haze layer as long as no extra high-altitude haze is declared, so in essence the visibility above the lowest layer certainly looks visually very high (this is intended since it gives you a realistic appearance of very clear air high up and the illusion of having several hundred km visibility) One could fix either of those: Changing aloft visibility in Basic Weather leads to memory issues. Not fading clouds leads to bad behaviour in low visibility. And fogging the skydome to agree with the set visibility leads to a completely unrealistic visual impression at high altitudes - 10 km forward visibility at airliner cruise altitude outside of cloud layers simply do not occur. So I'm not quite sure what the intended behaviour should be. Obviously, if you expect to see objects 70 km away with 10 km visibility set, there's something fishy with your expectation as well. And saying that you want to use visibility for memory management but otherwise have a realistic visual impression of objects 100 km away is also not quite a honest base expectation... Suggestion: rename cloud 'visibility' distance to 'draw distance' (since it's in the rendering dialog anyway), to make it clear it's nothing to do with weather / environment Sounds good to me - make that perhaps 'max. draw distance'. in basic weather, have clouds ignore environment/visibility, and simply use draw distance (as before) in advanced weather, cloud use the minimum of both, and get fogged, with nice results in low vis situations. That's in essence asking to code a dependence on the active weather system into the shader, and that's something which imo smells like bad design. The shader shouldn't have to care how the properties which drive it are created. Can a Basic Weather user perhaps test if there is a substantial problem at all, i.e. if 3d clouds disappear as compared with expectations when running Basic Weather and Atmospheric Light Scattering? Maybe we're trying to come up with a fix for a rather theoretical issue... * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Advanced Weather updates
I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. Rain layers and Cirrus clouds are not shader-generated 3d stacks of sprites like the 3d clouds but normal, Nasal-spawned models. 3d clouds are moved by changing the transformation matrix (I guess). But we have no way of moving Nasal-spawned objects except updating their position from a Nasal loop every frame (we do have hardcoded movement for AI-objects, but Nasal-spawned objects cannot use that for some reason - so the Nasal tanker has such a per-frame update loop). It turns out that per-frame position updates for O(20-30) objects from Nasal is already too much to keep a nice and smooth framerate above 20 fps. So I de-activated the Nasal loop. The functionality needed is that, like AI objects, Nasal-spawned models can get a heading and a velocity and then move automatically as specified. Vivian, do you still have the patch somewhere? It's somewhere on my old computer... * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
*Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. (...) It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not) Can anyone please explain to me why one needs to change visibility manually during flight so often? We're trying to create a simulated experience. Which means that for me there are things which I adjust before flying, i.e. I set the airplane, the location, the weather, the environment, the time,... And there are things which I can adjust in-flight - there's the throttle, levers for gear, flaps, various buttons, where I look and what I focus on. But the simulated environment in-flight largely is what it is if you aim for realism of the experience - if the weather deteriorates, I have to deal with it. If the visibility drops below VFR conditions, I have to change my plans. Conceptually, I understand that key bindings make sense in the context of a simulator standing for things I can do in-flight in the cockpit, because I may need to be able to perform these actions quickly or while I'm doing something else (like controlling an airplane). In many cases, we do not have a keybinding, and performing a real possible action ends up being awkward - you need to mouse-click something while flying on, or you even need to open an menu. Changing visibility magically is not of this group, it's not a realistic option which you could perform in a real cockpit. I understand that visibility needs to be manually controllable for setting up specific training conditions. But this doesn't need to happen in-flight all the time and can be from the menu. I understand that visibility has a role for memory management, but that doesn't need to be done in-flight either, memory management can be done much more efficiently by setting a max. visibility value once and just store it. You can't micro-manage memory consumption by adjusting visibility all the time because a) you'd need to have an open system monitor to see memory occupancy and b) you'd need to know in advance how much memory the next tiles to be loaded will have. About the only reason why I can see one would want to adjust visibility often in-flight is 'cheating' - you just take a quick look in bad visibility where you are. This is fine, it's a simulation after all, we have AP support for planes which have no AP in reality and an in-built GPS - but why do we need to support that with a key-binding? The question to me is not 'Do some people use it?' The question we should answer is 'Given the alternative between a key binding to change visibility and assigning a new key-binding to a function you can actually perform in a cockpit, isn't the second option better'? For instance assume we would assign z/Z to changing the NAV1 frequency or the heading of the AP - these are functions which I perform basically all the time when I don't do pure VFR and it's rather awkward to open the menu or hit a tiny clickspot. Personally, I think reserving key binding for things which you can really do in a real cockpit is not a bad concept. And I would really like to understand why some people think it's necessary to change the visibility so often that a menu option doesn't work for them whereas I need to change my NAV frequencies in the menu (while flying the plane with the mouse... I can do this with just one control device) * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
So whatever we do, we can't override the ability to get low level granular control of the weather parameters, and not just so that advanced weather can manipulate them exclusively, also so that external tools can manipulate them without advanced weather getting in the way or overriding the settings. (...) And please don't forget, there are command line options like --visibility, --wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic-weather and I'd love to keep all that functionality. I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed, but the internal control structure of the system shouldn't change. The current structure seems sane to me: * shaders which render the visibility take values from the property tree and are agnostic to how these got there * so does the terrain manager * the weather system has an 'idle' mode in which no properties are set by the system automatically, and it is possible to define weather with the property browser * Basic Weather can run and fill the properties based on interpolation tables * Advanced Weather can run using the idle mode and set the parameters from Nasal - once you stop the Nasal loops, you're back in idle mode and can set properties by hand * any external/future system can likewise use the idle mode to set parameters - any shader will render these parameters regardless of how they were put into the tree. - what you can't do is run two different systems at the same time The only problem arising is that Atmospheric Light Scattering uses three visibility-defining parameters to render rather than one, so if you define only one of them on the commandline, the rendering task is ill-defined and the framework falls back to the defaults as specified in environment.xml - which may or may not be appropriate for the weather situation you have in mind. The system is sane in the sense that it will always use the lower of visibility and ground visibility, so if you set visibility to a very low value, you'll not get to see the higher default ground-visibility on the ground. You can in any case specify the info by setting /environment-ground-visibility-m and /environment/ground-haze-thickness from the commandline and you will see the system responding appropriately, and Basic Weather or any external application could likewise set these parameters to other than default if so desired. There's a also host of secondary calculation of light attenuation and color rotation underneath clouds which are pretty complicated, and there's no chance to just set them to the right defaults - so unless you have a system which does the equivalent of these computations as done by Advanced Weather and sets the properties for the shader, you will get implausible lighting under some conditions. But that's an aestetic issue - FG remains usable with the defaults, it just doesn't give you the full eye candy. The whole part of the discussion about the max. visbility slider and realistic visibility checkbox in Advanced Weather is a completely different beast because it refers to Nasal-internal parameters which are not seen when any other system runs and not relevant for the shaders or the FG core. I think we need to keep parameters which are exchanged between subsystems in the discussion separate from parameters which stay inside a subsystem - there are many different wind parameters set by property rules for the water shader, others written for internal reference by Advanced Weather, yet others used to store the config of Basic Weather - but none of them has any relevance for the FDM for instance. So if there's any genuine concern that we might block options for any other development, I'd like to know what it is, because keeping options open is something which is high on my agenda as well. * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Advanced Weather updates
I've pushed some updates to Advanced Weather and the cloud shader of Atmospheric Light Scattering. Clouds now fade to transparent at distances between the visibility and 3 times the visibility. This gives a much better impression when in heavy groud fog (CAT I to CAT III) and shouldn't be a problem above the cloud layer for semi-realistic visibilities (if you have 20 km, you get clouds drawn out to 60 km or so). CAT IIIb using Atmospheric Light Scattering and Advanced Weather should now give better results (I won't start thinking how to support Basic Weather properly before this actually works) - although it takes a while for the system to ramp down the visibility to very low values (the interpolation routine has a time delay) - you may have to wait for 20 seconds till the visibility is actually all the way down. However, the change does mean that if you leave the visibility at cruise altitudes of airliners at 10 km, you will not get to see many clouds regardless of how the cloud visibility range is set (because they now respect the real visibility setting in addition), so this is potentially an issue for Basic Weather users. If this is a show-stopper, then we may need to undo the changes, but fading to alpha is by far the fastest way to deal with heavily fogged clouds. Please test and give feedback! Runway lighting and the sun are still not okay and seen through fog - any pointers as to where to modify the lights are highly appreciated. I've also tinkered a bit with the thunderstorm scenario and reduced the density of clouds surrounding the Cb towers as well as the number of sprites being used - I now get quite acceptable framerates of ~20-30 fps in the scenario - maybe it also helps for others. One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vs. FSX demo
Hi Vivian, That's really good to hear - but if we are falling behind in some respect then we will make an effort to improve. I am reminded that the flag and wake shaders are inoperative when Atmospheric Light Scattering is activated. With the departure of Emilian, I see no prospect of this being fixed unless someone else steps up to the plate. Well, we couldn't possibly leave the flag just hanging around, could we? :-) http://www.gitorious.org/fg/fgdata/commit/be7ee7e06cf4237d60cf8ae5849cf098308b7cd8 (The flag shader is a simple variant of the default model shader, so just 5 minutes of Copy/Paste the flag-specific code into the default model fragment shader did the trick - that must have been my new record for shader conversion. Also, in ubershader-lightfield.frag we now have all the code blocks of the atmosphere effects nicely separated and lined up in a fragment-only environment, so when you need to write a shader which isn't performance critical, then I recommend just copy-paste of the four blocks, supplying them with properties, and you should be almost there...) As a suggestion to improve the Vinson, I would ask for some dirt/rust/stains on the Flightdeck - the homogeneous grey appearance is the thing that sticks out most to my eye. I recently saw a short video of FSX with moving cars and trucks populating the roads. We can do that up to a point, and trains as well, and I forgot to mention that we can also texture tracks and roads properly: We can only have a few - around 50 if we are to keep framerate within bounds. If we ever get the Kent scenery fixed up well enough for release I'll include this around Manston/EGMH. You seem to have managed the trick to align the uvmapping of the street texture with the direction of driving. If so, I think we could have an almost arbitrary number of (low resolution) cars for cheap by shader magic: * use an overlay texture which is transparent except where the cars are supposed to be * use the heightmap technique of the urban shader to give them some substance * overlay them on the lane and move one coordinate along the driving direction over time (* add light effect in dark and so on) Since this could all be in the fragment shader, and only a vanishing amount of screen pixels would usually be occupied by linear features such as roads at any given time, you could generate tens of thousands of cars that way without hitting the performance badly. Of course they'd suffer from the same artefacts as the urban effect from close-up, but the sheer number may completely make up for that. Cheers, * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. Thanks. I can do the first item easily (I do think 10 km max visibility are a bit on the low side, but it doesn't hurt anyone..). As for z/Z - can we reach a decision first what to do with this? James and Stuart seemed to be considering to drop this key binding, and I would actually prefer that as well. Is there a compelling reason to manage visibility by key? For me, this resembles more an arcade game strategy than a realistic simulation. (If we keep z/Z, it'd be nice if anyone can give me a pointer how to link it with the max. visibility or just do it, because I don't know how it's done...) * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vs. FSX demo
A small addition: what has always bothered me about terrain in FG is that roads and rivers are all the same size. Good point. That wasn't really apparent from the FSX demo (not so many roads of different size in the Caribbean). I think rivers are less of an issue in CORINE based custom scenery - I seem to remember that I was quite happy following major rivers in custom France or Italy. Roads... yes - Vivian's screenshot looks quite promising though. It's not something that's very important to me personally because I usually fly in pretty lonely places where roads are far an inbetween, so it's something I tend to overlook. Obviously compare the worst YASim with the best JSBSim will always be beneficial for JSBSim. But the opposite will be benefit YASim. This is ridiculous. Erik basically said it - it's not a YaSim vs. JSBSim comparison here. We could make a best YaSIm vs. best JSBSim comparison, and I do have an opinion about that, but that's a different discussion. This kind of remark has no place here, and especially not by you. What's the last half-sentence supposed to mean? Why would I be an especially unsuitable person to remark on aerodynamics? Granted, I'm not an aerospace engineer, but I do have a sufficient comprehension of fluid dynamics, solving equations of motion and all the rest, and I have real-world experience as a glider pilot, so I feel entirely qualified to comment on aerodynamical issues. FS X was released in 2006. What is really surprising is that a person like you never had the curiosity to test it before today. Not really - I'm not a Microsoft fan, I try to run Windows as little as possible and mostly live on Linux. What is it then for X-Plane, Fly II Legacy and all the others ? And I am speaking not even of older sim. FS 1, FS II, FS 3, FS 4, FS 5, Gunship, Knight of the Sky, Reach The Sky of, A320, F15II, F29 Retaliator, Falcon, Falcon 4, IL 2, Flanker 2.0, Lock On, etc. .. I have logged many happy hours with Falcon 3 and Falcon 4 and I think they were excellent simulators. I fail to get your point though - if I compare FG with FSX and write my opinion, am I somehow under obligation to make a comparison to every other flightsim in existence at some point in time? So I tested FSX, I found we fare quite well in comparison, I did not test Gunship or X-Plane 10, so I don't know how we fare in comparison and I will not offer an opinion without knowing - what exactly is the problem? Best, * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional texturing project - Cntrl. Alt. Click
Thorsten, work is halted as my co-ordinates must be wrong, can you tell me the dimensions I need to use? Bruce, I'm not sure I understand your question - the coordinates in the conditional used to define a region are latitude and longitude in degrees (but I guess you know that, so probably you refer to something different?) * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vs. FSX demo
Renk, you should take a look at the default Cessna 172 in FG and it's mate in FSX. The FSX version wipes the floor with the FG version with respect to the cockpit model. (I'd really appreciate if you guys would call me on first-name basis 'Thorsten'...) That's a question of what a fair comparison is. I'm going to assume that whoever put a demo version from FSX together has specifically chosen scenery and airplanes in the demo to impress users. So my standard of comparison is not 'How does the same airplane or the same scenery in FG look like' because I regard that as unfair - they got to chose, we didn't. My standard of comparison would be - if I were to put together a FG demo to impress users, how would that compare? You are certainly right with the c172, but the fair comparison is e.g. our DR-400 against the FSX C-172, and FG is going to win that one. It doesn't matter so much that many aircraft in FG can not measure up to that standard - I don't usually fly them. We have 20-30 really high quality aircraft, and I doubt FSX has that many out of the box. If you count addons, we can field all the non-GPL hangars in return, where I believe T4T is doing some really impressive warbirds... If you're going into comparing 'the same' (scenery, aircraft,...) than my next question would be - FG has beautiful scenery in central Iran with the Middle-East texturing definitions. I doubt FSX out of the box has any scenery there at all. So we're winning flat out in many cases by virtue of having scenery everywhere. It doesn't make too much sense to me to go into that direction. One thing I'd really like to see put together is a The Hidden Secrets of FlightGear page that illustrates all the little bits that people aren't necessarily aware of. Things like the hard science behind a lot of the things FG tries to get right that other simulation software completely ignores or fakes poorly. We've sort of started this here http://wiki.flightgear.org/Unique_Features My problem is that I often know very well how X is implemented in FG, I may suspect that it's not in FSX or X-Plane, but since I'm not running X-Plane or FSX with all addons I don't really know for a fact if it is a genuinely unique feature or if there is a 3rd party addon to FSX/X-Plane which provides the same thing. And we would want to be factually correct here. While we wait for the FSX screenshot, I'd like to see the FSX equivalents of these as well: Honestly, I have no clue how to make a screenshot in FSX... and I don't want to fiddle around with it much longer, suffice to say it gave me some ideas how the GUI could be, but it doesn't draw me in in any way. And you'll not going to find me argue that the Vinson doesn't measure up. It's a spectacular model, and I do love doing carrier ops in FG. Cheers, * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG vs. FSX demo
Following a forum discussion, I finally became curious and tested the FSX demo version yesterday. I've spent about two hours flight with it, testing 3 different planes (the ultralight, the Baron and the Learjet) and had a look at different weather conditions and daytimes around TNCM. The installation process takes forever, opens one useless wizard after the next one and never gives any indication what it's actually doing - the Windows way Also startup isn't exactly fast. A few immediate nice impressions: * The launcher GUI is very pretty - including some pics in the GUI adds a nice touch and gives you more immediate impressions what things are about. In comparison, the FG GU (both launcher and in-sim) is very rough around the edges. - I guess it's a matter of taste, but including a pic of the weather situation to expect in pre-defined scenarios would not be a bad touch for our GUI for instance. * I got the IR-sycnhronized LCD shutter glasses 3D effect working out of the box, so I was able to test FSX in real-color 3D which looked very cool - I've never been able to make FG do that, I can activate the whole set of 3d options, but they never trigger my shutter glasses. I wish FG would support that function... - Win for FSX. One in the cockpit, I had serious trouble finding my way around. Maybe it's just whay one is used to, but looking around in the virtual cockpit the FG way came much more natural to me than looking around in FSX. I didn't find any way to adjust my field of view at all. In the following, I maxed out all graphics and realism options I could find. 1) Terrain: * A big plus about the FSX terrain is that it doesn't have landclass seams. That makes it quite a bit nicer to look at from above. It's not so impressive from close-up, and all in all, I would conclude that regions where we did apply a regional texturing scheme and use the best shader effects available are in fact quite competitive. In particular, I think the recent 2nd generation Hawaii in FG or middle-east looks much better from close-up and is still about on par when seen from a few thousand feet. Of course, FG terrain can look much worse in areas where we didn't customize it. - Pretty much a draw. Hiding the landclass seams better would still be the thing for FG.. it's just not so easy. * I know several people who were especially impressed by the water in FSX. Personally I wasn't at all. What it does get is that it knows where shallow water is and thus it gets lighter and the ground can be seen through. But for instance it doesn't have as nice waves and foam as our water, the scenery reflections it generates look completely unrealistic, ocean just doesn't do that, and it didn't really change color when underneath a 8/8 cloud cover where it should have gone to grey - as the FG water shader does. - So that's a win by a narrow margin for FG - still, being able to include depth information into the rendering would be cool. * Models of trees and of the aircraft carrier in the vicinity where largely on par. Probably FSX has more graphical artists and the quality of for instance tree textures seems to be a bit better, but the technique is otherwise pretty similar. I liked seeing a few other aircraft lined up on a carrier - the FG carriers are usually rather empty. - Ever so slight edge for FSX 2) Weather (I looked at 'Fair Weather' and 'Rain' scenarios.): * I wasn't at all impressed by the quality of 3d clouds. The Cu clouds are sort of very impressive at first glance from the ground , right until the point where you realize that they just don't look like real clouds. The form seems to be designed by an artist to impress, but the combination of shapes doesn't occur in real Cu clouds which are turbulent raising air motion. The distribution of cloud sizes is all wrong - a real sky generates Cumuli at all size scales, FSX just does two or three. The distribution of locations is all wrong - they should cluster over islands where convection is stronger than over water, but they don't. They don't respect time - I've gotten the same amount and size in the morning as during the day. They're far too white - real Cu have rather strong self-shading. This leaves the impression the clouds where made to resemble the pretty picture in the launcher GUI of fair skies, but they miss out pretty much every subtlety I've been struggling with when designing the Cu system of Advanced Weather. - Clear win for FG. * The Cirrus clouds do actually look quite nice and better than what we have - here having people who can do good texture extraction is an advantage... - We could need a helping hand from some photoshop/gimp master to get better Cirrus textures. * Rain and overcast skies didn't impress me either. The rain generated in FG looks more plausible to me, and the light underneath the overcast sky was just wrong. From above the cloud layer didn't look very good. - Well, the
Re: [Flightgear-devel] Air-to-air refuelling enhancement
I've just committed some small changes to the AI air-to-air refueling function: Had a short look yesterday - nice! I like the option to customize the envelope. Does anyone know what realistic numbers are - I guess the boom can be moved somewhat, so there must be a tolerance of few meters (?) or less. Someone in the forum made a Russian tanker - maybe we can include that as well? * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
2. Slider in Advanced Weather - Advanced Settings - sets a max value . The displayed vis in the min value of this and the value derived by Advanced Weather. (Is this true? I'm only inferring this). True. 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. It changes the internal model used to derive visibility as a function of altitude. In reality, once you clear the lowest convective layer which is normally pretty hazy, the visibility often goes to hundreds of kilometers. The checkbox largely controls where Advanced Weather would set it - if you don't check it, visibility increases more slowly with altitude, if you check it, you will in many weather situations open the visibility to 120 km (or whatever max. value you specified) a few hundred meters above the lowest convective layer. Basically, checking the box means 'model my visibility as real as you can do within the FG framework' and unchecking it 'model it halfway realistically, but keep an eye on performance and memory issues'. I used the old terms Basic/Advanced Weather, but I note that these have disappeared from the GUI. How would the user know why or when he would chose ether option? Scope for some rationalisation here I would think. The design idea behind the current GUI was that the user should no longer be presented with two different weather options to choose from, but just see a single GUI which controls weather. If that is still the idea, it works remarkably well. If you have an idea for a more descriptive text, please let us know. This should be easily fixable by having the atmospheric scattering checkbox set the value of: /sim/rendering/minimum-sky-visibility to 0, and returning it to the default value when unchecked. Is there an xml way to do that? I know how to do it with a listener from Nasal, but that seems like an overkill... Or am I thinking too complicated? In other matters, I was able to make some progress. I've replaced the hard cutoff by a smoothed, sliding cutoff, so the circle is gone. Fogging clouds properly turns out a no-go because the fog color is way too expensive to obtain, but it occurred to me that one can cheat here - rather than fading to fog color, one can fade clouds to transparent for distances larger than 2-3 times visibility. That gives the desired disappearance of the cloud layer in poor visibility from below (I have to check if it has any undesirable side effects in situations with high visibility). It's also neat because the fragment shader will drop transparent pixels - so performance of fading to transparent is better than fading to fog color. Since there are still unspecified but serious concerns about loading 20 km of terrain, I've hacked my way around it... so please drop the idea. This is what CAT IIIb now results in: http://users.jyu.fi/~trenk/pics/catIIIb.jpg There are some remaining issues. Specular light is way too strong in the picture, I have to tune that down (that's also the case in default rendering). As you can see, the lights are way too visible for CATIIIb - it took me 5 minutes to figure out that they are actually 100% fogged, but since they are fogged in the default scheme for some reason, the fog color is much brighter, and so it seems as if they were unfogged. Does anyone know where the various runway and other lights enter the rendering pipeline and what should be done to get a shader to process them? Can they be assigned to model-default, or do they need extra treatment? A similar issue is the sun (which is never fogged). It used to be hidden by the clouds, but if we fade the clouds to transparent rather than to fog color, that no longer works. In the default scheme, I think the sun becomes hidden when the skydome unloads - but that doesn't work either, the scheme needs the skydome. So we'd need some control over what we show of the sun - that's also relevant if the sun is below the horizon, but the horizon terrain is rendered by the skydome - in this case the sun can be seen through the 'terrain'. Does anyone have an idea how we could control the appearance of the sun? * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Discussion culture clashes
Actually, I think what he tried to suggest was, that the needs of visuals and the needs equipment like radar should not be mixed. For visuals we need the terrain and all the objects like trees and buildings which are hard on performance. It's a fact that the distances out to which we draw trees and buildings are considerably less than how far we potentially draw terrain (120 km max.) So these things are separated even now - we don't attempt to render random buildings in 80 km distance even if we render terrain. Nobody proposed to render buildings to the visibility range either. Also let me quote what James said immediately before: This is moving in the right direction for sure. I'd like to go a little further, and make the LOD setting a simple checkbox labelled 'reduce detail adaptively'. Then make the LOD ranges (for trees, clouds, AI models, whatever) internal properties, and crucially, enable OSG's LOD-bias feature. This effectively scales the 'visible distance' used to select LOD by a factor, and we can use a PID controller to adapt it based on target and actual frame-rate. (Of course I didn't try it for real yet). This ought to nicely adjust the LOD bias, and hence the final LOD, to keep a target rate (say 30 or 60fps). So this doesn't lead to any more gracious interpretation. * Thorsten -- 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_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
