Re: [Flightgear-devel] Project Rembrandt - next steps
I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? Thanks, * Thorsten -- 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
[Flightgear-devel] Lightfields to GIT - some more advice?
Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Thanks Frederic - this seems to be (sort of) working. I can only get it to work properly if I throw the new technique at index 7 (or lower) though. Otherwise all terrain types which have a special shader do not accept lightfield shading even if that special shader is off, and only by dragging down the index to 7 does this problem go away. No wonder I couldn't make it work before... I'll test this and rebase it with current GIT, then get it online, and then hopefully someone can commit it (and do the elegant implementations later). In the meantime, to iron out the edges, can someone help me with a few things: I need the true camera altitude above MSL as a shader-readable property (otherwise the scheme breaks in many custom sceneries). Currently I am doing this from Nasal, which means lightfields require Advanced Weather to run, but apart from that, I guess everything would run with Basic Weather as well. Is this information somewhere in the tree? - it somehow sounds like it could be, but I haven't found anything. Even if there's anything proportional to it, I think I could add a property rule, but I need something to work with, currently I'm using geo.viewer_position(). Do we have a list of what properties should control shader behaviour? I've now linked the whole lightfield to /sim/rendering/shaders/skydome because everything only makes sense together with the skydome scattering shader. But should we check for /sim/rendering/shader-effects or /sim/rendering/shaders/generic or any other properties in addition? Anyway, it's nice to see direct comparison screenshots for the two schemes - that makes it easier to spot weaknesses and problems. Thanks in advance, * Thorsten -- 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
[Flightgear-devel] Two small weather issues
I still have two small (weather-related) issues which I can't resolve myself: * rain is still 'smart' i.e. de-activates above the lowest cloud layer. Since Advanced Weather has its own precipitation region control, I'd need a dumb version which just rains when I set the property * for visibility 1000 m, the skydome seems to unload. This is not a problem in the default rendering scheme, but it is with terrain haze and scattering shader, because the terrain haze is made seamless with what goes on in the skydome shader, not with background light. Thus, for 1.1 km visibility everything is fine, but if it deteriorates further suddenly rendering artefacts appear. Can we just not unload the skydome? Thanks, * Thorsten -- 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] Project Rembrandt - next steps
Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Technically it could, but at the expense of forcing everyone to use lightfield shaders. It overwrites for instance the default terrain and model shaders. The reason why this is implemented in that way is that I have no clue how an effect file should be properly structured. I can change an existing effect file to insert new property-to-unifrom mappings, I can change the filename of the shader to be used, but my attempts to do more have so far gone terribly wrong and broken the effect. So what needs to be done for a clean commit is: * rename the special shader files where they overlap with default files * add conditionals to the effect files that if skydome scattering shader is on the lightfield files should be used, otherwise the defaults as they are (* not essential, but currently true camera altitude above MSL is obtained from Nasal and written into the tree - I'm fairly sure we have it somewhere better, I just don't know where) It's not much work, but it requires some better knowledge of how effect files work. Which is the point where I need help. * Thorsten -- 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
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 -- 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
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 that one 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. 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'. Cheers, * Thorsten -- 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] Web 2.0 paradigms
Actually I wonder a little why you accept using a modern tool like LaTeX being just 20 years old - while we all learned that the optimum scholar-environment was developed by the old Greeks (to my knowledge without any computers and/or LaTeX) -- after that we never had such a development of basic wisdom as during that time! Because you misunderstood a basic point: I use tools not because they're fashionable, but because I convinced myself they are the best choice to get a task done. I don't care what you learned about the optimum scholar environment, I also don't care what someone told me about it, it's one of the things which I can find out myself easily. Well - (to some extend) that was meant as a joke - but seriously: Did you ever consider how fast the environment changes today - for every human being in any kind of doing? And how fast the tools change that you can use to develop and deploy new ideas or to evaluate the basics? I'm looking out at this moment. There's trees and blue sky. They pretty much look like in my childhood. I'm looking forward to ice-skating later today - pretty much as in my childhood. I'll probably play in the snow with the kids layer - pretty much as in my childhood. When driving home, there'll be traffic and snow on the roads - just as in my childhood. I'll meet friends and we'll talk - pretty much as in my childhood. To first approximation, my physical and social environment looks pretty stable to me. My mind didn't change so much over the last years - I can process information at a certain rate, some things make me happy, others sad, I can dream up stories,... Is it possible that you're confusing 'environment' and 'any kind of doing' with something else which is much narrower? At the moment, I need to prepare a presentation. A 20 years ago, I would have done this with pens - now I use LaTeX. I'm going to reference other works - 20 years ago, I would have had to go through the library, now I can use arXive and spires to do it from my laptop. The tasks are unchanged, but there has been some progress in tools, and since I understand that the tools are superior for the task at hand, I use them (somewhat funnily, among all colleagues I know, I've been the first to use computer typesetting and my laptop for presentations...). There have been significant changes in available tools since - we've seen Powerpoint Co - but they simply don't deliver. I get a worse layout for two times the work and 100 times the file-size. So I don't use Powerpoint, even if it's fashionable to do so. We can look at Flightgear (and in the virtual world, the environment actually changed a lot). I want to do something (make nice clouds), so I acquire the tools I need (Nasal, GLSL) to get the job done. Note that we can argue if Nasal is the best tool or not (we've done this on this list a few times), but that I personally think it was the right choice. Believe me: I do understand that someone does not want to change his tools every couple of years - just about nobody wants to do that and really nobody needs to -- unless he is in a competitive environment! There's a reason LaTeX is still around despite all competition, and that it that it's hard to beat. Both its flexibility and its ability to do decent typesetting are so compelling that I haven't ever seen anything coming close. You're missing the simple point that you have so far not come up with much compelling evidence that your tools actually can do better than what we have, you've just delivered a few lines of web 2.0 phrases. I'd have to guess at what Martin and Stuart think, but at least I'm not impressed by web 2.0 phrases, I use what does the job at hand best. Those new tools will not have any effect onto the contents of any dispute about e.g. Egyptian myth and similar! Except that you can do that now with modern tools with every scientist worldwide in real time! Excuse me, but didn't you try to make a point about multiple languages? That's clearly a content issue, not a tool issue, and yet you somehow claimed it would argue for different tools. The sum of your statements did not seem to be 'leave the content what it is, just change to better processing tools', but you argued for changing the whole structure (including who gets to contribute to the manual). So kindly don't present red herrings here. - but does (e.g.) a Housewife really need to learn all theoretical basics about e.g. plastics, metal, porcelain - just to cook? Strawman argument. Of course not. However, you have to learn C++ if you want to contribute to the Flightgear core development, you have to learn GLSL if you want to edit shaders, you have to learn to drive a car if you want to join traffic and so on. Real pilots learn theoretical basics of aerodynamics just to fly - and there's some consensus that this is a reasonable thing. - and does every kid need to know everything about aerodynamic-theories, FAA rules, etc. etc. just to play with the
Re: [Flightgear-devel] Windturbines facing in wrong wind direction
1a. wind turbine orientation and rotation/spin speed is bound to /environment/wind-from-heading-deg and /environment/wind-speed-kt which represent current wind at the FDM position. This should probably change to ground wind. The same is true for the windsock, btw. Turbines should probably use mean ground wind, whereas the windsock should use actual ground ground wind (including gusts and direction changes) so that you can see gusty conditions on approach. Wind turbines are probably too heavy to swing with the gusts in any significant way. 2. Particles attached to local move against the wind on the northern hemisphere. Note: Particles attached to world (aircraft) behave correctly and move downwind. On southern latitudes, particles attached to local also move correctly downwind. This seems to be a bug. IIRC, there was a fix for contrails moving into the wind some time ago - maybe this is somehow related. Drag chute of the English Electric Lightining was also displayed blown into the wind at some point - might be related? * Thorsten -- 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] Web 2.0 paradigms
~20 years ago: Those wonderful PDF-files were introduced - we now could even transfer documents from one PC to another - even with different Operating Systems and/or different printer capabilities! That was also when LaTeX was developed [...] I'll skip all the other stuff because I've already made my position pretty clear in the past. Anyhow I'd like to express my disagreement on this one. I didn't check closely, but I'm pretty sure that even LaTeX, the comfortable, let's call it an extension to TeX predates PDF by almost a decade. And the underlying TeX had been invented even a lot earlier, maybe yet another decade. TeX was released 1978, LaTeX around 1982, the thing to develop later into pdf (Camelot) was introduced 1991 and became an open standard as recent as 2008. * Thorsten -- 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
[Flightgear-devel] Web 2.0 paradigms (was: New styled FGFS--Manual)
I discovered I really need a break from coding and debugging (found myself dreaming about haze rendering lately, and that's usually a warning sign), so I may have time for some philosophy (feel free to skip, it's not about FGFS in particular). I was surprised that this shift in Paradigms has such a big handicap to be considered for future developments. And if you believe you are old-fashioned, how about a 70 year old guy that started in Computer Development in 1970, and whose big boss predicted: I think there is a world market for maybe five computers. (Thomas Watson, president of IBM, 1943!) You may have some more laughs on http://www.pcworld.com/article/155984/the_7_worst_tech_predictions_of_all_time.html). Joerg mentions a paradigm shift here, and he writes similar phrases elsewhere: -- make use of the modern art of on-line reading/studying! e.g.: Jumping between the books to any given place inside and outside the book! As we accept that any professional can participate in the design, we should also trust our users to generate and maintain their manuals by themselves! FGFS, FGFS-wiki, Wikipedia, Linux, etc. etc. -- they all proved that it works! -- Avoid the dependency on uniquely skilled persons: -- Use common tools. Most kids today learn how to generate a Homepage and use html - while LaTeX (and similar) needs some more unique skills/environments/procedures. These are what I'd call 'Web 2.0 phrases' (if I am polite...) and something else (if I'm in a bad mood). The assertions made here are fairly close to what is typically asserted in Web 2.0 contexts: * there is a modern way of studying which involves hyperlinking and cross-referencing of information snippets * it is possible to avoid depending on experts (uniquely skilled or knowledgeable persons) due to the existence of something called 'wisdom of the crowd' or 'swarm intelligence' * there are 'digital natives' which practice the modern way of studying, generate content using swamr intelligence and have their own set of tools replacing 'old tools' In my experience, all three assertions are largely nonsense. Information processing is an unpleasant task for the mind if a certain complexity is reached. One can structure a text well which helps a lot, and (especially in philosophy) there is a tendency to express simple ideas in complicated words, and this can and should be avoided, but there is no way topics like Quantum Field Theory, Zen Buddhism or the development of languages from primitive roots will ever be simple and pleasant to study. Really understanding something is hard work, and the mind feels exhausted and tired afterwards - that's the way it is, and there is a good reason for it. Understanding a text involves reading it, memorizing it, making mental connections between its parts, thinking over it, making mental connections to other texts, re-reading it, making more mental connections - this is a process called 'learning', and as most people who ever tried to learn a language can certify that this is really hard work. Now, unless tempered by an unusual amount of wisdom, the human mind wants to know, but not to study hard, it wants to hold a respected position, but not to work for it and earn that respect the hard way, it wants to control, but not be held responsible. There are numerous examples for that to be found everywhere. I happen to be one of a handful of experts in the world with regard to J.R.R. Tolkien's invented Elvish languages (in fact, I wrote the standard introductory book to Sindarin). I've come across hundreds of people who wanted to speak Elvish, but at best 5% of those actually were willing to go through the pains of learning it. Any reader in the FGFS forum will have no problems finding users which know exactly what needs to be done in the Flightgear world, but 'unfortunately' are unable to step up and learn how to do it. And so on. This is where the Web 2.0 philosophy comes in - it caters to the less pleasant tendencies of the mind and states that all that somehow okay or even commendable. Hyperlinked information snippets give you the illusion of understanding something - you can replace making a mental connection by a click on a link. In the short run, it feels just the same just without effort, the information appears when you need it. In the long run, you just notice that the mental link isn't there (because you never needed to make it) and you haven't really understood anything. There is a reason why scientists write about their research not in any 'modern' way - if you really need to transmit a lot of information, then a well-structured text without any hyperlinks works best. As for swarm intelligence, I'm still waiting for any evidence of that. Take Tolkien's Elvish (because I know that case very well) - especially when the Lord of the Rings movies were popular, there were hundreds of sites advertizing Elvish phrases, tengwar writings, name translations; there was a
Re: [Flightgear-devel] Sanitizing materials.xml
The end result is that I'd like to do the following: - Create a new Materials directory under fgdata - Move materials-dds.xml and materials.xml into it - Create a new Materials/materials-base.xml file containing material definitions common to both materials files. - Create a number of small xml snippets, mainly for random object definitions, e.g. urban-buildings.xml which will contain the random object definitions for Urban areas. Any objections to this? Not as such, but if the whole file structure gets redone, might we at this point consider making regional textures by xml conditionals easy in the new file structure? See here for the concept: http://www.flightgear.org/forums/viewtopic.php?f=5t=12031start=15 I know that ultimately different landclasses are a superior concept, but I've very much enjoyed seeing different city and agricultural textures in Europe and the US over the last year, and I believe the concept essentially works without re-doing all the scenery. If we add something like this in now, we might also come to the point of implementing a re-parsing of materials.xml at runtime, so textures could switch on a transatlantic flight from US type to Europe type. Regional texturing is a feature which would be nice on GIT - by now, we also have enough GPL-compatible textures to pull it off (a while ago, Adrian posted a very impressive GLP texture pack in the forum). I'd be willing to help implementing it. Cheers, * Thorsten -- 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] Looking at a nice project from outside
Basically I see two different approaches in FlightGear Scenery world (aside from a few minor blends): 1.) Focus all ressources on one common World Scenery. 2.) Build pools of individual (and sometimes even contradicting) scenarios - also known as the M$FS way. It's obvious that 1.) was the one I tried to accomplish. I was convinced that, as a non-commercial OpenSource project, we could do better. Anyhow it's obvious that 2.) draws magnitudes more developer ressource and the gap is steadily increasing. I've even watched people explicitly trying to persuade/convince contributors _not_ to contribute to common, collaborative Scenery ressources - and, what's really sad, not one single voice objected. That's why I consider my approach as a failure, maybe not generally, but at least in FlightGear land because apparently there's no critical mass of fertile soil to make it grow even half as fast as it could. For a long time I thought this would be a failure of The FlightGear Community, but the more I think about it, the more I'm getting to the conclusion that there is simply no community in FlightGear Scenery land. Either there's a fundamental difference in the understanding of the term community - or 95 % of those who are repetitively exercising this term are just a crowd of narcissists I guess as far as scenery goes, I certainly qualify as an outsider, so here are my two cents. As far as my experience goes, this sums it up quite nicely: Just for the record, that's one of the common, big, but most avoidable mistakes: Submitting when it's finished. Since my first contact with Flightgear a few years ago, I have never witnessed that world scenery has grown more detailed. Objects - yes, but for me personally landclass and elevation resolution matters much more. Basically, during my whole Flightgear life, the world scenery has always been what it is. In my first year, I've occasionally asked when new world scenery will be available. Afterwards, I've given up. I was (and still am) glad that more and more custom scenery patches appeared. It is very obvious to me that this approach has its limits, there are errors and seams visible - but all in all, it enabled me to pick the areas where I like to fly and enjoy that while waiting for the real thing. Whenever that may happen. I read many forum posts, I follow this list - and yet I have zero idea what the status of the world scenery is, I couldn't even guess when, say, Europe might be moved consistently to CORINE data, I have no idea what the current issues in scenery development are. And I had no idea about your frustration right until reading your post. And I required your two follow-up posts to understand just what the issue is. Just maybe, there is a communication issue involved here (but let's also allow for the possibility that I am just too dumb). A community doesn't usually organize spontaneously in my experience - it has also something to do with the flow of information and ideas, with social skills (there are some people I enjoy interacting with, there are others with which I can interact if necessary) and last a good bit of luck to find the right person at the right time. Maybe, if there'd be a clear perspective for contributions to world scenery to appear, developers would be less likely to do their own patches of the planet. Maybe not. Having said that, I would also very much like to thank you for the work you have done. I don't understand enough of the details to fully appreciate it, but I do know that it is crucial for all bits of scenery I like. And I woul like to make it very clear that me being grateful for, say, Pacific Northwest Scenery doesn't take away my appreciation for your work. I really feel a strong manpower in FG on aircrafts, on shaders and weather items, And I wonder where that feeling comes from, because despite trying to get forum users interested in joining in weather-creation work (or texturing), I have the feeling that this has basically failed. The situation I observe is not really different from what Martin describes - the development of the weather system rests on a few (at times seriously overworked) individuals and there doesn't seem to be a pool of manpower to be tapped if needed. Being a theoretical physicist in real life, this is no different from work, so I don't really mind that mode of development so much. Best, * Thorsten -- 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] New styled FGFS--Manual
As we accept that any professional can participate in the design, we should also trust our users to generate and maintain their manuals by themselves! FGFS, FGFS-wiki, Wikipedia, Linux, etc. etc. -- they all proved that it works! Here's an actual user commenting on the state of the Wiki: http://www.flightgear.org/forums/viewtopic.php?f=17t=15215p=149638#p149514 (he thinks it doesn't work). No idea what user you have been talking to. I think the FG wiki is a great place to store ideas, dump obscure technical instructions for specialists or document some special features - but I certainly would *not* advise any new user to learn how FGFS works with anything styled like our Wiki. I also have issues with Wikipedia - it always seems to move down to the lowest common denominator of all who want to edit an article. Basically, an article isn't bad as such, but whenever I compare something on Wikipedia with something a selected group of specialists has written, Wikipedia scores rather low. So usually I use Wikipedia just as index to find what I am really looking for. Why shouldn't we, as the promoters of the most modern style of designing, not also make use of the most modern style of reading/studying/updating manuals, dictionaries, newspapers, etc.? Call me old-fashioned, but I read my newspaper starting at the beginning of an article and ending at the end. Jumping cross references is very bad for focusing attention and just generates a lot of noise which makes it difficult for the information content to come through efficiently. Most kids today learn how to generate a Homepage and use html - while LaTeX (and similar) needs some more unique skills/environments/procedures. It is streamlined for the use in publishing houses/departments - with the need for a so called corporate identity. It seems you still don't understand what LaTeX is for. You can easily turn LaTeX into both html and a printed book automatically - but you can't ever turn html back into anything resembling a printed book withd ecent layout without tons of manual input. Please let me know if you have an issue with that - otherwise I will start to setup FGFS-wiki versions. I think you can set up anything on the Wiki which you like - it just doesn't remove the need to have 'The Manual' if you want to offer a serious and structured documentation. My 2 cents anyway. * Thorsten -- 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] Fair practice autorisations
All people need to know that 60% (or more... it's approximate) of aircraft available for flightgear are created by helijah. More than 80% of them are totaly crappy ! They aren't a good point for FlightGear project ! I think you're mistaking Flightgear for a commercial project here. Sure, in an ideal world, people would make very realistic aircraft models, combine them with well-researched FDMs and then use all the available technology to model systems. Problem is, very few people combine all these skills (I for instance am not a 3d modeller - while I can see myself coming up with an FDM, I can't see myself do a cockpit). This is where the beauty of open source and a repository comes in - someone can make an aircraft model and commit that without doing much FDM work. It now belongs to the project under GPL. I can use the model in an AI scenario. Someone else can simplify the model and use it to populate an airport with parked aircraft. Yet someone else can pick it up and make an FDM for it. Which we couldn't if it wouldn't have been created and released before. There is no real problem if unfinished work appears in the devel version of Flightgear - that's part of what it's for. I have, on occasion, even asked aircraft modellers if I could have their unfinished work, because I was interested but it wasn't on GIT yet. If you want to blame someone, you have to blame the people who made the decision to make all aircraft in the repository available to the end user as well. But that point has been made a while ago, it has led to discussions about a formalized rating scheme for aircraft, that scheme exists and is being implemented, more and more aircraft are rated, so now the end user is getting a fair chance of knowing in advance if the aircraft he is about to try is finished work or not. Imagines a man who don't know FlightGear project : he test 1, 2 ,3 aircrafts by helijah then he says pfff all these aircraft are unusable. I leave FlightGear and I go buy MSFS ! *shrugs* I would assume that the average user is capable of some rational thought. The FG base package comes with hand-picked aircraft, so on your first contact with FG you learn how well they can be made. From there, it's a realization that in open source not every work is equally well done, and a quest looking for the aircraft you like. Which the rating scheme makes a lot easier now. I'm really convinced the work made by helijah is bad for FlightGear project. Aircrafts created by helijah aren't realist. So he's a 3d modeller, not an FDM specialist - so what? Does that mean that 3d models are worthless for the project because of that? It will be good if FlightGear community take conscious of this ! Do you honestly believe that you're the only one who has realized that there's unfinished work in the repository? I mean, seriously? Please, seriously change your perspective in this discussion. Things may have their use even if you can't see that - just try go looking for it then. Cheers, * Thorsten -- 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] Fair practice autorisations
The fact that we have now 3 different threads about the same topics: DC3, licence violation and cooperation in an OpenSource project, makes it difficult to see where the real problems are. There's a number of separate issues here. * license violation of some commits - this is a real problem, but I see no need to discuss this - it's brought to the attention of the people who have the rights to address this on the repository, if it's not obvious at this point that it needs to be dealt with, then why should further discussion help? * allegedly (I haven't checked) insults exchanged between people working on the same aircraft, followed by insults which I have witnessed - this is childish behaviour and should not be discussed on this list at all - adult people in the same project should be able to communicate in a professional manner with a basic level of politeness, regardless of personal disagreements. Certainly piling new insults on top of old ones, or mixing any other grievance with a person or the project at large isn't going to help * unfinished aircraft in the repository - seems useful to be to point out that there is a rational for having them * unfinished aircraft offered for download to end users - I am one of the people who nag and push for a rating, but these days I see the issue being addressed, maybe not as fast as I would like, but the world isn't perfect - certainly a soft of consensus has been reached and re-opening the issue won't help * misunderstanding about the nature of the GPL license - this is somewhat counter-intuitive and has been explained properly * unwritten rules for who is author and who decides what gets committed - tend to lead to problems, but this can be sorted out in a reasonable way, if necessary by forking. My personal impression is that original authors try to retain far too much control - anyone working closer to the core has to live with what others do and co-ordinate efforts. Case in point - weather radar development in the forum: This heavily relies on the weater system writing out the right info, you can't do it alone. So who is author in the end? Doesn't matter to me. * dislike of certain FDMs by certain people - simply don't use it, if I think a particular aircraft is bad/unfinished/whatever I don't fly it, likewise if I think a bit of scenery is badly done I don't go there - maybe I offer constructive criticism or try to improve it, but I don't think trashing someone's work in public will do any good whatsoever. Likewise, if you don't like to develop for a certain FDM, then don't do it. Above all, the problems shouldn't be mixed together. If there is a problem, that should be addressed, but not by creating a new problem. If a person has reacted improperly in some context, it doesn't give grounds to calling his work worthless in public. If the Flightgear project offers half-finished aircraft for download to the end user, that is not the fault of people commiting unfinished work to GIT. I don't think it's particularly difficult to see where the real problems are. I just think there are some personal grudges obscuring their identification. Cheers, * Thorsten -- 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] Shader debugging
The second problem is the 'checkerboard' appearance of fog rendering over ocean. To the limit of my ability to test, the cause is incorrect interpolation of distances and angles due to very large vertex spacing Update: Emilian kindly educated me how to deal with this properly: If the relative position vector eye-vertex is passed to the fragment shader and distance and angles computed there rather than in the vertex shader and interpolated from there, the interpolation is of a linear quantity and hence exact by definition and corresponds to in essence infinite vertex resolution - this solves this problem for good. * Thorsten -- 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
[Flightgear-devel] Shader debugging
I've spent four hours yesterday to trace down the cause for fog inconsistencies which I observed in custom terrain. One of them was the fact that the top fog level was sometimes displaced by some offset from terrain chunk to terrain chunk in the new CORINE Italy scenery and the other is the fog pattern over the ocean. The first issue goes like this: I've been operating under the impression that for the purpose of rendering scenery, vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; gives the correct altitude of the eye above MSL and terrain_alt = gl_Vertex.z; gives the altitude of the vertex and that comparing these altitudes against external uniforms (like the ground haze level or the snow level) gives correct results (the last assumption is coded in landmass.vert/frag for snow) - which usually does a good enough job. It turns out however this isn't correct in general - in the custom scenery, the altitudes computed that way were not above MSL but displaced scenery chunk by scenery chunk with a constant offset, so the same alt=500 condition in the shader meant 700 m MSL for one chunk of scenery but 850 m for an adjacent chunk, resulting in a discontinuity in fog (and snow) rendering across terrain seams. I don't know if this is a flaw in the custom scenery building process (I haven't seen the problem in default scenery yet) or not, in any case the terrain itself renders correctly, so the offset is known to ftransform(); but for the purpose of shader coding, it means we cannot assume to have know the proper MSL altitude scale inside the shader. The correct solution is to pass eye altitude (eye_alt) as a uniform, then the offset is given by offset = (ep.z - eye_alt); and the the true MSL altitude of the vertex is true_alt = gl_Vertex.z + offset; and this indeed deals with the discontinuities just fine. For testing purposes, I've implemented the eye altitude property to be passed as uniform from Nasal, but it should be done properly, hence: Do we have the eye altitude in meters in the tree in a property that is readable (= is continuously updated) by the shader, or alternatively, can we get it, i.e. the equivalent of var viewpos = geo.viewer_position(); var alt =viewpos.alt(); I believe all snow renderers should take that into account as well. The second problem is the 'checkerboard' appearance of fog rendering over ocean. To the limit of my ability to test, the cause is incorrect interpolation of distances and angles due to very large vertex spacing (I've asked the shader to plot step functions in angle and distance to see how the interpolation goes, and it had the expected outcome). Basically, when you approach a huge square directly from the side so that the closest distance is 1 unit and you see the two corners under 45 deg, then the distance to the corners is actually 1.414 units, and naturally the interpolator thinks that the distance is 1.414 units everywhere on the line even when actually it gets much closer - this is why fog seems to 'cling' to the middle of the line, because there the distance is overestimated. The default shader doesn't fog with true distance but with z-distance in eye space, which in the above situation pretends that the distance to the vertices is just 1 unit as well, which makes for homogeneous fogging along the line. But this leads to massive artefacts for larger FOV - at 90 deg FOV, the error in fogging at the edge of the screen already is 50%, at 120 deg the edges are done completely wrong. Moreover, the scheme doesn't work together with the two component calculations required by the terrain haze shader. To me, the only viable solution appears to be more vertices for ocean tiles, I don't think there are computational tricks which wouldn't be at least as bad under certain conditions - comparing with vertex density of normal terrain, even a factor 100 should be doable without problems. I vaguely remember that Vivian and Emilian had tried this and were negative, but I haven't really seen the outcome. I believe the results over terrain show conclusively that at some vertex density the problem goes away, and given that I can understand and explain all aspects of the problem I see, I think my analysis is correct. Cheers, * Thorsten -- 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] Final 2.6.0 Release Preparations
Best of all, the new features are based on user community requests, and not driven by economic incentives. Some of these features are already in the works for the next FG release [give continuity message about the development] That'd be suspiciously close to dishonest advertizing. I spend a fair share of my forum time explaining to angry/disappointed/overeager users that feature requests are suggestions which often end up being discussed, but more rarely end up being implemented, and rather that an army of eager developers waiting for features to be proposed, features usually get implemented if a developer is interested in implementing them (so the best strategy to get something done is to get a developer interested, not by just complaining...). As far as I am aware, the development is mostly driven by what developers are interested in, not by user community requests (which sort of makes sense in an all-volunteer community), and unless there is a formal commitment of core developers on the horizon to devote part of their time to work through feature requests, I would not advertize such a line - it's going to backfire on the project. * Thorsten -- 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
[Flightgear-devel] Local Weather documentation update
I feel a bit bad that it has taken that long to get it done, but at least I made it before the 2.6 release - here are the updated documentation files for Advanced (Local) Weather 1.4 http://users.jyu.fi/~trenk/doc_update.tgz including the description of the new gui and updates on the 'known issues' section (which fortunately has been shortened). Since the update cannot alter the functionality of the program, I would ask that it is committed both to the 2.6 release branch and the 2.7 branch. Thanks in advance, * Thorsten -- 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] Shader performance
After a few more tests, some more observations which seem to be right to me listed here (if that is confirmed, we may perhaps gather these and other statements to the Wiki to get some guidelines for efficient shader coding): * 'big' performance users seem to be the scientists's friends, i.e. functions like exp(x), log(x), sqrt(x) which for me make a noticeable impact :-(. I've made good experience by returning asymptotics explicitly, for instance in a light function f(x) = e / (1.0 + a * exp(-b * (x-c)) )**(1/d) simply asking if x threshold and returning e if the condition is true before attempting to evaluate the function speeds things up quite a bit in many cases while making a tiny error (in my case, 1e-4 or so). I haven't tried it yet, but I suspect now that x*x*x*x would also evaluate much faster than pow(x,4.0) since the first is just a multiplication while the second utilizes a function which is even more general than sqrt(). * GLSL doesn't go for smartness, so it has to be coded in. In an expression like mix(cheapExp, expensiveExp, fraction) even for fraction = 0 expensiveExp is computed. So again, an if (fraction == 0) in front of this can reduce the load quite a bit to compute expensiveExp only if it is really needed. * in the shaders I have seen, usually a very physics-centered approach is taken: We first take the color of an object from the texture, then apply ambient, diffuse and specular light to see what color it takes, then go to the eye and have a look at how much of it is fogged. However, an eye-centered approach seems much better to me - the first question to be asked is 'What can we see of the object?' and if the answer is '99% fog' we don't really need to know the texture or compute specular reflections. Which is to say, in many situations I would perhaps compute the fog function first (if possible) and base my decisions what else to compute for the pixel/vertex dependent on the outcome of that. For instance, in the cloud shader fog comes pretty much last - but we probably could dispense with bottom and away side shading beyond a certain fog value, because it's useless to first compute a darkening and then brighten it to transparent/white again. So far, this hasn't been too relevant because objects which are 99% fogged are soon to be unloaded anyway, because the distance to which terrain is laoded is set by the same parameter as the fog. But this may not be how to continue. The terrain-haze shader already allows the two to be different, and it has also a lot of merit to have terrain loaded even if you can't see it - weather needs to know terrain to get cloud-terrain interactions right, any terrain radar would need it (see for instance the very interesting development 787 MFD Vertical Profile here: http://flightgear.org/forums/viewtopic.php?f=30t=15200 this simply won't work under true IFR conditions when it is needed most because no terrain is loaded). All in all, it seems to me that making shader code efficient is just a very messy and ugly uphill battle in which lots of small effects sum up to something noticeable in the end... Cheers, * Thorsten -- 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] Shader performance
Gary adressed those creating the 3d-models and aircraft in FGFS. Yes, quite. And since your own aircraft doesn't repeat and is there independent of visibility range, so in some sense this is a special case anyway. Problem is, once you have created a model, you don't control what others do with it. Someone might think that a helicopter looks cool parked on a helipad on an airport as a static object, and that a few of them are even better. So suddenly multiple copies of the model end up in the scenery. I don't know first hand what shows up in MP, but some models seem to be a big issue for other pilots from what I have heard. Ultimately, I don't care so much for theoretical arguments of what should scale how, I care for what actually does scale how. The fact is, directly looking at a cluster of ~5 parked AI aircraft decreases my framerate by 25% when I have high vertex shader load whereas I don't recall seeing this for low vertex shader load, that much I have established. The conclusion that models are a potentially large impact and matter is therefore justified. Now, I may be wrong and this has nothing to do with vertices. Then whatever it has to do with would be interesting. But GPU's getting better and better today, but still the shape of the aircraft does not need hundred of vertices to make it look smooth. I believe 'as many as needed but not more' is a very reasonable principle. For an AI plane which most of the time appears as a dot, my smoothness requirements are actually not very high, but my framerate requirements are. The argument that GPU's are getting better isn't a very good one. I have enough ideas and schemes for atmosphere light and more detailed cloud rendering worked out to keep the next-to-next generation of GPUs busy, and I'm guessing so do others. Burning performance for more realistic visuals isn't often that difficult after all... As an example, an overcast layer made of 100 m sized cloudlets would look terrific, would be technically easy to code and would drive any GPU you can buy into single digits (yes, I actually try such insanity now and then just to see with 1 fps how it could look if I had the resources to do it). * Thorsten -- 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] Shader performance
Heiko wrote: And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. I used to develop in a situation in which I was completely driven by the speed at which Nasal scripts executed, i.e. I saw quite drastically the effect of switching certain Nasal scripts on or off. Handing more and more work over to the GPU means that in general things speeded up and I now see the execution speed of the Nasal scripts no longer, but rather I am now completely driven by the speed at which the GPU can do the rendering, and I actually see improvements in framerate by handing computations elsewhere, e.g. to (to be slightly provocative) Nasal. Basically, you want a situation in which all available processing pipelines are equally filled for best performance. Also, if you notice vertex count or not is a question of visibility range. If you're happy with 16 km default visibility, then it's probably not an issue. I used to think 30 km is a hell of a lot, but after having seen how 120 km look from cruise altitude and actually start to compare with real life, I actually want something like 120 km if I can get it. And since terrain vertex count goes with the square of the visibility, this becomes the determining factor rather sooner than later, and scenery models factor into that in a major way. So you can also pretend it's my fault and I'm asking too much visibility range, while all others are happier with 16 km visibility range and hires high-vertex count models (which is probably better for helicopter people :-) ). But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. @Stuart: That's very interesting. Do you have any suggestions for what information we could push onto the fragment shader? I'm still not sure how well my experiences generalize, but the obvious thing to try bothering the fragment shader with would probably be the bottom and away side shading computation. It probably also depends on what other shaders are running - for me, my terrain-haze is the major player, followed by the 3dcloud whereas skydome uses far less resources. I don't know how the balance is changing if water or urban are on. If any of those makes use of the fragment part more heavily, then shifting more things into there might not be as good. Cheers, * Thorsten -- 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] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. I did a quick check pushing everything which is not vector geometry to the fragment shader, and... * below 20 km visibility range or so, the scheme appears to be a bit (~10 %) slower than it was previously as vertex-based rendering * from about 20 to about 120 km visibility range, I had a constant and quite usable framerate around 22 fps for full screen 1920x1200 resolution (I suppose since this goes per pixel, the screen resolution should affect this). * above 120 km, the vertex part seemed to become an issue again and I went down to 15 fps around 200 km visibility range (this is a lot more than I had previously seen for that range) I guess this confirms your scaling prediction. * best part - for most of the range below 100 km visibility range, maxing out the cloud view range to 75 km didn't make a lot of difference for the framerate (apparently plenty of extra capacity for vertex rendering) In summary: 120 km visibility range with clouds drawn to 75 km at 22 fps with terrain haze and sunset effects on in the F-16 at full screen resolution 1920x1200. There seems to be something going into the right direction here :-) Have to test this more systematically, and also see if I can shuffle stuff from the skydome frag part to vertex. * Thorsten -- 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
[Flightgear-devel] Shader performance
I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance I don't know who stated that here, but I intuitively assumed that this must be right. You can imagine that I was surprised that when I trivialized the fragment part of my code, the performance didn't change at all, but when I trivialized the vertex part, the performance doubled. So it seems like the whole performance drain of my code is caused by an overworked vertex shader. I then transferred the haze color computations to the fragment shader, which improved overall performance in my benchmarks by 20-40%. It seems the optimal results appear for a shared workload between vertex and fragment shader. Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. This is also relevant for models, because having a cluster of ~ 5 AI planes (which happened to be stuck into each other) in my view or not caused a 25% change in framerate, so the vertex count of models matters compared with the vertex count of scenery and is not some insignificant correction. 3) shifting constant-per-frame computations out of the shader doesn't improve performance significantly. I suggested that here as an idea to improve performance of the cloud shaders. I was now able to construct a test case for the idea. The computation in question involved getting a per-frame constant from other constants, i.e. to compute sqrt(2 * hazeAlt * EarthRadius) where hazeAlt is the altitude up to which the haze extends which is passed as a uniform. Computing two of such square root expressions inside the vertex shader or not computing it makes the difference between 21 and 22 fps in a high vertex count benchmark test, i.e. 5%. Which is not that much in itself, but if we would find, track and eliminate all these occasions, the sum of such small improvements might well go into the 20-30%. I don't know how much of all that is specific for my system (NVIDIA GeForce 8600M GT) and how much is general, but my conclusion is that these things should be tested systematically, and I very much invite others to test the before/after version of the haze shader code. (I know that Vivian and Emilian are still working on separating the fog and light function out, but that's going to take, and if anyone could help me to get the correct xml conditionals so that the whole framework can be switched on and off along with the skydome shader, so that the whole thing can be committed and tested easily, that'd be terrific. I tried, but I keep messing the effect file up...) Cheers, * Thorsten -- 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] Local Weather menu structure: Wind settings
I just faild to set the wind speed and direction in the new weather menue structure (up to date next-branch). My intention was to set the wind profile from ground up to 3000ft. Hence I used the Basic Weather menue and set the desired values in the table. But I found that I got the wind speed and direction from the Advanced Weather Menue instead. Is this a bug/feature or am I simply to stupid to set the values correctly? Not sure what exactly you were trying to do. When you run Advanced Weather, it always uses its own wind model - it can't know what you entered in the Basic Weather config dialog and it doesn't care - we're not so far along the road to a merged weather system (if you were running Basic weather and it was ignoring its own config, that'd be a bug though). Advanced Weather has a few wind modes - constant (wind is the same everywhere), constant in tile (wind is the same in each chunk of 40x40 km, but may change between tiles), aloft interpolated (wind is interpolated based on the values entered in the wind dialog which is visible when you press 'show winds' and aloft waypoints (wind is interpolated based on a set of vectors both in altitude and in position - this is *very* cumbersome to enter manually and intended to run with online weather). Even the aloft interpolated modes don't allow you to select an arbitrary wind profile though, the low altitude interpolation altitude values are always 0, 5000 ft and 1 ft (this choice made following advice from TorstenD who had plans to get online aloft winds automatically in this format, something which isn't implemented yet), so you can only have a linear profile between these altitudes. The system doesn't allow you to specify wind conditions in the boundary layer, because it wants to compute them itself. You get a boundary layer which adapts to terrain roughness and local elevation, for instance there is no boundary layer slowdown of winds at mountaintops, and significantly less on upper mountain slopes than on the ground (which is somewhat important for ridge lift to work properly), boundary layer slowdown is far less pronounced over open water than in mountain terrain,... I suspect you were interested in specifying especially this region? In case you want to do something to the boundary layer computation, you'd have to dig into the code, this can't be done from config. Hope that helps. BTW: I'm totally impressed by the capabilities of the weather system, especially for glider pilots. I must admit that the weather system is a big motivation for me to keep up the development of a hangglider for FlightGear. Up to now the results are very promising. Soaring feels very realistic! Thanks. There's a lot of real life glider flying experience behind the convective cloud system and the thermals :-) If I find the time (which doesn't happen too often) I enjoy going cross-country with the ASK-13 very much. Like in real life, there are all sorts of surprises which can happen, and I always find mountain-soaring very exciting. Still need to implement that wave lift model at some point... Cheers, * Thorsten -- 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] Local Weather menu structure
The change is releatively small but I'd feel better if ThorstenR tested it before it gets picked. The menu structure works like a charm - I think the switching button is a very elegant solution. I did a couple of tests yesterday, and I didn't run into any problems here. I've also had a look at the impostor code. I tried a benchmark situation with some thin, detailed (= many cloudlets) and hence framerate-expensive layers to gauge the effect. It didn't really even work to set up the benchmark properly. * in sunrise/sunset conditions, I could see the impostors. They don't inherit the lighting from the shader, so they were showing up with the wrong colors which didn't look very natural, but at least there was something visible * in noon conditions, I couldn't even really see the impostors, as they were so faint and the sudden change in layer properties from visible to faint clouds was rather drastic * using the basic weather clouds, the differences where not quite as drastic and I could see the impostors, but I could still see quite well where the impostors started * under no conditions was I able to detect any significant framerate gain - just maybe something like 32 fps vs 30 fps, but that may have been driven by other factors - I think that agrees pretty well with Stuart's findings. So, I think that's functionality which is better left optional - it doesn't seem to do an equally good job for all cloud types, and the framerate gain doesn't seem to be there for everyone. Cheers, * Thorsten -- 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] Local Weather menu structure
I am hesitating from picking this into the release branch as one could argue if that was a bug fix. But if it's general consensus that this a an improvement that should make it into the release, we should do it. The change is releatively small but I'd feel better if ThorstenR tested it before it gets picked. Since the sunrise work is finished, I will catch up with master today and test a few things (I rather suspect that the water shader/environment interface may be rendered non-functional by some recent developments...). I'll also give the impostors a good try. BTW, if this change is merged into the 2.6.0 branch, we should also include commit a38820828c5343dbcb77d97a65597d736c845ff4, which removes a now-redundant reference to the local_weather_tiles menu item. I'm hoping this is local_weather_config.xml... local_weather_tiles.xml is actually the relevant menu :-) If nobody sees any issues, I would argue for deleting the menu itm also in the release branch, because a non-functioning menu can be considered a bug in my book. I also plan to make a list of by now obsolete files and textures. I'm too late for the release (I had this in mind a while ago, but the 6 weeks without computer really threw my schedule off the track), but I think it's useful to do some housekeeping. * Thorsten -- 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] Local Weather menu structure
Just an idea: as global and local weather are mutually exclusive, what about having just one single weather menu item and add button in each, global and local weather dialog causing the current dialog disappear and open the other dialog. While we are at it, I'd like to rename global and local weather to basic and advanced weather. So, let's add a Advanced-- button to the global weather dialog which closes the global-weather dialog, enabled local weather and opens the local weather dialog. In return, the local-weather dialog gets a Basic-- button which disables local weather, closes the local-weather-dialog and opens the global-weather-dialog. This sounds very convincing to me - I'm in favour of this solution. And we'd like to go that road further anyway :-) * Thorsten -- 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
[Flightgear-devel] Local Weather menu structure
My GIT is now a week old, but in all likelihood this hasn't changed and is in the release branch: In reaction to concerns about a confusing menu structure, I moved all relevant configurations to /gui/dialogs/local_weather_tiles.xml (insofar as they are not controlled by the rendering dialog, which now affects e.g. cloud visibility range). This means that the second dialog /gui/dialogs/local_weather_config.xml contains only obsolete options - with one important exception, which is the checkbox determining if the Local Weather Nasal module is loaded. This cannot simply be moved to the other menu, because it also de-activates the 'Local Weather' menu item, so if it is deactivated, the only option (short of the property browser) to activate the menu would be on the deactivated dialog. I don't know what the solution should be, but I don't think the current state of offering a configuration dialog which doesn't affect anything is very good for a release. On the other hand, it should be clearly recognizable that the Nasal module has to be loaded before the system becomes functional. If anyone of those who originally suggested that the config menu is removed could please take care of this? * Thorsten -- 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] Local Weather menu structure
It's not clear from your mail whether the local_weather_config dialog in the release branch can be removed once this checkbox issues is resolved. Can you confirm? I haven't actually tried if removing it causes an error somewhere, but it's not needed any more - all functions are either shifted to the other menu or don't affect anything any more. So my recommendation is indeed to remove it. I'd suggest moving the /nasal/local_weather/enabled checkbox to the top of the tiles dialog, and disabling the rest of the dialog when this is not set. That way the dialog can be available at all times, while users will not be able to set any local weather config without enabling it. Does that sound like a good solution to you? Would work fine, except that for me a checkbox to (de-)activate a dialog that way always caused errors (I tried at some point it to block inconsistent options on the GUI level, and I always ended up with garbage) - maybe I did it wrongly though. Cheers, * Thorsten -- 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
[Flightgear-devel] Atmosphere light - some personal perspective
And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? Project Rembrandt seems to be about something different - detailed rendering of shadows in the near zone (~15 km) - what I do is about approximate rendering of atmospheric shading in the far zone (~1000 Rembrandt is not just shadowing. A fair amount of code is about lighting. The principle is that the geometry is not renderer shaded at the first stage, but just geometric and material properties are recorded in textures. Then the lighting is done globally on the whole scene, with one pass for each light source. The atmospheric source (usually the sun but it could be the moon by night) is done by rendering a screen aligned quad on the whole scene, reconstruct the view position and normals from data stored in textures and apply whatever lighting equation you can write in a fragment shader. The fog is applied by another similar pass. The exception is transparent objects, including clouds, that are rendered the classical way and composited with the opaque world. I'm sorry if I misrepresented anything. Let me first say that what I have seen from it looks *very* impressive - especially the night video of a car driving around on the airport. I understand at best half of what you're saying :-) , but it seems to me that this is indeed orthogonal to what I am doing, and that we probably need to think of how to implement things optionally then. I realize I didn't really explain my thoughts properly, so here's a rather personal perspective: My stuff is based on a seamless integration of the skydome scattering shader. For rendering clear skies, that's a very nice piece of work, but it doesn't do in poor visibility because that's not solved by a single scattering approximation. So it needs also an optically thick part to account for poor visibility. That needs a matching terrain shader. But having that, suddenly possibilities arise - the atmosphere is no longer just something that fogs things in the distance - we can have realistic rendering of ground visibility different from aloft visibility, self-darkening of dense fog, seamless blending of layered clouds into the distant haze layer rendering - at this point I realized that 70% of what you see on a typical flight is not terrain, scenery or object but the atmosphere (think of distant scenery - a lot of the color is actually haze color rather than texture color). But that still isn't seamless for low sun, because the scattering shader knows that there is a gradient in light to and away from the sun, so the optically thick skydome and terrain shader must be told too. So, after implementing a differential light field in the shaders, it is now seamless basically everywhere at any time. You get proper and plausible atmosphere rendering from the ground all the way up to low earth orbit, from bright daylight into the night. Well, needs some parameter tuning, but the framework is there. But again that opens much more possibilities which weren't there before. It has the most spectacular sunrises or sunsets - a red band appears on the sunward horizon, high altitude cloud glow while the rest of the scene is still dark, red/orange morning light touches the mountaintops while the valleys are still in blue shadow, light creeps slowly lower and shadows appear in the haze, from low orbit crossing the terminator looks now quite spectacular as sunddenly the visible detail is largely stark shadows of the elevation data mesh rather than the more coarse landcover data, ... It literally brought tears to my eyes as I first saw morning light illuminate distant mountaintops and then approach during the next minutes to my position, so beautiful was the scene. And once we have a differential light field, a lot more can be done. The scattering correction can now applied to each point exactly, rather than with the mean value at altitude. In dramatic cloud scenes, haze here can be colored differently from haze there. I'm not very good in technical aspects of GLSL, and the relevant scattering integrals are too complicated to do real time in any case - so just half of this is physics which I worked out with pen and paper, and the other half is art, just the light field and the fog written into the shaders and the parameters tuned or controlled from Local Weather to mesh well with the rest of the scene - obviously the renderer needs to be told what the atmosphere is supposed to be like from the weather system. Ultimately, I realize full well that this is a dangerous path for development, because it doesn't work well with other shader-related development and breaks a lot of other good stuff. I lack the technical skills and the insight into effect file structure to implement this properly, so I'm fooling around here and there to make it work. The reason I am doing it this way is that it's simply the atmosphere light model I want. It can do all the things I've been missing
[Flightgear-devel] Default effects for cockpit
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 -- 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] Default effects for cockpit
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. Yes, I know that - but can you somehow catch that it's a cockpit you're loading rather than a scene model and hard-code that pointing to a different default effect file? * Thorsten -- 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] Default effects for cockpit
If I understand this correctly, you want to change the default behaviour for the scenery models while leaving the cockpit as is with the current default behaviour? Does it also involve changing the behaviour of the non-cockpit parts of the aircraft model? That depends... For most external views, one can safely assume that the plane isn't fogged and that the light is that light at the airplane position. Except for tower view if the plane is far from the tower - then it needs to be fogged. There's also usually better framerate in external views. To be on the safe side, I'd treat the external model just like scenery then and just dump the cockpit into a different class. At first glance this seems to be a huge task to modify each aircraft model, but it might be automatable. I would think the work should lie where it falls - if you want to change the default behaviour of scenery models do just that and leave the aircraft alone. Well, how would we do that then? Just some final thoughts - what is the framerate cost of this enhancement? Surprisingly, so far it doesn't show much difference to the terrain haze shader without differential lighting (the new code primarily hits the vertex shader - apparently the bottleneck is the fragment part). In practical terms, with the F-16 flying over default scenery (KNID to KLSV) I get ~17-20 fps with 120 km visibility range and moderate clouds. It strongly scales with visibility and terrain vertex count - Alaska custom scenery Juneau for instance hits quite badly with 120 km visibility range dependent on whether you look into details scenery US side, or default scenery Canada side. With the X-15 in suborbital flight and 250 km visibility range I get similar figures but no clouds (too high...). But this isn't optimized shader code, for instance currently all haze is done in the fragment shader which is a must for terrain, but for models this can go into the vertex shader since they're not so large, no scattering integrals for the lower half of the skydome need to be computed, ... And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? Project Rembrandt seems to be about something different - detailed rendering of shadows in the near zone (~15 km) - what I do is about approximate rendering of atmospheric shading in the far zone (~1000 km). The two approaches might be mutually exclusive such that you have to run one or the other, I don't know, but somehow the question itself strikes me as odd - certainly it's worth doing if only for the simple reason that I find it interesting working out what causes all the colors we see at sunrise. I take it that whatever you do it is not for the upcoming release? No - it's part of the terrain haze shader branch - the fate of which to be determined. Maybe it can be integrated properly, maybe it can be committed as an alternative scheme whenever the skydome scattering shader is on. Cheers, * Thorsten -- 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] Default effects for cockpit
I don't think you want to be changing the behaviour for all cockpits, just the one that is your aircraft. For other aircraft (AI/MP), you want them to fade etc. just like the scenery and the rest of the aircraft model. We seriously show cockpits over MP?? I actually wouldn't want to show them at all for distances where it matters if they would be fogged or not - some LOD animation should eliminate them long before... Alternatively, are you not already determining the distance of the object from the viewer? Can you now simply put an if() test around this, or are there fragment shader implications as well? It would also affect the fragment shader to some degree. But yes, one can in principle also do an 'if' statement, it's just one of these things which strike me as bad design, probing for 1000 vertices 30 times per second if the cockpit is still nearby... * Thorsten -- 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] Reminder for the release process for version 2.6.0
* All major bugs fixed? I found three in the last days - one major and two minor - since I have added some sunrise/sunset support features to my working copy of Local Weather, I'll just list the fixes rather than provide the updated files: *** local_weather.nas, line 2917 (just after 'Starting hard-coded terrain presampling'), insert the line setprop(/environment/terrain/area[0]/enabled,1); (we used to have to start it with that property, or this used to be part of the compat layer checks, but now it is needed to switch terrain presampling on properly). *** weather_tiles.nas, line 857: rn = 0.1; is for debug purpose and should be commented out. *** weather_tiles.nas, line 1004; var alt = spread * 400.0 + local_weather.cloud_vertical_size_map[Nimbus] * 0.5 * m_to_ft; has an obsolete altitude correction in and should just be var alt = 400.0; to get the correct altitude for Nimbostratus layers *** If someone could just edit these on FGData master please? Cheers, * Thorsten -- 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] Reminder for the release process for version 2.6.0
*** weather_tiles.nas, line 1004; var alt = spread * 400.0 + local_weather.cloud_vertical_size_map[Nimbus] * 0.5 * m_to_ft; has an obsolete altitude correction in and should just be var alt = 400.0; to get the correct altitude for Nimbostratus layers *** make that var alt = spread * 400; of course - otherwise the altitude is *very* low indeed... * Thorsten -- 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] Cloud altitudes in shader?
If you want to know the altitude, you need to have the matrix that transforms from the current view position/orientation to the earths center. And you need to transform from cartesian space into the earth ellipsoid. The best you can do is to do this per vertex. And even that is way too much computation for that single altitude that you can just set when you set up the geometry. The most efficient method is probably to set up a 4 vector plane equation that represents the sea level altitude horizontal plane in object coordinates. This plane needs to be updated when the cloud object moves significantly by the cpu code. In the shader you can then compute the distance to the plane in the usual way. That would give an altitude per vertex which would be even exact per fragment by correct interpolation. If you only need the altitude per cloud, put that scalar value in a uniform. That somehow seems way too complicated. We're currently rendering clouds to 45 km, my private hack does 75 km, in my wildest dreams I am speculating about 250 km, cloud altitude is always below 30 km - all these numbers are way smaller than the Earth radius, so a local Cartesian system and the first term of the Taylor expansion in curvature will always be enough to any sane accuracy. I have now a scheme that does seem to do the trick - high stuff and stuff towards the sun glows properly before lower stuff and stuff away from the sun. http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=15#p147240 The idea is: * compute the relative vector between eye position and vertex * get its z-component as altitude difference * pass the eye position altitude as uniform * add eye altitude to relative altitude - this is the uncorrected vertex altitude * use the known distance to correct for curvature to get the actual altitude (it's probably off by a few percent, but who cares?) I have the feeling there should be an even simpler way to do it, but after coordinate-system-crawling for 5 hours yesterday I'm simply not in the mood to try to find out. What derailed me for a while is that the shader doesn't do numerics to high accuracy - the small difference of two individually large numbers doesn't compute very well (I know it's a bad problem), and that screwed things up for a while, and so I thought the scheme itself was flawed, but I think I sorted that out as well. So, thanks for the input to everyone! * Thorsten -- 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] G115; Was Aircraft issues: dg101g, Lightning
Which motor aircraft do you use for towing ? Given the above figures I suspect you're using the Piper Cub, right ? Did you ever try the Grob G115 ? I've never flown that one, neither in RL nor in FG, but I *guess* it's probably the closest in performance and FDM credibiliy to commonly used towing aircraft. I tried it today and as far as I can tell from a simple setup with mouse-control only I'd say the G115 behaves sufficiently reasonable. BUT I'm _very_ surprised: Don't these birds have neither a speed indicator nor engine gauges on the pilots side of the panel ? Hi Martin, the DG-101G comes with a drag robot - I don't do multiplayer, so I couldn't test aerotow over MP, I just tried to hang behind the robot which itself was flying quite reasonably - just my glider was bouncing around wildly. Without MP, I don't think I have a chance to test aerotow from the other side, or is that implemeted somewhere? Cheers, * Thorsten -- 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?
Rather than passing in the eye position as a uniform, why not pass in the cloud altitude instead? Is this simply to avoid needing to modify the C++ code? I thought uniforms are things which are per frame constant in the scene and apply to all objects the same way - i.e. I pass light attenuation (scattering) or terminator position as uniforms to the shader. I don't see that cloud altitude falls into that category - it is constant per cloud, but not per frame throughout the whole scene, I have clouds with very different altitudes floating around. It seems on would need to pass it the same way as, say, the top, middle and bottom shade parameters on a per cloud basis. Either there's something I do not understand here, but I decided to pass eye altitude largely because that is a constant per frame for the whole scene and I understand what I am doing with it. * Thorsten -- 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
[Flightgear-devel] Cloud altitudes in shader?
Hi Stuart, is gl_Vertex.z a reasonably approximate guess for the altitude in which the cloud finally appears or do I have to look elsewhere? There's lots of reshuffling of the vertex coordinates going on in the shader, and I've kind of lost track a bit... * Thorsten -- 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] Aircraft issues: Vostok-1, (dc-3, dhc6, CRJ700, pa24-250-CIIB)
Thorsten, can you make a test flight and see if the instruments behave as they used to? I've just updated everything and had a short hop with Vostok to ~100 km altitude and 2nd stage burnout - at least five minutes into the mission, everything was looking and responding normally, so I'd assume that your fix was good. I'll try a full orbital insertion and return in the next few days (it's quite tricky and takes some time) - I want to test the the skydome shader performance anyway. Thanks, * Thorsten -- 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?
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? 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 (?) 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. * Thorsten -- 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] Aircraft issues: Vostok-1, (dc-3, dhc6, CRJ700, pa24-250-CIIB)
Thorsten, can you make a test flight and see if the instruments behave as they used to? To try it get the vostok-1 branch from my fgdata clone: git://gitorious.org/~andersg/fg/anders-fgdata.git If you tell me how to pull only Vostok from your fgdata? I have a GSM connection from home and not too much bandwidth... and my GIT knowledge is still rather limited. Cheers, * Thorsten -- 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] Local Weather 1.4
I've just committed to origin/next a better fix for the LoD range that adjusts based on the view distance, and also attempts to account for the possible size of the cloud itself. Thanks - working fine here! Does this contain the impostor functionality already or not? Cheers, * Thorsten -- 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
[Flightgear-devel] Aircraft issues: dg101g, Lightning
Continuing the list: DG-101G: I tried to do some soaring in the DG-101G. There seems to be something wrong with the plane's inertia. * To turbulence, it reacts much more violently than other planes. I thought a while ago that this may be due to a different implementation of turbulence in YaSim and JSBSim, but I'm not sure any more. Even a moderate magnitude of 0.2 leads to wild ups and downs from -4 m/s to + 4 m/s (the variomenter seems to react instantly, which is another thing which isn't very realistic). * The real giveaway is aerotow. I have to add that this is something I can fly and have done in real life, there's no way I am doing anything wrong. On the ground, when the dragger starts to pull and the rope comes under tension, the glider suddenly accelerates forward to ~180 km/h rises wildly and *overshoots* the dragger as if even the small force exerted by the rope could accelerate the glider tremendously (no intertia). In reality, it takes a lot of time to accelerate the glider under aerotow on the ground - for about 10 seconds someone needs to run with the glider to keep the wings level, for another 10 seconds or so the glider can do it on its own, then the glider lifts off the ground, finally the dragger lifts. It is quite physically impossible for the glider to overshoot the drag plane from above (and quite easy in the simulation), basically all you need to do is keep behind the dragger and try not to lift its tail too much, controlling speed is not an issue. In addition, I was unable to get any brake action either on the ground or in the air. The ground friction coefficients seem to be all wrong, the plane can roll for a kilometer after touchdown, but in reality once the tail comes down, that exerts quite a bit of drag and slows the plane down even if no brakes are applied to the wheel. Right now the only thing that does seem to work properly is gliding outside of thermals (probably the missing inertia factor cancels here, or the problem is with external forces only, but there are none?). English Electric Lightning: Nothing wrong with it, but if anyone would like to add a new splash screen picture, I have a nice series from the top of a ballistic arc at around 65.000 ft with nice aerial views of Nevada. Just let me know. * Thorsten -- 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
[Flightgear-devel] Aircraft issues: Vostok-1, dc-3, dhc6, CRJ700, pa24-250-CIIB
An (incomplete) list of issues I have observed in flying various aircraft recently - maybe some of them can be fixed by maintainers before the release: * Vostok-1 is currenty a no-show - it crashes before doing anything, the log seems to point to a property as the cause. I guess it *may* be a JSBSim issue (?). Being one of the few people who has actually flown the beast into orbit, I think it's a model well worth maintaining (especially as I am now able to create a bit better environment up at 120 km altitude using the skydome shader). In the forum vitos (the original creator) has clearly announced his intention not to maintain the model any further since we haven't delivered a new rendering engine, so it's looking for a new maintainer. Maybe some JSBSim person can have a look? * CRJ700: The altimeter on the main glass instrument is currently unreadable or displays the wrong altitude - the band hundreds runs correctly, but the numerals before can't be deciphered. Probably a simple graphics issue, the AP holds correct altitude. * dc-3: Very nice cockpit work - the manual needs an update though, starting the engine seems to require at least one more step than advertized (the selection of a fuel tank). Even then for some reason I got only the left engine on - repeating symmetrically what I did never started the right engine until I used the autostart function. * dhc6: Nice to see more details in the cockpit. Just, how the hell do I switch all the warning signs off? After starting the engines, the whole warning panel lit up (which I know from some other aircraft as a test mode), but the lights never went out. Plane was flying fine though. * pa24-250-CIIB: I still suspect that there's something not working correctly with the engine at high altitude. In 14.000 ft with mixture full rich, I should be choking the engine, but I don't seem to, it just runs fine and EGT drops to an abysmally low value. * Thorsten -- 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
[Flightgear-devel] High altitude horizon
In case there is any lingering doubt that Flightgear can't deal with horizon curvature at high altitude: http://www.flightgear.org/forums/viewtopic.php?f=19t=14844 (taking the X-15 to 270.000 ft) Done with recent Local Weather (which, as I discovered, is fine with Mach 6) and Terrain Haze shader, LOD bare range is 150 km, max. visibility is limited to 120 km (something culls the terrain when I try to get a bit more...but I'd probably run out of memory at some point anyway), frame rate was consistently between 20 and 25. No cheats or readjustments of the shader parameters - the whole change in the sky and horizon is seamless from the ground all the way up to 270.000 ft. * Thorsten -- 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] Local Weather 1.4
The LoD is currently hardcoded to 20km, so if visibility 20km, it kicks in before the transparency effect. I have a good fix that takes into account the current visibility as part of the Impostors work, but that won't be available until after the release. In the meantime, I can increase the LoD range to (say) 40km. However, there will probably be some performance penalty. What's the maximum visibility that the Local Weather package uses? We used to have 45 km range out to which clouds were shown. With the new more efficient system, I have made tests with 75 km (which is enough for a good impression even from airliner cruise altitude), see here: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg The penalty for having this is not so severe as compared with other goodies (it's cheaper than the terrain haze for instance). Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. Clouds are shown out to the same distance as normal 3d clouds since they are subject to the same distance slider. If you hard-code some lower number for the release, please let me know where to change it so that I can go back to my extended layer testing. * Thorsten -- 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] Local Weather 1.4
At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. What's more important from high altitude is what happens beyond view distance where no terrain is loaded. What you see then is the skydome, and the skydome shader for instance knows about the Earth radius and gives you (approximately) the right behaviour. A postcard from 85.000 ft is here: http://www.flightgear.org/wp-content/uploads/2011/09/fgfs-blackbird05.jpg (this is still from some early work where I didn't have the terrain haze shader yet - by now the seam between skydome and terrain is completely gone. I would redo these pictures except... I can't draw clouds to more than 20 km, and from 85.000 ft that means clouds aren't drawn at all because you are more than 20 km above them) This applies even to low altitudes. In reality you can see that the clouds wrap our planet. They do - Stuart spent a lot of time reacting to my complaints that clouds were placed in a flat layer initially :-) It's difficult to spot the curvature though, I can't (even conceptually) draw clouds to 140 km without changing the code in a major way. * Thorsten -- 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] Local Weather 1.4
We should agree on a common place to publish actual surface wind (for one or many given locations?) in the property tree. /environment/config is definitely not the best place to use but due to historical reasons, many objects rely on these properties (windsock, chimneys/smoke, many more). Someday, we also might want to have winds aloft data for one to many locations and altitudes, so it might be worth to think It's actually surprisingly intricate. For instance, Local Weather allows for boundary layer gusty winds. For some problems (the wave pattern) you'd like to have the base (mean) wind at the surface, for others (windsock) rather the actual wind that the aircraft is feeling. I am now internally storing the interpolated wind (wind at aircraft location and altitude based on all available 3d interpolation points), the current wind (interpolated wind after local boundary layer correction and gust effects), the interpolated surface wind at current location and the current surface wind at current location. May I suggest a subfolder /environment/surface (and possible subfolders /environment/location[i] in case a location other than aircraft position is needed? /environment/surface/ could then contain surface-base-wind-speed-kt surface-base-wind-direction-deg surface-actual-wind-speed-kt (for gusts) surface-actual-wind-direction-deg (for variable winds) In addition we could maybe use effective-cloud-coverage-octas (how much is covered by the sum of all relavant layers) wetness-flag (boolean - in case we want to use wetness-dependent textures) snow-level-ft ...? What would shader people like to use? I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple 2d-layered clouds without shaders to the full-sized weather model in just one system. Hopefully not with a plain Nasal implementation, but by using existing and new FlightGear systems and Nasal. I wouldn't have any problems with that. It's just difficult for me to imagine how it would look like, as the philosophy is rather different. Although the boundaries become more and more blurry since now both systems refer to the same set of cloud textures and to the same rendering system. If anyone has a vision how the finished product should look like, please let me know :-) By the way, Torsten, could you clarify the status of --prop:/environment/terrain/area[0]/enabled=1 to start the terrainsampler in 2.6 - will this be needed at startup (i.e. should I re-activate the check at startup if this is on), or will the sampler be available automatically, i.e. can I assume that the system will be available? * Thorsten -- 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
[Flightgear-devel] Local Weather 1.4
Local Weather is now (almost) in the shape I would like to see in the release, and I've worked quite a bit through the list of issues: 1) Local Weather places clouds at the wrong altitude. I've corrected that. 2) The GUI is not consistent with the system (I will fix that) A new gui combines all needed option and in principle obsoletes the Local Weather config. Problem: After on-demand loading of Nasal modules was introduced, the Local Weather Config menu contained the checkbox which determined if it should be loaded or not and if the Local Weather menu item was accessible at all - where should this go if the config menu item is removed? 3) High-altitude single-layer non-rotated clouds get shaded when the ground gets shaded (I verified that they are subject to /rendering/scene/saturation, but I believe I can undo this dependency in the model xml wrapper - I'll try to deal with it) The correct solution to that turned out to write a shader for static clouds (much like the rain layer - in fact I could have used the rain layer shader with different parameters, but I chose not to because I forsee the use of a different fog function and different lighting for rain and high-altitude clouds). In addition, these clouds are moved to render bin 9. This seems to get the correct depth ordering and apparently also removes a lot of transparency artefacts I have been seeing previously. 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? I have verified that the corresponding tile is already loaded, so it's not something my part of the system does. With GIT pulled just before Xmas, I still see a hard-coded limit of ~20 km cloud visibility range which makes impossible for me to test layers appearance from above properly. This is very annoying, I hope the underlying problem is identified and fixed soon. 5) Changing the cloud density slider with LW clouds in the scene still erases all clouds for me. Imho, would be a net option to have. Stuart, what are your plans? Will not be addressed for 2.6. 6) External rain textures are visible through clouds from above, Moving them to render bin 9 solves the issue for good. 7) Similar problem with non-rotated high-altitude clouds - they are always drawn in front of any other clouds, which looks silly when you see them through a low overcast layer. See above. 8) Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which always renders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? Still to be fixed. I tried a workaround using negative cloud altitudes with respect to a very high layer, but Stuart's system doesn't accept that, so I really can't fix this myself. 9) Water shader (very impressive!!!) doesn't react to wind/overcast in Local Weather. Vivian, Emilian - at some point we discussed an interface of how to pass the situation to the shader. Technically it's really easy for me to write in any form you like - just tell me where you want to pick up that info. The current implementation works by writing into the Global Weather config which does the trick. Let me know as soon as a different interface is in place and I'll change the code accordingly. 10) Skydome scattering shader - is now basically broken in overcast situations when visibility is low, because the clouds fade rapidly but the shader doesn't react, so more blue sky is seen when visibility goes down. I have a working (slow) seamless version of the terrain haze shader with recent GIT, so the shader continues to be maintained even if it doesn't make it into 2.6. I've also found and fixed a few bugs. Recent version of Local Weather (still lacks updated documentation), please test: http://users.jyu.fi/~trenk/files/local_weather_1.4.tgz Current version of the haze shader: http://users.jyu.fi/~trenk/files/terrain-haze-23_12_2011.tgz (use a separate GIT branch, because it overwrites several default files - also doesn't work properly with global weather or any other shaders) Cheers, * Thorsten -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development.
[Flightgear-devel] Grassland vs. GrassLand
And another materials.xml issue: materials.xml has the spelling 'Grassland' whereas materials-dds.xml knows both 'Grassland' and 'GrassLand'. I believe the intended spelling is 'GrassLand', at least the other spelling leads to problems with the newly compiled Colorado and Minneapolis sceneries. * Thorsten -- 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
[Flightgear-devel] AI traffic off?
Does anyone know how to switch AI traffic off? I edited preferences.xml and autosave to verify that it's set to false, I checked /sim/ai-traffic/enabled to be 'false' - and yet tons of messages still pass my screen about AI aircraft starting up. Am I missing something obvious? * Thorsten -- 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] Weather issues for 2.6
We are still looking into this one. At first glance there doesn't seem to be any good reason for the wind not being honoured. The overcast is a problem of interpreting different implementations between Global and Local weather. Now you are back operational we will try to come up with a suggestion in the next couple of days Seems you are currently referencing /environment/sea/wind-from-east-fps for the actual shader work(?) which seem to be tied to the global weather boundary layer. Problem is, I can't set that directly, but I wrote a hack yesterday to write into /environment/config/boundary/entry[0]/wind-from-heading-deg , and that does the trick quite nicely (see http://www.flightgear.org/forums/viewtopic.php?f=19t=9446p=144955#p144955 for screenshots) But I'd much prefer a different interface - writing into global weather config isn't something I should be doing - so this was just a test for me to see how it looks like. A couple of observations: * I've been unable to work out what triggers the color of the water. In some cases I had overcast and reduced lighting set and got green water, in others it went grey (I haven't looked into the shader code though). * I have an implementation of gusty winds which I tried. My code actually provided the mean wind (i.e. before the gust correction) to /environment/config/boundary/entry[0]/ , but set the actual wind felt by the aircraft after gusts. Nevertheless, each gust triggered a redraw of the wave pattern, so that's something we'd perhaps rather avoid. It seems a change in wind triggers new parameters being passed to the shader and a redrawing, but it doesn't actually take the wind parameters (?) - something is confusing me. Anyway, an interface should be robust against gusts and ask for an average rather than the actual per-frame winds. * The wake effect of the carrier is also something that is drawn before the cloud - you can see it through an overcast layer, which makes the carrier unusually easy to find in bad weather. We had some problems with adapting the ground haze shader to the new, universal fog scheme. At the moment, our results are unacceptable for release. We are not clear at this stage if we can do it at all, and we are unlikely to come up with a tested and tuned solution by the 17th. We will continue to work on it in the next few days to come up with a better informed decision on the way ahead. Okay. Is there something I should still be doing? I'll try to rebase my haze shader branch with the recent developments to see if I can keep it alive. Maybe it's better to try to insert this into the 2.8 release, as it is quite a substantial and capricious piece of work... Some improvements to the wake of Vinson are likely to have cost some framerate. These can be reverted by selecting a lower quality setting so it should be possible to compare like-with-like. Yes, I did that. Switching all water shaders off got me from 15 up to 20 fps - it used to be around 35, so there's still a chunk missing. Could AI traffic cost that much? * Thorsten -- 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] Weather issues for 2.6
I've just placed a patch into the forum fixing the altitudes, providing a new GUI which makes Local Weather Config obsolete and ports Cb towers also to the new rendering system. I haven't tested it excessively yesterday, but most of it was written and tested before my computer died, so it should be fine. You should be able to set the render bin for the effect if you are using one. Alternatively, it may be that we can get more performance from the clouds such that we won't need to put them in a separate render-bin. Hm, this seems to be more subtle then. I adapted rain-layer.eff from cloud.eff and as a consequence I see that in both files render-bin bin-number10/bin-number bin-nameDepthSortedBin/bin-name /render-bin occurs. So that is in fact not the problem?! But then what it - why are the rain layers always sorted in front of the clouds? * Thorsten -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weather issues for 2.6
Thanks to Hooray who helped me setting up the CMake environment and the guys at Infocare who finally managed to fix heat management of my computer, I am now back on the devel tree. I've done a few tests yesterday and identified a list of weather-related issues which I think should be addressed (unfortunately, I can't do all myself). (all refers to GIT as pulled yesterday afternoon and FG, SG and FGData in sync) 1) Local Weather places clouds at the wrong altitude. (I will fix that). 2) The GUI is not consistent with the system (I will fix that) 3) High-altitude single-layer non-rotated clouds get shaded when the ground gets shaded (I verified that they are subject to /rendering/scene/saturation, but I believe I can undo this dependency in the model xml wrapper - I'll try to deal with it) 4) Clouds now appear to be loaded in discrete lumps when they come into visual range rather than gradually be faded in via transparency which looks a bit ugly from high altitude - Stuart, is this intentional and a performance-related issue? I have verified that the corresponding tile is already loaded, so it's not something my part of the system does. 5) Changing the cloud density slider with LW clouds in the scene still erases all clouds for me. Imho, would be a net option to have. Stuart, what are your plans? 6) External rain textures are visible through clouds from above, looking very silly. As far as I understand, since rain textures are true models with 2d billboard animation whereas clouds are sprites with shader rotation, the issue here is the render-bin again (?). I see three possibilities - either we write a 2d rotation shader like the cloud shader and use it for the rain textures and the infrastructure to go with it, then rain is just like clouds and it should be fine. Or there is a way to assign a render-bin somehow to the model as it is loaded. Or external rain textures go away for the moment. 7) Similar problem with non-rotated high-altitude clouds - they are always drawn in front of any other clouds, which looks silly when you see them through a low overcast layer. Most of the time it's not so bad though, since clouds on clouds is low contrast. So again, either they get a non-rotating cloud shader and the infrastructure (difficult, since they're really on curved sheets modelled to follow the cloud structure) or they can be assigned to a bin which does the sorting right. Or they stay as they are. 8) Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which always renders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? 9) Water shader (very impressive!!!) doesn't react to wind/overcast in Local Weather. Vivian, Emilian - at some point we discussed an interface of how to pass the situation to the shader. Technically it's really easy for me to write in any form you like - just tell me where you want to pick up that info. 10) Skydome scattering shader - is now basically broken in overcast situations when visibility is low, because the clouds fade rapidly but the shader doesn't react, so more blue sky is seen when visibility goes down. In October, I had a near-seamless solution to that involving the ground haze shader, a modified skydome shader, and modified cloud distance fading behaviour which did the trick both for local and global weather (which was also posted in the forum as very experimental feature). Is anyone (Vivian, Emilian?) still working on that - or should this better go into the next release? All in all, the performance requirements of the current version are weird. I took my Carrier-Ops flight from Vinson to Nimitz in the F-14b which used to have good framerate (no terrain) and I ended up with 14 fps. Not really improved a lot by switching water shader off... I then wanted to know how far down it'd go in really detailed scenery and used the Lightning to blast around Hawaii to Maui - with similar cloud coverage I ended up with twice the framerate and a comfortable 24-30 fps. With the Concorde on the runway in Seattle, I had a whopping 3 fps (never seen anything this low...), but the AAr with the F-16 around Las Vegas gave me 34-40 fps (again in similar clouds). Doesn't agree at all with my previous experience. Cheers, * Thorsten -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
IIRC clouds were moved into bin 10 to improve appearance vis-Ã -vis particles. If we put clouds back into bin 9 and particles remain in 10 all the cooling towers, chimney efflux, aircraft contrails, exhausts etc. are drawn after the clouds i.e, in front. Rather looks as if we can have realism or framerate but not both. Are these assignments runtime-changeable? If so, one could use a simple criteria to get it (roughly) right. * particle effects associated with an aircraft are always drawn in front (they must be nearby to see them anyway) * aircraft contrails are always treated as clouds (they are clouds) * ground-based model effects are drawn in front if the current view is below some decision altitude, and they are drawn at back if the aircraft is above (with the decision altitude being the lowest cloud layer) This set of rules should get so much right that the exceptions don't really matter. Cheers, * Thorsten -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
But this is definitely some food for the brain. Here is what they write: So, how do we render these clouds in x-plane 10? the answer is levels of detail, which is a display of resolutions of buckets. (...) AGAIN! NO MATTER HOW BIG THE SKY, EACH LEVEL OF DETAIL ONLY COSTS US 1,000 PUFFS! Cutting through all the excitement of the blog writer - we've been discussing this previously, and (at last I) disregarded it for the following reasons: 1) Using many small 'puffs' (or 'sprites' in Stuart's terminology, or 'cloudlets' in mine) are a nice way to render diffuse shapeless clouds, but to arrange them in such a way that you get the correct shape of a well-defined Cumulus cloud is near impossible (which is way we use not so many larger full-cloud image textures). 2) Setting up 'puffs' of different size dependent on distance in a static setup is all nice and crispy, but unfortunately the darn airplanes *move*, so you need some algorithm which replaces a collection of small puffs by a single large puff - and this transition shouldn't actually be visible. If you code it for just a few configurations, it can be done, but then your clouds lack variety. 3) The problem that follows from the above two is that you must make a transition from a Cu cloud composed of 100 small puffs to one which is a single large puff, but the cloud shouldn't change visibly while you do so - which is tricky because Cu clouds have a lot of structure. 4) The problem is worsened by the fact that Cu clouds are not exactly self-similar across too large distance scales - a single puff which works well to represent a cloud from the distance isn't represented well by 10 smaller versions of the same puff - the shape gets wrong. Instead, you'd need a mixture of different smaller puff types dependent on where in the cloud you are. 5) Talking about km-sized puffs at distance is all nice, but the cloud layer may just be 100 m thick, so you can't represent it by 1000 m scale puffs without making it thicker than it really is. Again, with shapeless clouds you can use z-rescaling to deal with the problem, but with structured clouds, that shows up in a very pronounced way. My guess is that X-plane with this approach invites trouble with representing cloud structures, but fares better with very featureless clouds. Also, shape variation of clouds might be an issue, dependent on how this is coded in detail. It's not a bad idea, but the devil is in the detail, and a dynamical way of doing a reduction of complexity at distance (= the imposters) seems a better way to me. Anyway, it's hardly like this writer invented the wheel... Cheers, * Thorsten -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Trying to get more performance out of the 3D clouds!
Since according to the newsletter Stuart's current ongoing quest is to get better performance for 3d clouds, here are some of my observation: * I've noticed that when I use the relatively lowres Altocumulus texture sheet (3x3 on one sheet) I can basically use a ridiculous number of sprites without performance deterioration, whereas when I use the hires Cumulus sheets (1x2 plus 1x3) the number of sprites I can show before performance takes a nosedive goes down substantially. The high resolution is however only needed for the small amount of clouds which are relatively close, but what makes a real difference is the amount of distant clouds, because there are so much more. So my guess is that using lowres textures for distant clouds would do just fine and improve performance. I've been wondering if dds sheets with the mipmaps would not automatically address that problem. The other option to test would be to scale down the resolution of the Cu cloud textures and see if the result is still acceptable (I know it isn't perfect, there was a reason I went to high resolution in the first place, but maybe the flaws can be hidden by the right mixture with other texture types). * There seems still to be stuff computed in the shaders per vertex that is actually an uniform per frame - eyepos for instance. I wonder if the computations could be speeded up significantly by consequently pulling all things that are really uniforms out of the shaders. * We're likewise fond of computing stuff per frame that changes more like per minute. The orientation of faraway clouds doesn't have to be computed per frame, because it can't change much per frame. If there'd be a way to store the value used last time, then (based on a distance criterion), one could assign clouds into n task groups and recompute a task group only every nth frame and use the last stored value otherwise. Back when I rotated clouds from Nasal, this did work and improved performance by a factor 5 or 6 - not sure how much it could do with a Shader setup, not sure how to do it technically, but my guess is that it would speed things up. Maybe some of this helps! Cheers, * Thorsten -- 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] Trying to get more performance out of the 3Dclouds!
Vivian: We also note that you are back to using the .png textures with their black edges etc., rather than the .dds that we provided. Use of .dds textures should at least be no worse than .png and at best will provide a small performance advantage. That's a technical requirement of Stuart's system, no intentional step: Textures have to be arranged in regular m x n structures on the sheet. I don't think I have seen dds textures from you with this structure. What I used earlier and what you converted to dds where textures associated with a model which supported any arrangement of textures on the sheet. The dds couldn't be used, and I needed everything in m x n sheets in a hurry - Emilian at some point offered help for the transition in the forum, but that apparently got lost on the way. My original intention was that the texture sheets get completely reworked and replaced by better quality imagery where possible, then converted to dds while the current sheets are to be used for a transition period only. But evidence suggests that that period may be longer than expected... So again, there is no intention to disregard your conversion work involved here - sorry if that impression was created. * Thorsten -- 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
[Flightgear-devel] Off-topic help request
Not related to Flightgear, but with the hope for some help from Linux-knowledgeable people here: I received my laptop back with a replaced motherboard yesterday, and it seems to be working fine apart from... a suspicion that I've lost fan control. I can't be sure, I never checked the state of things before since everything was just working, but: 1) NVIDIA display settings with the Thermal Monitor shows the GPU in yellow region (75 deg C) even without any 3d rendering load. 2) heavy computations did previously cause an audible fan increase (I used that to check when a calculation was finished) - not there any more even when I start with heavy CPU load I have no idea what normal temperatures for GPU and CPU would be (I know the computer did get hot when heavily used), I have no real idea how temperature management under Linux is supposed to run, and I even don't know if it is even possible that everything else works and just fan control is gone after a motherboard change or if I am just being paranoid. So if anyone could spare the time to contact me off-list with some suggestions for diagnostics for a slightly antique FC9 system and possibly some additional help and pointers, I would really appreciate it. I don't really want to re-install Linux from scratch unless absolutely necessary, because that means another month or so till I have everything back running. Thanks in advance, * Thorsten -- 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] Shaders vs. frame rate;
Spoke too soon. The trees look great, but the frame rate hit makes it unusable (from 30-35 to 2-4) even with the other shaders disabled. Thank you! I haven't had seen trees in FlightGear for ages (can't run with shaders). I didn't realize the trees were supported at all without shaders. Trees are still done with shaders - all that is being discussed is if the menu option 'material shaders' should deactivate trees as well, or if it is sufficient to just (de)-activate trees using their own checkbox. * Thorsten -- 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] Shader properties and dialog
In any case, the 3 frame rate killers here are 3d Clouds, Trees, and AITraffic. Compared to these, the effect on frame rate by shaders is trivial. Not for me. For me, the landmass effect at quality 3.5 (or 4? - I can't check without computer) is the killer - with nothing else enabled, it brings be down from 60 to 12 fps. 3dclouds can be adjusted as needed with the distance slider - having a similar slider for trees rather than having to hack materials.xml would be rather nice. Landmass being so expensive, I can 1) have landmass off completely to run other shaders at high quality setting (which is what I'm doing, so I always have to shift the snow line as high as possible to not get artefects because some terrain doesn't show snow now) 2) run all shaders at low quality, even those which run fine for me at high quality settings So I am very much in favour of a more detailed dialog which allows me to select quality levels of shaders individually (with the convention that quality zero is off). * Thorsten -- 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] Local weather stopped working
Hi, I know that Thorsten Renk is having to deal with some hardware problems, so that he may not be around for sometime. Nevertheless, we have been promoting the local weather stuff quite exensively, so I would really like to demonstrate it at FSWeekend. The problem here is that still the 'old' gui is on GIT while the new rendering system is active, so there is a mismatch. You have dynamical weather on, and what the system is prepared to do is to create information for a quadtree structure for a new cloud which doesn't need or have that structure, so the parameter isn't defined. This doesn't have a proper fix yet because the problem will disappear on its own when the option 'dynamical weather' is gone from the gui - in the new system clouds move with the wind anyway, so there is no need for the opion any more I have just started on the new gui, and he first sketch is in my forum-posted snapshot of the terrain haze shader. But (as you observed), unfortunately my laptop seems to be gone for good - apparently the motherboard is dead and can't be fixed locally, so while I don't really have data loss, it seems I need either a new computer or send it in, both of which may take a while. Currently I'm sitting on my 8 year old spare laptop, which is good for emails, but doesn't have either performance or harddisk space for a Flightgear development environment. If there are serious problems with Local Weather till I have a new setup, I can probably comment on many issues without running the code, but I can't actually maintain or debug the code :-( Cheers, * Thorsten -- 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
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
My current setup can be found here http://www.phy.duke.edu/~trenk/files/terrain-haze-shader24102011.tgz I've now tested a few more things: There are still some issues with ocean tiles left - I *think* throwing in more vertices will fix this, or Emilian's hack of testing point altitude against layer altitude rather than doing trigonometry. Most of the changes are actually to the skydome shader which had wrong assumptions about what the terrain shader does. Seams are still rather obvious at sunrise/sunset *if* the terminator position is set appropriately (that's currently done via a Nasal hack too I figure out what the exact function should be)- I still have a mismatch between terrain and shader geometry and need to dig into this again. But I want to spend some more time on figuring out sunrise/sunset anyway. I've also transferred some things into the vertex shaders - I have the impression that is a bit faster. Cheers, * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
Also there's a bigger issue here. The number of varyings is limited (in fact it's the most constraining limit of all the limits present), and integrating this with other shaders will become problematic. Moving stuff in the vertex shader has the unwanted effect of requiring more varyings... Unless it's significantly faster for you than for me, we need the speed to come from somewhere. I believe we can save varyings by computing things as uniforms - hazeColor for instance actually is a uniform, I just don't know how to compute it outside the shader and pass it. The whole relative geometry between sun and eye is uniform. Cheers, * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
Yes, doing stuff once per vertex rather than once per pixel is faster, but also may lead to poor results. The more stuff you do in the vertex shader the more visible the mesh grid will be. Maybe someone can really enlighten me on this point: My understanding is that * the vertex shader computes stuff for each vertex If I don't use a fragment shader (as e.g. in the 3dclouds), things like shading get a linear interpolation between vertices. * the fragment shader allows me to specify a non-linear function to interpolate between vertices If I have two points with distances d1 and d2, I can either compute fog1 = exp(-d1/vis) and fog2 = exp(-d2/vis) in the vertex shader. The result will then be a linear increase in fog from fog1 at d1 to fog2 at d2 - which is in general very wrong for large d1-d2 because the actual result is exponential and not linear. Or I can pass d1 and d2 to the fragment shader and compute the non-linear exponential there - which would give me the correct result, since a linear interpolation between d1 and d2 actually should be an exact result. So there should in fact not be any loss of accuracy when I move linear quantity computations to the vertex shader, this should only be true if I move non-linear quantities. Is this essentially correct? * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
1. You forget the fact that in the end this all gets applied to faces
(triangles), and a point inside the triangle will have a value
interpolated
between the values of the three corners. I don't think that's a linear
function anymore.
Then the fragment shader would never get correctly interpolated distances
as these are linear (?!)
2. Afaik light scattering and in the end fog isn't a linear function, so
you
get wrong results anytime an edge length is close to the value of the
visibility distance.
Yes - which is why I left the non-linear fog function in the fragment
shader and moved the linear geometry computations into the vertex shader.
You can pass any precomputed value from the property tree as an uniform
just
as you're doing with ground-visibility-m.
Remember, an uniform has the same value for all vertices in the mesh,
and then
for all the fragments.
Yes, the angles between eye and sun are constants per frame throughout the
scene :-) So is hazeColor. My problem is not passing the value from the
property tree, my problem is getting it there - I'm not a C++ coder, I
have no clue where to look for gl_LightSource outside the shader, I have
no idea how (lat/lon/alt) property coordinates map into (x,y,z) in the
rendering process and I have no real idea how to make a vec3 out of
property values.
Which is why I asked for help in the first place...
* Thorsten
P.S.:
The edge between fog/unfogged areas is too hard now, and it still doesn't
match the horizon.
The edge is just as hard as it was previously - the functional form of the
fading hasn't changed. But just insert any distance function you like in
float fog_func (in float targ)
{}
and see what works best for your taste.
As for matching the horizon - it did in all my tests which were not at
sunrise/sunset - which combination of visibility-m ground-visibility-m and
ground-haze-thickness are we talking? I have just tried a few realistic
cases which I suspected to be problematic, but for instance a pathological
case with ground-visibility visibility would probably not work,
ground-visibility 25000 m starts to create other issues unless you
really open visibility into the 100 km range, I haven't tried extreme fog
like a 1 km thick layer with 50 m visibility. All I can say is that it
worked seamless in normal cases for me.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
I'm using 100-300m thick layers with visibility anywhere between 200 to 600 meters, in the layer.. then I play with the global visibility using z/shift-z. Problems arise with increased global visibility, at higher altitudes. Okay, got it - thanks - mean one. Basically, you're never looking at the top of the layer, you're looking about one attenuation length into the layer - but under a shallow angle, that is essentially the layer top. Now, the amount of light decreases as you go lower and lower into the fog, so you get to see slightly darker fog looking straight down than looking under an angle, but the skydome shader doesn't know this because it doesn't have any concept where things are in position space, it just knows angles. That's why the colors don't match exactly. I might be able to correct for that... While I was thinking, the ocean tiling problem actually looks similar to my terminator too-large-numbers problem - which is why your altitude comparison works better because it doesn't have a large distance in the game. Will have a look *sigh* (really want to fly for a few days instead of fixing things - I'm logging 10 times more time in the ufo than in the sum of all other aircraft). Cheers, * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
After spending half an evening trying to wrap my head around the ocean problem, here's what I found out: Just to be sure, I moved the geometry back into the fragment part - this indeed seems to work more accurately. Then I switched ground layer effects off and computed just with distance attenuation (as the default shader does). Basically, I think the geometry works just fine, i.e. the code is correct but there's something else going on which is funny. First, note that the water vertices are fogged correctly, it's just the lines between them which don't check out. Whoever based the default shader on a distance measure fogCoord = abs(ecPosition.z / ecPosition.w); instead of the true distance to the vertex obviously knew this: While this screws up the fog at the periphery (it computes the projection of the distance to the current view axis, so if it's in the center of the screen this is the distance, but if it's at the edge the fog is (for 120 deg FOV vastly) underestimated). Now, contrary to my first impression, in a pure distance fading picture this largely compensates for the error on the line between faraway ocean vertices, i.e. it is pretty good in removing most of the ocean problem (without the ground haze layer - with it it screws the whole trigonometry because all the altitudes compute wrong if you insert something which isn't the distance as a distance, so I can't use it anyway), but it introduces wide-angle artefacts over terrain. So, I think that function has been used here intentionally - if the person putting it there could please comment? Thus, I think we're dealing with a known problem, and for all I can see it really has to do with vertex spacing. However, artefacts aren't limited to vertex spacing. Using Emilian's test setup, I proceeded to render very dense, thin ground fog layers. Here's an area above KINS: http://www.phy.duke.edu/~trenk/pics/shadertest4.jpg Note on the left part that even for large distances, the fog is able to trace fine features of the terrain. This would be completely impossible if we had any real problems with the geometry or the distance measure. But now focus on the lower right - there's a very ugly wedge which doesn't really belong there. To me this seems like a fault in the terrain mesh which is picked up by the shader which gets a wrong distance. If you make the fog layer thicker, it gets swamped eventually. To test that conjecture, I've moved to an area where I know a terrain mesh faultline (north of Grenoble with France custom scenery). Same exercise: http://www.phy.duke.edu/~trenk/pics/shadertest5.jpg To the left, you can see that the shader gets even very fine terrain features right out to large distances. To the right is the terrain fault line (there's even a blackish line which corresponds to a real gap in the terrain overlap) - and lo and behold, the shader gets completely thrown by the terrain mesh fault line. So I believe at least part of the problem is that it gets drawn to problems in the terrain mesh. Maybe there's also something funny with the ocean mesh - apparently it doesn't need to be a visible problem to be picked up by the shader. Hmm, that's not what I'm experiencing here. What I see is insufficienlty fogged tiles at the edge of visibility, where I would expect them to be fully fogged (either by the haze layer or by the fog). Haven't seen those, but: Switch ground haze off (set altitude to zero). Then you're left with standard fog based on distance. Ramp up the fog function to the degree that everything fades out properly. Then switch ground haze back on - this adds fog, so whatever was faded properly before should now be faded as well. Whatever else you see is coloring mismatch, nt incomplete fogging. I have a slight residual color mismatch whenever there are thin layers and finite terrain elevation. That comes from the fact that the actual color seen depends on how deep into the layer you look, and that depends on terrain (if the layer is 1000 m deep, but the terrain is 990 m, you can only go 10 m deep). However, the skydome can't know how high the terrain is where it is not loaded, so it makes the default assumption that the terrain has zero elevation - which might overestimate the darkening of the fog, and thus we get a mismatch. There is no solution to this one, I'm afraid, except to load terrain farther out. Going to do something else now - I'll dream of fog otherwise... Cheers, * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
Emilian and I have been busy investigating the integration of these shaders into the shader system that we are evolving. The good news is that we have come up with a fog function that can be easily included in all relevant shaders. The bad news is that in doing so we have bumped up against what we believe are bugs in your original shaders. The haze seem to work fine in some situations - but not in others. I've been unable to clone your GIT repository from home (it was one of those 20 kbit/sec days), but I think I have successfully addressed several (all?) issues in my working copy of the shaders. In particular, there is a problem over the ocean: http://imageshack.us/photo/my-images/217/fgfsscreen031.jpg/ this is caused, we think, by the haze being attached to the vertices in the tile in the .vert. This appears to be largely gone for me now (?). I suspect the cause may have been the line fogCoord = abs(ecPosition.z / ecPosition.w); which I found in the original default.vert and used as distance measure - which it isn't however. The long-standing issue of the number of tiles loaded needs to be resolved - the haze no longer hides the join: http://imageshack.us/f/825/fgfsscreen033.jpg/ but this isn't a unique haze problem. This was an easy one (and the reason I asked about this a while ago) - I had assumed that visibility is one optical attenuation length, however it several, so the task was to work out the precise assumption of the tile manager, and the number turns out to be two, so I inserted that into the fogging function and all tiles are then fogged out before the tile manager unloads them. This led to the discovery of a bug which drew the default skydome background in a slightly wrong color (it didn't account for the scattering parameter whereas terrain-haze did) which should now also be fixed in the skydome code. Downtown SF with the default sky: http://www.phy.duke.edu/~trenk/pics/shadertest1.jpg and for the same visibility (ground-visibility-m is set to zero, so there is no ground layer effect here) with the skydome-terrain-haze shaders: http://www.phy.duke.edu/~trenk/pics/shadertest2.jpg which now shows about the same visual impression for when objects can no longer be seen. And with the ground haze on - 6000 m haze thickness, about 12 km visibility inside the layer http://www.phy.duke.edu/~trenk/pics/shadertest3.jpg I'll package and upload all this to the forum link tomorrow (my upload here is as bad as my download) and let you know. I haven't tested all possible conditions (lighting, low/extremely high altitude,...) but I think this is some progress. Cheers, * Thorsten -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
As for the topic brought up here, I sense a bit of sentimentalism clouding the technical judgment of some. (...) In a positive creative development structure you leave the contributors their freedom. Contribute your planes! rather than Come to Gitorious, ask for our permission to get your repository, work under our supervision! Work, work, my busy bees, and make us planes for our big master-repository! Freedom naturally finds its limits where it impacts on the freedom of others - you seem to miss this point. You always have the choice to make your development available in whatever form and license you like. You can create your own hangar, present your work there, are free to use whatever license you like, are free to offer whatever level of user support you like, you can even sell your addons ... You can also offer your work as part of 'The Flightgear Project'. Once you decide to do so, it is no longer your freedom to do what you want with your work - it is under the control of 'The Flightgear Project', you may have to compromise, you can't choose your license, But you get something in return for giving up that freedom - you get to use the official Flightgear infrastructure (you aircraft will be for download on the official page, others test compatibility, other developers may take care of your work when you're not around, others will feel responsible to provide support if they can,...). You seem to entertain the idea of a free lunch - get the goodies which being part of the Flightgear project has to offer, but keeping the freedom to do what you want. That may be a positive creative development structure from your personal point of view, but certainly not for everyone else who is then supposed to provide infrastructure for you. This has nothing to do with what technical possibilities GIT offers, or what GIT is about - it's just common sense that there has to be a balance between give and take whenever people interact and work together. So, if you like your complete freedom, you can't be part of a collaborative project. It's as simple as that, being part of a bigger project always implies giving up that complete freedom. Cheers, * Thorsten (R) -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear aircraft repository
This is exactly the deal which I think you are rather hurting yourself with. I allege, that contributers of planes are not looking to make a deal with you, at least I would not. First, you're talking to the wrong person. I'm not Thorsten B, I am Thorsten R, and I do not represent the core developers, nor do I have any sorts of commit rights, I just take some time to explain something to you which seems pretty obvious to me. Second, if you do not wish to make the deal, then don't. End of story. No need for your rants. There are excellent planes without GPL license around (the Tu-154b comes to mind), the development is well respected, I don't see the problem. Obviously people can and do contribute that way. What you are offering them, is what *every* contributor should be entitled to in the first place. *shrugs* I'm a contributor, I just contribute a different thing (weather) which isn't so easily separable from the core. So - I need to talk to people, work together with others, accomodate structure constraints all the time. I can't usually decide to structure things in a certain way - I propose changes, they get discussed, sometimes implemented, sometimes not. You feel you are entitled to more because you do other development? Apparently yes... You only get to be on our download page if you surrender your autonomy to us? Yes. Seems pretty obvious to me. I work at a university, so I get access to the university webpages. Someone else doesn't, so he doesn't get to be on the university page. If I misuse my access to university webpages, I see it revoked. Me being able to send emails from a university address gives me mroe credibility than a yahoo address - that's some bonus. Where precisely is the problem? You work for the Flightgear project, your work gets promoted by the Flightgear webpage. You work for Cedric Sodhi, your work gets promoted by Cedric Sodhi. What are you trying to achieve? Do you really think anyone would readily change their mind to rather publish their plane as GPL, although they'd prefer not to, and give up their autonomy, although they'd prefer not to, to get a goodie from you? Frankly, I don't particularly care about that aspect. People who want to publish with a different license can do so, see above, end of story. For me, fairness is an issue. If one single person on the official project page doesn't get to keep control of his work, then no one should. It's a decision the project has made a long time ago, I entered it knowing that this is how it works, it has worked well. Again, I can't help it but wonder what image you have in mind when you accuse those, who voluntarily make planes for Flightgear, of taking from you but not giving back. Oh, but you're not talking here about people who make planes 'for Flightgear'. For people who make planes 'for Flightgear' the implication is that the planes will be given out of their hands because Flightgear is GPL. You're talking here about people who make planes as addons which rely on Flightgear - a rather different beast. Please, let's be very clear about this. We may speculate why people choose not to publish under GPL. One reason might be that they can't because they have used material that isn't GPL compatible. Another may simply be ego, or fame as you put it. Either is fine with me, people can do that, but it's not 'part of Flightgear' or 'for Flightgear', because Flightgear is GPL. Taking your argument a bit further, you'd also include FlightProSim into the group working 'for Flightgear' because they do something relying on the Flightgear code? Or if not, just when is it 'for Flightgear' in your book? Your desire to patronize the other developers may be more fit for core and code development, but the development of planes differs substantially from that of the core: Planes are contributed modularily, have no strong interaction amonst eachother and can thus be contributed freely, as in the freedom to contribute or not. It's a bit tiresome to point out again that you have the complete freedom to do whatever you like with your plane, but that you don't have the freedom to use the Flightgear page for it. Basically, the reason an idea called 'equality'. It's been around since the French Revolution. Just because there's a technical infrastructure which would allow us to be unequal we don't have to be - it still remains ethically wrong. It'd be easy to ask people to pay 1000 $ before they can cast a vote. Election results would be very different then - but does that mean we should we do so? In essence you're saying that because it is technically possible for you to exercise more freedom rights than for me, you should have more rights. I think that's not a particularly ethically well-founded position. Or, to say it bluntly, it wouldn't appear fair. A collaborative, open and free project means, at the very least, conforming to the project's requirements, technically and possibly socially. And that means
Re: [Flightgear-devel] FlightGear aircraft repository
I would have happily continued to maintain/upgrade them , and I,m hoping this change might make things easier ... but if Im now being told that my work can be changed without any notice to me , that i have no say over my own contributions, then I wont waste any more time here. I think that needs a distinction between what's true in principle and in practice. In principle it's true that you signed over your work, so anyone can change it without notice. The rational is that if anyone gets angry, he can't leave and take his work with him and stall the whole project in the course. So in the case that you would decide to leave Flightgear in anger, it would probably occur that your work would be modified over your objection if that's needed to keep it running. In practice, there is common courtesy to authors. I haven't witnessed many situations in which an aircraft was modified without consulting the author, when this happened it turned out to be an accident rather than intention. I have witnessed the opposite, i.e. that a change to an aircraft made by someone else was not committed because the original author objected. Most of us are adult people, and most of the time we are able to act like civilized people, i.e. we can work out things in a reasonable way without invoking the law and waving license around. There are some rules for emergency cases necessary though. So, I'm pretty sure no one will go ahead and modify your stuff without asking you first as long as you're around and participating. Hasn't ever happened to me (and the temptation must have been there...). Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
The Models folder for example, since that's not maintained there - it's just a copy of what is maintained in the scenery database and we shouldn't modify it directly in fgdata. Um... not true. Cloud textures and models currently reside in /Models/Weather/ and as far as I know are modified within fgdata, but are not in the scenery database. * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
Yes, true, we noticed that already. Hence we'll have to leave it as it is right now. A bit unfortunate, this would have really shrunk the archive significantly. But we may still be able to do that one day... The two biggest chunks in Models/ are Weather/ (110 MByte) and Geometry/ (35 MByte). If we'd rip these out - just as a thought experiment - the rest which somehow relates to Scenemodels would be only 100 MByte. That's quite small compared to most other subdirectories. Half of the textures in /Weather/ will be obsolete soon (= as soon as the new cloud rendering system runs reliably and is tested, i.e. in a month from now?). That can potentially reduce the size here. * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Rain
Just adding to the list of issues which might need attention: I've recently noticed a weird behaviour of rain - was okay on the ground, but it faded out 300 ft above ground in spite of /environment/rain-norm being set to some number. After some thinking, I think I understand why: The current system displays rain only below the lowest cloud layer, no matter what value is set for /environment/rain-norm. In contrast, Local Weather conceptually defines 3d volumes inside which rain is switched on, otherwise it gets switched off. Previously I didn't bother because I didn't use the layer infrastructure, so I set the lowest layer altitude to 30.000 ft and this guaranteed that rain works fine. Now, with the new rendering system, I place clouds (formally) into the lowest layer, but it gets altitude zero and I keep track of every individual cloud altitude myself which gets passed to Stuart's system as an offset to layer altitude zero. But of course, that now affects rain. Now, the reason why I don't want to be stuck with a layer based system is best explained using my test case Maui. Here, the typical situation is that the layer itself comes in rather low (say 2000 ft) above the sea and then hits the slopes of Haleakala, in strong winds being pushed up all the way to 14.000 ft, raining in the process. So, here practically all the precipitations happens above what one would call 'layer altitude' (the altitude one would have without the obstacle). In order to get that with the current system, I'd need to set layer altitude to the highest point (14.000 ft) and define all clouds with a negative offset with respect to that altitude. Another example would be rain inside a Cb tower (I'm not sure what sense it makes to speak about a layer in the context of Cb anyway). None of this is a fundamental problem, there are various workarounds in which to do it, but a clean solution would be an option to have rain displayed whenever /environment/rain-norm is nonzero and the same for /snow and /environment/snow-norm, without any regard for layer altitude or temperature (there is such a thing as supercooled rain droplets at -10 degrees C, it's not automatically and not even usually snow once it drops below zero). These are things the weather system should be deciding, not the precipitation rendering routines. Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, after some testing of the new scheme, I have two minor and one major comment. Minor stuff first: * how is the cloud density slider supposed to influence the clouds generated by add-cloud? Heiko claims that he gets to see an effect, I tried to reproduce that but all that happened is that all clouds vanished as soon as I moved the slider, never to reappear. * same thing actually with switching shaders off and on again (I sometimes do that to see how the scene would look in a different rendering scheme) - while the global weather clouds reappear, the manually added ones are gone never to reappear for me. Is this behaviour expected/consistent/as it should be? Now the big thing: it seems I can't use the shading options under most conditions. The only thing that seems to matter is what I pass as middle-factor, and that determines the color of the whole cloud from top to bottom. I have some idea why this might be the case: It's not clear to me how a vertex shader could paint a single sprite with 4 vertices consistently with a top, middle and bottom color. All it can do is paint the upper two vertices in one color, and the lower in a different color, and the rest is interpolation. A fragment shader could probably do it, but that's not where the shading code is. So, it seems to me that there's the implicit assumption in the scheme that cloud_height is at least 2-3 times sprite_height, so that there are enough vertices in between such that 3 colors can be achieved. But building clouds that way is a luxury we can't afford too often. You have to start all design considerations from 8/8 layers which need to run with decent performance, otherwise you'll never be able to do overcast. You can't start with a design working well for 1/8 coverage and expect that it will stay that way for 8/8. Currently I'm doing overcast layers with single elements (still a few sprites per element to avoid too flat-looking layers) of ~ 2000 m size, scaled using z-scaling of 0.25 in the vertical axis to 500 m. To cover a 40x40 km area, one needs some overlap, i.e. about 32x32 ~ 1000 basic elements do nicely. The value of z-scaling is a bit pushing it - it can't be much smaller without creating ugly artefacts, i.e. the thinnest layer I can achieve in 3d is 500 m. A 200 m thick layer isn't conceptually possible in this scheme. This setup already gets the first people up and complaining about low framerates, so there is basically no margin to throw in more basic elements - just maybe a factor 2, but that's it. The virtue of z-scaling is that I can do a 500 m thick layer with 2000 m size elements in the (x,y) plane. Without z-scaling, I'd have to cover everything with 500 m x 500 m x 500 m elements, that'd be a factor 16 (!) more for the same layer - not doable. If you now impose the requirement that I need a sprite size 3 times smaller than cloud size to get the lighting to work properly, we end up for the same layer with ~166 m sized elements in the vertical axis. Since z-scaling can't be smaller than 0.25, these elements are then 660 m sized in x and y direction and one needs a factor 27 (!) more of them to do the same layer. I am fairly sure this would drive every GPU we have into single digit framerates. So that's the reason why layered clouds will almost always end up with sprite-size ~ cloud-size - the third power in numbers needed to fill large layer volumes is killing you otherwise. And since we can't do it otherwise, the shading system must be capable of dealing with sprite-size = cloud-size. It's nice to have the option to render situations with 1/8 coverage in really detailed lighting, but we can't base the design of the system on that situation. I hope that's enough explanation to convince everyone that I'm not being mean here and just do stupid design that doesn't work with the shading, but that there are real issues here. I actually feel bad firing off one issue after the other... I am happy with the performance of the system in most situations otherwise. Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Skydome and Terrain shader with haze - some help required
Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. This is: * the original skydome shader, with an added simulation of a low altitude constant density haze layer and meaningful response to the parameters /rendering/scene/overcast, /rendering/scene/scattering and /rendering/scene/saturation. * a matching terrain shader which connects to the skydome in a (mostly) seamless way * this can render everything from rather heavy fog on the ground to a near space view at high altitude with (mostly) seamless transitions * some additional code getting the sunrise/sunset plausible by darkening the haze where needed. See http://www.flightgear.org/forums/viewtopic.php?f=47t=11274start=135#p140031 for some recent pictures * a small change in 3dclouds.frag to let clouds fade into a matching horizon haze color. All this is conceptually independent of Local Weather - while it is supported and the relevant parameters are automatically set by Local Weather, they can be set from anywhere else. Now, I need some help. First, the combined effect of lots of 3d clouds and haze shading isn't fast. It isn't really slow either, with multiple layers of 6/8 clouds drawn to 45 km distance I still get ~20 fps out (36 without the haze and skydome shader for the same clouds), but I have the feeling it could go faster, there's too much redundant things happening. For instance, I get my altitude in model space by vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; in the vertex shader - but this could probably easily be passed as a uniform if I just would know how (lat, lon, alt) maps into model space. And so on. So if anyone with more experience in shader writing can look over it and smooth it a bit, that'd be very good. There is a writeup of the underlying ideas available, and I have tried to comment a lot, and I can also explain the underlying math. The second thing is - I can't get it into a distributable form myself. I don't understand the structure of effect files. In my current implementation, I have just overwritten the Flightgear defaults, used some really ugly hack at one point and distributing that in this form means either using my skydome/terrain or CPU rendering. I don't want to commit it in such a form, this should be optionally linked to the scattering shader on/off. Also, I run into other problems - I've tried to use the haze shader instead of object default, but they're not blended to the same final color when fully fogged, they come out too dark, and I don't know why. I suspect that something happens to objects later that doesn't happen to terrain... So, I'd need the help of someone who understands the effect file structure to create a structure which can be committed without wrecking everything else. If anyone is willing to help with either problem, please let me know and then we can take the bulk of the technical discussion off list (where I can use attachments). I have a pretty good idea what the issues are and in what direction one should probably go to address them - I'm just a bit out of my depth doing it myself. Thanks in advance, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, This should now be fixed, and the clouds should be white once more. Thorsten R. - regarding the 3000ft altitude offset problem, can you check that you haven't got an altitude set for the layer itself? Offsets as such are okay. I used to have some models with internal coordinates (0,0) at the center of the cloud, some at the bottom, with your rendering engine I can't specify offsets in the *.ac modelw any more, so they go into the code. They should be just something that is measured once and then stays. I've just done a quick check after a pull, and it seems that the curved layer problem is indeed gone :-) I'll have a look at offsets later today, but if they're just different - don't worry. Thanks for the hard work. Side remark: we now seem to have a speed limit: Whenever I exceed ~ 1600 kt with the ufo I get callsign Previous waypoint Cruise Departure airport 0xb85b380 Leg 5 target_speed 1004.05 speedFraction 0.00287666 Currecnt speed 1004 Segmentation fault So I just have to fly very slowly. Don't know where that is coming from... Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Hmm - after double-checking, it looks good to me. Checked with running --prop:/environment/terrain/area[0]/enabled=1 That seems to be the key, thanks. Works fine if I set the property on startup in the commandline, doesn't work if I don't. We used to have a state where it wasn't necessary to set it in the command line any more - so something there might have changed (?). Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Torsten has kindly committed my recent merge requests. So, not only should the curved field be fixed, but there are also many more shading parameters available for the top/middle/bottom/shaded part of the cloud. See README.3Dclouds for details. Thanks, I'll pull this right away! * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New environment properties (Was: A collection of issues)
We would like surface-wind/speed-kt, /direction-from-deg, /velocity-from-east-fps, velocity-from-north-fps, (please not 'from heading' ), but use whatever is easiest, we can handle the conversions easily enough. Torsten, does that sound viable to you? I'll be happy to write them from Local Weather, but we should agree on a set of names to write. That would be great - we thought perhaps this is what the property overcast was intended to do, but it's different in Global and Local weather. In my way of thinking: /rendering/scene/overcast The amount of haze color mixed to the sky color. Unless it's very close to 1, the effect is more like a thin haze layer at high altitude not really blocking the sun, if it's close to 1 it can double as a credible but cheap overcast layer from below (doesn't work from above obviously). Not really a good proxy for cloud coverage /rendering/scene/saturation This directly dims the sunlight and is supposed to represent clouds blocking the light. Unfortunately, in many situations it turns out to be an overkill (it doesn't do to dim the whole sky when you're circling below a cloud) so I only use it in low visibility situations such as inside rough weather (heavy rain usually). /rendering/scene/scattering This is supposed to represent the (perception-weighted) light intensity below the clouds, i.e. it selectively dims the terrain only without touching the sky. Probably, this is more or less what you'd like to use. The math can be done out in the GPU - there's plenty of scope to offload tasks from the CPU. Not necessarily. I was a bit shocked yesterday when I flew the IAR-80 and lost 1/3 of my framerate with the skydome scattering shader on - it has never ever affected my framerate that much, but I suspect the IAR80 places a high workload into the GPU to begin with, so suddenly this becomes the bottleneck of the whole operation. As for putting math to the GPU - from an algorithm point of view, something doesn't seem right. Cloud cover is something we want to compute once per minute or so - putting it into a vertex shader means it's computed per frame per vertex, that seems a bit excessive. Is there a way of putting things to the GPU such that they're only computed once per frame? For instance, for every cloud vertex we compute the eye position by multiplying zero with the inverse model view matrix - although it doesn't change from vertex to vertex! That's a few thousand matrix multiplications per frame which we actually don't really need to do. With rendering haze (and some people are thinking of rain already, some asking for cloud shadows) I see us running rapidly out of GPU performance... Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cloud shadows
We already adjust the greyness of the sea to reflect the overcast value. (It would also be nice if the visible weather in Global matched the description a bit better: we make the sea grey when it's overcast, but the sky is still mostly blue). This sounds all really nice and thank you very much for improving this shaders. But for visible weather we need shadows. Just dimming reflection by some general cloud density makes no sense for me. It seems to me there's a difference between 'we need' and 'would be nice to have'. What, precisely, do we really 'need' shadows for? I'd very much like to have clouds cast real shadows, but: How? Clouds are not 'real' 3d objects in models space, they are rotated stacks of texture sheets. So you can't use any 'real' shadow-generating technique like for a normal object. Real time ray intersection with some ad-hoc light absorbing distribution is out for performance reasons. So we'd somehow have to pre-calculate a shadow distribution (I've worked out the math for that so far), pass it to the shader and project that onto the ground (no idea how to do that in a seamless way), and since it doesn't do to have bright sunny ships with crisp sunlight reflections in a shadowy patch of water, the information needs to go to every single object shader and used there to dim reflections (no idea about the performance footprint of that). As far as I understand, every reflection shader in the scene somehow needs to know if its position is in shadow or not What I really need is a framerate above 20, preferably 30. I'd rather have that without cloud shadows than a framerate of 2-3 with cloud shadows. I don't know about the rest of us... But if you know a fast way of rendering the cloud shadows - please just let me know. Sorry, I'm just getting a bit touchy about reading 'we need' - I've had too much of that recently. Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
So, not only should the curved field be fixed, but there are also many more shading parameters available for the top/middle/bottom/shaded part of the cloud. See README.3Dclouds for details. Somehow, that didn't work out for me. * clouds are now black (see also http://flightgear.org/forums/viewtopic.php?f=5t=7358start=435#p139537 in the Forum - I'm not the only one with that problem - the common theme might be an NVIDIA GPU here (?)). I've temporarily fixed that by setting top_factor and middle_factor to 1.0 - it seems the shader itself is working fine, it just doesn't get the right values. * cloud placement altitudes are offset to what they were previously. I had measured out an offset value for each cloud type which places that cloud at exactly the right altitude, that's now 3000 ft different from what it was - something can't be right here... * the problem that clouds move upward as I increase distance is still there :-( On my machine, currently the weather system only produces crap *sigh* - rain works randomly, rain and haze are offset from clouds, clouds appear at unpredictable altitudes... Maybe we should revert to the previous state till that is sorted out - or am I a small minority experiencing such problems? * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A collection of issues
Some observations I've made in the last couple of days: * hardcoded terrain presampling: This seems to have died on me after the last pull (probably even earlier?) - currently all I get out is zero everywhere. Since geodinfo() is now 50 times faster than it used to be, falling back to the old system doesn't really make a huge difference in performance though. Whatever you think is best - fixing or going back to geodinfo() - just let me know please. * new water reflection shader - since it doesn't talk too much to Local Weather, I had completely missed it has plenty of features. Great work, Vivian and Emilian - the foam caps look gorgeous. I'd like to talk to the shader better from Local Weather as well. I've had a look what parameters you're probing, and for example you use the wind from the global weather lowest boundary layer config. Now, I can write that from Local Weather, but that's not a clean way to do things and I'd like to avoid going back to writing into the global weather config to get things done, Torsten spent a lot of time on making it possible to avoid that workaround. Instead, we could maintain properties 'surface-wind-fps' and 'surface-wind-direction-deg' under Environment which are continuously updated by the weather system (global weather has also interpolation and continuous time dependence, so if I'm not mistaken the actual value doesn't have to be the one in config/). That set of properties could also be used by any other wind-dependent surface objects (smoke effects on the ground, windsocks,...) - which somebody else on the list wanted to have implemented a while ago anyway. Likewise, with total cloud cover - currently the shader tries to deduce that from a number of sources. But for the weather systems, it'd be rather easy to add the coverage of the individual layers probabilistically to get a total coverage and simply provide that number to be used by the shader. (adding layers probabilistically: say I have a 5/8 and a 2/8 - the total coverage is then 5/8 * 6/8 (I'm hitting first layer but not second) + (3/8 * 2/8) (I'm hitting second but not first) + 5/8 * 2/8 (I'm hitting both); or simply 1 - 3/8*6/8 - which is 0.718 or a bit less than 6/8.) Does that sound like a reasonable way to transmit info from the weather system to shaders? * visibility: Comparing X-plane and Flightgear screenshots for supposedly the same visibility, I've come to think about the definition. In nature, things fade exponential in distance, so the contrast goes away as exp(-distance/lambda) where lambda is the mean free path of photons in the medium. Any physicist would usually take lambda and say that this is the visibility. But after the distance lambda, of course 1/e ~ 36% of the contrast is still there and you can recognize objects. So what's the limit when we conclude we don't see anything any more? 1% of contrast? 0.1%? Dependent on that limit, the relation of lambda to visibility can be a factor 3 different. Flightgear currently seems to fade with exp(-(distance/visibility)^2) by default, which sort of lessens the question by a harder cutoff at the expense of being unphysical for small distances. X-Plane seems to cut visibility even sharper with some kind of smoothed theta-function, so no attenuation up to a point, then sudden fog. So, how's it done in practice for weather reports? Is there a precise attenuation definition, or is it more or less guestimated? Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
I see. So what do I do when I want to change the wind and want the clouds to follow the new setting? Simply do a setprop for the layer height setting it to the same value it was? For the moment, Yes. At some point in the future we should fix it so that we're picking up the wind from the appropriate aloft layer. Okay, no hurry with that, I have no infrastructure for creating tiles for a set altitude anyway yet, so it may not be needed for a while... What's the status of the flat layer on curved Earth problem by the way? Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
What's the status of the flat layer on curved Earth problem by the way? This should have been fixed since September 12th in git. https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6 Are you still seeing the problem? Unfortunately yes. I've pulled and compiled just today, I'm seeing the new replay system, so I guess there's no chance of me mixing up the binaries. Do the following test (this is what I'm seeing): * with the ufo, select any non-scenery intensive area (say, TNCM) * set hardcoded_clouds_flag = 0 in local_weather.nas * get any weather tile in 'repeat tile' mode * fly to the cloudbase, then level off and get going with 6000 kt into any given direction, keeping your altitude constant = after 250 km or so, you are still about at the same cloud base as originally * repeat the exercise with hardcoded_clouds_flag = 1 = after 250 km or so, you are well below cloud base, you can observe as you go that every subsequent tile is drawn above the last The increase even appears to be non-linear in distance, getting worse as you are further and further away from your origin, in agreement with the expected 1- d^2 expansion of the cosine as you follow the sphere. Could you perform this test and let me know if you observe something different? I have a customized version of FGData, but since the patch is supposed to simgear, which I use unmodified from the devel version, I can't see that this is an issue here... Thanks, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
Hi Curt, thanks for your comments and explanations. We always recognized potential difficulties with blending the sky into the terrain. The original design used the fog color as the opengl clear color (the color that the display buffer is cleared to before starting to draw any of the frame). We blended the bottom of the skydome into the fog color. And then made sure we drew enough tiles to extend at least to the fully fogged range in all directions. This allowed us to hide the seam between the sky and the ground in the fog/haze at the horizon. Yes, as far as I can see, that's the only way this can be done and why the scattering skydome shader never worked with the default terrain shading. As a side note: I've observed that we're currently fading into fog with exp(-d^2/vis^2) where d is distance and vis is visibility where I believe the physically correct behaviour would be exp(-d/vis) Now, the only reason I can think of to do the square fading is that you really get a hard cutoff after d = vis and minimize the amount of terrain tiles you need for a seamless blending. On the other hand, the square fading brings less fog for d vis than there should be, and actually many optical integrals rely on the factorization transmission (layer a) * transmission (layer b) = transmission (layer a + layer b). So I would prefer linear exponential fading. If the hard cutoff is the only rational for square fading, then I'd propose to use exp(-d/vis - 0.1 (d/vis)^6) instead which for any distance d vis gives linear fading and then has a cutoff as efficient as square fading. Please let me know if there's any other reason why the current code is as it is! One problem: tall mountains in the distance would be fog colored and extend visually up into the blue part of the skydome and look weird -- so the original design worked pretty well, but wasn't perfect. I would guess it is visually acceptable to let mountaintops never blend into the horizon fog. In my current design it would be possible to do so, provided the visibility passed to the tile manager is a clever combination of ground and aloft visibility. Maybe that's actually the general solution - pass a function of different visibility properties used by the shader to the tile manager. The simplest solution is to pass the maximum of all visibilities, but that may load more than one ever needs, so probably an angular weighted version dependent on current altitude would be more useful. I can work the math out... as long as it's possible to go for a solution like that. Oh, and we also had some additional code that would change the fog color depending on your view angle relative to the sun ... so at sun set/rise the fog color would be oranger/redder looking at the sun versus looking away from it. I'm currently using gl_LightSource[0].diffuse as fog color - to the degree that sunlight light changes, my version inherits that (seems to be working fine so far). So definitely we should try to figure out how to make your sky model blend with the terrain some how. It *seems* to be doing fine now after I introduced the harder fogging cutoff - above the ground layer, it still uses /environment/visibility-m to keep track of this part of the optical integrals, so the amount of tiles loaded is actually sufficient - but at 50.000 ft or so I rountinely have visibility values of 100 km. For me, Flightgear renders that still stable and reasonably fast (I tried Custom France scenery, Hawaii as well as Pacific Northwest as test cases), and only above 140 km I get unstable behaviour (some of my Blackbird Screenshots were rather difficult). But on slow machines, this'd probably be a show-stopper. But that's not a shader problem but related to the weather code - that can be instructed to provide a cutoff for visibility that is never exceeded. One more thought while I'm writing. The current scattering effect skydome has a glitch/seam at the azimuth. Depending on the time of day it is more or less visible. It can be really ugly, I'd love to get this fixed if you happen to stumble on what's causing it as you play with all this code. I know... I'm really not a shader person, I have just one idea as to what the cause might be (?). I've often observed that the edges of scenery tiles with the water reflection shader have different colors. I have also on occasion seen fog artefacts at just the same position. My theory as to what happens is that the vertices in this case (= the tile edges) are rather far apart, so when the vertex shader is asked to compute an angle for reflection or light scattering or fogging, it must interpolate over a large area because the vertices are far apart. If it interpolates linear, but the quantity to interpolate is (as in this case) non-linear, then in a certain angular regime there must be artefacts. In this case, there'd be nothing wrong with the shader, the vertices would just too far apart to get it right. Now, I have
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Hi Stuart, (Apologies if I've missed this already) Are you planning put this into git? Should actually be in now - you might have to activate it though, because I haven't changed the gui and some menu options cause errors with the new rendering system because they are not implemented or obsolete. Find var hardcoded_clouds_flag = 0; in Nasal/local_weather/local_weather.nas and change it to var hardcoded_clouds_flag = 1; All the parameters for the layers are in cloud_definitions.nas I've had another look. The property is /environment/wind-speed.kt However, the layer only gets updated when the layer height (/environment/clouds/layer[n]/elevation-ft) is subsequently updated. A similar thing happens with the wind direction. I see. So what do I do when I want to change the wind and want the clouds to follow the new setting? Simply do a setprop for the layer height setting it to the same value it was? Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of 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-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atmospheric haze modelling
I've spent some time over the last days to add a model for an optically thick regime to the skydome scattering shader. I am rather happy with the model (as far as the skydome is concerned, it now renders visibilities down to 1000 m in a plausible way, the transition to the optically thin regime looks nice and you get spectacular sunsets - see http://www.flightgear.org/forums/viewtopic.php?f=47t=11274start=90#p137694 for some pictures). The problem is that making this really work means rethinking some concepts. What I have done so far is adding a layer of constant optical thickness from ground level up to some given altitude. That particular case has an analytic solution and hence computes rather fast - I think it's much faster to render an arbitrary density distribution as 10 subsequent layers of constant density each than to put the numerical integration in explicitly. What that means is that visibility is no longer a parameter which changes with your loaction - the visibility at the ground is tracked and determines in an essential way how the scene looks - even if you have 100 km horizontal visibility at your current position, what you see on the ground depends on the angle under which you view the ground haze layer and may be much less. On the other hand, this means that mountain ranges can stick out of the ground haze and be visible much further than the terrain just below. Ultimately, in this concept the notion of a single visibility determining everything is gone and instead you specify optical properties of the atmosphere in certain regions. It's probably obvious why this is tricky - the single visibility parameter currently governs many other things (scenery tile loading springs to mind, objects,...). It's also tricky but crucial to apply the same technique to the terrain, otherwise the horizon line never matches up. So, at this point, I thought I better start asking for some thoughts before finding myself in a difficult place. * Is this something we want to do at all (it's reasonably obvious that I want to do it, but I don't think I can develop this as a harmless addon mode)? * Is there a good way to implement this concept *without* causing too many problems for global weather or the default terrain rendering (for instance, right now, my version of skydome.vert and skydome.frag only run with global weather when some parameters are manually entered via property browser - not user-friendly... but in principle the parameters necessary could be computed from weather info), or is it acceptable that only non-shader rendering stays how it was, but shader-based rendering gets all changed? Or that global weather can't use the skydome shader any more? * Is there a way to implement this without altering every single terrain type/object/... shader and to put the equations for fading of objects with distance into one single place where they are easily updated? Some thoughts are very welcome at this point (possibly also some help in the implementation - I can derive the math quite alright, but to get GLSL to run for me takes an awful lot of time - I'm essentially learning by reverse engineering and trial and error). Cheers, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
LaTeX is not a word processor, it is a professional typesetting tool. I see all the reasons to keep the docs in LaTex (like keeping the process efficient at the moment), but this sentence here about professional tools is probably not that serious as I read it, right ? I don't know how you read it, but I know for a fact that many professional science publishers use it (Elsevier is just one example, pretty much every physics journal asks you to prepare manuscripts in LaTeX). So yes, I guess I am serious - pretty much anyone I know who is publishing on professional level (i.e. makes money by selling books or journals) and has complicated layout problems (math formulae, Hebrew sentences with reverse writing direction inside English texts, Egyptian hieroglyphs written from top-down or right-left,...) uses LaTeX for typesetting. It's not some exotic tool in publishing business - it's just not so well known for every-day office work. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable random seeds
Thorsten Renk - If this something we need to be thinking about for the Local Weather as well? We've been tossing the idea around in the forum that Local Weather stops using the rand() function from Nasal and uses its own internal random number generator. In this way, it could be initialized in a well-defined state on different machines, the sequence could not be messed up by other Nasal scripts running and you'd generate a predictable configuration. I haven't done anything in that direction though... * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Links for new FlightGear pilots
Thanks for the info - that confirms what I noticed: After Installing and doing some tests with LaTex and LyX I did not find a feasible way to import the newly designed appearance - seems you really have to just extract everything except the plain text and and build it up new - without the support of a WYSIWYG-system! And if you wanted to change the appearance of the manual you first would have to build up new predefined structures (comparable to the CSS-Structures in HTML). That sounds like a whole lot of work - and I wonder how I or anybody else can help with that! Is there a description of that process? As a long time LaTeX user, let me comment on a few points. LaTeX is not a word processor, it is a professional typesetting tool. I don't know about fiction books, but the vast majority of science books you can buy is done with LaTeX. If you know how to work with it (rather than against it), the layout you can get is orders of magnitude better than anything else. If you want to work with LaTeX, you have to think in a new way about things. You're talking about support of a WYSIWYG-system - but in reality, there is no such thing - it doesn't really support you with anything. As an author of a text, I should not micromanage the layout - my task is to define what is in what section, what is figure caption, what is footnote, and so on. Based on that, the publisher does the layout. You may design the manual in 12pt fonts and an a4 page format so that people can print it. I may rather want to change it into two column, 10 pt fonts and a B4 format to make a hardcover book out of it. To do so with a properly designed LaTeX file costs me 5 lines in the header, and just maybe less than 10 minutes optimizing figure placement manually. To do so in a WYSIWYG word processor is a nightmare, to say the least. You have to rethink your task as author - it's just to identify the function of all text elements and to trust LaTeX to do the rest (it's *really* good doing that). There are numerous manuals around in the web - www.ctan.org is as good a starting point as any. In case there is a specific question not covered in the manual, you can also ask me - there's hardly anything about LaTeX which I don't know (or can't find out within 10 minutes). Cheers, * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Display existing path?
Nasal can handle pretty general problems (you can run a whole weather system in it...). 3) Finally, what seems most general would be to write some code in nasal that can read in a csv file, and then to display objects in those locations. Is this feasible? Can nasal import a csv file or other general file format that could contain points? I don't know about reading general file formats, but what is certainly possible is to have a file of your waypoints in xml format, such that it appears in the property tree. Nasal can then read out the waypoints from the tree, place object markers at the given positions, compute the connecting lines and compute regularly spaced positions to indicate the lines. All this is rather straightforward. To see how xml creates property nodes, see preferences.xml. To see how to read properties into Nasal, read the FgWiki on Nasal. To see how to make Nasal display objects at given (lat, lon, alt), study the tanker.nas script. To see how to do the trigonometry calculating your course lines, see the documentation of geo.nas. Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
for inspecting the upcoming Swiss airports, I obviously needed to zoom out (see my posts in the forum's hardware and scenery section) After looking through the Forum - I guess what you mean is that you want a viewpoint from high above (outer space)? As established in lengthy discussions with vitos which you can read up at your leisure, Flightgear isn't designed to show the planet from outer space. Apt.dat 8.5 will be a great move forward but local weather is ugly. You're not forced to use it... It obviously will not work for a view from outer space (there's a reason it's called 'Local Weather' rather than 'Planetary Weather System Simulation'). Only one tile seems to be rendered, everything outside is black. That sounds like using the skydome shader and badly configured visibility/bare LOD distance. And yea scenery textures...sigh...I've no idea on how to implement for ex. google textures (which I've downloaded once for x-plane' Switzerland area) Any hints? There's aerial photograph texture around Brest available where you can see how it is done. Also throughout 3D clouds would be a very nice addition. No idea what you mean. We now have most cloud types in 3d, expept those which *really* *don't* *work* in 3d (very structured Cirrus). Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
See some screens. Default before and after using local weather. both with high z Yes, just shows that you haven't understood the issue. Fact 1: The Scattering Skydome shader doesn't work for low visibility (100 km) because the haze it creates (the yellow-black stuff) doesn't blend with the terrain haze. It works for large visibility because then the terrain covers the yellow-black stuff all the way to the horizon Fact 2: Local Weather has its own vertical visibility model which determines what you get to see, so you can press 'z' all day long and it won't do anything. In particular, for performance reason Local Weather usually restricts the visibility to less than 50 km. Consequence: You go from a situation at high altitude where visibility is maxed out and the scattering shader works to a situation where visibility is quite restricted and the scattering shader's problems are not hidden any more. This has *nothing* to do with Local Weather, it's only related to the value of /environment/visibility-m at your position. If you use a low value with Global Weather, you'll see the same black stuff coming up, if you instruct Local Weather to display a large aloft visibility, you get this: http://www.flightgear.org/forums/viewtopic.php?f=17t=13339start=15#p135799 Future advice: First: Understand issues involved. Then: start bitching if necessary. Not the other way round. Cheers, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local weather, apt.dat 8.5 and scenery textures
no definitely not not even your explanations...so i have to live with such as local weather is not capable of doing such? ok no problem Quoting myself: This has *nothing* to do with Local Weather, it's only related to the value of /environment/visibility-m at your position. What in these two lines is difficult to understand? * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
3) Antishading If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. Okay, I've decided over the weekend that I'll make my current code available this week, because there's so much new stuff in which is not related to the transition to the new rendering system (some new textures, the detailed cloud-terrain interaction model, ...) that it may even be interesting for a 2.4 user. So the new routines will be off by default, but editing a simple flag in the code will switch them on and then you can study the problems in situ. 4) Fading in poor visibility Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Okay, I'll try to come up with a function which works for that. I guess exp(-d/d0) is the correct parametric form, just d0 should be changed to a function d0(visibility-m), but I should be able to find a solution if we agree that this is what we want to modify. 5) Specify top and bottom shade I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. I see - then let's do it like this. Also, I remember I asked this already, but you weren't quite sure then and the answer you guessed turned out not to be correct: What property determines the speed at which a given layer drifts? It gets set correctly when I initialize Local Weather with constant winds, but I'm not sure if it gets updated when I allow interpolated winds. I've been thinking of doing Lenticularis clouds by simply assigning them to a different, unmoving layer - I think that'd be pretty cool. Thanks, * Thorsten -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
