Re: [Flightgear-devel] Low visibility issues
On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote: A lot of stuff, mostly deflecting the discussion to other irelevant points * Thorsten While I should know better than to answer to this, as it will again get deflected to other areas, let's imagine ourselves a simple scenario: Let's say I'm an average user with a 32bit system, I can barely find my way through the maze of menus and dialogs flightgear presents to me, and I want to use this more advanced weather simulation engine. After I accidentaly find out how to enable it (it's hidden under a rather confusing radio-button selection Model overall weather conditions based on metar), great, select Fair weather scneario, Apply, OK, let's go flying. I muck around, wonder at the nice sky/clouds, notice that my visibility improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, why did that happen? That didn't happen before? All I did was change the way the weather is interpreted... What's wrong here??? Well, now let's see what actually happens in a default flightgear instalation (all settings are from preferences.xml, and Environment/local-weather- defaults.xml) -trees are enabled by default -default visibility with Fair weather is ~16km -local weather comes in and sets a default value for max visibility of 120km (o.O), ok, that's a bit far, but in practice I see that's actually hovering in the 40km range (+-10km based on altitude). (roughly 3x more than the default) So in the default scheme we load 9 tiles at startup, then we keep loading tiles in the direction we're traveling, and those initial tiles remain resident in the tile cache for a while (in case you decide to double back). But let's stay with the startup condition. when you ramp up the visibility to 40km you demand 3 extra rings of tiles to be loaded. That would give you at least 69 tiles loaded (81 if the rings are square). So that's an instant increase of 7-9x the memory requirements of the terrain + objects + trees (tres being the largest contributor here), just because you click an option that says it just _interprets_ the METAR string differently. Do you think that's an expected result? I don't. Well, our average user might have read the manual, might have mucked about with the visibility setting before, and he remeber that all things being the same, visibility is what impacts performance/memory the most, so he decides to try again, this time trying to use z/Z to limit how far the visibility goes, maybe he gets lucky and it won't crash again, but he's in for a surprise... z/Z doesn't work... You might argue that he should know better, go into the advanced settings dialog, figure out what all those sliders and selection boxes do, etc, etc... But remeber, our user is an average one, he wants things to just work (with time, he might find a use for the more advanced configuration stuff, but for now he's not interested, he just want to click something, and be done with it), The z/Z case above might be a lucky one where he might have read the manual. The problem is not with Advanced weather in itself, the problem is in the details of a part of it, themost important part from the user POV. Your approach might work, given unlimited resources, but as it is Flightgear has to run on a variety of puny little desktop/laptop machines. You have already implemented half of the control, is it so hard to implement the rest and provide a system that's consistent with the rest? Yes it breaks the real world scheme, but this is a simulation, we lie, carefully crafted lies, that give a global impression of truth, of copying the real world behaviour, but in the end they are lies. Fog/view-distance is one of those lies, they need just be plausible, not a faithful representation of the real world (and a faithful representation of the real-world is practically impossible given the current state of the technology). You are comfortable with abdicating from that when it suits you, but where it really matters you defend the minute detail faithfull representation of the real world scheme vigorously... Don't you think thre's something amiss here? As someone said in another thread, there are various techniques that are not constrained by the real-time requirement, that do a pretty good job of giving you real results, but their place is not here. Here we have to do our best to trick the mind, while doing that as fast as possible, with a reasonable usage of resources. Just because you can set visibility to 1000km doesn't mean you should, just because you can shove a lot of data into a shading scheme and get back photoreal results doesn't mean you should, if said results reduce performance, increase the probability of running out of memory, etc. You'll argue again with the IAR as an example. Well, take a look at those numbers again, and you'll see that for the amount of detail it presents to the user it uses ~0.66 of the memory used
Re: [Flightgear-devel] Discussion culture clashes
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote: 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. Buildings/trees are generated at tile load time currently, and remain resident in memory, for as long as the tile is loaded. If you don't se them on screen doens't mean they're not there. Emilian -- 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
On Saturday, February 23, 2013 11:51:55 Stefan Seifert wrote: The solution is not to give crude tools like limiting visibility to the user. The solution is to fix FG to be consious about how much memory is available and make the best use of it. Yes, many games simply limit visibility if memory or performance pressure gets high. But FG is a flight simulator. Visibility is a very important part of flight (at least for me as a VFR pilot). Stefan Guess what happens when memory is limited and visibility is set to 120km? You see the end of the world, because no more tiles can be loaded to reach that distance. Guess what you need to adjust then, independent of what the real world says? Visibility distance (implicitly fog) to mask it. Regarding trees: you think that way, I might, someone else in the know might too, but the average user sees that they work well with his setup in the default condition, why would he want to disable them? The only thing that new setting advertises is it reads the METAR string in a more advanced way... Manual setting of this has the added benefit that you're not moving tiles back and forth through the tile cache/display as memory becomes more or less available. You set a max setting that suits your machine and or the area you fly in (in the carribean you can easyly reach that 120km, not so much at KLAX) and you're done with it. And why should you have to set that in _n_ places, when there was a perfectly reasonable documented setting in the first place. This thing with the visibility is just one part of a bigger problem here, that someone doesn't want, or doesn't uderstand that he has to take shortcuts, use tricks, and abdicate from a faithfull model of the real world. Instead he shoves everything but the kitchen sink in, disregarding what effects that might have, expects everyone else to accomodate any needs that might arise from that and considers any bit of critique or negative comment as a personal affront. Now if that's how things are supposed to work around here, I'm not the one to decide, but for me it's not. Regards, Emilian -- 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
On Saturday, February 23, 2013 13:09:29 Stefan Seifert wrote: Why do you want the user to have to repeatedly press a key after starting the sim instead of setting the maximum visibility once and for all in the advanced weather dialog? In other words: why should the user press a key _n_ times instead of setting a slider once? I don't care if it's _a_ key / slider / command line option/ registry setting/automagic ... just use one, and be consistent about it's use, is that so hard to do? If there's a docummented option (key shortcut, command-line switch, property setting) about setting that, is it so hard to obey it? If it's there chances are it's there for a good reason. Use that, don't go about creating layer after layer of property options that duplicate/triplecate existing ones, just because you canand then expecting everyone else to fold in line. 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. These are not just isolated litle bits that can do all they want without affecting anything, they're integrated into a bigger picture, and a small seemingly insignificant change can bring down the whole system, why? Just because someone saw that it's possible to set view distance to 1000 km, or that his gpu can handle 1k LOC in a shader. And all this is solvable just by adding a crappy line of text as a warning in a dialog, and making a slider take the global setting. Just that. BUT no, we can't do that, because it's not a faithfull model of the real world then... As if everything else would be much more than a few little rgb points on a display. Regards, Emilian -- 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
On Thursday, February 21, 2013 12:33:17 Renk Thorsten wrote: I was talking about the 16km value (sorry for not being more clear about that) and see below for the huge value. Let me get this straight. You state that the 16 km are a pretty sane value. The proposal being discussed is to load terrain to 20 km no matter what the visibility is. Vivian has concerns about memory on 32bit systems. I have test data showing that I can do 250 km visibility on a 32bit system and 50 km with trees and buildings and custom scenery. So as far as the topic of the discussion is concerned (which up to this point had nothing to do with what visibility Advanced Weather may or may not set) - can we agree that 20 km (or 16 km) of terrain loaded no matter the visibility is a sane value even for a 32 bit system? Or do you have different test data? See below... This There's no warning/statement about what that selection implies, nowhere. The average user doesn't know what that will do to his system, or how it will change behaviour of other parts, that seem unrelated, nor has he control over a simple thing that might improve his experience, while enjoying both high detail scenery+objects and advanced weather. has nothing to do with the question discussed (which is how much terrain we load when the visibility is small). It is a quite different issue which you bring here for no discernable reason whatsoever (the thread title is 'low visibility issues' and you're suddenly switching to high values...). Your statement as made above is pure hypocrisy. 1) There is zero warning given what increasing the visibility with z might imply (I just tried that to be sure). If you're concerned about the correlation between memory usage and visibility, you should not care how the large visibility is obtained, you should warn whenever this happens. Have you ever read the getstart.pdf? apparently not. In current version at page 61 getstart.pdf wrote: – Rendering Options configures various graphical features. This allows you to trade eye-candy such as shadows, 3D clouds and specular reflec- tions for frame-rate. To help you achieve a good balance, enable the “Show Frame Rate” option in the Display Options menu, which will show the current frame-rate in frames-per-second in the bottom right of the screen. Most people find a frame-rate of around 20fps adequate for flying. The frame-rate is affected by the graphical features you have enabled, the current visibility (set by Z/z), the number of objects in view and their level of detail (LOD). - 2) Last time I checked, there was no warning given that the IAR-80 uses a large chunk of memory. If you are genuinely concerned about users filling up their memory, why don't you start here? Don't we like to compare apples and oranges... Hmm, let's see, your statement would be valid if: a) The IAR 80 would be part of the core distribution. It isn't. b) If parts of it would be a hidden requirement for the corect operation of other aircraft, under the apparence of optional usage (it isn't), while advanced weather is required to be on to get full advantage of the atmospheric scattering scheme, a thing that isn't specified anywhere (except in some obscure forum post, or wiki page, for which you need to search really hard and only when you know what you're looking for) c) it would completely override the operation of other core components just because it can, and would do seemingly unexpected things for the unaware user (it doesn't). As for the memory usage of the IAR80, you might be surprised if you botherd to check. BTW, weren't you the one crying on quite a few forum threads, some time ago, that aircraft need better 3d models/cockpits, the one who started rating them based on how they look... hmm... I suppose it was just an attempt at a personal attack, but, unlike you, I don't consider [more or less informed or documented] critique to my work as a personal affront. 3) In order for Advanced Weather to reach the really large visibilities, you actually need to check a box labelled 'Realistic Visibility' This may also provide a hint that we're not doing rendering for a 3d shooter where fog is a device to hide the edge of the scene, but that visibility is an essential and very relevant property for the environment we're trying to simulate - it makes the difference between IFR, hard VFR and easy VFR. Even leaving this argument aside, I would argue that a user who has a) set LOD bare to a high value and b) checked this box can be assumed to have the intention to render a high visibility. 4) I actually brought up the very same issue on this list - the correlation between memory, choosing highly detailed options and getting a large visibility delivered. There was a discussion and a decision was made to attach the warning to the
Re: [Flightgear-devel] Low visibility issues
On Wednesday, February 20, 2013 08:44:24 Renk Thorsten wrote: . 1) Black skies: This may either be skydome unloading which I can't reproduce (but we should have a property preventing that, I don't know if it's set only by Advanced Weather, if not then this is a Basic Weather problem, not a shader issue) or actually the correct behaviour - if you have 50 m visibility in a 300 m thick fog layer, you're 6 attenuation length down, so the amount of light reaching the ground is just exp(-6) ~ 2 permille of that reaches the top of the layer. Which gives you a pretty dark sky. If dense fog is to appear white, it can't be a very thick layer. Thanks, * Thorsten 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. -- 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
On Thursday, February 21, 2013 10:31:18 Renk Thorsten wrote: I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p17739 2 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... * Thorsten Draw distance and, consequently, fog used to mask the edge, has always been used as a device to limit graphics workload, resources needed, and improve performance of 3d applications. It allows you to fill the visible scene with as much detail as you can handle, and provides a fairly gracious and credible way of hiding the cutoff. And this technique isn't going away soon. And this is exactly the case of decent GPUs stuck on a limited memory system (be they 32bit or low memory ones), they can handle all the goodies in a limited scene (maybe even more), but their memory can't hold the wide scenes. Why should those users be forced to give up on those goodies just because one part of the rendering scheme doesn't want to play by the rules? Even more so when there's no indication that happens... The default max visibility value is a pretty sane default, and simply increasing that to huge values without any kind of warning of the implications provided to the unaware user is simply _BAD_DESIGN_ imho. (As is disabling the z/Z key behaviour in one of the weather options, again without any warning provided whatsoever). Cheers, Emilian -- 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
On Thursday, February 21, 2013 11:13:21 Renk Thorsten wrote: Why should those users be forced to give up on those goodies just because one part of the rendering scheme doesn't want to play by the rules? Even more so when there's no indication that happens... The default max visibility value is a pretty sane default, and simply increasing that to huge values without any kind of warning of the implications provided to the unaware user is simply _BAD_DESIGN_ imho. (As is disabling the z/Z key behaviour in one of the weather options, again without any warning provided whatsoever). Fact check: 1) I'm proposing to set the distance out to which the terrain is unconditionally loaded to a value of 20 km. The hard-coded default max value of the visibility is currently 120 km. FGs default visibility at startup is about 16 km (and I'd be fine with that value as well). No idea why my proposed 20 km would be a 'huge value'. I was talking about the 16km value (sorry for not being more clear about that) 2) 3) I wasn't talking about these, neither was Vivian. 4) z/Z is disabled because weather comes with a model for the vertical change of visibility as you go to different altitudes. You are allowed to affect that model (that's what sliders are for), but you are not supposed to micro-manage the weather simulation. There's a clear idea behind all of this, which is that in Advanced Weather you trust the simulation to have an understanding of weather and terrain and get the details right, you do not adjust the details. I'm not forcing any Basic Weather user to the Advanced Weather philosophy, don't try the reverse on me. Leaving your obvious expression of dislike for Advanced Weather aside, is there anything in your post which has relevance for what we're discussing here? If yes, please explain. * Thorsten There's no warning/statement about what that selection implies, nowhere. The average user doesn't know what that will do to his system, or how it will change behaviour of other parts, that seem unrelated, nor has he control over a simple thing that might improve his experience, while enjoying both high detail scenery+objects and advanced weather. Sorry, but for me, forcing your usage-pattern on the user just because you think you know better what he wants is bad_design by definition. -- 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
I was talking about the 16km value (sorry for not being more clear about that) Sorry this should have read: I was talking about the 16km value (sorry for not being more clear about that) and see below for the huge value. -- 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] Two rendering issues
On Tuesday, February 05, 2013 08:17:43 Renk Thorsten wrote: 2) Flickering in water http://www.flightgear.org/forums/viewtopic.php?f=68t=18924start=15#p176001 With the sun in the back, under some conditions a strange flickering in the water can be observed. Dialling down the amount of direct light, I could verify that these are light reflections, they go away when no direct light is available, although they appear unnaturally large and blocky. What bothers me is: * I have never before observed this flickering, I did hundreds of test flights under all possible conditions, I've looked at water from altitude ranges of zero to suborbital, I have logged several hours of flights over open water since I last changed the shader. Under Windows I have a 1 1/2 months old binary in which I am 99% sure the problem does not occur there, although it occurs on recent GIT. * I have not changed the shader code or effect code for more than 3 months So this would indicate that the problem was caused by some other developement and slipped in. Does anyone have an idea as to what this could have been? Were there any changes to the water shader files / normal maps/ textures in the default rendering scheme (the Atmospheric Light Scattering version uses the same files)? Or to the effect files? Could the ATI hack have done something weird? Any ideas welcome, I have no good plan of attack for this yet. Thanks, * Thorsten Cannot reproduce here on today's GIT. Given the intermitent nature of it, I have a possible culprit (but you're not going to like it): -try with the texture fetches outside of the conditionals, see if you (or the reporter) can still reproduce it. Emilian -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Two rendering issues
On Tuesday, February 05, 2013 11:12:14 Renk Thorsten wrote: Cannot reproduce here on today's GIT. Given the intermitent nature of it, I have a possible culprit (but you're not going to like it): -try with the texture fetches outside of the conditionals, see if you (or the reporter) can still reproduce it. I think I told you a while ago that I learned that particular lesson - no texture2D() lookup is currently done (or has been done in the last months) inside the conditional block, only the sine wave evaluation is conditional on whether you see their effect or not. So that's out. * Thorsten I think the foam texture is still read in a conditional, based on distance. (water-lightfield.frag/water-lightfield_lr.frag lines 422-434) Unfortunately, since I can't reproduce, I can't test if that's the cause of the artefacts. Emilian. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote: Ah, now I understand what Mathias is after: That would be ok if this would be optional in the sense that it does not impact what is there performance wise. But since this is all runtime configured by an uebershader with a lot of uniforms this is not the case. Any additional feature done in this way *does* impact everbody in several ways. Any additional uniform takes time to be set up in the driver. Any code that is in the shader and that cannot be optimized away at *link* time of the shader may take registers which affects the partitioning and the amount of paralell executed threads in the GPU. At least a notable amount of gpu's on the market can get register set limited at that point. This paragraph has nothing to do with what is actually happening. 1) The 'ubershader' for _models_ (model-combined-deferred.eff and ubershader.vert/frag) has not been introduced by myself but by Frederic Bouvier and Gijs de Rooy with major additions and revisions by Emilian Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader requires to insert generate tags into each model which uses normal maps. The shader is optional, i.e. it is not compiled if model shader quality is set to zero. It is configured by a lot of uniforms (really a lot more than I ever used for terrain). My own contribution with regard to this shader is just to change the light and fog functions, I did not otherwise alter its design. However, since there's lightmap, reflection map, normal map and dirt map, there are potentially 15 different combinations of dedicated shaders which are not configured by uniforms, it seems to me there may be a maintenance issue to consider and it makes sense to do it that way. I did not come up with the need to modify each model, that is a property of the original shader. Mathias, you picked the wrong audience. Just to set things straight, models don't need to be modified. The local effect inheriting from model-combined*.eff needs to have those, and this is a workaround to Flightgear not handling graciously untextured models fed to the binormal/tangent generator (by this I mean FlightGear simply segfaults). and this requirement has been in the associated documentation for a year and two full releases Regards, Emilian -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Thursday, January 17, 2013 13:16:03 Renk Thorsten wrote: I've recently come across the idea of using one generic sand or rock texture and selecting the particular hue desired by multiplying every pixel value with an (rgb) vector - so rather than two different-colored sands, we'd just store one texture and three numbers on disk (and potentially in GPU memory, although mostly regionalizing means they won't occur together usually) and save some space. I know materials.xml permits statements like diffuse r0.9/r g0.95/g b0.9/b a1.0/a /diffuse which seem to be going into that direction - do they actually do anything or are they obsolete - I tried to modify one and wasn't able to see that I had just set the red channel to zero, but maybe I made a mistake. At which point are these values supposed to appear in the shader - gl_Color, or gl_FrontMaterial.diffuse perhaps? Anyway, with a base texture created from six different overlays, we'd need the possibility of passing a rotation vector for every overlay texture separately to make this work. Technically it's easy to define the corresponding uniform vec3 in the effect files - but in practice this means about 18 more slots of uniforms used. Taken together with environment sensitivity of the shaders and the strategy to make an ubershader configurable from materials.xml rather than have a separate effect for every landclass, we might end up having 50+ uniforms being fed into a shader. I know an uniform is way cheaper than a varying since it doesn't need to be tracked per vertex/fragment but only per draw, but is there a definite number beyond we should be worrying? A color rotation strategy is not a must-have, having an additional 300kb file on disk for a separate texture file with colors rotated manually is not so bad a penalty, but it'd be nice if there is no problem. Does anyone know for sure? Thanks, * Thorsten That goes into gl_Color. I have found that gl_FrontMaterial.diffuse has issues on some ATI hw/driver combinations, in some cases. The uniform support varies wildly with gpu manufacturer/model/driver. (and some report the wrong number) For example here on an nvidia 8800GT with 313.09 linux driver I have: MAX_VERTEX_UNIFORM_COMPONENTS 4096 MAX_FRAGMENT_UNIFORM_COMPONENTS 2048 There are also quite a few built-in uniforms. Emilian -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
Also see here for uniforms: https://www.opengl.org/wiki/Uniform_(GLSL) -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D vision
On Friday, January 11, 2013 12:07:27 Renk Thorsten wrote: I was wondering if anyone has experience with the stereoscopic view modes of FG. Coming with my new laptop were very fancy NVidia IR synchronized LCD shutter glasses for 3D vision, and I've used them to have a look at some 3D movie clips, which was sort of impressive. Unfortunately, they don't seem to do anything for any of the 3D view modes of FG - all I see are for instance two images next to each other. Now, 3D movies appear the same before the glasses activate (which requires to press the 3d button under Windows (no idea if this would ever work under Linux) at which point the two movie image streams get time-shifted superimposed and the IR sync starts activating the glasses. However, pressing the 3D button when FG is running in any of the available view options does precisely nothing, the system does't seem to recognize that there's a 3d capable data stream and doesn't even attempt to fire up the glasses. I have no idea if this should in principle work and just requires to set some option somewhere, or if the 3D capabilities of FG are simply not designed for the hardware - does anyone have that mode running with similar hardware? There is an option configurable in the xorg.conf file, but this appears to work only on Quadro Cards (it might be simply a case of stale documentation). About a third of the page down here: http://uk.download.nvidia.com/XFree86/Linux-x86_64/310.19/README/xconfigoptions.html -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Removing landclass seams
On Thursday, January 10, 2013 08:03:39 Renk Thorsten wrote: Which reminds me - is there a performance penalty for using many uniforms? My impression is not, at least I've never seen any, but it'd be good to have this confirmed. Also, can be declare uniform vec 3 in the effect files, and if so, what is the syntax? . * Thorsten You could run out of uniforms on some gpu/driver configs, and those could be dropped silently and then you end up with undefined behaviour in the shader. For vec3 uniforms in effects syntax is like this: uniform-name type=vec3d 1.0 1.0 1.0 /uniform-name BTW: I've been discussing with the terragear guys something similar, with a texture encoding material info accompanying the btg, and being generated at scenery build time. This texture would use a secondary set of texture coordinates, relative to in-tile position, and would be read in the fragment shader, determining the actual texture patch(es) to be used from a texture-atlas(sheet), and amount of mixing. There are issues with relying on the interpolation in the vertex shaders, especialy with the irregular mesh model we have. You get long streaks along stretched triangles, making edges in the mesh visible, basicaly creating starred artifacts around the vertices, reading the info from a texture in the fragment insures this doesn't happen. Anyway this is only in the theoretical stage right now. Emilian -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata Commit c8a69dffd49a298e01c0e0e1320f4a1d49a0bca4
The DR400 Guide (Aircraft/DR400/DR400 Guide.pdf) commited in this has a non-GPL compatible license (All rights reserved). I think this situation needs to be fixed (either the guide removed, or a proper GPL version of the guide is pushed) I think it would be a good idea if contributors would check more thoroughly the licenses of third party material commited. Relevant links: https://gitorious.org/fg/fgdata/blobs/master/Aircraft/DR400/DR400 Guide.pdf http://flightgear.org/forums/viewtopic.php?f=4p=172822#p172818 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 19:37:37 James Turner wrote: On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? Right, I had exactly the same thought. Of course, if by some terrible mistake we aren't sharing textures, that would be a very big bug, but hopefully easy to fix! James Running under gdebugger would suggest textures are indeed shared across tiles, as I can't find any texture loaded twice. Emilian, -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote: On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote: Aw, that looks bad... I've never seen anything like, so my first guess would be that it's one of these NVIDIA vs. ATI issues (which are really tough to understand from my side with just NVIDIA cards available). For reference - I've seen it running fine on a GeForce 8600M and on a GeForce GTX 670M. No idea what Stuart runs. I'm also running NVidia (GT260M). This looks to me to be one of two things: - a straight driver bug (worth checking if your drivers are out of date) - (less likely) we're going beyond the number of textures your card supports for a specific fragment shader. BTW - I just came across this: http://developer.amd.com/tools/graphics-development/gpu-shaderanalyzer/ I've yet to download it, but it looks like it might be a very useful tool for those of us trying to improve shader performance. -Stuart Hi Stuart, I've used that. Unfortunately it won't help with compatibility issues, as the shaders compile fine with it in most cases, then they fail silently with the driver compiler... Thorsten, from discussion on irc, it seems you're assigning to a varying in the fragment shaders. See this log: http://dpaste.com/845317/ Most likely the other errors will go away once you fix that. Sometimes the nvidia compiler is too lax... HTH Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote: On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote: Aw, that looks bad... I've never seen anything like, so my first guess would be that it's one of these NVIDIA vs. ATI issues (which are really tough to understand from my side with just NVIDIA cards available). For reference - I've seen it running fine on a GeForce 8600M and on a GeForce GTX 670M. No idea what Stuart runs. I'm also running NVidia (GT260M). This looks to me to be one of two things: - a straight driver bug (worth checking if your drivers are out of date) - (less likely) we're going beyond the number of textures your card supports for a specific fragment shader. BTW - I just came across this: http://developer.amd.com/tools/graphics-development/gpu-shaderanalyzer/ I've yet to download it, but it looks like it might be a very useful tool for those of us trying to improve shader performance. -Stuart I'd rather use this one: http://www.gremedy.com/downloadLinux.php It has general OpenGL profiling features, but it also provides nice glsl compiler errors/warnings, with a lot of other useful things (inspection of various values the varyings/unifroms/attributes, textures, etc) (The warning/error handling is better than what the drivers do in any case) Also it has very little overhead for this use-case. Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 12:33:52 Renk Thorsten wrote: Thorsten, from discussion on irc, it seems you're assigning to a varying in the fragment shaders. See this log: http://dpaste.com/845317/ Most likely the other errors will go away once you fix that. Thanks, the log was very helpful - please pull and try again, at least the assignment to the varying should be fixed now. * Thorsten Hi, Those are fixed, but you still have some implicit casts/coversions in there, those are tolerated by the nvidia compiler but not by other drivers: http://dpaste.com/845842/ HTH Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 13:28:08 Renk Thorsten wrote: Those are fixed, but you still have some implicit casts/coversions in there, those are tolerated by the nvidia compiler but not by other drivers: http://dpaste.com/845842/ Aw, a forgotten decimal point - that's picky. Okay, how about now? * Thorsten Apparently that's ok now, another issue cropped up in the urban-lightfield shader, something wrong with an #if: FRAGMENT glCompileShader /home/chris/FlightGear/Shaders/urban-lightfield.frag FAILED FRAGMENT Shader /home/chris/FlightGear/Shaders/urban-lightfield.frag infolog: 0:196(22): preprocessor error: syntax error, unexpected IDENTIFIER, expecting NEWLINE 0:193(1): preprocessor error: Unterminated #if Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue collection
On Wednesday, November 28, 2012 08:17:56 Renk Thorsten wrote: Um... what should I do with this? I've gotten one comment pointing to a problem with the urban shader, but I can reproduce the same problem on a pristine master branch, so it's not related to the merge request. * Thorsten That was caused by your previous merge request, which was resolved without proper testing I guess. There's a bugreport about that http://code.google.com/p/flightgear-bugs/issues/detail?id=836 Which was marked as fixed, but obviously it isn't. -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Strange GPU behaviour
Hi, You might want to take a look here: http://ubuntuforums.org/showthread.php?s=92e1641ae03fc09b4a10e772e569987bt=1478192page=2 I'm not sure if the settings suggested there still work with current drivers, but it's a start. Cheers Emilian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Effects/shaders change (fgviewer related)
Hi Thorsten The atmospheric rendering scheme should not be affected by this change. All I did was to add /sim/rendering/shaders/quality-level to the techniques that had a single check on /sim/rendering/shaders/$shader. The atmospheric rendering related techniques, and the Rembrandt ones, have not been modified in any way. Emilian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Effects/shaders change (fgviewer related)
Hi all, I've pushed a change to the effect files that makes sure that shaders are disabled when /sim/rendering/shaders/quality-level is 0 or non existant. Previously this relied on gui.nas to set the individual shader levels to 0, and fgviewer had no easy way to disable them. This will change default behaviour for fgviewer, in that it will not load/display shaders by default anymore. To enable shaders preview run fgviewer like this (any non-zero number will do): fgviewer --prop /sim/rendering/shaders/quality-level 1 /path/to/object Cheers, Emilian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 06:43:32 Renk Thorsten wrote: Speaking of which - it'd be nice to have local north as well defined direction as well - that would allow for things like the snowline being higher on south slopes ... In the Northern hemisphere ;-) Quite so - but once you have a north-pointing vector, the rest is trivial because you can pass geographical location as uniform and use that to compute the magnitude and sign of the bias in a one-liner... * Thorsten vec3(1.0,0.0,0.0) seems to be a pretty good aproximation. In my tests dot(normal.xy, vec2(1.0,0.0)) worked good enough. (for N hemisphere) Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. -- 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_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 07:58:14 Renk Thorsten wrote: Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera altitude as uniform and computing absolute vertex altitude from camera altitude and the vertical difference. :-) The current point seemed to be that Mathias says we _should_ not rely on that even if we evidently can. * Thorsten Hint... I already knew that ;) -- 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_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 08:58:43 Renk Thorsten wrote: In any case, since the 'additional computations' are subtracting one number from another number, I can just about live with the performance degradation caused by the operation, given that it provides backwards compatibility to existing scenery. :-) * Thorsten And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance -- 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_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
On Thursday, October 18, 2012 09:31:27 Renk Thorsten wrote: And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance A uniform float doesn't have a matrix transform. I thought you'd know that. * Thorsten I'm talking about the ep ... which is done for each vertex, everytime -- 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_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] In-sim selection of materials.xml file - what to call DDS?
On Saturday, October 06, 2012 23:34:13 Stuart Buchanan wrote: Hi All, I've just added a trivial enhancement to the rendering options dialog to allow in-sim selection of the materials.xml file. This is limited to those available in the base package (regions, default, dds). I've used the phrases Global and Region-specific to describe the default/materials.xml and regions/materials.xml options, neither of which is particularly satisfactory. I'm also really struggling to think of an appropriate name for the dds/materials.xml variant. Has anyone got any suggestions that would help an end-user who has no really knowledge of the underlying materials.xml file, or what DDS is? Thanks, -Stuart While I have no idea how to name the dds selection, I have some some suggestions about the box. First I think the name is missleading, since the changes that come with a different materials file are not limited to just different textures. Maybe materials set or material definitions would be better? Second, could we devise a way to make localy customized materials appear among the options automagically? I know that simply listing the files under Materials/*/ is not going to work, since some of them are not complete definitions, so maybe a new tag in the materials file that marks it as a viable option, or some sort of naming scheme for the file (new folder under Materials/ with only the materials.xml in that folder being a viable option for the chooser?) Or something combined between these, a materials.xml and a display/ tag, that would contain the name to be shown in the selection box. ( then we could have something like this: Materials/myset/myurbanmat.xml Materials/myset/materials.xml with Materials/myset/materials.xml containing displayMy Custom Setdisplay/ that would show up in the box as My Custom Set ) Regards, Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Sunday, October 07, 2012 07:44:53 Renk Thorsten wrote: I've had a look at this in Scotland, where it is a bit too bright based on my own experience, so I'd like to leave this change so it only applies to South America. Obviously I could do the opposite and make some specific materials for Scotland (hmmm, good idea :) I wanted to have a look at Ireland regional definitions (islands are always easier since it's clear where the boundaries are, I know it from first-hand experience,...) at some point - let me know if you actually start for Scotland, because I guess there's plenty of overlap :-) On a related note, I've just added a new feature to the ufo: Ctrl+Alt+click displays the lat/lon/alt and landclass(es) of the clicked upon point. Nice - been using a customized button with a Nasal one-liner for the same purpose so far. Cheers, * Thorsten Hi Thorsten, Some quick finds: First I get this when opening the shader settings dialog: Nasal runtime error: non-objects have no members at $FG_ROOT/Nasal/props.nas, line 181 called from: __dlg:shaders-lightfield, line 32 and the slider is off to the right, and can't be of much use. Second, the fast(4) water lacks specularity, is this intended? Third, there are lawnmower/corn rows on the detail textures, I suspect these to come from texture fetching inside conditionals, but I might also be wrong. Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible in high detail terrain, (just staying put and rotating the view), and that stuttering at the 22-25 fps it outputs gives a much worse impression than a fluid constant 16 fps. I still think that doing heavy work in the vertex shader won't cut it, it might give *you* a fps boost in corner cases, but the way that scenery is going it will only make matters worse in the long run... (NV 8800gt here, in case that matters) Sorry for being the negative voice :) Cheers Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Sunday, October 07, 2012 11:28:24 Renk Thorsten wrote: First I get this when opening the shader settings dialog: Nasal runtime error: non-objects have no members at $FG_ROOT/Nasal/props.nas, line 181 called from: __dlg:shaders-lightfield, line 32 and the slider is off to the right, and can't be of much use. Assuming that this is the shader GUI dialog, I have no memory of touching it and the merge request did not include any changes to the dialog - this must be some other problem (?) Second, the fast(4) water lacks specularity, is this intended? Hm, could this be a dds problem again - the typical symptom is lack of specularity? I thought I had understood how the dds nature is communicated, but I might have messed this up. I see specular reflection with the shader. Third, there are lawnmower/corn rows on the detail textures, I suspect these to come from texture fetching inside conditionals, but I might also be wrong. No, that's just plain old tiling of textures. One would have to optimize the detail overlay textures further to get completely rid of it, but I'm not really good in texture creation. I suspect some of your dds material would be rather good overlay textures, as they're very homogeneous and low tiling, just what one needs for the detail overlay. Texture fetching inside uniform int conditionals can't give you artefacts in a scene as far as I know. Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible in high detail terrain, (just staying put and rotating the view), Would this be the stuttering that according to Vivian is Nasal related, of which I claimed all along that it's caused by the shader? :-) I still think that doing heavy work in the vertex shader won't cut it, it might give *you* a fps boost in corner cases, but the way that scenery is going it will only make matters worse in the long run... I have no clue about the way scenery is going. I think the optimal solution would be LOD levels on disk, so we have low vertex resolution at the horizon and relatively high vertex resolution nearby. You can try to shuffle more work to the fragment shader, but personally I'm not fond of flying with 5 fps, so I'm not going to do it (yes, I actually tried it...). It doesn't give me a boost in some corner cases, it makes the difference between unflyable 5 fps and usable 15 fps. I never intended the procedural texturing for use in custom scenery and I don't use it in custom scenery. All the newer aditions are optional - if they don't perform acceptable on you rmachine, then don't use them or use the bare atmospheric scattering scheme which hasn't changed, or switch trees off (they're pretty expensive for me). I'm frankly tired of 'This needs to be faster/smoother'. No, it doesn't. I'm not forcing anyone to use it, I put a lot of effort into cooking up ways to make it run faster, I don't work on things outside the rendering pipeline which determine smoothness, I'm bitching all the time about things like the instument panel should obscure terrain here on this list which I can't do myself, and the result is optimized as I can make it. I'm not the miracle man, sorry. It's simply not productive to point out that you'd like to have it faster and smoother - we all do, it's an open secret. * Thorsten Understood... I will refrain from any further tests/opinions on this topic then. Please accept my apologies, and disregard any of the issues I've raised. Everything's working smooth, and looks better than IRL... it's just my imagination playing tricks, better get my eyes checked Cheers, Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
On Thursday, October 04, 2012 06:42:30 Renk Thorsten wrote: You know that rendering a transparent object twice alter its transparency. Of course, you can avoid to render it in the color buffer using write mask in one pass. What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to set the z-buffer and discard all transparent pixels in the first pass, then render the rest in detail with lequal comparison later. The first pass has just one texture lookup in the fragment shader, but what this saves is rendering the terrain pixels (and other trees) covered by the tree, and the terrain has a lot of complicated light and fog equations to solve, as well as up to four texture lookups and lots of noise generation. To trade that against an additional pass for trees which is essentially trivial turns out to be a really good deal. Of course, here's the part I don't know: All this makes perfect sense as long as the fragment shader is the bottleneck. But the first tree pass also needs the geometry computations in the vertex shader, and in an environment where the vertex shader is the bottleneck, it would make matters actually worse. So, the framerate gain for me personally left aside - what should I do with such things? Commit them and hope a majority will benefit? Not commit them? Make them optional and create a complicated rendering dialog? Test them and gather feedback? The idea with clouds is still to slip rectangles in which cover most of the opaque core of a cloud, render them into the z-buffer early on while passing through the normal clouds through vertex shading and discarding them in the fragment shader, and then render the rest of the clouds and the terrain with lequal comparison onto that depth buffer. I don't know if it actually works, but at least I'm pretty sure I understand now what is expensive about cloud rendering - funnily enough, it's fogging them. In a layer looking forward, we can have hundreds of cloud sheets overlapping all drawn from outside in, and so the fogging means we compute hundreds of exponential functions for every pixel... Depth buffering should definitely help here. * Thorsten Hi, Take a look here http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide_G80.pdf pages 43, 44. They deal with cases where the culling optimizations might be disabled/underperforming. Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound and HSI problems with Lightning
On Monday, October 01, 2012 19:16:09 Alan Teeder wrote: James I have just run a very quick check on a few aircraft. My apologies, but I should have used the word opaque and not translucent. F22 (jsbsim) has an opaque HUD, Mirage F1 has an opaque cockpit. They are both transparent when Rembrandt is disabled. The Saab Draken seems to have no cockpit. This is with or without Rembrandt enabled. Concorde crashes Flightgear at start-up. Again this is not affected by Rembrandt. As a general comment I find that the flying characteristics of most of the aircraft that I flipped through seem very unrealistic. They seem to be optimised for ease of use by non-pilots. This makes Flightgear appear to be a toy, or game, when it is capable of being an accurate flight simulator. IMHO this is a great pity. There are exceptions - e.g. the default Cessna 172, so it can be done. How can we encourage developers to pay as much attention to aerodynamics as they do to eye candy? Alan Hi Alan, Most aircraft need to be ported for Rembrandt. The amount of porting necesary is in most cases proportional with the complexity of the eyecandy used before by said aircraft. For some is as simple as assigning an effect for transparent surfaces, for others it might require more involved work (might even require remodelling of some parts). That said, there are quite a few aircraft that have been ported. By the symptoms you describe it's most likely the f22 the Mirage and the Draken weren't ported yet. However I'm concerned with the Concorde errors, since I've adapted that one to Rembrandt, and it uses the same effects/shaders as the C172p. Regards, Emilian -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Announce: Changed behaviour of model-combined and model-combined-deferred effects under Rembrandt
Hi, I've just pushed a change to fgdata that modifies the model-combined and model- combined-deferred effects when running under Rembrandt. This was done in order to be able to provide the same effects that are available for transparent surfaces in the clasical pipeline for transparent surfaces when running Rembrandt. Those that want to enable reflection/bump effects for transparent surfaces under Rembrandt just need to create a local effect that inherits from Effects/model- combined, and add at least the transparency include that can be found in the the Docs/model-combined.eff/model-combined-transparent.eff template. (this is needed for proper z-sorting of transparent/opaque surfaces in the classic renderer). If they want normalmap support too, then they need to add the normalmap- include that can be found in the same Docs/model-combined.eff/model-combined- transparent.eff template. This change breaks current local effects that inherit from Effects/model-combined-deferred, due to a needed change of technique numbers. Thus, the local effects that inherit from Effects/model-combined-deferred and use normalmaps need the folowing change in order to restore them to a working state: change technique n=8 to: technique n=7 Local effects inheriting from Effects/model-combined used on transparent surfaces do not need any adaptation. Local effects inheriting from Effects/model-combined used on opaque surfaces need to be switched to inherit from Effects/model-combined-deferred, and modified according to the above recomandation if they use normalmaps. Regards, and sorry for the minor(I hope) nuisance this change is causing. Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: Changed behaviour of model-combined and model-combined-deferred effects under Rembrandt
Hi, Another change, hopefuly after this things will be clearer. With previous change I forgot the case of the model shader being disabled, thus transparent surfaces would lose transparency and be rendered wrong. I've commited a new effect, Effects/model-combined-transparent, which should be used for transparent objects. From now on Effects/model-combined should not be inherited directly in local effects. use either Effects/model-combined-deferred (for opaque objects), or Effects/model-combined-transparent (for transparent objects). If you have local effects for transparent objects, please update them to use Effects/model-combined-transparent. (they will continue to look right unless you move the model slider in the shaders dialog to the extreme left, so it might not be readily noticeable they are broken) Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water reflection needs fix
On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote: Just stumbled across this one: Effects/water.eff now declares png textures for reflection and nose to avoid dds. The relevant commit changed the effect file and water_sine.frag but didn't change the corresponding lines in water_lightfield.frag which has pretty identical normal-generating lines. dds seems to require to reverse normals (?) - in any case two lines marked by 'dds fix' need to be removed in order to restore the expected behaviour. vNorm = -vNorm; //dds fix (...) N = -N; //dds fix If anyone with GIT rights could take care of the change in devel and release branch? Thanks! * Thorsten Are you sure you're using/looking at the correct fgdata? Looking at the files here they use the proper uniform to determine if the normalmap is dds, and reverse the normals only in that case: water-lightfield.frag line 321: if (normalmap_dds 0) vNorm = -vNorm; //dds fix line 369: if (normalmap_dds 0) N = -N; //dds fix normalmap_dds is set to 1 only by water-dds.eff. It's set to 0 in water.eff, and used by the lightfield technique properly. regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water reflection needs fix
On Friday, August 03, 2012 15:43:45 Emilian Huminiuc wrote: On Friday, August 03, 2012 12:29:51 Renk Thorsten wrote: Just stumbled across this one: Effects/water.eff now declares png textures for reflection and nose to avoid dds. The relevant commit changed the effect file and water_sine.frag but didn't change the corresponding lines in water_lightfield.frag which has pretty identical normal-generating lines. dds seems to require to reverse normals (?) - in any case two lines marked by 'dds fix' need to be removed in order to restore the expected behaviour. vNorm = -vNorm; //dds fix (...) N = -N; //dds fix If anyone with GIT rights could take care of the change in devel and release branch? Thanks! * Thorsten Are you sure you're using/looking at the correct fgdata? Looking at the files here they use the proper uniform to determine if the normalmap is dds, and reverse the normals only in that case: water-lightfield.frag line 321: if (normalmap_dds 0) vNorm = -vNorm; //dds fix line 369: if (normalmap_dds 0) N = -N; //dds fix normalmap_dds is set to 1 only by water-dds.eff. It's set to 0 in water.eff, and used by the lightfield technique properly. regards, Emilian Also the shaders work/look properly when enabled. At least in fgdata master regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master, updated. f81456998442b1f30d86c4925a7d000d46ea4f1f
On Monday 30 July 2012 16:29:28 Curtis Olson wrote: I am in no way picking on any single committer here. This just happens to be the most recent commit message that came through while I was thinking about this (sorry Gijs, we do really love you. I'm mean, not really really really love, but well you know how I always say one sentence too many and paint myself into a corner I can't get out of.) :-) I sense that there have been a substantial number of updates to individual aircraft that are only going into the master branch and aren't getting cherry picked into the 2.8.0 release branch. Perhaps this is intentional or I'm misunderstanding something, but I wanted to at least ask. When I create the downloadable aircraft .zip files for the 2.8.0 release, it will be from the release/2.8.0 branch, but most of the aircraft changes that have been made since the 2.8.0 branch was created are not going in there, and are only going into master. Thanks, Curt. Hi Curt, I've already cherry-picked that commit to release/2.8.0. My impression is some of the contributors have some dificulties/issues with this part of the git workflow and they'd rather not risk messing up the release branch. Maybe we should setup some sort of system (bug category?) for this, so that we're made aware of fixes to aircraft already present in the release branch that should be cherry-picked there. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
On Saturday 14 July 2012 06:22:06 Renk Thorsten wrote: In case we want to remove those, the corresponding *.ac files have to be changed. Is there an opinion on that question either way? * Thorsten This should be fixed too, as of now, in GIT. Hopefuly, warning messages (if left enabled) should appear only when specificaly using Materials/dds/materials.xml Regards Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim static friction?
On Thursday 05 July 2012 15:21:24 Viktor Radnai wrote: 1. When the aircraft is parked with no parking brake, it will usually start to roll slowly backwards -- pushed by the wind and maybe the runway slope. If I start the engine on idle, the thrust generated by the idle prop might stop this roll. On tarmac, even a 3 knot wind is enough to start pushing the plane back. On grass more is needed -- maybe 20 knots? Hi, In that case, even in real life, there's no other friction at play than the friction inside the wheel bearings, friction which is very low, almost ignorable. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nvidia 8800GT for the taking
On Saturday 30 June 2012 10:44:46 James Turner wrote: I happen to have a spare 8800GT (512MB, 64k rom - NOT suitable for Mac use) First person to say they want it for something useful gets it. Ideally you'd PayPal me the price of posting it to wherever you are in the world. If something useful includes making shaders work better on 'slightly-older' hardware, I'll pay the postage myself! James I'll take it. (it's better than my 8600gt). And as you know I'm messing with shaders too. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
On Friday 29 June 2012 12:13:31 Edheldil wrote: On 06/28/2012 05:31 PM, Heiko Schulz wrote: I have no idea how to communicate it or present it. That's why I hoped that we maybe can have all three skydome variants selectable. So we would have the default skydome, the skydome shader and the Lightfield/Haze aka Atmospheric shader selectable. That would have made it easily to present different developement stages and performance requirements to the user. Maybe a less strict approach would be a solution, then? Let selecting a rendering mode set some sane combination of shaders and give user freedom to change them, but display red warning in the shader dialog that the combination may create problems. Edheldil That's not an option. There is no independent skydome shader anymore. This whole confusion is generated by it being left enabled in 2.6. It shouldn't have been, and we should not perpetuate that mistake. There's only the default sky that works together with the normal shaders , or the Atmospheric scattering stuff which supersedes the old skydome shader. The Atmospheric scattering is a whole set of shaders, that interact to give a seamless horizon, and much more... They replace all other shaders when enabled, that's hardcoded in the effects, and it needs to be otherways it wouldn't work. So you'd end up with a dialog full of sliders that do nothing... There is a red warning in the dialog, anouncing to users that by enabling the Atmosperic stuff will lead to much of the shaders being replaced. (Of course on top of this there's Rembrandt, with its own set of shaders and issues.) Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
On Wednesday 27 June 2012 16:37:11 Heiko Schulz wrote: Is there a way we can have all three possibilities (default, skydome shader, Thorstens atmospheric light scattering) selectable? Cheers Heiko Not quite, since both terrain-default and model-default effects have a separate set of shaders which gets enabled by that switch, and overrides all other shaders (they are defined in a lower numbered technique, and thus take precedence over any technique defined in effects derived from those two) The dialog options reflect the actual behaviour of the effects. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
On Wednesday 27 June 2012 18:39:30 Heiko Schulz wrote: Hello all, I think the problem now is that the nice scatter effect sky dome no longer works correctly with any render mode in the git version. The scatter effect sky dome will give you very pretty skies -- especially in combination with advanced rendering, just don't look at the terrain or your own aircraft model because those are now rendered incorrectly with many missing effects. With disabling the predicate section I got a middle thing between (no FGFS Default Skydome). Sky scattering with pretty skies and fog in near distance and all other shaders working, but bad horizon at far distance and other features like terrain haze missing. Thorsten's Athmosphere effect enabled: http://www.hoerbird.net/fgfs-screen-764.jpg Not enabled, but with disabled predicate section: http://www.hoerbird.net/fgfs-screen-763.jpg http://www.hoerbird.net/fgfs-screen-768.jpg Surely there is now way? Cheers Heiko Hi Heiko, Unless the same fogging technique is used you'll see the tile edges in very low/ very high visibility conditions, or from high altitudes, or some other artefacts. Allowing a decoupling between the Skydome and the ligthfield/haze shaders, would lead only to inconsistent settings, and useless bug reports from users blindingly enabling every switch available to them. The current effect scheme and the corresponding dialog options tries to prevent this, and tries to use a consistent set of shaders. This is extended to the options available when Rembrandt is enabled too (i.e. it doesn't allow you to enabe the light scattering shaders when Rembrandt is active since those aren't ported, and don't display right, or any other shader that isn't ported yet). This doesn't work quite right yet, as others have mentioned here, but Gijs is aware of that. I hope you can now better understand the reasoning behind this. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
On Wednesday 13 June 2012 12:05:42 Renk Thorsten wrote: Now, random vegetation seems to increase vertex count a lot, and this may well be not doable by just taking the code and applying it to the vegetation (it didn't work with clouds either). So it probably needs a dedicated approximation scheme making use of the fact that vegetation is drawn relatively close to the position and not 100 km distant to run at all. Given my framerate when switching on lightfields and random vegetation without lightfield shading, I'm not too optimistic :-( But worth a try. * Thorsten There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as: float fragmentDepth = gl_ProjectionMatrix[3].z/(gl_FragCoord.z * -2.0 + 1.0 - gl_ProjectionMatrix[2].z); (Currently, if taking depth info in the vertex shader for the trees, you need to do some ugly hacks to get the right depth, hacks that fail to work most of the times. ) As for performance concerns, yes, fragment operations might be slower than vertex ones for the same complex task, but they are generaly done on a limited amount of fragments that varies only with camera position/orientation and isn't adversely affected by high vertex count scenes. And the trend is for vertex count increase. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A plan for a 3.0 release?
On Tuesday 19 June 2012 12:29:34 Renk Thorsten wrote: There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light - that's the part which doesn't go easily into the fragment shader. Maybe we have enough varying to pass all raw vectors involved right through the vertex shader - then everything can be done in the fragment part? The problem might also be that similar to clouds, tree textures are transparent in places, and so the fragment part may be slower than expected (for clouds, moving too much into the fragment shader gets very slow for that reason). Thanks for the suggestion in any case - plenty of things need to be tried... * Thorsten Just look in the tree shader, there's a line there dropping the fragment if it hits the transparent part, so no there won't be any penalty incurred for the transparent bits in the trees. You can have the position, properly interpolated, in the fragment shader. You already have it in most shaders. And if you don't you just replace the current varying holding the result of your work in the vertex shader with a varying passing the position/ecPosition depending on what you need. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reflectmap
On Monday 11 June 2012 07:25:44 syd adams wrote: hi all. I updated the Citation-II to use model-combined-deferred , but it originally used reflect.eff.Try as i might i cant seem to get the reflectmap section to work.Is this a bug? Ive tried greymaps and alpha maps but see no effect . I get a constant environment reflection over all. Syd Hi Syd, Could you post the local effect that's using model-combinedd-deferred? reflect.eff and model-combined-deferred have different texture slots for the reflect map, also the prameter names are changed. (reflect uses texture n=8 model-combined-deferred uses texture n=4) regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Two issues: Shader control and turbulence
On Friday 08 June 2012 09:53:58 Renk Thorsten wrote: tie to some yet unknown master switch? Who has a plan? * Thorsten There's no master switch anymore. There's a property that's checked by some nasal to set the quality of the shaders, but there's no master switch available for effects. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 10:23:12 Renk Thorsten wrote: Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. We might be generating too many buildings then? The greater Los Angeles area has between 13 and 16 million inhabitants (dependent on what you count). Assuming you haven't changed the visibility range from the startup default of ~16 km yet, checking with satellite images you should get about 1/12 of the greater LA urban area at startup, that means you generate 340k * 12 = 4 M houses in the greater LA area. The average number of people per household in the LA area was about 2.9 in 2006, so we have just populated Greater LA with ~12 million inhabitants - seems okay. Besides being totally off topic, you can't do that direct comparison. First off, our default scenery lacks a lot of detail in the urban area boundaries in that area thus marking a far larger area as being urban - a far larger area on which to generate buildings; second, the generated random buildings are a mixed set of residential and comercial/office buildings, so the math is a bit off there. Here's the catch: That's just assuming that the number of households per house is really 1 - but I think this assumption doesn't hold in dense urban areas, you can easily have 10 parties living in a larger building (even while I was living in Durham, NC we had 14 households in one building - and Durham NC had plenty of space to spare). Assuming for the sake of the argument that we might have on average 5 households per building in a dense urban area, we'd be overestimating the actual population by a factor 4.5. = use less, but somewhat larger buildings. Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. Cheers, * Thorsten Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 12:10:16 Stuart Buchanan wrote: Actualy the Geater LA + Inland Empire area should use more somewhat small buildings, as the overwhelming majority of the residential buildings in that area are individual houses, all the way E to San Bernardino. So, are these areas defined as Urban, or Suburban/Town in our global scenery? -Stuart Just by looking at how the terrain is textured in FG, I can say they are defined as Urban. Emilian. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 14:16:02 Emilian Huminiuc wrote: So, are these areas defined as Urban, or Suburban/Town in our global scenery? -Stuart Just by looking at how the terrain is textured in FG, I can say they are defined as Urban. And the mapserver seems to agree with that assumption: http://mapserver.flightgear.org/map/?lon=-118.18562lat=33.91857zoom=11layers=0B00TFFFTFFFTFFF Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 11:20:28 Renk Thorsten wrote: We're not talking a regionalized building placement concept here... we're doing an order of magnitude case study for our average US-themed city. * Thorsten No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used to do the math to compare with reality. Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
On Wednesday 23 May 2012 12:05:05 Renk Thorsten wrote: No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used to do the math to compare with reality. A more constructive argument would have been to present your own counter-estimate, rather than calling all irrelevant... I think it's actually interesting that we can do such order of magnitude consistency checks. * Thorsten Keeping your initial assumption of default visibility, you'd get at least 6 tiles loaded, that makes for ~600 sq miles, wich is ~1/8 of the LA Metropolitan Statistical area, 8*340k ~ 2.7 million buildings for a population of ~12.8 million, that gives about 4.75 persons / building. Assuming 1/3 of the buildings are actualy represented as commercial/office that gets us to ~7persons/building or around 2households/building, which would be about right if it were residential, but is of course wrong for the apartment buildings; that is not the algorithm that's at fault, that's the underlying representation of the terrain (which should have just the core of the bigger cities in the area mapped as urban, and te rest as residential/town) Disclaimer: All this ignores the fact that Stuart was actualy using the live weather hence we don't actualy know the visibility/ number of tiles loaded, that we don't know which way he was facing, the fact that in reality just 1/6 of the surface loaded at startup is dense urban area, while the rest is residential, and wide spaced commercial/business area, etc. Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random buildings improvements - phase 2
On Saturday 12 May 2012 21:49:46 Stuart Buchanan wrote: Unfortunately, it appears to no longer work when the lightfield shader is enabled - the buildings all lose their textures. I've had a look at the hierarchy of effects files, but can't see any obvious problem. Do you have any idea what might be going wrong? -Stuart I've pushed a fix for this one. Emilian-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] model-combined-shader
On Friday 11 May 2012 22:19:43 syd adams wrote: Hi guys, Is it just me or has the model-combined shader stopped reflecting ? Moving the model slider seems to have no effect now . Syd Hi Syd, Any specific aircraft you're refering to? I've just tested it and it works. (777-200ER and IAR80) Cheers, Emilian-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Thus if runway inherits from terrain the actual runway effect as seen by flightgear gets a technique 4 of its own (inherited from the terrain effect). So when the skydome shader is active, it's the technique 4 in this runway effect that is active, which then uses the textures specified in the runway effect, as it's supposed to. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 07:55:19 Renk Thorsten wrote: No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy? Or what is the use of the current setup in which higher techniques overwrite lower techniques? * Thorsten Every other effect written so far. Better explanation: Think of the parent and the child effect as two property trees. At runtime they get merged, with any paths in the child effect overwriting the same paths in the parent, all under the heading of the child effect. The lower techniques override higher techniques. The functionality is to enable you to use different options in specific conditions that are present in the predicate section of each technique. As you are using them in the terrain effect. It's not the effects that change at runtime between those specific conditions, it's a different technique of the same effect that's used. The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Say you have shaders active, the default effect has a technique that specifies some default shaders to be used. Now you make your own effect, but you want to use different shaders in the same situation; in that case you add a lower numbered technique in your new effect, that by the order of precedence (lower numbers before higher numbers) trumps the technique used in the default, and this new technique specifies the different set of shaders that you want. By putting the sky-dome technique in a low enough place, you ensure that your new technique will not be overwritten and will be lower placed than any other in the child effects' trees, ensuring that those shaders are activated when the sky-dome is active, and that they take precedence over less strict conditions that would activate some other set of shaders/options in one of the other effects. Keep in mind though, that they will then use the merged parameters as they're specified in the child effect (this includes textures). Important note: the *texture n=x* numbers in the parameters section can be as high as you need them, but the *texture-unitunity/unit* numbers in the technique section should be kept =7 as those are the actual texture units as seen by the shader, and some impplementations oanly have 8 texture units available. *y* and *x* don't have to match. In fact you can get very creative and have 3 different *texture n=x1*, *texture n=x2*, *texture n=x3* in the parameters section that are assigned to the same *unity/unit*, each in a different technique, according to different predicates. Regards, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 10:53:31 Frederic Bouvier wrote: On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers Regards, -Fred I would say it's intended and it's very powerful. We only need to be careful with technique numbers. Take a look at how I worked around the binormal/tangent generator crashing for objects that are not textured in the model-combined effect: by enabling the generator for that technique only in child effects that are supposedly applied *only* to textured objects. All these with only a couple of xml entries, and not requiring a different complete effect. (Ref: Docs/model-combined.eff/)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
On Wednesday 02 May 2012 09:07:57 Renk Thorsten wrote: So far we had: start with skydome shader on and landmass set to 4: - models appear black and are not shaded properly Click on landmass slider without changing the value: - modelss jump to proper shading I've made one more observation: Do the above at noon. Then change to dawn - models remain stuck with bright daylight shading It seems to be a problem in passing parameters to the shader, apparently at least some of the parameters aren't updated by frame but only when specifically triggered. As to the underlying cause, I remain in the dark though... * Thorsten Using tied properties as uniforms? http://code.google.com/p/flightgear-bugs/issues/detail?id=445-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
On Wednesday 02 May 2012 12:13:23 Emilian Huminiuc wrote: Using tied properties as uniforms? http://code.google.com/p/flightgear-bugs/issues/detail?id=445 This is easily solvable using a property-filter (check Environment/metarinterpolator.xml), that writes the properties to some other place, in which case they get untied and are passed properly to the shader. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
On Wednesday 02 May 2012 09:18:15 Renk Thorsten wrote: Using tied properties as uniforms? I don't think so, because the same parameters do get updated per frame just fine when shading the terrain. * Thorsten Hmm, that would be really strange, and a legitimate bug then. Worth a try with the property filter to see if that fixes them. Emilian-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. Adding the correct entry fixes it here: uniform nameterminator/name typefloat/type valueuseterminator/use/value /uniform -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
What I think happens, is that, without the detail option on, the same shaders are used for terrain and models (terrain-haze), thus they get the terminator assigned from the teerain-default.eff. Once you enable the detailed shading for the terrain, that uniform is no longer assigned, since in terrain-haze there's another technique active, assigning the property to the terminator uniform in the terrain-haze-detailed shader, thus the terminator value seen by the terrain-haze shader active on models remains at the last value it had. This would explain why the lighting gets fixed momentarily when you move the landmass slider back and forth. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 'Black model problem'
On Wednesday 02 May 2012 10:08:07 Renk Thorsten wrote: Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. I'll be buggered... you're right. How embarrassing... * Thorsten I'll push a hot-fix then. Emilian-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote: Fred, One small question, what's with the multiple passes/ shader overrides and al sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It looks like a real mess. I wanted to clear out the unneeded include_fog.vert that crept back in somehow and found that... Or is this an artefact of a messy git merge? Could you please check, or explain? Cheers, Emilian Nevermind, checked the git history, it's itended to be that way since a while ago :) Sorry for the noise Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Tuesday 01 May 2012 12:19:27 Renk Thorsten wrote: Question to Fred (and other Effect people) - is this a bug or am I misusing the system? What happens is as follows: * the code finds a runway and looks first through terrain-default.eff to see what it should do. It finds, if skydome shader is on and landmass is above 4, a technique 4 telling it to render the runway with terrain-haze-detailed.* * in that technique, it gets the advice to use texture unit 6 for snow * however, parsing further, the code finds an effect with a higher technique declared for runway as well (the rain reflection). In spite of this being not executed because a technique with a lower number is used, this overwrites the texture associated with texture unit 6. * as a result, rainbows instead of snow appear In my naive opinion, that looks a bit like a bug, because a technique with a larger number which isn't used shouldn't be parsed or be able to set textures for what actually is used. But maybe I misunderstand how the system is intended to work. The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. HTH, Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Tuesday 01 May 2012 15:33:36 Emilian Huminiuc wrote: The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. HTH, Emilian Forgot to mention the fact that runways have the runway effect applied to them from materials.xml, hence they obey that one and not terrain-default. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Friday 27 April 2012 06:50:22 Renk Thorsten wrote: Thank you for the info - that's good to know (although admittedly I have to do some reading trying to understand what 'that' precisely is - the linked article is a bit opaque for me). Seems there's a lot to learn about the hidden secrets of GLSL... Since this doesn't look like a crippling issue (it seems to work on my card just fine, it potentially affects only higher detail settings,...) I would like to take the time and understand what is going on before making any changes. The reason is that things end up in conditionals usually because I tested them to have better performance, so just pulling them out would degrade performance again. The article seems to suggest a different syntax to do conditional texture lookup inside an if clause, so I would like to look into that and compare performance in some benchmarks. I would also be intersted if anyone is actually seeing any texturing artefacts (should be mainly the snow effect) caused by the issue, so that I can see if I implemented a fix correctly, because on my system it's running fine as it is. Thanks, * Thorsten Found the original article describing the issue http://www.opengl.org/img/uploads/pipeline/pipeline_001.pdf page 3, New Texture Functions with Awkward Names to Avoid Ugly Artifacts The new functions require the extensions present, and a port of the shader to glsl 1.40. And even then they may or may not be properly supported by different cards. So the simple solution is to pull them out of the conditional. I have hit this with the transition shader, it worked fine on different cards, but it blew up the mipmap lookup on a card similar to mine: http://flightgear.org/forums/viewtopic.php?f=5t=13513hilit=dds+textures#p136566 check the cornrows in the distance on the forest areas. The usage of custom miplevels made it more obvious and easy to spot, but the effects of these can range from a small discontinuity in the features to the shader eroring on some other implementations. Regards Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
On Thursday 26 April 2012 12:20:36 Renk Thorsten wrote: I've just created a merge request containing the recent work I've done for the haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...). The procedure described in the wiki to create a merge request did not work for me, I could not push a local branch containing my changes to remote, it just pushed master to master, but I don't want to make any commits to my local master branch. Hooray helped me find the command to create a remote branch containing my changes, so I used that for the merge request. Maybe someone who knows these things properly can have a look at the wiki? (Also, please don't kill me if there's something wrong - I'm trying to learn how to do this). Thanks, * Thorsten One short comment on the shaders, texture lookups inside branches gives undefined results, so any texture2D() call should be pulled outside the branches. (http://hacksoflife.blogspot.com/2011/01/derivatives-ii-conditional- texture.html)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
On Sunday 22 April 2012 11:02:46 Renk Thorsten wrote: After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not working than thanks for things working, and all in all I perfer a pleasant atmosphere on the mailing list, and critique of someone's code tends to lead to the opposite. But then, we had a performance discussion, and I had my share of criticism about my use of Nasal slowing things down, and in the end it's information which is better transmitted than not. Let me nevertheless start off by thanking all the people who worked on the shader codes I've been looking at - I learned a lot about how this is done and what can be done by just taking things apart and putting it back together again, I have often enjoyed the effects before starting to mess with shaders myself, and I guess many others also do. I've been over the water sine wave shader again, seeing if I could make run it faster. What I found reminded me of something I (mean-spirited as I am) did to a PhD student starting to work for me. I asked him to write a code evaluating a quantum mechanical scattering process. He did so using an established general-purpose Monte Carlo integral solver. I wrote a code for the same problem, we compared the results and they were the same, so we did solve the same problem and had the same solution - just my code was 100 times faster. Afterwards, he was ready to accept that he can learn from me how to code physics properly. That miracle was accomplished by me telling the integral solver where performance is needed and where not (technically, this involves using an a priori suitably biased sampling distribution, which after the fact gets corrected by conditional probability calculus - which can be proven to work, but looks like black magic). To give a very simple simple example, if we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good strategy to spend an hour to calculate a billion digits of pi. It requires to understand the problem and not use all-purpose, but specially designed problem-solving strategies. The same accuracy statement is true of the shaders by the way - so far all I have seen use the Blinn–Phong shading model, so it's completely useless to aim for an accuracy beyond what that can deliver, because Blinn-Phong is already an approximation which limits the precision that can be achieved. Now, it struck me that the water shader computes wave patterns and foam on a meter-scale. It does so even for a pixel which is 120 km distant (and which probably represents an area of 100x400 m or so). We first calculate a very detailed wave pattern and foam for that pixel, then let the renderer average everything out again to give the pixel a color. That didn't strike me as a particularly efficient way to do things. I replaced the wave pattern in the distance by something that averages to the same thing. That's not the average wave pattern (=a flat surface) because reflected light intensity is a non-linear function of the surface distortion, but noise with the right amplitude, leading to the same standard deviation and the same average, gets the job done. I also asked not to compute any foam beyond some other distance. As a result, the shader performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at 30.000 ft looking at the horizon, 120 km visibility range). In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective. So in terms of performance, simplifying the rendering of distant objects counts a lot. I have spent 30 minutes testing the visual impression of my changes in different winds, in different light and from different altitudes, and I could not spot any problem - the shader just ran faster. Despite this, it's possible that there is a problematic situation somewhere. But the answer to this should not be to revert the changes, the proper answer should be to code an exception dealing with the particular problem. I did not get the impression that there was so far any attempt made to optimize the performance of the water sine shader. It's difficult to compare directly since I added the whole terrain haze and lightfield rendering, but I suspect that if all I did (remove redundant operations, throw per-frame constant computations out of the shader, do not use textures to sample constant colors, do not interpolate the normal of water,
Re: [Flightgear-devel] Shader - Environment interfacing issues
On Friday 13 April 2012 07:05:40 Renk Thorsten wrote: I know that Vivian and Emilian had the plan to separate fog and light computations from the shaders and have them in general functions to be called by all shaders. While this is very elegant and maintenance friendly, I've come across a few issues in converting the water shader which aren't really trivial for that approach: 1) The water shader doesn't actually use the full amount of light information, it just uses the diffuse channel and assigns that rgb value to both ambient and specular light while diffuse scattering isn't computed at all. A general light function returning ambient, diffuse and specular would waste ~2/3 of its computation time here. See below*. 2) The precise implementation matters a lot - calling the light where it is used (in the fragment shader) is significantly slower than calling it in the vertex shader (water vertices are sparse...) and passing it as a varying vec3 to the fragment shader. So, if one generalizes light, one has to do it in such a way that diffuse, specular and ambient are separate functions and implement it in a clever way. But then Not when the varying number is limited. So you gain a bit of speed, but you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) 3) Light and fog lighting computations share a lot of stuff - the whole relative geometry between eye, sun and vertex altitude determining the light at low sun has to be solved once in a dedicated do-it-all shader. If the light function is generalized, somehow lots of vectors and parameters have to be either passed or re-computed, which presumably slows things down (I'm not sure how a general include framework would look like and whether parameters would need to be passed inside the function call or as varying from the vertex shader...) No it doesn't, it's not a separate shader, it's a separate function in the same shader (think of it as equivalent the #include system). At compile time the two files are concatenated resulting in a single shader. I've also looked at the environment interface of the water shader and changed it drastically in the lightfield version. In my view, determining the cloud coverage on a per-fragment basis by passing 5 uniforms into the shader and evaluating them in the fragment shader is bad design. Things which are constants in the whole scene per frame need to be determined outside the shader and passed as a single uniform. Doing so gains me ~20% more performance in my test case. (*)No it's not bad design, it's a conscious hack around the state that the environment interface was in when the shader was developed. And it's an attempt to make it work with both sytems. IIRC there was a request posted on this same ML at that time that the environment properties be extended, and unified between weather models, but there was no action take on that. So Vivian (and I in the transition shader) had to work with what was available. Question: Currently basic weather is not properly supported by the framework because I've pulled many computations outside the shaders to be passed as uniforms. Are people interested in keeping Basic Weather and lightfield shading compatible? If yes, let me know and I can help setting this up, it's not difficult, it just requires Basic Weather to compute a few things which used to be in the shaders. If no, please also let me know then I don't bother trying to set up reasonable defaults. It would be good to make it Weather system agnostic from the effect/shader side of things, don't you think? Cheers, * Thorsten Regards, Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
On Friday 13 April 2012 08:45:26 Renk Thorsten wrote: (*)No it's not bad design, it's a conscious hack around the state that the environment interface was in when the shader was developed. Something like a property rule or a Nasal script outside the shader would have done the trick as well... But I'm not arguing why it's done the way it is, and I don't want to talk down the great work that has been done with the water shader, I think we agree that a proper weather/environment interface is the way to go. It would be good to make it Weather system agnostic from the effect/shader side of things, don't you think? No. If you want to render atmospheric light effects, the shader needs to know the structure of the atmosphere and at what altitude the light attenuation due to clouds occurs, and the only system which has this information is the weather system, so the effect side can not be agnostic to what goes on in the weather system. It should be agnostic to how the weather system internally determines and manages these parameters, but I don't think we need to argue that passing a single 'ground light intensity' is superior to passing 5 cloud layer coverages and determining ground light intensity from that inside the fragment shader. Currently the issue is that I determine many parameters characterizing the light attenuation in the atmosphere dynamically in Advanced Weather but insert default values into environment.xml which are never changed by Basic Weather, so Basic Weather runs with lightfields, but doesn't produce realistic results because the defaults aren't ever adapted to the actual weather situation. If so desired, someone can insert computations/property rules/whatever... into Basic Weather to set these things dynamically - that is what I'm talking about. I don't see the value in inserting a heuristics for determining such parameters dynamically from the native parameters of Basic Weather inside the lightfield shaders, because that degrades performance quite a lot, and I have spent weeks optimizing the computations to get decent performance. In my view, this heuristics should be outside the shaders. You got me wrong there, I meant that what the shader sees in the proerty tree should be weather system (basic or advanced) independent. The shader doesn't need to know if the value comes from either, it just needs the value to be there no matter one's preferences for weather simulation. So in short, a common interface between the various weather implementations and the rest. Not when the varying number is limited. So you gain a bit of speed, but you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia) You gain a lot of speed. But what is the max. allowed number of varying? It's difficult to code anything when there is some upper limit, but I just don't know what it is. Cheers, * Thorsten To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Regards, Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
On Friday 13 April 2012 10:09:12 Renk Thorsten wrote: To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Okay thanks, then I am safe. Btw (spotted this while checking) - is there any particular reason to compute a normal from gl_Normal in the vertex shader, use a full varying vec3 to pass it to the fragment shader and add noise there? I mean, this is a water surface, it ought to be flat up to tiny corrections before adding noise... * Thorsten Yes because you don't have acces to gl_Normal in a fragment shader, and because the water surface is not a perfectly flat surface, it's a sphere patch (a low resolution one), so the normal varies between vertices. Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
On Friday 13 April 2012 10:42:48 Renk Thorsten wrote: Apart that the earth is a sphere and ocean tiles are large pieces of terrain where the curvature is quite apparent, how whould you define flat ? 'flat' = 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you won't spot the difference to the actual normal including earth curvature if I show you a picture.' Cheers, * Thorsten That will give you even worse lighting difference between tiles, and will shurely give you ugly artefacts and wrong speculars in relation with the sun ;) Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
On Friday 13 April 2012 12:35:57 Frederic Bouvier wrote: Emilian can testify that the current water shader is extremely difficult to convert to Rembrandt because it doesn't have a clear reference frame. It seems to work in object space but with assumptions on the object-to-world transformation. My gut feeling is that it was originally a demo from another project and added to FG without much thought, and a lot of trials and errors. As the writer of the urban shader, I am thinking of rewriting the Rembrandt version of the water shader in the same spirit. Regards, -Fred Actualy it makes assumptions about the lighting scheme used, and it boosts the visible reflection of the sun using a texture instead ofthe light's specular in the specular pass. That gets to be less aparent in the Rembrandt specular pass.(That would be easily converted by using the sun position, but we don't have that in the geometry pass :( ) One other issue that needs to be investigated is the changing specular position related to camera direction in Rembrandt (the leads to the ugly black banding in other objects too). It's visible on any object at certain surface to camera angle. -Regards, Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
On Friday 13 April 2012 11:00:14 Renk Thorsten wrote: 'flat' = 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you won't spot the difference to the actual normal including earth curvature if I show you a picture.' Cheers, * Thorsten That will give you even worse lighting difference between tiles, and will shurely give you ugly artefacts and wrong speculars in relation with the sun Basic ray optics says no such thing will happen, and basic ray optics turns out to be right - I just ran a changed shader - if anything, the tile boundary artefacts are reduced (actually I expected them to be gone, but there's probably another vector in the game). Cheers, * Thorsten If it looks right in one limited test case, doesn't mean it's right, or the proper way to deal with it (so it won't backfire later on) But feel free to do whatever you want with the information provided, and the code, after all it's open source... Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
On Thursday 12 April 2012 11:24:23 Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel I've got an 8600GT non mobile, and it works just fine(minus the perf hit with shadows on, due to the huge vertex number in the suncamera scene). I'm using the latest driver 253.40 as of yesterday. Might be a good idea to update the drivers. On Linux they support any cards from the 6xxx series up with this branch of drivers, while fx and older are supposed to use the older driver series. HTH, Emilian -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Monday 05 March 2012 12:02:26 Frederic Bouvier wrote: Hi Thorsten, De: thorsten i renk I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Yes please. Or if someone could just help in creating an effect structure thatone can switch these things on and off so that installing the lightfields doesn't have to overwrite everything and that it would be on GIT? Then we can worry about how to merge later? Lightfields would work optionally, there's no fundamental obstacle here. I know there's the idea to get everything perfectly merged in an elegant way by factoring out light and haze functions, but I'd be happy with a simple optional structure now and the rest later. Be sure that I am extremely interested in merging your work into Rembrandt. It is just too early for me, and as the discussion raised the point of the compatibility with older hardware, the mockup (from by clone) can't be merged as is. So, in order to have the less disturbing migration path as possible, things will take even more time. But i will come back to you to see how decoupling light and haze can be done in the future framework. It's getting somewhat frustrating... Not so much for myself, but for others who want to try it, and it's starting to look silly when I have to tell everyone who is interested 'Sorry, it's ready since a month ago, but we haven't been able to put it on GIT yet, so you still need to go through a tricky manual installation process'. Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Regards, -Fred No it can't. The fog/light functions need to be extracted and put into include_fog.*, and there needs to be a check in that one that switches between the different models based on the sky shader setting. There is an important issue though, the functions appear to be different for objects and terrain. That's not quite optimal IMHO, and will lead again to diverging fog models (what I've been trying to avoid by using a common fog function). And just throwing them in and splattering all the other shaders with fog functions in them will triple the work required later. So it's better to do this right from the beggining. Regards, Emilian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Monday 05 March 2012 13:27:00 thorsten.i.r...@jyu.fi wrote: There is an important issue though, the functions appear to be different for objects and terrain. What?? Both model-default.eff and terrain-default.eff refer to terrain-haze.vert/frag as shaders - how can the fog function be different if they're using the same shader code??? I think you're mistaken here. The fog function is different for clouds and rain layers (because clouds and fog are the same stuff, so there need to be different rules) and for the skydome (because the atmosphere fogs in a different way looking straight up than looking straight down). Cheers, * Thorsten Sorry, my bad, I remembered something like that, but it was in fact me thinking that it would need a separate function for objects. Anyway, first thing i noticed while looking more carefully at the code is this (terrain-haze.vert line 126): // now the light-dimming factor earthShade = 0.9 * smoothstep(terminator_width+ terminator, - terminator_width + terminator, yprime_alt) + 0.1; which has undefined behaviour. smoothstep(a, b, x) requires specificaly that a b. Also, all light terms should have alpha 1.0 not 0.0. Will report more as i find them :) Cheers, Emilian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windturbines facing in wrong wind direction
On Tuesday 28 February 2012 23:14:18 D-NXKT wrote: The smoke is particle system based and thus uses a slightly different mechanism -- is the smoke really still reversed? The steam off the catapult on the Vinson is correct. Wind heading is typically the direction the wind is coming from, not the direction it is blowing to. Curt. Yup! Tested with release 2.6.0 at KSFO. Wind from 90° with 30kn. Fly direction San Fransisco. Behind the arena are a few chimneys. The smoke drifts to the bay! Use the dragonfly. You can fly with no groundspeed besides the chimneys and watch the weird scenario! Best Regards D-NXKT That's due to the particle system on those chimneys (Models/Industrial/generic_chimney_01.xml) having: attachlocal/attach instead of: attachworld/attach Also while invetigating this I found the smoke.png texture these are referencing as missing from the terrrasync Models/Industrial folder. That makes the smoke look square/ugly. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sanitizing materials.xml
On Monday 13 February 2012 22:13:04 Stuart Buchanan wrote: On Sun, Feb 12, 2012 at 1:59 PM, Emilian Huminiuc wrote: On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote: Hi All, - The forest effect doesn't currently use the default fog effect (include_fog.[vert|frag] etc.).. For consistency with the rest of the terrain, and the tree effect, I think it should. Is there any particular reason why it doesn't? -Stuart Hi, just an oversight on my part. I'll fix it ASAP. Emilian, Thanks very much Emilian. I've also noticed a different bug with the ShrubCover landclass at high quality. http://code.google.com/p/flightgear-bugs/issues/detail?id=650 I've made no headway in understanding the problem, other than possible the geometry shader doesn't set up gl_Fog correctly. Any idea what's going wrong? -Stuart Hi, Pushed a fix for #650 into master. Also got rid of an extra vec3 along the way. If we're on the subject of materials*.xml: 1. could Construction, Industrial, Port be split from Urban/BuiltUpCover as they are now in materials-dds.xml? 2. We should remove big-apartment.ac from the urban areas. It's rather ugly, out of scale and pretty much pops up everywhere :(. 3. For urban/town areas I would do the same with water-tower.ac (for the same reasons as #2). 4. If we do #1 then we could limit oil-tanks.ac to those areas. Now you've got an oil-tank popping up in every village. (wish I had one of those in my backyard :P ). Cheers, Emilian -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sanitizing materials.xml
On Tuesday 14 February 2012 21:37:16 Stuart Buchanan wrote: On Tue, Feb 14, 2012 at 5:19 PM, Emilian Huminiuc wrote: 2. We should remove big-apartment.ac from the urban areas. It's rather ugly, out of scale and pretty much pops up everywhere :(. I'll check the scaling, and reduce the frequency. I personally quite like the combination of the urban shader and some additional random object (churches, apartments etc.) I wasn't suggesting to get rid of the random objects in urban areas. I'm refering to that speciffic model, that big ugly yellow building (looks like a ) from above ). The rest are ok. Emilian. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sanitizing materials.xml
On Monday 13 February 2012 22:13:04 Stuart Buchanan wrote: On Sun, Feb 12, 2012 at 1:59 PM, Emilian Huminiuc wrote: On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote: Hi All, - The forest effect doesn't currently use the default fog effect (include_fog.[vert|frag] etc.).. For consistency with the rest of the terrain, and the tree effect, I think it should. Is there any particular reason why it doesn't? -Stuart Hi, just an oversight on my part. I'll fix it ASAP. Emilian, Thanks very much Emilian. I've also noticed a different bug with the ShrubCover landclass at high quality. http://code.google.com/p/flightgear-bugs/issues/detail?id=650 I've made no headway in understanding the problem, other than possible the geometry shader doesn't set up gl_Fog correctly. Any idea what's going wrong? -Stuart Hi. The newly created vertices done by the geometry-shader need to have their position passed as a vec3 varying to the include_fog fragment shader. (include_fog.frag uses varying vec3 PointPos;) I would do it but I'm not familiar with the geometry shaders :(. Maybe we could CC Fred to the bug? Emilian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sanitizing materials.xml
On Friday 10 February 2012 23:05:45 Stuart Buchanan wrote: Hi All, - The forest effect doesn't currently use the default fog effect (include_fog.[vert|frag] etc.).. For consistency with the rest of the terrain, and the tree effect, I think it should. Is there any particular reason why it doesn't? -Stuart -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi, just an oversight on my part. I'll fix it ASAP. Emilian, -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather-utility.nas
On Friday 20 January 2012 16:16:18 Emilian Huminiuc wrote: On Friday 20 January 2012 15:01:35 Torsten Dreyer wrote: The shader scales the texture with windspeed and rotates it to get the right orientation, but the actual rate those change is too quick to look good, and gives the impression of very high speed, that's why I suggested a longer interpolation time for the values passed to the shader, and to avoid doing the interpolations in the shader itself (as that would hit performance). Only the two values of wind-from-north-fps and wind-from-east-fps are the ones that need this applied, as everything else is derived from these. OK - that explains the impression of fast movements during wind-speed changes. I have now added a time based interpolation to the wind vector components in /environment/sea/surface/wind-from-XXX-fps. I made the timing configurable at runtime in /environment/sea/surface/config/wind-filter-time which sets the filter-time for both exponential filters. This is initialized to 60 in FGDATA/Environment/environment.xml and looks reasonable to me. You might want to play around with that value and we can adjust it if desired. Along with this commit, I cleaned up water.eff and flutter.eff files from unused properties wind-from-(heading-)deg which seemed to be unused. Please check if that was correct. The relevant commit is 2071a3297c9bc3a7f8df397fd8acaa71bc110f06 in fgdata. Torsten Hi, Sorry previous reply was written before receiving this, I will play around with the wind-filter-time prop. Emilian Played around with it a bit. I got reasonable movement sensation with wind- filter-time set at ~1000. The flutter effect might need the wind in realtime though, as flags usualy react imediately to wind direction changes.-- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather-utility.nas
On Thursday 19 January 2012 00:14:34 Torsten Dreyer wrote: Hi, due to a bug in weather-utility.nas, the wave shader properties were stuck at a constant value for wind-speed zero. There was more unfortunate code in that file, so I refactored it as xml based property rule. This is the relevant commit: http://gitorious.org/fg/fgdata/commit/9b2e72e12d9a07b58d513c688a078f4fce3867 81 The computation of the properties for the wave shader and the snow line now live in FGDATA/Environment/interpolator.xml and FGDATA/Environment/metarinterpolator.xml Please check if the waves now correctly react to the wind and if the snow cover is right. If everything is OK, this should go into release/2.6.0, too. Greetings, Torsten Hi, So far it seems to be working over here, will test more thoroughly today. I had another question, could the wind vectors reported to the shader be interpolated on a longer (10x - 20x or so) time frame, or could they be updated only once a given time (1 minute or so)? I ask this in an attempt to cure the fast moving waves effect that happens each time METAR gets updated. Greetings, Emilian -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] weather-utility.nas
Hmm - actually, the wind properties _are_ interpolated over time if set from METAR which can be easily verified by observing /environment/sea/surface in the property browser and changing the global-weather scenario from, say stormy monday to fair weather. Despite the fact that the properties change slowly, I can see the waves jump in speed and direction. I have no idea why this happens, maybe something the shader itself? Torsten The shader scales the texture with windspeed and rotates it to get the right orientation, but the actual rate those change is too quick to look good, and gives the impression of very high speed, that's why I suggested a longer interpolation time for the values passed to the shader, and to avoid doing the interpolations in the shader itself (as that would hit performance). Only the two values of wind-from-north-fps and wind-from-east-fps are the ones that need this applied, as everything else is derived from these.-- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
On Monday 16 January 2012 11:34:23 thorsten.i.r...@jyu.fi wrote: I've noticed recently more or less by accident and to my dismay that model-default.eff is used both by models placed in the scenery and by typical aircraft 3d cockpits. This is rapidly looking like a bad idea when a more detailed atmosphere model enters the game - the terrain haze shader has altitude-differential fog, the sunrise/set code I'm working on has position-differential lighting and fog coloring. Models placed into the scene need essentially the same shader as the terrain and skydome, otherwise they don't blend properly - no choice here. However, half the visual field is typically taken by the cockpit, and the vertices and pixels of that don't really need to go through ~120 lines of differential fogging and lighting code just to discover that they get the default light at the position and no fog. One could probably write some provisions into the shader to make a distance check first and if the model is very close not to go through all the motions, but it seems more reasonable to me to do this on the level of the effect declarations and simply feed the 3dcockpit through a different default effect file which never tries to do any fogging in the first place. Would this be complicated to do (i.e. require changing all aircraft xmls), or is there an easy way to do this? I'm just testing the waters here... as far as I know none of the position differential shading code has been committed yet, but I'm sort of developing strongly into that direction, and I want to identify trouble as soon as possible... * Thorsten This behaviour is hardcoded, as there needs to be a default fallback effect/shader when none is specified in the model and shaders are turned on. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
On Sunday 15 January 2012 12:34:43 Mathias Fröhlich wrote: Well, I hope that we can get rid of the compression. Can somebody with the apropriate tools convert the compressed textures to non compressed ones? That could still be dds, but dds without these compressions that produce the warning. So no problem with cubemaps in dds as long as the compression is not there. Then *everybody* is again able to use this stuff. There are a couple of isue with that though. Biggest one is it will increase disk/RAM usage by at least 4 times, if not 8 depending on texture/compression method used. That basicaly negates all the advantages of the dds format, except for the embeded mipmaps. Is that acceptable? I remember some complaints about base package size increase, and also repository size increase. btw: Tools for dealing with any of the dds compression formats, and access to them is freely available under the MIT licence. http://code.google.com/p/nvidia-texture-tools/ So, I am not entirly against moving this to an other log level, but at first I think it is good to tell that this will only work for a few people. And I think it's good to see this *immediately*. Mathias I believe the numbers are a bit reversed here, and the vast majority of users has no issues with displaying these textures. But I agree there's an issue with (un)available support for these extensions in the OSS drivers (be they nvidia/intel/ati). Regards, Emilian-- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader fixes (only 8 texture units)
On Tuesday 10 January 2012 08:07:08 James Turner wrote: Hello, Since it appears I (and presumably others) have a limit of 8 texture units on my GPU, I am planning to edit the effect files to either remove the noise texture (if it's unused by the underlying shader, which is the case in several due to copy+paste), or move it down to an unused slot. I *think* the noise shader is the only one residing at an index above 7, in the all the existing Effect files. In the uber-shader, the only available texture unit below 8 is unit 1 - thanks to Fred for pointing this out. There's no deliberate reason for leaving this index empty, is there? Comments, or advice? James The copy paste issue might be larger than you think, some aircraft developers copied over the full effect file in the aircraft folder in order to tweak it, so there might be countless copies of some of the effects, especially the reflect one.-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud altitudes in shader?
On Monday 09 January 2012 10:31:24 Stuart Buchanan wrote: On Mon, Jan 9, 2012 at 10:00 AM, thorsten.i.renk wrote: I don't think the Model matrix will help you much either, as IIRC (0,0,0) is the center of the earth spheroid. Hm, the line is gl_Position = gl_ModelViewProjectionMatrix * gl_Position; Doesn't gl_ModelViewProjectionMatrix transform things into 2d screen coordinates? Correct (hence my reference to the Model matrix, rather than ModelViewProjection matrix). Would it work if I use a different matrix instead? Apparently vec4 groundPoint = gl_ModelViewMatrix * vec4(0.0, 0.0, 0.0, 1.0); can be used to generate the zero altitude point just below the current view, so then the length of the difference vector dotted with an 'up' normal would represent altitude (?) I didn't know that. What do you need it for? sunrise/sunset lighting? Yes, the earthShade factor should affect objects dependent on their altitude, basically I want glowing high-altitude clouds whereas the lower clouds are still dark. Thought so. That would be yet another nice effect to add :) On Mon, Jan 9, 2012 at 10:08 AM, Emilian Huminiuc wrote: In the transition shader (and the other terrain shaders), using gl_Vertex.z works as a good aproximation (it's used to determine if there should be snow painted, sometimes it behaves funny, but it's generally reliable enough), but for clouds maybe using the final value of gl_Position.z might give you what you want? The gl_Vertex of the terrain has a different coordinate system (presumably based on (0,0,0) being the center of the tile at sealevel?) than the clouds (where (0,0,0) is the center of the sprite). -Stuart I know that, that's why I suggested the final position, which should be actually given by ecPosition.z. (At least for fogging the trees that works as expected, I assume the trees use roughly the same approach).-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud altitudes in shader?
On Monday 09 January 2012 12:48:25 Emilian Huminiuc wrote: I know that, that's why I suggested the final position, which should be actually given by ecPosition.z. (At least for fogging the trees that works as expected, I assume the trees use roughly the same approach). Actually meant gl_Position.z (ecPosition is in screen coordinates)-- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
WOW indeed. That's great Fred. Words are useless anyway to express the joy/excitement this brings :) -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announce: AeonWave 2.1 for Linux available
On Friday 25 November 2011 22:44:47 Michael Sgier wrote: So AeonWave is a complete replacement for OpenAL? Must be...now could it do synthetic speech as used for X-Plane's ATC? Thanks Ever heard of festival? ever read the flightgear manual ? You've got everything needed already in place. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
While we're on the subject of texture size, I'll expand a bit on the background issues: First, there are a couple of technical limitations: power of two sizes, and a maximum texture size of 4096x4096. Getting the technical part out of the way we come to the tricky part. My opinion is that texture size depends very much on the amount of detail that one wishes to provide in the texture, and by the area covered by the texture (the famous xsize ysize tags). One aspect of this is how do the textures look up close. This one's easy to determine dividing the pixel size by the value in the tags. So let's say we have a texture 512x512px that we consider should map a 1024x1024 meters area. Right away we see that a pixel would end up covering a 2x2m area. It's not for me to decide if that's good or bad. This is not so important on textures with general wide features like grass, savanna etc, but it becomes a problem on textures that contain isolated features, for which we know the size from experience, like trees, houses, roads. If these features are present in textures, they'll give false visual cues if they're not scaled properly. Let's take a narrow road for example: it's about 7m wide, you spot one on the ground while flying your Cub and decide to land on it, you do so with some dificulty, and when landed you realize the road is as wide as a freeway. Or you need to do an emergency landing in a field, with no working instruments, and you take as reference that lonely house you noticed there, you land further than expected, in a ditch, as the house was scaled up twice in the texture, and gave you the impresion you're twice as low as you were. For these textures, I think there should be given as much consideration to their scaling, as for how they look and how big they are. To sum it all up: - size should be stricly a power of two. - maximum texture size is 4096x4096 px, though preferred maximum size would be 2048x2048. - size should depend on area covered and amount of detail wanted. - size assignment in materials*.xml should be done carefuly, with respect to real scale. - on-disk size depends on texture size, amount of colour variation in the texture and compression method. (a 4096x4096px texture can be as big as 10 to 30 MB if compressed as png, or ~20MB if compressed as dxt5 .dds, or ~10MB if compressed as dxt1 .dds, figures for .dds given with embedded mipmaps) -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sunday 06 November 2011 21:08:22 Jacob Burbach wrote: On Sun, Nov 6, 2011 at 7:17 PM, Robert dogg...@googlemail.com wrote: I hope that all you guys involved in the dds transition use nvidia-texture-tools because: 1. It is Free/OpenSource and platform independent 2. The compression quality is much higher than with the dds-plugin for GIMP However, and correct me if I'm wrong, the nvidia tools do not let you use pre-defined mip maps do they? I prefer the nvidia tools if for no other reason than they are command line and I can easily script and automate batch jobs. But if you do need pre defined mip maps I don't believe you have a choice except the gimp plugin..on linux anyway. cheers There is the version of nvidia's dds utilities that can be found here http://developer.nvidia.com/sites/default/files/akamai/tools/files/DDS_Utilities_8.31.1127.1645.exe that can be installed under wine. stitch exe from that package allows you to use custom mipmaps. That's how I've created the forest and grass textures. I've converted each of the mipmaps with nvcompress (with the -nomips option), then I've used stitch.exe to put them together. I've found the gimp plugin to be very unreliable. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather stopped working
On Sunday 30 October 2011 23:33:22 Durk Talsma wrote: Hi Czaba, On 30 Oct 2011, at 23:18, Csaba Halász wrote: That should make nasal happy, but whether it does what was originally intended, I do not know. Yes, that brings the clouds back. Whether the cloud patterns *look* sensible is something I'll check tomorrow, and whether the fix is physically correct is something that I hope Thorsten can answer. Thanks! Durk Hi Durk This might help: http://flightgear.org/forums/viewtopic.php?p=137492#p137492 -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
