Re: [Flightgear-devel] OpenRTI / HLA
Hi, On Thursday, March 07, 2013 18:26:46 Clement de l'Hamaide wrote: Mathias, some weeks ago I told you about a compilation problem for FG on Linux when RTI is enabled. You asked me to remind you of this problem later, this day is came :) Thanks, I have moved the rti libs below the simgear ones. Does this help? Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Hi, On Thursday, February 21, 2013 16:43:51 James Turner wrote: This is moving in the right direction for sure. I'd like to go a little further, and make the LOD setting a simple checkbox labelled 'reduce detail adaptively'. Then make the LOD ranges (for trees, clouds, AI models, whatever) internal properties, and crucially, enable OSG's LOD-bias feature. This effectively scales the 'visible distance' used to select LOD by a factor, and we can use a PID controller to adapt it based on target and actual frame-rate. (Of course I didn't try it for real yet). This ought to nicely adjust the LOD bias, and hence the final LOD, to keep a target rate (say 30 or 60fps). Of course if you enable every conceivable shader effect, the PID will drive the LOD-bias to a large value trying to keep 60fps with almost nothing drawn, so this needs some testing and sensible limits, but I hope could give much more flyable results - stuff will just disappear rather than the frame-rate plummeting as you approach LFPG or EHAM (or KSFO, even) (Of course it also needs an audit of our LOD hierarchy, which is currently a bit cumbersome, but that's all good incremental work) Well, that's on the way. Please do not steer any lod ranges except may be the lod bias by any property. That's again cross connecting code areas that do not need to be connected and that then suffer from updates into the scene graph that are unneeded. The osg LOD system is simple but effective if used in a sensible way. The spt loader used in fgviewer also has lod hierarchies built in. You can already load - may be I need to push this series to the latest version - lower level of detail huger tiles if you put them into the right directories. That's in preparation and has no upstream support form the scenery yet. Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgviewer preview
Hi, On Thursday, January 31, 2013 17:13:46 James Turner wrote: I've just pushed some model-loader tweaks, to support the same 'no preview' tags which FGRun supports, for viewing models. Currently only 'fgfs --fgviewer' mode sets the requisite flag, 'fgviewer' probably should but I need to check with Mathias what's a suitable way to control it, since I guess always-on may not be desired. You can currently set arbitrary osg loader options by -O 'string option'. Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear Multiplayer jitter using Matlab/Simulink
Hi, On Monday, January 21, 2013 12:01:54 Yingcai Bi wrote: I am a starter here.I'm doing a university project. I need to control two aircrafts for close formation with two Simulink at the same time. I do as vbnhu's post in viewtopic.php?f=4t=3165p=174710#p174710http://www.flightgear.org/forums/v iewtopic.php?f=4t=3165p=174710#p174710, and met the same jitter problem. One plane flies well and another jitters. fgfs --aircraft=c172p --fdm=network,localhost,5501,5502,5503 --multiplay=in,25,localhost,5701 --multiplay=out,25,localhost,5702 fgfs --aircraft=c172p --fdm=network,localhost,5507,5508,5509 --multiplay=in,25,localhost,5702 --multiplay=out,25,localhost,5701 Then, I tried the LAN fgms, There are two computers for two simulink controlled fgfs, one computer as the fgms. There is still the jitter problem. Now, I find the implementation of network control with simulink in viewtopic.php?f=36t=16200http://www.flightgear.org/forums/viewtopic.php?f= 36t=16200 . I wonder if I must implement the multiplayer protocol in simulink and if the jitter problem can be avoided. Any suggestion from anybody? Thank you,all. If you relay one aircraft by the net fdm and then the multiplayer you will add some latency just by that store and forward. This is then made worse and jittery by the main loop doing this store and forward controled by the independent frame rates of those both simulations and not by any simulation time slices. The input of the net fdm is also not time slice synchronized - at least if I remember right. Then on top of that the incomming multiplayer code tries to even out jitter in the incomming multiplayer packets which accounts for some extra latency that will probably hurt your application too. I am currently working on something that will probably arrive too late for you if you need that about now. The hla components will enable correct time slicing over more participants and components. May be for your particular case: If your simulink models live in the same matlab, it could help if the data for both aircraft is sent by the same atomic network packet. But that also involves hackery in matlab as well as in flightgear. Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote: Ah, now I understand what Mathias is after: That would be ok if this would be optional in the sense that it does not impact what is there performance wise. But since this is all runtime configured by an uebershader with a lot of uniforms this is not the case. Any additional feature done in this way *does* impact everbody in several ways. Any additional uniform takes time to be set up in the driver. Any code that is in the shader and that cannot be optimized away at *link* time of the shader may take registers which affects the partitioning and the amount of paralell executed threads in the GPU. At least a notable amount of gpu's on the market can get register set limited at that point. This paragraph has nothing to do with what is actually happening. 1) The 'ubershader' for _models_ (model-combined-deferred.eff and ubershader.vert/frag) has not been introduced by myself but by Frederic Bouvier and Gijs de Rooy with major additions and revisions by Emilian Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader requires to insert generate tags into each model which uses normal maps. The shader is optional, i.e. it is not compiled if model shader quality is set to zero. It is configured by a lot of uniforms (really a lot more than I ever used for terrain). My own contribution with regard to this shader is just to change the light and fog functions, I did not otherwise alter its design. However, since there's lightmap, reflection map, normal map and dirt map, there are potentially 15 different combinations of dedicated shaders which are not configured by uniforms, it seems to me there may be a maintenance issue to consider and it makes sense to do it that way. I did not come up with the need to modify each model, that is a property of the original shader. Mathias, you picked the wrong audience. 2) The terrain 'ubershader' (terrain-haze-detailed.vert/frag and terrain-haze-ultra.vert/frag) is my own work. These are two quality levels of procedural *terrain* texturing with terrain-haze.vert/frag being the 'bare' light scattering framework without any terrain effects, just modifying light and fog. This shader is very different from the model ubershader and does *not* require any insertion or modification of any model. All of these shaders are only compiled if the respective quality level is actually used and atmosperic light scattering is actually checked. 3) terrain-haze-detailed.vert/frag still has if-clauses linked to quality level in - however the plan (made on this list) is to take them out as I recognize it doesn't help for performance. This has largely been done in terrain-haze-ultra.vert/frag already. It would have been 5 minutes effort for Mathias to take a look into our effect files to see how all this is actually implemented and to realize that none of the shaders being discussed here is compiled unless this is asked for by the user. But it would appear his criticism is not based on any understanding of the situation, but just on his interpretation of bits and pieces of messages out of context. So, I will disregard it as unfounded. Mathias, please next time have a look at what you are against before you start writing. Thanks, You may be right that I did not pick the exactly right person for every line of code. But I also did not get the completely wrong one as you never cared for the state of the art even if being pointed to. If you think that you are right just by being the last one in the mail thread than you are actually very wrong. That just does mean that you have probably the most sloppy job so that you can write more mail than others. I am after technically superior stuff not after fighting for that. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
Hi Stuart, On Wednesday, January 23, 2013 21:52:49 Stuart Buchanan wrote: The current proposal that Thorsten and myself have been thinking about is that all of this is optional on the quality slider on the rendering dialog. So we absolutely will be supporting both, and users can balance frame-rate against eye-candy, as they do today. Nevertheless, we obviously want to be as efficient as possible, and personally speaking I have insufficient knowledge of modern graphics pipelines to know where the bottlenecks reside. Does that address your concerns? This kind of answer is the one that I expected to get at some point. Generally, I think that the major point in our kind of application gets lost. Think about the type of technology and why we are using this type of technology. We do currently use a rasterizer based approach which is delivered with hardware acceleration by either OpenGl or DirectX. And I think the reason we are doing this is that we reach the speed required for realtime simulations. REally if you are interrested in nice pictures no matter how long it takes, there are really convincing techologies out there. Global lighting integral equations give the most convining and most expensive pictures. Then ray tracing like approaches get more and more interresting as they can deliver great pictures down in the seconds range. At least for inside scenes and with a bunch of gpu's doing compute work. Outside ones are still much more problematic. Then there is that faky rasterizer based approach. That one has a lot of downsides but this is still the only aproach that can deliver pictures at deterministic 60 hz - if the renderer is not being crippled to be slow. At least some of the flightgear users need stable framerates over a not so small amount of screens. These might be genlocked to have a common buffer swap. So, you need some headroom if you do not want a missed frame everery second or so. Really: speed is the only reason not to use something that gives way better pictures by itself. If the priority is too much shifted on pretty pictures then it's better to look at a different project out there. That does not mean that it's impossible to render nice frames with a rasterizer. And there is a lot of technology out there which enables this great faky pictures where you do not recognize that its so faky. But what I saw lately - especially from this finish guy - is noting close there. He is extremely loud, argues with 'works for me' like arguments and does not listen to suggestions that would guide in a better direction. Let's take the uebershader like approach.That's really one of the worst ideas that you can have gpu wise. There are a lot of if's that are impossible to be optimized out since these are runtime configurable by a lot of uniforms. And thats actually the second bad point in this approach. So, just looking at the problem it must be clear that this is a not so good idea. Sure from a softwareengineering point of view having a configurable shader seems good. But for the purpose of having a fast renderer it is not - and remember if you are interrested in nice pictures at any (performance) price use an other technology. For our type of application, speed matters. Then there is the scattering stuff. That's great but I told him may be two years ago how this could be done efficiently. Now he presents something that he tells that needs to be inserted into any shader in any model. So it's just clear that he did not listen to any suggestion at that time. That would be ok if this would be optional in the sense that it does not impact what is there performance wise. But since this is all runtime configured by an uebershader with a lot of uniforms this is not the case. Any additional feature done in this way *does* impact everbody in several ways. Any additional uniform takes time to be set up in the driver. Any code that is in the shader and that cannot be optimized away at *link* time of the shader may take registers which affects the partitioning and the amount of paralell executed threads in the GPU. At least a notable amount of gpu's on the market can get register set limited at that point. Getting back to procedural textures, go on with what you planed. But keep in mind that you should not use resources just because you have a lot left. Think if you really need what you think you need. And if you really (again really) need this resource add it. Also please do not throw away the old style textures just because we have now that hot and spicy new technology. As also mentioned in a private mail to you, I will provide a different renderer sometime in the future where I aim to provide better isolation of this kind of renderer options so that people with very different aims can probably coexist better. Have a nice weekend Mathias -- Master Visual Studio,
Re: [Flightgear-devel] Color-shifts for textures
On Sunday, January 20, 2013 19:17:18 Renk Thorsten wrote: Well, if you ask in that way, then the question is: Do we need 10 different flavours of rock? If we want to look a scene roughly as it would in the location, the answer is yes - volcanic rock on Hawaii looks very different from Alpine rock in France. Rock in Iran looks very different again. If we're happy with one recognizable generic fast-rendering look for Flightgear, the answer is no. Personally I'm in the first camp. The problem is that there's always somebody unhappy. People are unhappy because the base package download size is large, so we'd not want any more textures. People are unhappy because FG doesn't look like FSX, so we'd want better texturing. People are unhappy because framerates are bad, so we'd want less GPU load. People are unhappy because insert name of game here has grass moving in the wind and FG has not, so we'd want more fancy effects. I'm trying to sort the reasonable from the unreasonable here and to identify genuine problems before they occur. The point is - less uniforms, more distinct textures render faster. Any rendering load can even be optional. What can not be optional is the size of your base package once I start adding textures to it. So it's a question of pain because a scene looks bad vs. pain because of large download vs. pain because of high performance needs. I see applications that care for stable 60 hz. If you get for one frame 59 hz they have too much jitter and look for an other renderer. What I really do not like is that people purely push in the direction they just like more. If you work sensibly, you can support both. If you want photorealistic pictures use a raytracer or do global illumination and use a cluster to do the pictures. But this is a *training* *flight* *simulation*. And as this having nice pictures is great to have, but if this is at cost realtime frame rates this is not acceptable at all. This is especially bad since it is possible to support both. It's just that enough loud people are after more glossy pictures and do not care for the initial purpose. At least this is my impression. Do not get me wrong. Especially the defered renderer is a huge step into a good direction. And this accounts for a lot of gloss and currently still for a lot of slowdown if being used. Not to talk about that implementation not running at well on some of my machines, but still, this is optional and really great to look at when it's working. And no, attacking the big base package by procedural textures exclusively is something that gets my clear NACK. If done sensibly, you can do a lot with shaders, and this even can look way better than a texture. This can be even faster than with textures. If you work sensibly and also care for performance I am all for this *as* *an* *alternative*. I personally live behind a very slow 1gbit DSL connect. So, I must be the one that is whining about the download size. But why am I able to manage this? If you want to have a smaller download, you can for example walk all textures that are in the base package and in the scenery, look if there are rgba textures with a constant equal to zero alpha channel. Then for textures with a needless alpha chanel, replace these with rgb textures. That would be a simple and effective candidate for improovement. That would help osg for unneeded transparancy sorting and that would help the gpu. Sure the git commit object will stay. But people wante to have a distributed revison control system. It was clear that these objects stay then. And please finally teach your mailer not to drop the reply reference! ... if you write just one less of these lenghty mails you should be able to find that knob. This goes via a webmail interface that is managed by my University's beloved IT department - please don't ask me any more, or I would tell a few really good stories... Suffice to say, it doesn't seem possible to do. In the overall scheme of things, this is a minor annoyance... You could use an other mail for example. And to me this is *really* annoying. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: release branches are ready,
Hi, On Thursday, January 17, 2013 20:23:23 Torsten Dreyer wrote: Done. Version 2.10.0 now lives on the release/2.10.0 branches on SimGear, FlightGear and FGDATA to be released around the 17th of February. SimGear and FlightGear next branches as well as FGDATA master branch are now on version 2.11.0. These branches are again open for regular development. Thank you all for adhering to our feature freeze policy. Curt, James, ThorstenB and Tat: Please create our first release candidate as soon as possible to give many users without source code compile expertise the chance to test our new version. Thanks! Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Thursday, January 17, 2013 16:31:57 Renk Thorsten wrote: For example here on an nvidia 8800GT with 313.09 linux driver I have: MAX_VERTEX_UNIFORM_COMPONENTS 4096 MAX_FRAGMENT_UNIFORM_COMPONENTS 2048 Nevertheless, that would make 50 seem a rather harmless number. Especially when I'm going to assume that no one with a much older card will be able to run a shader with 6 overlay textures in anything resembling a usable framerate anyway. So I will for the time being consider a number of below 100 uniforms harmless, and we can change strategy once actual problems crop up. Any objections? Yes. Any uniform needs to be handled by the driver. And any of them takes cpu cycles to load. I think having lots of them is one factor that accounts for the long draw times I see here. Looking at profiles the function collecting them and putting it into a buffer for use in the gpu is always in the top 5 functions on the cpu where exactly this takes a lot of cpu time. So, just putting a lot of uniforms somewere because the maximum allowed number is so far away is not a good idea. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slave flightgear as external view to monitor traffic
Hi, On Saturday, January 12, 2013 12:03:07 Wolfram Wagner wrote: We have the idea to use flightgear to display the external view onto the airport for OpenRadar. (OpenRadar Version 2) This is something that would add a necessary grade of realism and would make ATCing more attractive. As it is possible to use flightgear as view slave for another fg instance, this seems to be possible. I think I need an invisible airplane, position it a the tower position and tell it, where to look to. Is there a documentation that helps me? I guess there is a protocol that I have to use, once I have started the flightgear instance. As of today, you can send some udp messages and run flightgear with the external fdm. That's a pretty simple packet format. Details better looked up into the code. I believe Erik has at some time added a more flexible packet format that is also able to set some properties and freely configurable. Details from him. And finally fgviewer is not at the point where this is already usable as the viewer is not complete and the code I am talking about is not yet in a usable state. But If you have just a single configured viewpoint this already works by adding the apropriate hla objects and attaching the viewer to them. In the long term this is probably the viewer to use as it is designed to be used in an environment like this. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.0 Changelog - help required
Hi Stuart, On Friday, January 18, 2013 00:04:35 Stuart Buchanan wrote: 1) Are there any significant features/enhancements that have been missed? (Matthias: what HLA enhancements have been made, and can you provide a couple of suitable sentences describing them? I'm happy to wordsmith any text) Well, nothing user visible I think. There is a lot of private code pushed into the repositry, and at some point this tied together will make a lot of sense I think. But up to now just a lot of loose ends. What is there is a sketch of an AI module working on top of hla objects, this sketch also shows how you can roll on ground - at least for solid ground. Also fgviewer gained a lot of unfinished hla code that enables fgviewer to sit on a hla configured view - more or less. At least a python script that I regularily use for development providing this works fine. Together with fgviewer there is also some work done on the scenegraph that is used there. fgviewer is since some time just able to display a whole world paged model that has the stg/btg files in the leafs. With this work there is also some level of detail work done in the leaf nodes that is used by the usual fgfs scene. On my setups here these changes accounted for some performance gains which are also partly visible with fgfs. So not sure if this is worth to be mentioned as there is nothing finally useful for an end user there. Greetings and thanks for collecting this. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bucket change
Hi, like already negotiated with the scenery guys, I have now pushed a change to the bucket tiling at the poles. The current scenery does not handle these cases well anyway, the tiles there look very much broken. So, there is not much lost in the current state by this change. The scenery guys promised me that the next scenery build is nearing, so the hope is that they will pick up this change and we get by that a whole world scenery without holes, even including the 2 degrees around the poles. In any case this is at the very beginning of the development cycle so that problems arising from this change should have enough time to be iterated out before the next release. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Sunday, January 20, 2013 14:44:17 Renk Thorsten wrote: Yes. Any uniform needs to be handled by the driver. And any of them takes cpu cycles to load. I think having lots of them is one factor that accounts for the long draw times I see here. Looking at profiles the function collecting them and putting it into a buffer for use in the gpu is always in the top 5 functions on the cpu where exactly this takes a lot of cpu time. So, just putting a lot of uniforms somewere because the maximum allowed number is so far away is not a good idea. Well, that wasn't quite the question. I know that having lots of uniforms is more expensive than not having lots of uniforms. But if I want to have 10 different hues of rock - is it preferable to create 10 different rock textures and manage those, or is it better to have one rock texture and a uniform vec3 for each? Likewise, if I have to decide between running 5 different shaders or one shader taking two uniforms to configure its action - what is more efficient (leaving aside the fact that just having one is vastly more maintenance-friendly). Well, if you ask in that way, then the question is: Do we need 10 different flavours of rock? If your question means: if procedural textures are good or not. I think that this is worthwhile to have and make a lot of sense. But I expect that for a very long time this will probably just look like bad chewing gum as realistic materials are a lot of work to make them look good. It's normal that this takes time and that it looks wierd in the first place. As always if this is optional I am fine with that. I still think that a traditional fixed function renderer has its applications in certain areas. We had a sufficiently good lookin one there and if this would have been preserved this would still be applicable where it was sufficient. And please finally teach your mailer not to drop the reply reference! ... if you write just one less of these lenghty mails you should be able to find that knob. Thanks! Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of Wayland and Flightgear
Hi, That's somethign that should be done in osg. There is an egl compile flag in osg that enables use of egl. IMO this should at some point made a ron time configuration instead of a compile time one. Then what's left is providing egl bindings for opening a window. Which is about 100 lines of code. Both are issues to be discussed on the osg list. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenRTI / HLA
Hi, On Thursday, December 20, 2012 22:22:19 Clement de l'Hamaide wrote: 1 ) I'm really interested by your work about OpenRTI / HLA. I've added the RTI support in the download_and_compile.sh brisa script's in order to make it more user-friendly to use and participate to the development. I compile SG and FG with -DENABLE_RTI=ON since some weeks but today FG compilation crashed with this option :/ Here is the compilation log : http://pastebin.com/HnPSfyzs OpenRTI and SG compilation are fine. I've deleted my OpenRTI/FG/SG build dir but the issue still here. Do you have a solution ? Remind me to look at that past the Christmas days please. 2) I'd be really happy to use/test HLA unfortunately I haven't found recent documentation about it. I know about the wiki page http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture) but this page is not up to date. Looking at your source code it seems that --hla=bi,hz,federateType,federationName,profile is no longer the correct way to activate HLA, but more --hla --federation= Are you able to tell me/us the current state of your work : Is it currently working ? can we test ? how can we test ? what are the possible argument ? what is your dev plan (current step, next step) ? Have we need to be connected to an HLA server ? Can you explain a litttle bit how it works at architecture level ? (Is it a centralized server routing every packet between user ? similar to FGMS network ?) Documentation is flying around a lot. General ones and probably stuff that is too far away to be directly useful. Simgears hla classes should abstract us away from some of these details. I am not exactly convinced that this library is the best design so far, but at least it currently provides something to conveniently access that standard apis. And this should shield away the most popular problems with high algorithmic complexity. The same goes for the rti library below. I am regularily running with this enabled. Also testing a lot here. Currenty cleaning out a lot of proof of concept stuff that lingers around on my local disk. You still can use the the --hla= commands, but there is a shortcut --hla-local which optimizes away a lot of successive ,,, in the command line that I usually had. So, --hla-local=rti://localhost/FlightGear is a shortcut for a longer --hla= line. Steps are currently to clean out my disk and provide what is there. What will come in the shorter term is a standalone viewer that can sit on any of the configured views. There are beginnings of that checked in but there is a lot more in preparation. The fgai is just a brief sketch chat could be done in that corner. It already contains most if what is needed in complex infrastructure. You can inject vehicles and you can now get ground queries. I am for a long time running here also a brief python script which does about the same than fgai. While a scripting language is not fast enough to drive a lot of ai traffic, it is rather nice to do only a few such objects without much worries. Whatever happens here, if you are really driving a lot of ai models it requires a huge amount of thoughts to get that scalable. Updates to specific models as well as specific parts of those need to be updated in an sparse and intelligent way to make this somehow work. This includes the basic part of the fgai implementation which aims to have steady and differentiable movements. This is at this time not made use of so much, but the classes that I called something like *Physics* in there are mostly there to make sure that all components can see and even extrapolate the same steady movements than the originating component does. There is also infrastructure there to play some tricks with timing so that nobody needs to wait for ai traffic updates to arrive - they should just already be there. There is also a small gatweay application translating between the old multiplayer and hla that might go into the utils directory past the next release. So, I was pushed to put this code in the public, even if I personally think that there are still too much opportunities to break stuff. Well, with break I do not mean that it does not run or compile. With break I mean that people just put something together that works either for their private needs and they do not care further, or break in the sense that if you would know the bigger picture it would already be very clear that this cannot scale for the kind of use that will most probably happen in the not so distant future. I can really observe this in the scene and model area. I have really seen incredibly fast osg applications with stable framerates and nifty looking models. But the way we use osg and put together models leaves osg and below that the driver only little chance to be fast. Which leaves only little headroom for sensible further development. Getting back to components: Latencies are a critical part of running in
Re: [Flightgear-devel] (JSBsim) body accelerations
Hi, On Wednesday, December 19, 2012 15:48:40 James Turner wrote: // accels, set that to zero for now. // Angular accelerations are missing from the interface anyway, // linear accelerations are screwed up at least for JSBSim. // motionInfo.linearAccel = SG_FEET_TO_METER*SGVec3f(ifce.get_U_dot_body(), ifce.get_V_dot_body(), ifce.get_W_dot_body()); The JSBSim values aren't screwed up, I think, just including other non-inertial terms which YASim does not. Since it's the inertial accelerations I want to sense in the instruments, that's why I will tweak the JSBSim-FGFS interface and not YASim. Well, to streamline the interfacing this might be a good idea. For the motion onfo part, I can well think of removing the accelerations from the motion info. Over time, it turned out that the velocities are sufficient to transfer. I am currently not sure if the multiplayer code currently makes use of my latest thoughts about this kind of interpolations, but I would think that we can just remove the accelerations from fgfs internal multiplayer code. The multiplayer udp packet needs to stay as is. Just pack zeros there ... Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi Adrian, The same idea is behind the osg lod based whole world model. Where do you store the elevation data? Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 20:24:48 Adrian Musceac wrote: It's actually nothing really special about it, I'm just modifying a little the tile manager to define inner tiles and outer tiles. The elevation data is inside the same old BTG files, which are actually lists of polygons making a tile mesh, hence why it's hard to simplify on runtime this mesh. The Terragear team might now more about this. This is just a few lines of code modification to decrease memory usage by really detailed scenery and allow a greater terrain loading range. So nothing's changed about the terrain format itself. Ok, so it's not really less level of detail. It's just about stripping out the models to have bare btg's. Right? Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: I am aware there are better systems out there, I'm just doing what I can within the restrictions of the BTG format. I'd be more than happy to have a real terrain LOD, but right now that means lots of changes in Terragear and simgear. Well, I suspect that this effect is easy to get without any additional manager. Not to speak about sophisticated continous lod. Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 22:32:48 Adrian Musceac wrote: My main interest with terrain was a) having longer distances available, and b) having separate traversal masks only for surface. All for use in my infamous now radio code. This lead to what I have now, an improvement in memory usage and view distance. Ok, for that, I can see a lot of solutions. Having one that is may be close: Use the BVH tree that is used in fgelev or fgai. The fgelev one is parametrized like you probably need today. There is one hacky switch in the BVH paging that only loads terrain into a bounding volume tree. Have two different bvh trees and making sure that these nodes are not cached for scenery loading - since they are incomplete in the sense of the visible viewer - would provide you what you need. Since you are doing radio stuff I expect that your main workhorse is a line segment intersection which should be done best with this kind of structure. True? May be you need an other line segment visitor which measures the distance that is covered by material. Ok, what might block this approach is the amount of static variables that is spread around. Already in face of reusability almost every global/static variable can be a serious problem ... Look into fgelev and fgai and look for BVHPAger and its getBoundingVolumes(sphere) method. May be flightgear is not really ready for this kind of shared usage, but the basic building blocks are there ... Ok, in the end you might need an other custom approach. But just off my head what I think is probably best algorithmically. Also keep in mind that tuesday is the deadline for new features for the next release. Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Canvas reuse/restructuring
Hi, On Saturday, October 20, 2012 18:10:42 Thomas Geymayer wrote: recently I've been asked by the FGRadar developers if we could modify the canvas system such that it can be reused in other applications and we can all work on a single and stable implementation, instead of a separate implementation for each single application. I think thats I good idea and I want to take any opportunity to get the canvas better and usable for more applications. As some of you have noticed I've already done some preparation work by moving FGODGauge to SimGear. Take care of the license. I have seen this is already under the headless option. Also once it is in simgear It should be really multi viewer/threading capable. Everything that is not, might be changed at some time to match this criterion. Such a change often comes with changes in the behavior that are not strictly needed but where people started relying on at some time. So better think about that at the first time. Now the question is if this is the best way, and the canvas should get part of SimGear or another solution would be better? I'm not quite sure what belongs to FlightGear and what should go into SimGear instead. The canvas is something that could also be useful to other applications as it's basically just an offscreen rendertarget for 2D drawing. Any opinions? No application logic should be there. That's the cut. Anything that is an application decision should not end there. Also if there is stuff that is used by multiple applications it's a good candidate for simgear. Also the scenegraph should not have any self propagating state. State should be kept in the application logic. That means the scenegraph should only contain a plain description what is being displayed but not what can happen next. This is one of the parts which ease multithreading. Also it would be nice if the state of the canvas can be serialized easily and with only little data into an other application. That is to be able to set up multiple viewer applications all displaying the same content. Think of an mfd that is shown in a bigger multi viewer environment. This should be efficient. How to achieve this efficiently requires a lot of thought. Greetings Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader optimization
Hi, On Tuesday, October 16, 2012 15:17:04 Tim Moore wrote: I don't have access to a local copy of the tree at the mo', but I remember that this was introduced by Mathias when he added BVH. Yes. That is to align the bounding volumes boxes as well as the drawables bounding boxes to the earths surface - which makes most of them smaller on average. But never rely on something like this in a renderer. Mathias -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle
Hi, On Saturday, October 06, 2012 14:14:49 James Turner wrote: I've sometimes wondered if we could have much greater variety of 'trees', to place scrub (cactus in Central America, bramble in Scotland) in areas where full trees don't make sense. I guess wi the regional materials that ought to be much easier? Doesn't that mostly depend on the average temperature? Which usually depends in the first order on the lattitude and altitude above sea level. What is beyond this temperature dependence could be tracked with specific materials then. Mathias -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] custom_scenery/Models objects aren't loaded anymore
Hi, On Sunday, September 16, 2012 21:10:54 David Van Mosselbeen wrote: On Sun, 16 Sep 2012 16:35:37 +0100, James Turner zakal...@mac.com wrote: [...] This was caused by some changes Mathias made a few weeks ago. I've discussed the potential fixes with him and will be making some code changes in the next few days - please be patient! (or use the stable release :-P ) Regards, James Hey, Seems to be already fixed and working here! Awesome! :) A copy and paste typo. Sorry .. Mathias -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
Hi, On Thursday, August 30, 2012 07:27:45 Renk Thorsten wrote: Computing constant values at runtime is bad design and we should not do that. No matter if we notice a significant increase in load time now or not. The ground elevation at a specific point is well known at scenery generation time and that is where the vertical position of an object has to be computed. Not in the main loop at the moment of scenery loading where computing time is precious. Just my two cents from a mere scenery user perspective... I think I understand where the idea comes from - like the floating tanks in Seattle Int. Say someone wants to populate an airport with buildings - there's the real layout and there is the Flightgear default scenery layout - which are sometimes quite distinct (think of places like Courchevel or Alpe d'Huez where the default layout, especially in terms of elevation, is *really* off). He can get closer to the real layout by using custom scenery where it exists (as in the case of Seattle) and place objects at their actual position, but when this is submitted to the scenery database, the objects float or sink. So, people would like to populate close to the 'real' layout, but still do something useful for the scenery database I guess, and it would be nice to have a way to automatically place objects at a plausible elevation for people who use default scenery and for those why use custom scenery. Determining elevation runtime would do that - but there may be other ways of achieving the same result - maybe alternative object positions can be computed at custom scenery creation time and shipped with the custom scenery file, overwriting the default declarations? I don't know how to make this work in practice, but perhaps the discussion should focus on how objects can be placed plausibly with minimum manual effort under the assumption that there are users which use custom scenery and users which use default scenery in the same place without making the computations runtime? I can see this. Sure. It's a matter of fact that we have different scene sources. This is completely independent of - if some of us like that or not. I personally think that it would be very nice to have more of these stuff contributed to the official scenery, but I can also see that there are some edges that at worst do not allow this at any time. So fine lets assume that we need to cope with that. Ok, this addition solves some problems that are probably the worst for some of us currently. Still fine - this is the reason for me that I did not change this into a devel only option as suggested. But I still think that everything that is officially published which is obviously self consistent *shall* *not* *use* agl levels for the explained reasons. It's really no good idea to convert everything to AGL placed just because it's there. Using this is *at* *best* sensible if you cannot solve that in a different way. There is so very often some ideas floating around which are really bad and which are followed just because anybody talking about that stuff knows nothing about what what's happening behind. And so very often from my point of view it would take magnitudes of time to explain the very basics which are required to understand the problem. I don't have this time. And in this particular case *do* *not* *use* this! Please! Only if you cannot get around that. And no, just for convenience is *in* *no* *way* this kind of a reason! And do never tell that I have not warned you! Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
Hi, Really nice to read about that. I got the chance to look at a similar install of flightgear in Tübingen very close to where I live. And You may remember me - I believe we have talked about the problems you have at the fsweekend. So to say: I am glad to see this piece of software installed in this kind of environments. Thank you! We did have one issue tough with our setup. Since we run three different instances on three different machines, we got clouds which weren't consistent across the screen. We fixed this with a small hack in the random number generator and the cloud rendering code. It's not pretty, but does the job for now. If you're interested, it is in my gitorious repository: https://gitorious.org/csflightgear. In the next few weeks, we will be fiddling a bit more with the setup and might do some further tweaking. If I have more problems, workarounds, tweaks, ... I'll let you know about it. And we are of course interested in feedback from you all should you should you see something you like or don't like. I am somehow short on time. But I want to have the problem with the clouds solved. As explained every now and then, I am working on a viewer instance that is designed from ground up for this kind of scenario, so in the long term this should work, but for the short time it is really good to know that this is at least somehow solved. If I forget about that, feel free to remind me ... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. 26664aaff0e2f97db916909218d849b51636ccc0
Hi, On Wednesday, August 29, 2012 09:08:44 James Turner wrote: Nice work Mathias - much better decoupling of the AIModels from the scene. Thank you. Thanks, it was independent of what you started. It just originates from moving the bvh stuff to simgear core which could be solved like that ... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
Hi, On Monday, August 27, 2012 10:57:57 Torsten Dreyer wrote: If that feature helps scenery developers to _temporary_ place objects, may I suggest that this code is enclosed in #ifdef's and only enabled during compile time with a special CMAKE switch and never enabled for a release? That's possible. We can guard this with a cmake configure time variable. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compute ground elevation dynamically for STG format
Hi, On Sunday, August 26, 2012 11:20:38 Clement de l'Hamaide wrote: I changed my technical solution in order to use the technical solution proposed by Mathias. I hope this git diff is more adapted : http://pastebin.com/30GD4ksE This looks much better. And I think you agree that it is much simpler and probably less error prone. As you can see the parser is ready, I have tested with modified STG file and it works. Now I just need to implement the ground elevation calculator. I have just a doubt about the variable elev I'm not sure that's is a good idea to send it as parameter since send change it in the function. Let me know what is wrong, how to improve this little change code. About the ground elevation calculator I think you are more able to create it because you know how to do. Personally I don't see how to adapt you fgelev because he is create for standalone program. In this way I think it's not really possible to adapt it for runtime program. Let me know if you accept to create this calculator. Ok, I hope that nobody really picks that feature up except may be a few people having their home grown stg files. Especially I would strongly advise the scenery people doing the 'official scenery' - whatever this means currently - not to use the agl based objects for placement and instead precompute the mean sea level elevations instead. The next advise would have been to look into osgUtil::IntersectionVisitor and osgUtil::LineSegmentIntersector and run this on top of the already loaded base nodes. I have some pending changes in this file here, so please forgive me if I introduce a huger conflict with your local changes. So the upside of this is that I really already implemented but not tested the changes on top of what I had pending yesterday and provide agl based objects with the next push. BUT: Never complain that scenery loading takes a long time in ground level computations! You have been warned! Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format
On Sunday, August 26, 2012 21:04:53 Clement de l'Hamaide wrote: I have done some test. Here is the result : Nb of objectWithout _AGLWith _AGL 0 20.4s 20.4s 500 21.4s 21.4s 5 000 21.6s 23.4s 15 000 24.0s 29.9s 30 000 27.2s 39.1s 100 000 52.1s 95.6s For information, TerraSync has 1 100 000 thus when I try to load 15 000 object I tried to load 1% of the entire TerraSync database in at once. And with 100 000 it's 10% of the entire TerraSync database. Of course it's not realist since objects are placed everywhere in the world in this way 1 STG file can't contains 1% of the entire TerraSync database. For example if the whole LOWI region (less than 4000 objects) was transformed with _AGL the loading time will increase of less than 2 seconds. As LOWI is one of the most advanced scenery it's a good comparison. With these test I can conclude that the _AGL tag can increase the loading time (and it's normal) but it's insignificant because FG doesn't load more than 5000 objects at once since tiles are loaded step by step. That's what I was trying to say to you. It might be the case that you do not see a huge problem today, but given you will see some changes in future scenery this will come up. To me, for that argument I just no not care at all what todays scenery just do by accident. Where accident I mean in this particular case that we have currently few triangles in the scene - which is good for many reasons including the one you are talking about. But it's clear to me that it's just a matter of time until we have something more finegrained. Then this will be more of an issue. Really, think about how such an algorithm works that you need to implement this feature, what computational compexity is sitting behind this and under which curcumstances this hurts. So not to be harsh, but to really judge about if this will be a problem or not I expect you to understand the above *in* *detail*. Then once you understood that, think about what is probably happeing next to the scenery. Then think about how people typically act in this kind of projects and see how the probability is that we will in the not so far future get scenery where it will be way more of a problem. How these claims all affect each other is left as an exercise ... Also you will find that today convenient to give agl numbers. But Trust me, there are plenty of people out there who do not care at all about your convenience. They want the scenery and they think about why this is taking longer when you use this feature widely. And the only answer is in the end: for no sensible reason - we can equally well precompute these elevations. And given your numbers I am surprised very bad how huge the impact already is with the current scenery. If you personally want to wait longer - I personally don't care. But please, in any officially published scenery, do *not* use this agl numbers and instead precompute the elevations! Thanks for reporting that it works so far. Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compute ground elevation dynamically for STG format
Hi, Hmm, I am not sure if we want this. It's really a few lines code thing to implement above ground placing of objects. The point is that this is a task that could be done once when the model is integrated into a scene. So, why the hell should we do that *every* time the scene is loaded? Just for convenience? ... which is where I tend to say: No, not for that reason ... I have read well what you can do with that. Sure, but in the end this is *nothing* that delivers a different value on each load of the scenery - given the scenery below is the same. Really it seems like this is not a huge problem today. And if you do a test case with a few of these elevation numbers this does not matter - I am pretty sure that this works pretty fine for a few of these elevations and for todays scenery. But I had seen scenery where even the runway markings were done with individial polygons. Not that this fact could be source for an other lengthy discussion about whther this is sensible or not, but also this means once you have this kind of scenery and consistently use your proposed feature, you *will* wait a long time to finish this kind of scenery loading. And no, do not just compare loading a single tile. Really consider what happens when you load the paris scenery with *all* houses placed in this way. The first part is pretty advanced, the second part is mainly already create by Mathias with the new fgelev tool. I hope that fgelev can be adapted for a runtime execution. With my changes, SG compilation works fine, but even if I haven't touched FG files (I have only touched ReaderWriterSTG.cxx) FG doesn't compile :/ I'm a little bit surprised that SG compilation is a success but FG compilation fails since I haven't touched FG source code. fgelev is written purely to support the scenery generation process for the svn scenery. This is just the tool that I wrote to replace some really old tool where the source vanished and that is used by the scenery generation process for the svn scenery to place the objects. The tool itself is only written to support some database scripting together with awk and sed to give the right SELECT BLA FROM BLUBBER statements. So currently the output/usage of fgelev is not really thought for everybody use. It's just in the git so that the sourcecode cannot vanish anymore :) Do I understand right, you want to start fgelev to get the scenery elevation while loading scenery? That's something I would like to avoid on any price. The problem is solved with a few lines of c++ so easy that I would never take this burden of relying on sometihg error prone like only loading scenery correctly when some binary is found in the path or all is installed right in the right paths and so on... This is really a task for inline c++ ... Also, the bounding volumes might not be present in some variants of the scenery being loaded. So, relying on this as the fgelev visitor does is a bad idea. This is because you will not need these bounding volume trees for every type of application. Imagine you want to have a viewer only application that never does ground queries - which is on the works - you do not want to spend the extra time for computing these tree just to make no use of them. Therefore you can switch off generation if these trees. But consequently that means you need to rely on a different mechanism for this purpose. The implementation is not harder but different. Also the direction where the bounding volumes will move is that they will not just cover individual leafs in the scenegraph as they do today. A single leaf ground query object will in some time in the future cover a whole tile of static geometry. Only moving parts will show up individually. This is to improove lookup times for parts of the simulation that really need to do these lookups often and fast. But this collides with the need of scenery loading were you do not yet have the full tile loaded - you are actualy in process of loading it by composing the tile from the buildings placed above agl. In this case you would need collision geometries that do *not* cover the whole tile. Which is either something you have to compute at that point or you need to resort to processing linear lists for what you want to do. Which means that the computational cost per agl placement will raise considerably. And no, the next idea to structure the scenegraph like a collision geometry for the scenery loading reason is bad for rendering, the scenegraph should be optimized for rendering the collision tree should be optimized for collisions and both needs collide in some ways. In terms of computation time - people scream about loading times for scenery . all the arguments provided here are targeted to shorten the times. Either compute the bounding volumes which are costly or spend something longer in determinging the ground elevation of former loaded scenery. Which wart do you want to have? I am targeting
Re: [Flightgear-devel] Rendering passes question
Hi, On Sunday, July 22, 2012 01:17:43 Tim Moore wrote: That is a big problem, but we also have CPU bottlenecks upstream too. I agree. The scenegraph structure is not well suited. But therefore at the first cut I hope to simply get less tiles and models present by a better lod structure. Therefore the below work. I would really like to see that code! SGReaderWriterSPT. Start fgviewer without arguments. There is a meta loader for these spt files that encode the area they should cover in the file name before the spt extension. There are problems with the tiles near the poles. But this is something that the original stg database covers very bad. So the spt loader just reflects this weakness. I wanted to address this just before somebody who felt responsible for a while for the scenery quit this work. Since I would need assistance from the scenery guys for changing the tile layout at the poles ... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] commit 75087095b132ec7a42e14000c7c8b3b09147d720
Hi Tim,
The mentioned commit breaks scenegraph picking.
For reference take the c172 door handle that opens the dor but never closes it
anymore. Well, except you click at the position where the untransformed door
handle would be.
Also I have some issues with this.
I agree that we should move this into the cull stage. I wanted this also for
some time now. So, thanks for doing this.
But:
I think we should do this in a usual osg::Transform derived class in the two
methods computing the transforms.
That would make picking work again.
That would make osgUtil::CullVisitor find some already pooled RefMatrix without
the need to call new/malloc and delete/free implicitly on each of these nodes.
That would make the nodes work without the EffectCullVisitor and with a plain
osgUtil::CullVisitor. Sure this could be done by just changing the
dynamic_cast to the osgUtil::CullVisitor.
Also osg::Matrix has some methods like {pre,post}Mult{Translate,Scale,Rotate}
which works with O(n^2)~16 operations instead of O(n^3)~64 operations. Ok, the
rotate method saves less.
Greetings
Mathias
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
Hi, On Thursday, July 19, 2012 17:09:09 James Turner wrote: I have some plans in that direction post 2.8, especially to flatten the LOD quadtrees and transforms of the tiles. Each tile will get some top-level LOD groups for all objects (shared and static). I'm hoping in combination with the LOD-scale function in OSG, this will mean we can automatically drop random tress / building and STG objects to keep frame-rate up. (as an optional mode of course!) You mentioned flattening the transforms. As already discussed this is good to do. But some of them are critical to stay like the are or at least similar. The first one that positions objects with respect to the earth centered coordinate system for precision reasons. Also these coordinate systems coudl for drawing reasons aligned in any direction. But as long as we do simulations using the same tree and geometry alignments that we do for draw this still interferes with the bounding volumes we have for ground intersections. And this axis aligned bounding box implementation gains a lot by having the boxes horizontally aligned. Todays transforms are done so that huger things are aligned with the horizont which serves this purpose. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering passes question
Hi, On Thursday, July 19, 2012 15:32:01 Tim Moore wrote: The depth-pass-only pass is a well known optimization, but the fact it is not helping implies that our bottleneck is not in fragment processing. I've suspected for years that it lies on the CPU, and have been trying to optimize our scene graph a bit... It *is* on the cpu. At least for most of the use cases. Every now and then there is an other limit that comes up for specific stuff. But we are *mostly* draw limited. The draws are way too small to be efficient. James and I were talking about this some time ago. I would go even further for the LOD's. In the meantime I have in fgviewer a PagedLOD whole world database tree running. This is similar to osg's marble dataset but carefully designed around our tile structure. Using this I think we can really replace a lot of our fine structured scenery tiles with something more croase that is used for tiles more far away. Drawback with our current codebase: Our integration of the particle systems need to be rethought as this contains geometry with culling disabled which makes a pagedlod just never expire. Switching the particle systems off works pretty good so far. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Monday, July 16, 2012 07:20:32 Chris Forbes wrote: If DDS is not politically acceptable, there should be an alternative way of providing premipped textures. Mipmap generation is a *significant* portion of the load time, particularly on the nicer aircraft with large textures. Even something as simple as a bunch of PNGs concatenated from small to large mips. I do mostly see nvidias binary driver suffering from this problem. And to my experience there it really helps to switch off compression at all. As a workaround append --prop:/sim/rendering/texture-compression=off to the command line. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote: I can see a number of options to resolve this (and I'm sure there are more): The 4. Method that I can imagine is to precompute the mipmaps in the loader. IIRC tests with some of the guys suffering from this problem, providing premipmapped but uncompressed dds files had helped to get a fluent viewer. The argument against providing these dds files in general was that these files are really huge because of not including any compression and having all the mipmaps. But that means we could at the point where the warning happens compute the mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be used to do this I think (or something similar not requireing a context). This one is an imported version of the original glu function that is included in osg for running on an EGL stack which no longer provides GLU. That is take the image scale this to the 1st mipmap, take the 1.st mipmap and scale this to the 2. mipmap and so forth. This would have the advantage that the png's do not deviate from the dds files over time. 3) Add a /sim/rendering/use-dds property, drop the file extensions from the effects files (and possibly materials.xml entries?) and add some logic to check this flag and search for .dds extensions, and failing that .png for images. Hmm, I could think of both solutions. Both have pros and cons. Greetings Mathias-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote: I can see a number of options to resolve this (and I'm sure there are more): Oh, I forgot in the previous mail: There is a 5. Solution: Provide premipmapped uncompressed dds files and compress them with something like gzip. Osg can handle this kind of thing I believe, it uses the gz plugin to uncompress and the dds plugin to do images from the dds byte stream. Hmm, need to double check... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Saturday, July 21, 2012 11:56:39 Harald Johnsen wrote: gluScaleImage does the usual job of blurring the texture to compute the mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is that we can use better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. Perhaps gluScaleImage could be upgraded with some more algorithms ; the original code was trying to be fast but this is perhaps useless nowadays if the code runs in a separate thread. Ok, I see. I did not look into the nvidia tool too close. If somebody wants to use something better then the proposed function, that's great. Also Fred has some nearest neighbour mipmapping code somewhere in simgear. Whenever somebody provides a good mipmapper, we should probably also use that everywhere we need this. I wanted to give a sketch of how this could be implemented without a huge effort programming wise. Well, for the computation time. I expect that we can observe this on startup. May be not too much, but this could be at least measurable. For really loading something new during the simulation, I think running this in a loader thread makes most of the runtime discussions about on cpu mipmapping cost mostly obsolete. What about solution 6 with (uncompressed premipmapped dds).gz? On linux this should work as long as you have zlib installed which could be regarded as a system library there. Can we rely on zlib being compield into our osg distributions on win32? We do need zlib in any case, it's mostly about teaching osg that it finds our zlib on configure and build the gz plugin. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slow frame rates
Hi, On Monday, June 18, 2012 13:20:17 castle...@comcast.net wrote: The HLA/RTI architecture is far more sophisticated than what might be needed. The idea is not to split FlightGear into a distributed, federated application across a multi-platform machine or network although that is an intriquing prospect for stimulating the brain cells. ;-) While the interface is providing more than you need today, I think the major benefit is that it shields away a lot of synchronization stuff from you in a way that you can still programm younlocal component in a single threaded way. The coupling of components *can* be that tight so that you can get determinicsit time slicing for some of the components. Say you want to simulate glider towing you can do that with each fdm running in its own process while still deterministically exchanging simulation results at a the fdm's rate and st time step boundaries. The same goes for components within the aircraft which I consider a possible use case for your kind of application. In contrast to that, You can still run the viewers asynchronously to the simulatoin core providing hopefully 60 stable frames without being disturbed by synchonization needs of specific components. So, you might have an Idea how to to that by ipc directly, and trust me I have considered this at some time. But what this standdard provides is really driven by exactly those problems that need to be solved once you dig into such kind of implementation. So one of the benefits is that you gain a encapsulated communication library that does what you need. This library can be tested independently of such an application beast like flightgear. And this is IMO a huge benefit. By way of an example, consider the 3D cloud system. Given a three projector system, each CPU is configured in a similar manner as before for a multi-monitor system; i.e. there is a master FDM, the slave FDMs are disabled and each CPU is bound to a display. I don't recall the exact syntax but for those who have run multi-monitor display systems you understand. The doc files and readme's provide a good description of how to implement this configuration for those not familiar with the setup. The down side in this approach is that each CPU creates it's own graphics context and dynamic/random scenery objects are not sync'd. It has been a year or two since I last spent any time digging into or running FlightGear with master/slave machines. The current 737/747 sim runs on a single CPU with three projectors to make use of all the eye-candy. But I believe the above assertion is still true. In the case of the cloud system, something similar might be possible. Rather than using the network, we would use shared memory as the IPC. The master cloud generator creates the shared memory segment and manages the cloud objects. The slaves obtain the objects from the memory segment and render as required. They do NOT create their own objects. AI objects could be handled as well with this approach. Yep, this is exactly what I want to do with the HLA stuff. A weather module running in a different process/thread/machine that computes positions for clouds that are consistenly displayed on each attached viewer. That being a module that is exchangable. The simple version just interploates metars like today, but more sphisticated versions might do a local weather simulation to get good results for thermals in some small area. The same goes for every component you can think of splitting out. A simple AI model does just the trick what it does today. But more sophisticated modules might contain an owhn fdm so that these machines really live in the same fluid that the weather module provides data for. Note that the rti api already provides a subsriber model that ensures that ypu don't feed data to participants that dont' need that. May ba a radar controller screen that can be attached there to see the machines in this word. But sure that radar screen is not interrested in flap animations for the aircraft ... Or take the viewers, if you just exchange data by a shared memory segment, you are limited to a single machine. So that's nice for the 3-chanel thing you have. But I know of installs with 9 chanels I have been visiting some few time ago. They run flightgear on that beast by the way. Or I know of installs that currently run 14 or 16 chanels within a single view. For that reason I thought: better have a technology that is also extensible for this kind of installs instead of programming everything on top of something limited machine local. Each fgfs executable is still a monolithic process within the supporting CPU and would not require major surgery on the existing source outside of adding a shared memory instantiation. The question would be how to make it applicable for all platforms. Linux I can do, clueless for Mac and MS. Also a benefit of that hla stuff. Use this and it alredy works on all platforms.
Re: [Flightgear-devel] Slow frame rates
Hi, On Sunday, June 17, 2012 13:00:15 castle...@comcast.net wrote: This email rekindled an idea from a while back. Last year while working on the 747 sim with multiple projectors and a quad core CPU I experimented with setting up three instances of fgfs - one for each cpu, graphics card, and projector. The improvement in the frame rate was quite dramatic; from around 20-22 fps to over 55 fps for each instance. The down side was that all the dynamic features (3d clouds, AI objects, random stuff, etc) all ran in their own graphics context. so while all the static scenery sync'd across the projectors, the dynamic objects ended at the display boundaries. Multi-core machines have been around for some time now. Perhaps it is time to think beyond running Flighgear as a monolithic process in a single CPU configuration. It is my understanding that all three platforms ( MS, Mac, Linux) support some form of shared memory IPCs. I use shared memory in the 737/747 cockpit software to great advantage with a global section for all common data and sharing data between the Captian, FO, and MCDUs processes. In Linux creating a shared memory segment is simple and straight forward. The master fgfs would create the shared segment and compute the graphical objects, in this case clouds and AI, and the fgfs slaves would simply access the shared segment for the data required to create their visual scene. Hopefully, I'll have some time in the fall to pursue this idea further. In the mean time, the floor is open to anyone who would like to comment or pursue this idea on their own. Well, that's about what I am about to do with the HLA stuff. The nice thing is that the ipc is hidden behind something that is also able to distribute this across multiple machines. A local network connect is mostly sufficient. But doing the same by an infniband connect is possible too. Experimenting with shared memory did not bring notable improovements over a system local network connect. At least not on linux... In any case I think this could be fast enough to do this stuff. Also this stuff is based on a standard that is probably enables us to be a little more connective in the end. At least this is a slight hope from me. John, by this way, I did send you some mails regarding the unwrapping, but did never get an answer - did you recieve them? Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Good morning, On Friday, May 25, 2012 19:48:32 Stuart Buchanan wrote: Thanks for taking a look. I think that the SGBuildingBin destructor will be called when I call the list clear() method on the SGBuldingBinList (SGBuildingBin.cxx line 654). That in turn calls clear() I have no current code update, since I am on travel, but I think that the SGBuldingBinList is a list of pointers. Then, on clear of that list, the pointees are not cleared. Either store the objects itself in the list, which should copy a lot more in the way you do this, or use SGReferenced together with a list of SGSharedPtr values. Just to give two simple solutions. In both of which, the clear can be completely omitted, that happens anyway on the destructor of any stl container. on the BuildingList (SGBuildingBin.hxx line 105), which is a simple struct of basic types, so shouldn't need a destructor. That's right. Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings - memory consumption
Hi, On Wednesday, May 23, 2012 10:37:00 Stuart Buchanan wrote: So - Does anyone have any bright ideas on what I can do to reduce the base memory occupancy? One option might be to not generate the basement if the terrain is level. - Could a fresh pair of eyes take a look at the obj.cxx, mat.cxx and SGBuildingBin.[ch]xx code to see if I've missed something obvious. I may be false since I really only spent *very* little time on that. But I believe you never free the content of the building bin list. That means the pointers stored in the list are gone, but the building bins - the pointees - are still alive. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hi, On Thursday, April 26, 2012 08:32:19 James Turner wrote: On 25 Apr 2012, at 14:56, Stuart Buchanan wrote: If you're going to be looking in the code anyway, the depth of the quad tree is set in some constants at the top of the SGBuildingBin.cxx file, and (IIRC) the LoD range is also set up there, so you could see if reducing the depth makes a difference. Found at least part of the issue: BIND_PER_PRIMITIVE should be avoided - it forces OSG to use manual calls, at least for me. Changing the normal binding to vertex (at 4x the memory for the normal array) gets the performance back to 'sane'. There's still quite a big FPS hit (eg, 50 FPS down to 30FPS over the centre of Edinburgh), but it's not 'crazy-off-the-scale-slow'. I did a check, and fortunately nothing else in our code is using BIND_PER_PRIMITIVE. Yes, there is that 'fast path' and there is already a method at the geometry that tells you if it will run in the fast path or not. I believe the method is areFastPathsUsed or something like that. And it's a bit tricky to trigger the flags evaluation. But looking at the source helps. In the end its all about if there is a corresponding OpenGL draw call that can just work on the unchanged arrays. Nice work so far. From some distance it looks pretty good. Thanks Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi, On Tuesday, April 24, 2012 13:39:59 James Turner wrote: Okay, then I realise this isn't useful for you, but I'm stumped why it crashes for you. In particular, the hashForAirport function is being passed something that looks like a valid pointer (I think), and it crashing on a line that should only really happen if the pointer is invalid, or there's other memory corruption going on. Just stepping into this discussion somehow. I could by the length of the thread not exactly find what is going wrong and how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I can see that this does not match the intented use of SGReferenced. I have checked in what is needed to match how it's intented to be used. Given that you seem to experience dangling pointers and now things are actually deleted when the reference count drops to zero - that did not happen before, I guess that this makes things worse at first. But you might be able to find the real cause of the problem a little better now. Else, I am online again tomorrow evening. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT as of today unstable
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
Okay, I guess I was assuming I can use SGreferenced the same way I use
release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
this is not the case, from looking at your commit - I can't use
SGreferenced as a virtual base, and I have to make the delete call by hand.
I guess this is to avoid virtual method overhead on SGreferenced?
Yes.
SGReferenced should exactly *not* contain any virtual table. This is supposed
to be the helper class for reference counting, but it should be as lightweight
as possible. Imagine we want at some time have a variable size mathematical
vector container that works with a copy on write semantics, I definitely want
to use SGReferenced there and have no vtable at all.
If you want something that you can just use a general base class for
heavyweight stuff, invent a class derived from SGReferenced or better
SGWeakReferenced that introduces this vtable stuff. And since we are looking
then for something more heavy, I would tend to use SGWeakReferenced as base
class for an SGObject
class SGObject : public SGWeakReferenced {
public:
virtual ~SGObject() {}
}
The weak referenced class provides the ability to have weak pointers to such a
WeakReferenced derived class. That are pointers that know about when the last
reference to the instance it points to is deleted and provides a
SGSharedPtrT SGWeakPtrT::lock() method that atomically and thread safe
returns either a valid shared pointer to the still alive object or a null
pointer since the objects reference count was already zero and the object is
at least being deleted or already dead.
If you want the destructor protected, I need to backport something more from
OpenRTI and stuff to simgear.
What about the mentioned problems? Better? Worse?
Mathias
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vesion 2.6 breaks distortion code
Hi, On Thursday, April 19, 2012 15:32:46 castle...@comcast.net wrote: We need to fix the problem, just not sure best way to proceed. Send me that change, I will see how to incorporate that. This will take some time since my next two weeks are extremely full for me, but somewhere past that ... For distortions, there are several ways to do this even outside the application: The easiest way I can see under Linux at least is to use the composite extension to unwrap distorted displays. There is no code out there that really does this, but I believe this should be about as easy as doing unwrapping in an application. If I had time to do something like that, I would at least know an other user who is interrested in that ... Greetings Mathias -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hi, On Wednesday, April 18, 2012 10:25:55 Stuart Buchanan wrote: For those interested, the technical background is as follows: - a Quadtree is used to ensure very fast culling of the buildings - based on the work that Tim Moore did for the forests. - a single 1024x1024 texture is used for all the buildings, minimizing the number of state changes on the GPU - all the buildings at the leaf of the quadtree are part of the same geometry, so the GPU can churn through it very quickly without having to change state. That sounds like we are heading in the right direction. Thanks! Let me be somehow picky: You are talking about having the houses in the same geometry, that's already fine. The next thing to care for is that they are also in a minimum amount of osg::PrimitiveSet instances. That's about minimizing the amount of draw calls that happen underneath. The best thing would be to have one single *DrawElements instance doing the whole geometry in a single draw call. Greetings Mathias -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hi, On Wednesday, April 18, 2012 17:21:56 Stuart Buchanan wrote: I think I've already got that covered. I'm using a single osg::PrimitiveSet, and a single list of QUADS/vertices/normals/colors/textureCoords at the leaf of each Quadtree. Great! Thanks! Mathias -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 09:49:18 James Turner wrote: On 13 Apr 2012, at 23:28, Chris Forbes wrote: Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? Yeah, unfortunately I think people want the high-res art for a reason - this needs a runtime test for the Intel chipset (on Mac only?) and something to reduce the size. Unfortunately that's a lot more work, and might require OSG changes since OSG loads the textures :( But every image goes through our hands. We can just rescale this under certain conditions. At least the uncompressed textures are unproblematic. I would introduce some property that is evaluated in the image load callback than. Today the chain of readerwriter options should in any case provide a simgear options object that contains the property tree that could be queried then. Mathias -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 11:05:10 James Turner wrote: On 14 Apr 2012, at 10:10, Mathias Fröhlich wrote: But every image goes through our hands. We can just rescale this under certain conditions. At least the uncompressed textures are unproblematic. I would introduce some property that is evaluated in the image load callback than. Today the chain of readerwriter options should in any case provide a simgear options object that contains the property tree that could be queried then. Ah, I thought many textures only when through osgDB, and we didn't have any callback or place to make such changes. If we do, then it's easy to add a property as you suggest. That's in ModelRegistry::readImage() Alternatively we could traverse the scenegraph of a loaded model and look for textures. That shouold work also. But the model registry thing sounds at first more plausible to me. Greetings Mathias -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 13:51:33 ThorstenB wrote: On 14.04.2012 13:08, Stuart Buchanan wrote: I like the idea of resizing textures at model loading time a lot. The other option would be to switch the shader off. Presumably that would not load the normal map into the GPU. Shader textures are loaded unconditionally, at least into main memory. Hopefully GPU loading is optional - but I'm not sure. Textures are loaded in main memory when the model that references them is loaded. Handing textures over to OpenGL is done once they are rendered the first time. Then the driver decides when to put the buffers in which area of the gpu/cpu memory. You cant control this then. And I think you should not try to control this last part mostly since this highly interacts with paging, uses of the GPU by other applications and so on. So this really belongs hidden into the driver and interacting with the system. If someone was looking into improving the effect/texture loading code: it would be great if loading shader textures could be made optional, i.e. defer loading them until first access. Well, what do you mean with 'first access'? As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. That's actually something I consider having. Also for different reasons. All the shader stuff is really nice but there are really use cases out there where it does not matter if the chrome is glossy or not. For them it's really most important that you get stable 60hz in *any* case. Which is still easier to get using the fixed function pipeline. So again still having that available would be good IMO. Greetings Mathias-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 17:16:52 ThorstenB wrote: On 14.04.2012 15:18, Mathias Fröhlich wrote: Shader textures are loaded unconditionally, at least into main memory. Hopefully GPU loading is optional - but I'm not sure. Textures are loaded in main memory when the model that references them is loaded. Handing textures over to OpenGL is done once they are Right. But some of the global shaders always seem to be loaded. For example, start at LOWI. Doesn't matter whether shaders are enabled or disabled - you still get the warnings about the proprietary sea_foam.dds textures being loaded. Not sure whether it's really referenced by the scenery there - the sea should be really far away ;-). Ah, thats probably everything that is referenced by the materials. Yes, this could be done on demand when the materials are really accessed. Is this worth? Try it out ... The material states could be loaded by an other meta loader that registers statically at the loader registry. The simgear internal part of the materials would be created once the xml file is loaded but tha state sets can be done on demand by a readObject() method in this loader. Look into the SPT Loaders state sets and world texture state how this could be done. When you do this take care that this happens probably more concurrent than it happens now. If someone was looking into improving the effect/texture loading code: it would be great if loading shader textures could be made optional, i.e. defer loading them until first access. Well, what do you mean with 'first access'? To somehow create the effect object when the model references it, but to defer loading the texture until the effect condition becomes true for the very first time - which is the moment when the texture is actually needed/accessed for the first time. This would keep the feature of being able to enable shaders at run-time, while avoiding to waste memory/CPU performance on loading unnecessary textures. Hmm, ok. You will then need to introduce this kind of paging into osg. I see already hooks for something like that, but I never saw this finished. So I would prefer to not do this with a huge amount of adaptions at our osg integration just because of some effect textures being loaded. If it's easy to do and does not require just an other addition to the cull visitor ok. Anyway, one method that is always on top of flightgear profiles is the effect drawables interaction with the cull visitor. And in the far term I would prefer to move away from that decision about the effect being used at *every* time that drawable is being culled. IMO this should be done in advance with a set of extensions that is determined at context creation on viewer startup. And with this static decision within a single program run, instantiate the effects. for multiple contexts use the subset of extensions that is available in all contexts. Practically this should not introduce additional restrictions as usually all graphics boards in a single viewer are the same. And If you have different ones you are probably more interrested in a consistent look across the whole view than in a maximum feature special view because of a single different graphics board. Given that, you should at load time know about the required subset of the effect textures, which make the above thought less important. And much more important, I expect some improvment in the cull times with that kind of change. If you still want to change the effects being used on runtime, you need to walk the sceneraph models one time and switch the effects being used. Or may be reload the scenery or something like that. But It makes no sense to pessimize the code path that is really important and happening on every frame because of something that you mostly only do when you install flightgear and you try out if the shaders are worth being enabled or not for your use. That's actually something I consider having. Also for different reasons. All the shader stuff is really nice but there are really use cases out there where it does not matter if the chrome is glossy or not. For them it's really most important that you get stable 60hz in *any* case. Which is still easier to get using the fixed function pipeline. So again still having that available would be good IMO. +1 Ok. Greetings Mathias -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I try to catch up on things past an other busy week. On Thursday, March 29, 2012 00:22:46 ThorstenB wrote: Mathias, maybe you can have a look at the simgear changes. Maybe you see a way to improve this even further - i.e. do we still need all these cache maps? Or could we simply rely on some OSG cache in some places? Just looking quick over what you checked in, I think that this needs some improovements: The change just returns pointers to objects you get from the observer_ptr. In general, this is not exactly thread safe. I do not see currently if you can ensure from a higher level that this is not a problem or not. In general consider the following situation: Thread 1 has an observer_ptr to A. Thread 2 owns the last reference to A. Thread 1 gets the still valid raw pointer to A from the observer_ptr. Thread 2 releases the last reference to A and deletes it. Thread 1 assigns the raw pointer to a ref_ptr. This probably ends in a segfault. If you work with weak pointers/observer_ptr you need to use the lock method. That one gives you a atomically a dead or alive ref_ptr to A. If you have this ref_ptr in our hands, you own a thread safe reference which makes sure that nobody deletes the object. If your ref_ptr is invalid. An other one was faster on unreferencing. In effect this groups step 3 and 5 into an atomic operation which can not be intercepted by step 4 in the example above. So, if you use this kind of weak stuff, you need to ensure that all the call chain from getting the ref_ptr from any cache down to adding this object to the scenegraph does not use raw pointers. Also the initial ref_ptr in this chain must be gained by observer_ptr::lock(). Regarding the effects, I don't think we can rely on any caching in osg since we do not currently use any osg based loader mechanism to gain these objects. At least nothing that I know of. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, I had a busy week, so sorry for the delay. On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote: I have not had time to consider the proposal carefully, but I agree that the ocean tiles are problematic in the old (old) scheme if you have object directories with overlapping objects rather than jaust additional objects. I have not tested the new changes at all yet. At first, is the current state something you can currently work with? It should stop opening stg files once a base object is hit. While the (old) new behaviour is as Martin expects it is not what most that has read Docs/README.scenery would expect (I'd think). However, I would not consider Docs/README.scenery a normative source (i.e. not how it should be but rather how it was) - but Martin's expectation (as far as I know about it) is also not the behaviour I'd like or want. I agree with that. The aim to clean up technically the scenegraph lead me to this area and looking at the implementation I found plenty of stuff that was dangling from the osg switch I think - so the old source could not considerred normative either. I feared that it did much more than it should do. So, I was looking for documentation and somebody who knows about that. What I did at first sounded plausible somehow but missed your needs for your workflow. IOW I can well see the need for reading from more than one directory for your workflow. In the old old scheme entries in the path could point to just terrain or just object trees in addition to full scenery directories containing both Terrain, Objects and (more recently) Airports and Models subdirectories. Both those options are useless with the stop-at-once behaviour (you get either terrain and no objects or just objects). Could a working middle way be to merge objects from path entries containing only the Objects (and maybe Models) tree encountered before the first full scenery directory for the tile in question? That way an ocean tile in a full scenery directory would terminate the search. (How to decide that a scenery directory is full, that is, considered to contain both terrain and objects for a particular tile, may need more thinking). Yes, all boils down to this question. So currently full means 'I have found a BASE_OBJECT'. Which is something that will not happen for sea tiles. So one of the proposals was to be able to explicitly generate sea tiles by putting them into the BASE_OBJECT line. That does not mean that every sea tile must be explicitly triggered, but a sea tile *could* in this model be explicitly triggered to get a propper termination point. This can happen by a id.seatile metafile or an other keyword in the stg file for example. Similar questions most likely arise for the files in the Airports and Models directories, and for terrain only scenery directories (but there soft links to the desired Objects, Models and Airports directories may help to turn a terrain only directory into a full scenery directory). E.g. for ground net development I would like to be able to have a local Airports directory (containing just the files I'm working on) that would be searched before the one in the full (e.g. terrasync) scenery directory. I don't know exactly what happens currently for the Airports directory. But yes I see. This must work the same than the scenery object search as the stg/btg files need to match with the taxiway descriptions. But that means that finding the matching groundnetwork files must also follow the same complex stg file algorithm. Or even more, this one also needs to look *into* the stg files to scan for an OBJECT_BASE line and take the files from the matching Airports directory beside? Do you think it is possible to define 'full' scenery by the plain presence of a Terrain/id1/id2/id3.stg file in the Terrain subdirectory? This would at least reduce the need to look *into* the stg files to barely looking for the existence of an stg file to see where to stop? For the sea tiles this would mean that those tiles with object need a terminating Terrain/... file, sea tiles without dont need anything as it is today. This question is motivated by the scenegraph structure we currently generate. I can imagine improovements to scenery paging with this kind of change. What I want to try is not put individual model files into own level of detail nodes or paged nodes, but put all models in one tile into a single paged osg node. This node is then paged in later/paged out earlier than the bare Terrain node that we need even for far tiles. If I try to do the same with the current semantics, I need to execute the same search sequence by opening the stg files multiple times. Not sure yet I gain something here, but willing to ask if this is at least possible. Ideas? Comments? Thanks Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Hi, On Wednesday, March 21, 2012 13:29:52 Renk Thorsten wrote: Mathias, maybe it's just me - but I have a serious problem understanding what you write. I have greatest respect for what you do, and I've seen some amazing things like the factor 50 speed increase of the geodinfo() call, but most of the time I have no idea what you're talking about. The above is symptomatic. I agree that I am mostly very short. But this really is due to the lack of time to do all step by step. Where I start explaning at that point where I believe that it starts to get non trivial for others. So obviously I do not hit that point ... Martin mentions you trying to integrate space-view into Flightgear. I've tried to google space view, but that returns mainly image collections and some company websites. So I have no idea what it is. As a result, I ask you to comment, because I want to know what you're trying to do and how it compares with what I do. Your anwers starts with reference to how to do scattering integrals outside the atmosphere. It assumes I know all the rest (how Earth is modelled, how scattering integrals are done inside the atmosphere, ...) and would just be interested in the technical detail how to do it from space. You then continue under the assumption that I had asked a highly technical question, detailing rendering with fog and scattering separated into the last step. So what am I doing: I load a scenegraph model of the whole earth that, using apropriate osg methods, aims toward a scalable scenegraph that is still able to display high level of details once you are close to ground. This is just a scenegraph object that is rendered. There is a whole lot of stuff contained there to make that scalable, but for rendering this could just be considered seperately then. Take this and combine it with some technique that simplifies the skydome which is only used today as a proxy geometry to get rendered pixels for the sky shaders. And as such a way to high real existing dome/sphere that needs to be rescaled and repositioned. You need to take care of this geometry for the near/far clipping planes. All that could just be replaced by a simple fixed screen aligned quad that has way less geometry and provides the same effect of providing fragments for the scattering/sky shaders. Once you have realised that scattering/sky is just the same than fog for objects, it is clear that you want to do both in the same way/code. Which simply leads to what I am talking about: Put that into a compositing step where you combine the stuff that you get from rendered objects with the scattering integrals. When you do this in a compsiting step, you get a lot of possibilities to implement say shafts in the atmosphere where scattering happens differently in directly lit areas than in inderectly lit ones. Appart from that being a technology enabler for really nice visuals, you can then omit ugly fog computations from the models. You can seperate different stuff into different modules and untangle dependencies, which is good in its own. This is to a high degree really what Fred is working on, just with a different detail in its usage. And in an other sense not that sophisticated than freds approach for the material properties of the objects. That's all you need. I typically prepare a lot of things that are usually sensible and helpful for its own but with such a final goal in mind. Once all is set up in place I just need to grab into the black hat and pull out a white rabbit - in this case this could be space flight. Totally independent of your request, but only realizing stuff that is helpfull for its own and fitting together into some bigger picture. Does this help? Mathias-- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, On Saturday, March 24, 2012 09:29:41 James Turner wrote: Tangental, but, yes please! This and a few other similar options, like generating a low-detail terrain node 'automatically' for distant tiles, were some ideas I considered last year to allow further draw distances. Yes, the spt loader does this currently. but the lower level of details still lacks altitude information. And the basic texture is just the croase whole world texture even in the mid lod case. That's what I currently use for developing a seperate hla viewer that can be attached to any hla object. I can currently safely sit on top of the ogel generated on the sphere in san diego flying over LOWI. Works fine here :) So, short, I have never described the spt loader, but it is able to provide a scalable whole world paged scenery. This is similar to google earth or osg's marble or the like. The scenegraph is done with a quadtree/octree structure that in the end fits our tile structure of stg files. That should be fast to cull. We have currently three levels of detail one of which with the recently added earth texture and croaser tiles. One in between that still uses the same texture but should use a set of higher detailed ones in the future. and the third level then contains the stg files. So what needs to be done here is provide a set of earth textures for the mid level of detail together with may be associated altitude textures for both lod's. Then extend the croase ground tile implementation either in a vertex shader or in static load time geometry generation to make use of the altitude information. This could in a next step replace the high detailed btg/stg tiles for far away tiles. And this should build the ground work for seriously enable using really high detailed btg files but still being scalable. All that would then need a lot of tuning and improovements the high detail scenery so that paging happens smooth. Well, I for myself do not plan to work on this in the near future but this could just be a sketch of how this could be extended probably somehow easy. Whoever wants to work on that please stay in touch with me, as I already have a lot of hooks in place. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi Jon, On Tuesday, March 20, 2012 17:27:52 Jon Stockill wrote: Except a bunch of scenery developers pointing out it completely breaks their method of working. Merging the work into an existing tree isn't really an option - the ability to completely erase a tree and rebuild by script during testing is pretty much essential. I think, the current checked in version should address this problem. At least I think I have addressed this. Please, tell me if I have still missed something? Thanks Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Hi, On Tuesday, March 20, 2012 08:15:54 Renk Thorsten wrote: Once you understand how the scattering integrals work it's natural to compute them also from the outside of the atmosphere. Okay, now I am *really* confused. Are we trying to solve the same problem? I think so. Light scattering in the atmosphere is not part of what Earthview does at all. That is currently solved by the scattering part of the skydome shader Lauri has originally written (and which I have modified to include a haze layer and lightfields), this shader works inside the atmosphere and reasonably well outside of it (apart from a few quirks). But it should. You will get the halo around the earth by that. Thats just the same. Also if done right you just get all the altitudes in between for free correct too. Not only correct but really impressive ... Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. Well, that is probably what you call cloudsphere. These are just the scattering integrals ... Oh, the whole world model is already there. There is the spt model loader that provides this. Load w180s90-360x180.spt with fgviewer. That just happens when you call fgviewer without model (I believe, since I have a much further developed version here). You need to provide a property config that completely switches off shaders to see something useful. But well, that's all in an early state... This even works with different altitudes in between. The lod scales in between need to be improoved. But this will happen gradually I think. Apart from the fact that both somehow have to do with spaceflight, there doesn't seem to be any overlap at all?! Well, it does. :) Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Good Evening, Ok, no feedback to my comments here except Martin who tells me that the current checked in version behaves as expected. I personally can understand that people want to have a local seperated directory for their own personal additions. Let it be additions to the scenery that are just being developed and not yet ready or may be just the personal garden gnome before your house that you are living in. OTOH, reestablishing a completely unterminated accumulation behavior like we had before is problematic IMO since you will get duplicated models for really common use cases. A terminated read accumulation sequence would help those who complained about the current behavior. Terminating the read accumulation sequence can happen reliably on solid ground with an unmodified scenery. On sea this is not possible without modifications to the scenery that I cannot do myself. So, I will now push something that is IMO not a real solution, since parts of the duplicate model problem is not solved correct. But it should cover most common use cases and enables people like Jon to continue developing scenery models without messing with outside provided files. If somebody wants to change this behavior to something really reilable go ahead. But, since I will do further modification to the implementation of these code areas, please coordinate such changes with me for the next few weeks, else we will probably get needless merge conclicts. Greetings Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, On Sunday, March 11, 2012 21:07:37 Martin Spott wrote: Mathias Fröhlich wrote: The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for example) with models never contain a base tile line where we could know when to stop seraching the FG_SCENERY directory sequence. So for this kind of tiles we could probably place someting into the stg file that signals that we should stop seaching here and finish with a sea tile. May be we could place a OBJECT_BASE id.seatile into the above drilling platform stg tile example to terminate the search. It's unclear to me wether you mean adding the above line into the respective .stg-file in the Terrain/ folder or into Objects/ ? If you propose to add it into the Objects/ folder, which is how I understand your idea, then the procedure to create the Objects/ directory structure would be required to know wether there's a terrain tile or not - a dependency which I'd recommend not to introduce. I could imagine putting this into any stg file. I also have some yet untested code here that implements something like that: for p in FG_SCENERY load p/Objects/id0/id1/id2.stg load p/Terrain/id0/id1/id2.stg if found OBJECT_BASE in one of the above break done So, the whole thing is to have a propper termination point where to stop accumulating non disjoint scenery models from different sources probably also not exactly matching the elevation of the loaded base tile. I am more guessing what you mean by that dependency? The current process to export all the collected models for the svn scenery is independent from the knowledge if there is a matching Terrain stg file? And you want to preserve this property? Any solution that gets rid of the ugly duplicated models is good. Better solutions do not introduce even more implicitness into the loading process than we currently have. Any simplification would be good also. Better ideas welcome. Greetings Mathias -- 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] scenery loading cleanup
Hi,
On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
This change breaks my setup. I consider it a feature that FG used
to load objects from all scenery directories visited up until the first
one that contains terrain for the tile. It made it possible to have
scenery object directories with extra objects by just putting them early
in the path (useful not least for keeping work-in-progress object
placements separate from terrasync data). It appears you removed that.
Can you clarify what the new behaviour is?
Is the first object .stg found for a tile the only one that is loaded now?
The problem with accumulating all stg files' content is that you get duplicate
models.
So the situation that I was trying to fix is as follows:
Assume you have the base package installed and assume you have terragears
scenery installed. Terragear has some improoved models from buildings included
where the older models already are contained in the from the base package.
What you would observe are models that are technically just needlessly drawn
twice and if the models are not identical or may be placed at different
altitudes because of the base tile providing a sightly different ground
elevation you will at best see some kind of z fighting between the two models
and at worst two shifted models in each other with occasionaly z fighting.
You can see this with a lot of buildings in San Francisco.
Now you might argue that I should omit the FG_ROOT/Scenery from FG_SCENERY
since it already contains all that the base package contains. Then I take an
other example with reversed coverage of the scenery:
I have terragear worldwide and the nice innsbruck scenery. And both include
some of the hangars at the airport. You will in this case see that described
z-fighting for the tyrolean writing on the wall of one of the most east airport
buildings.
For the uglyness in the scene and for the needles model duplication for draw I
do not think that we want that.
Ok, the lookup for stg files is as of today:
for path in FG_SCENERY
probe tiles files in path/{Objects,Terrain}/id0/id1/id2.stg
if one is there, stop probing.
end
Why do I stop at the first found file/file pair:
I got told that some scenery tiles do contain sea tiles there we only have an
Objects directory with offshore windmill models for example. If I do not want
them in the same way duplicated like described above you need to stop at some
point.
With the windmill example I tend to say, ok, let's just duplicate them. We do
not have so much models on the sea. So then we could start accumulating all up
to the point where we find either a base tile or run out of serach path.
But I think a complex oil drilling platform on the northsea breaks this
argument a little.
Ok, I get an idea:
The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for
example) with models never contain a base tile line where we could know when
to stop seraching the FG_SCENERY directory sequence.
So for this kind of tiles we could probably place someting into the stg file
that signals that we should stop seaching here and finish with a sea tile.
May be we could place a
OBJECT_BASE id.seatile
into the above drilling platform stg tile example to terminate the search.
An other alternative might be to also probe for a Devel directory structure
for a given scenery path extending the search to
for path in FG_SCENERY
path/{Devel,Objects,Terrain}/id0/id1/id2.stg
...
An third alternative could be that we explicitly flag stg files that should not
terminate the FG_SCENERY search. So you could just put that flag into your
development stg files.
The first alternative would require modifications to those scenery files, but
it
works today as good/bad as it worked yesterday and it works fine if the
terminating OBJECT_BASE is inserted.
The second one would be a code only change.
The third one would be a change only for those people that develop scenery.
Does this match your concerns? Would it solve? Thoughts?
And sorry for breaking at first ...
Mathias
--
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] scenery loading cleanup
Hi, On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote: Without this little tweaks the tile can't be loaded. In conclusion, with your change we need to associate Object AND Terrain folder. It's just a feedback of my experience, don't take it as a critics ;) That's fine. Have written something longer in response to Anders. I think this maches your problem as well. So I guess we are on the way ... Greetings Mathias -- 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] scenery loading cleanup
Hi Jon, On Friday, March 09, 2012 10:43:55 Jon Stockill wrote: Can you explain exactly how the loading now works, and if it's still possible to use extra local objects trees in the way I describe? Thanks for the response. Well, I guess this hits the same problem that I try to solve now with the previous mail. Greetings Mathias -- 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] [Flightgear-commitlogs] SimGear branch, next,
Hi, On Wednesday, March 07, 2012 11:54:39 Gijs de Rooy wrote: Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0 ZI1_Wk/s1024/fgfs-screen-055.png No screenshot here, but I also agree that the current lights are way too big. May be they were too small before, but with this commit I think they are now just too big. Greetings Mathias -- 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] [Rembrandt] the plan
Hi, On Wednesday, March 07, 2012 14:58:26 Lauri Peltonen wrote: 3. define an XML format for describing the two possible rendering pipelines (the current and new). The format will introduce optional elements (such as shadows, ambient occlusion, glow). I want to point out my work on my newcameras branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things. Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them. I was not aware of your work. But given what you write here, this looks pretty promising. Fred mentioned your name in an offline mail. IMO the complexity of this kind of rendering method in terms of requirements to the driver makes me frighten a bit when I think that we have currently no fallback to the old style renderer. Even back to the fixed function pure oldest style stuff which is still the fastest thing we have. Keep in mind that plenty of people will likely trade speed/deterministic frame rates for any eye candy. And beyond that all people that cannot see anything with rembrandt but a black window will love to have something that at least shows the old style stuff (may be just fixed function?). So, wherever we end, I would highly apprechiate that we do not lock out low end graphics boards by not having any fallback. May you both should combine forces? From what I read, I think both are heading in the same global direction and both implementations have some benefits over the other? Hmm, I should really look into the code ... Greetings Mathias -- 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] scenery loading cleanup
Hi, Also for the breginning of the development cycle, I started working on improoving fgviewer and cleanup scenery/model loading. I have now checked in a change that should fix some long standing problems with modelss that appear to have z-fighting. This change should not harm and works so far for all I have tested. But it slightly changes the way stg files paths are handled. So if this really introduces a problem, please tell me. Greetings Mathias -- 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
Hi Fred, On Friday, March 02, 2012 19:03:13 Frederic Bouvier wrote: thoughts ? Since we are now at the beginning of a release cycle, I would think now is the right time. For the question to preserve both renderers, compatibility of models I think that we need to preserve both if we cannot guarantee that your new approach runs on a wide varity of drivers. Given the complexity of this kid of change I doubt that we can iterate this out completely within this current release cycle. Also I believe you told that you are using float textures. And again this is the other patent problem lingering in OpenGL. This extension will not be supported for a long time. But again I think that any rescaled fixed point representation that works based on an integer datatype should do its job as well. The changes to make this work should be limited. And no, I have not really reviewed the changes. Any yes this is the problem, there is a lot of work left to do to integrate this kind of change, but I think too little people will try if we do not push this into mainline. Consequently not iterating out anything. The only other option could be doing something incremental. May be like this? 1. Move the renderer into a pre render camera using the current shaders. 2. Set up the depth texture and normals and make them available for a composition step. 3. Remove fog from the models, do this in the composition step. 4. Build up the shadow and light map texture. 5. Incorporate this into the composition step Or may be with modifications - just scratching in my head how I could imagine tackling this with smaller steps. Really just thinking about an idea that might not be a good one. But tell me if you think this is reasonable??? Greetings Mathias -- 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
Martin, It's sad to hear that this central scenery database should have failed. I never cared myself much about how our scenery is built. This is just because all my interrests and work are in completely different corners of this project. So concentrating on other corners than scenery can just work if the scenery is *just available*. That saied, I always apprecheated this work and I strongly guess I am not alone with regard to this. Given the discussion that comes up due to this announcement, I hope that we can find a solution for a worldwide scenery that stays available and gets improoved. I think it's a huge step back if we just have plenty of small islands of scenery spread across independent sources. Anyway, I hope you enjoy your life, family and children and I am looking forward to meet you again! Mathias -- 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] DDS texures (Was: Improving random trees
Hi Vivian, Sorry for the long delay, also in face of the pending release. Thanks for the suggestions. On Sunday, January 15, 2012 19:08:17 Vivian Meazza wrote: On the other hand, if you are trying to tell aircraft modelers not to use these forms (.dds .ivs) of compression, then: Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed textures which may be unsupported some systems. To remove this alert, decompress this texture. My concern with the latter form is that it only applies to very limited number of aircraft models and developers, while it is at best meaningless to the user, and may lead to confusion. Yes, the usual user might ask 'what should I do?' What about: Image ... uses compressed textures which cannot be supported on some systems. Please decompress this texture for improved portability. So, instead of waiting for a reply now I just commit this now as I do want that change in the release also. So, that I just committed this so far does *not* mean that I don't care for the answer! Also I will commit a lowered warning level for the *release branch* only. Thanks Mathias -- 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] DDS texures (Was: Improving random trees
Hi, On Saturday, January 14, 2012 20:17:22 Gijs de Rooy wrote: is there an easy way to disable this message? since i'm using dds texture, it's flooding the console... +1 Every single texture of --material=materials-dds.xml seems gives an error... How about moving these messages to --log-level=warn or the like? Well, I hope that we can get rid of the compression. Can somebody with the apropriate tools convert the compressed textures to non compressed ones? That could still be dds, but dds without these compressions that produce the warning. So no problem with cubemaps in dds as long as the compression is not there. Then *everybody* is again able to use this stuff. So, I am not entirly against moving this to an other log level, but at first I think it is good to tell that this will only work for a few people. And I think it's good to see this *immediately*. Mathias -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Hi, On Sunday, January 15, 2012 10:56:14 Vivian Meazza wrote: Just what is the user meant understand or to do about it? What do you want to read? Mathias -- 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] Announcing Project Rembrandt
Hi Fred, On Sunday, January 01, 2012 16:14:17 Frederic Bouvier wrote: Exactly. I want to give access to every stage of the rendering to the effect system. The geometry pass outputs to render target, but the fog, the lights, the bloom need to have access to the textures of the buffer, and there is a separate one for each camera associated to windows or sub windows. I have found a solution where I can make an association between the cull visitor and the G-buffer and then modify the pass of the effect on the fly. I hope some multi-threading model will not screw up this scheme. Hmm, 'on the fly' sounds not so good. Without definitely knowing what this means ... There should better be sepereate datastructures for the effects. I have not looked into the effect code, but having an extra property in the effect that tells, 'per-toplevel-camera=true' or something more descriptive. Then in the effect code assign seperate texture state in this case. ... my two cents. And may be pointless for your actual implementation. Currently, the fog is computed using the depth buffer as a post-process pass. Any smarter computation (like atmospheric scattering) is just a matter of writing a single shader that would replace the default fog computation. Exactly. And you are looking into the sky if you find a far clipping plane depth value. Actually, it's a null normal. I could also use the stencil buffer but I already messed with combined depth/stencil shared between fbos without much success. Null normal is probably fine too. And no the scencil is really per fbo pass. And much worse, I believe you need a non standard extension to access the stencil from an fbo pass that is not active anymore. The only thing you could do to get a stencil out of a render pass belonging to an fbo is to draw a screen aligned quad in as the last geometry in an fbo render target that evaluates the stencil and writes the result into a normal render fbo texture target. Then you will have this result available as a seperate texture. But I do not think that this is needed for this purpose. Greetings Mathias -- 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] Announcing Project Rembrandt
Hi Fred, On Sunday, January 15, 2012 13:08:03 Frederic Bouvier wrote: Well, for the moment my solution works pretty well. I posted some videos on the forum to show progress on lights (http://www.flightgear.org/forums/viewtopic.php?f=47t=14883) Nice! I was able to attach the same depth texture to 2 fbos and have a depth buffer already initialized in the second one. I don't know if it would work for the stencil buffer if I choose the PACKED_DEPTH_STENCIL_BUFFER attachment. The comment was about having the stencil available in an other pass using an other depth buffer. But simply reusing the same one and not clearing the the scencil is a nice idea. For interrest, even if this sounds plausible, is this a side effect of your driver or is this guaranteed? Do you know? Greetings Mathias -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Vivian, On Sunday, January 15, 2012 12:08:14 Vivian Meazza wrote: I would suggest Image D:/Git_New/my_fgdata/Textures/Terrain/sand6.dds uses compressed DDS textures which may be unsupported by your video driver and not display properly. Ok, Can you help me further: It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably have the same effect. So I think simply ommitting DDS is ok? Also, much more important, the comment is not about 'your video driver'. It is in your (Vivian) case even wrong. Your driver will display this fine. So, in the end I do not care if it is 'your particular video driver' that does not like this. You will just see this in the best case as the models look wrong, and in the worst case fgfs just crashes the driver if these textures are used. What I really care about is that these files are expected not to work on a huge amount of graphics boards out there. The point is to tell people doing textures that they should omit compression so that this message disapears. Ideas how to write this? Thanks!!! An other thing: On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this also the case for the default win32 case? Is there a osgdb_gz.dll or something along the lines in the directory containing the plugins? If yes, we can already tackle the size problem of the uncompressed dds files on disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. And I assume that this works fine for all unix like operating systems including mac?! James? Mathias -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Hi Emilian, On Sunday, January 15, 2012 14:33:40 Emilian Huminiuc wrote: There are a couple of isue with that though. Biggest one is it will increase disk/RAM usage by at least 4 times, if not 8 depending on texture/compression method used. That basicaly negates all the advantages of the dds format, except for the embeded mipmaps. Is that acceptable? I remember some complaints about base package size increase, and also repository size increase. btw: Tools for dealing with any of the dds compression formats, and access to them is freely available under the MIT licence. http://code.google.com/p/nvidia-texture-tools/ [...] I believe the numbers are a bit reversed here, and the vast majority of users has no issues with displaying these textures. But I agree there's an issue with (un)available support for these extensions in the OSS drivers (be they nvidia/intel/ati). Counting the developers machines this is probably true. And exactly this is the reason for the message. If your machine would refuse to display this you, developing that, would probably just say 'nice try, but it does not work' before you check in something. In the case it displays fine, you probably say 'it works here, so I assume it works also for others, lets do'. And the message tells you, 'despite of just seeing this working on this current machine, it does not work for others'. Seriously, I think plenty people not being on this list today and probably never will be in touch with anybody here, will run into this issue. People here are those few guys from the power users that want to develop this stuff. I am not going to discuss the patent stuff. Please search the mesa-dev archives for the discussion and see there why they think that the nvidia tools and other stuff out there cannot be used. Really - it is not that the code for that is too dificult or unavailable. I am not a lawyer and I cannot change this world - even if I would like to in this regard. I agree that techically for drivers/gpus supporting these compression formats it would be best to use these precompressed files. Doing that differently will provide some overhead that could be kept at a minimum I think: For the disk usage, I think gzip compressing these will work sufficiently fine. Ram usage of the images should not hurt too much. Sure the images are bigger in memory. But fgfs is not just about images - far from that. On the GPU, you can still use compression for the textures as the internal format. This is what flightgear tries to do if the extension is supported (checked by osg). The major point is that there are several ways that use slightly more resources to get around this problem. But once the patented compression is on disk, there is *no* way back for people not having this feature. If you have better ideas that do not rule out intel and the oss drivers, you are welcome! Greetings Mathias -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS texures (Was: Improving random trees
Hi, On Sunday, January 01, 2012 11:41:22 Mathias Fröhlich wrote: I think then, computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation. Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU. Ok, checked in is a log message that checks for image formats that depend on OpenGL extensions not required to be present. That should at least help people running drivers providing those extensions to see when they use texture files that do not work fo all. Greetings Mathias -- 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] Improving random trees buildings
Happy new year! Vivian, On Friday, December 30, 2011 10:48:40 Vivian Meazza wrote: The hangs are caused by mipmap generation on the fly by OSG? The hangs are caused by mipmap generation by the driver which happens on forst use of a texture. The old texture files are static and I would expect them to work into the future, but the new dds textures will leave them further behind as work progresses. The only problem in htat is that some users will lose out on some eyecandy - it will not affect the basic operation of the sim. Which is in this case sad I think. If it's easy to fit both needs I think we should. You do not experience any hangs? None that I have seen so far Ok. I have also seen one of the machines at the flightgear booth at the fsweekend which did not show any problems. But Thorstens huge machine really hangs in an unaccaptable way. I would really never tolerate this as a user ... What is the motivation for you to use dds files? It's a better way of storing cubemaps for reflections or other layered images. The built in mipmap OSG algorithm is a bit slow - using dds works around this (for some systems) Ok, granted. Use it for that. What do you gain by not using the usual image files? Dds textures remain in video memory, so we get improved performance when switching textures. We expect that at least some people will see smoother performance when loading scenery textures. I haven't been able to measure any gain, but there are some have reported that they see a subjective improvement. No, this really should not be a difference. Probably this is what I refer to as these hangs. But the reason is not that dds is in video memory and other textures are not. These *are really all* in video memory. There is no difference between dds and png. The driver decides where to put which buffer objects so that it is accessible to the gpu. And depending on the memory pressure on GPU's memory of the whole system driver the driver might page something out or not. So, once you really reach these huge GPU boards memory limits you might see that using compression you start paging less. But our working set is way below. The real reason appears to me like being the initial mipmap computation when allocating a texture in the driver. And an other post of Erik in this thread tells me that we should try to provide a mipmapping method that already runs in the database loader thread so that on initial allocation in the driver the mipmaps are already present. Also according Eriks comment, compression on the fly on the upload path in the driver seems to work without delay. So, for drivers that announce the compresin extension we can still tell the driver to store the textures compressed on the gpu to minimize gpu memory paging. So, still, since it is technically incorrect to provide these s3 patent precompressed textures to a driver that does not announce the apropriate extension and since we are not allowed to code something that deompresses this, I think we should avoid using this compression for all the provided models/textures. I think of a warning that is issued from the image loader in flightgear that detects when these precompressed textures are seen. So even people using drivers that just offer this extension have a chance to see that the provided textures will not work for others. The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu. Seems to work here - I have tried --prop:sim/rendering/texture-compression=dxt5 I hope that is the right syntax - no warning from fg anyway. I don't see any problems with running the F16 using that. I might be entirely wrong of course. Yes, that is thought like that. But since you do not see the hangs in any configuration you can just sit down and watch us testing :) Thanks anyway! Mathias -- 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] DDS texures (Was: Improving random trees buildings)
Hi, On Friday, December 30, 2011 11:11:39 Frederic Bouvier wrote: * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. I implemented a mipmap control and generation tool in effects when I last updated the urban shader. For the moment, it relies on hardware when the average operator is used for all texture channels but it could easily be modified to compute all mipmap on the CPU. look the mipmap-control effect option and mipmap.[ch]xx in SG material lib Thanks, I will look into that! Greetings Mathias -- 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] DDS texures (Was: Improving random trees
Hi Erik, On Friday, December 30, 2011 11:39:37 Erik Hofman wrote: On Fri, 2011-12-30 at 10:42 +0100, Mathias Fröhlich wrote: * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. Ok I'm quite convinced it's a mipmap problem. I tested uncompressed dds textures with pre generated mipmaps with different compression techniques but none of them improve the situation much. Switching to uncompressed DDS textures with mimaps however speeds things up roughly three times (just onder 3 sec. instead of around 10 sec to switch). Great to know! Thanks for testing. I think then, computing mipmaps for any texture file on the CPU in the loader thread should globally improove the situation. Also avoiding the compression already in the files should help every use case. Except that the on disk memory consumption is higher. Well and except that the database loader has more work to do on the CPU. Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Hi, On Friday, December 30, 2011 11:45:21 Frederic Bouvier wrote: The problem I have to solve currently is how to feed the G-Buffer to the Effect system because the textures used to store it are camera-dependent (in a multi screen context) but the pass (which is a stateset) is built once for all. I do not exactly understand. I see that the effects collide in some sense with this kind of an approach. Partly effects do try to achieve some similar results in the good old fixed function derived world, than you get once your code is used, but as far as I see, the intermediate screen sized textures sould not be processed anymore with the effects? Or at least how would you know which fragment to process with witch effect? Or I think that all the effects probaly need to be changed to write their color/reflection/whatever information into the appropriate render target? So, far how I understand the question. I am almost sure I miss your point. Ahh, ok do you want to write the compositing step as a usual effect file? Then, I understand the problem. Well, If this is the problem, I do also not see an easy solution. I would think that this final compositing step is so different from the rest off the effect stuff, that inseriting these textures using non generic custom code for this special purpose is fine. So, for this kind of problem currently no solution - may be one when I think about this for some time. Let me know If I am looking at the right problem ... Currently, the fog is computed using the depth buffer as a post-process pass. Any smarter computation (like atmospheric scattering) is just a matter of writing a single shader that would replace the default fog computation. Exactly. And you are looking into the sky if you find a far clipping plane depth value. So, may be just one question for what you have done already again without looking into any code: You do not require float textures? As far as I can see, there is a patent issue on this extension and usually this is not strictly required. Using a fixed point representation that makes use of the usual depth buffer - one that scales differently than the usualy perspective depth - could be used instead and I think we should use this in the end. In the end this really gives even better accuracy than a float representation since floats waste some bits for the expontent, where a fixed point representation could just use all the bits for accuracy. I used Policarpo's tutorial on deferred shading so I don't store absolute world position in a float texture. As described in the tutorial, I used the view direction and the depth value to compute the eye space position of the fragment. That's fine! That's what I had in mind also. The fragment position gives the vew direction by the projection matrix and together with the depth value fed through the inverse projection matrix yields the right values. Nevertheless, I use float texture to store the normals. I tried setting up a normal buffer with just luminance and alpha with half-float while the color buffers were rgb8 but it was very slow. Instead I used rgba16f for all textures (except the depth buffer). As I use additive blending to collect the lights, I thought it would be possible to have some kind of HDR without the risk of saturating the 8bit color components. I can try to use 2 color channels to store the x and y components of the normal and reconstruct the z part with sqrt(1 - (x^2+y^2)) but that won't solve the saturation issue. Some use LUV color space to store higher intensity in RGB8 but afaik, it don't support additive blending. Ok, I have not thought at the normals yet. Lets first make this work and then care for a fallback or nice trick that does not need float textures and looks fine performance wise. Greetings Mathias -- 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] DDS texures (Was: Improving random trees buildings)
Hi, On Friday, December 30, 2011 00:09:20 Csaba Halász wrote: I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). No, Sadly. It is all about an OpenGL extension that could be exposed or not. If it is exposed you are allowed to provide texture images in the precompressed format. If this is not exposed you are not allowed and the implementation may behave undefined. This is perfectly legal for an OpenGL implementation - the usual extension behaviour. By providing these precompressed data blobs without checking for this extension is an applications fault. Ok, what to do if we detect that we cannot feed the implementation with these blobs? We could try to decompress the blobs? --- No, patent infringement!!! Just feed the blobs? --- No, the driver may behave undefined - at least it does not work as expected. So, what can we do? I can see several approaches: * Just do not use the patented compression stuff. The precomputed mipmaps could probably do the job of avoiding the hangs (hopefully? to be checked?). May be we could lower disk space usage by providing a dds.gz or similar wrapper? * If it's just the mipmaps. May be we can precompute the mipmaps using the cpu in the database loader thread. This would help all textures not only the ones that could be converted. May be this is the most generic solution. * Implement some kind of image lookup order that knows if the compressed files could be handled or not. On loading an image in case of available compression first try to find a dds file with the same name of the original one. That involves some 'magic' which often leads to problems but that could at least work. Other ideas? Also may be creative ones? Next step is to make sure that compression is not required to avoid the hangs. My favorite bet would be that then the new configure option regarding texture compression needs to be set to none. Greetings Mathias -- 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] Improving random trees buildings
Vivian, There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Mathias -- 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] Improving random trees buildings
Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. Yes, the dds textures could provide pregenerated mipmaps. I guess that our dds files really do so. Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Thanks Mathias -- 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] Improving random trees buildings
Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. You do not experience any hangs? What is the motivation for you to use dds files? What do you gain by not using the usual image files? The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu. Greetings Mathias -- 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 ___
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
Hi, On Wednesday, December 28, 2011 15:29:50 James Turner wrote: So, this is where my knowledge runs out - can someone suggest the next debugging step, to identify the problem in the water effect? Can you post the output from glxinfo -l. Where the -l prints 'some interresting limits' ... Or since you are on macos. May be there is an appropriate 'aglinfo -l' Mathias -- 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] Improving random trees buildings
Hi, On Tuesday, December 27, 2011 10:49:07 Erik Hofman wrote: Actually for the F-16 I did not switch because of compression but because livery switching is almost instant while the previous textures is took about 10 seconds to switch from internal view to external for the first time. That's too long. Hmm, if precompressed textures help here, may be nvidias driver has problems compressing textures on the fly? Can you try to short circuit SGSceneFeatures::setTextureCompression() to see if this helps for the long hangs? If so we could make the use of thexture compression customizable? I would be very pleased to use another texture format that has the same effect though. Well, I am not sure what is better then. Use precompressed textures that cannot be read from one driver or uncompressed ones having these unacceptable hangs. Both is not acceptable IMO. Mathias -- 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] Debugging an Ati shaders issue (with 3d textures, again)
Hi, On Wednesday, December 28, 2011 16:22:20 James Turner wrote: On 28 Dec 2011, at 16:15, Csaba Halász wrote: Since we are talking about shaders, aren't the limits GL_VERTEX_SHADER_ARB: GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16 GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 16 GL_FRAGMENT_SHADER_ARB: GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16 The texture IMAGE units are the right ones. Well, I just commented out (in the effects file) any reference to the noise texture, or texture unit 9, and the errors go away. I note the Texture3D code in OSG (which underpins the noise texture in SimGear) must use a 'traditional' texture unit, not a shader one. So when a shader does actually need to use the noise texture, presumably it should be assigned to units 0...7 in my case. May be osg confuses the traditional texture units and the shaders texture image units? Mathias -- 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] Improving random trees buildings
Hi, On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote: Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Hmm, regarding dds. I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that. And in fact this will not happen to the open source drivers before something about 2020 because of patent issues. Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... Thanks Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
Hi, On Wednesday, December 21, 2011 21:25:11 Csaba Halász wrote: Seems to be gone now :) Ok. So, still I could not easily reproduce... Any comments for my other question, about background model loading? Well, models *are* loaded in the background. More than it was in the good old times where just the scenery tiles were loaded in the background, but not the aircraft/multiplayer/ai models. The only thing that I can observe with model loading is tht the nvidia binary driver takes a long time to generate mipmaps. This still happens in the main thread. And this is something we leave to the driver which is IMO the best way to handle this since the driver should know how to do that best. I thought for a long time that the hardware could not do better, also since the binary ATI driver takes even longer to upload and build the textures. But since some time I just use the open source ati driver here and I could see how fast texture upload and rendering mipmaps could happen. So, I am not sure if I would recomment the open source driver variants for ati today. In fact they still have various merrits and the performance is not as good as the closed source drivers performance. But at least texture upload does *not* take long time here - with the same hardware where it takes up to seconds with fglrx... May be we can do something here also, but not for the current release cycle and probably not for fgfs core. So, merry christmas! Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
Hi, On Friday, December 23, 2011 17:05:03 James Turner wrote: == glValidateProgram FAILED id=12 contextID=0 infolog: Validation Failed: Sampler error: Samplers of different types use the same texture image unit. - or - A sampler's texture unit is out of range (greater than max allowed or negative). OpenGL extension 'GL_EXT_texture3D' is not supported. === Just a quick answer: Make sure the shaders effect files have ths extenstion correctly tested. Then, fgfs should disable these shaders and the errors are gone. In the end, the driver tells you that it does not support this feature by not announcing this in the extension string/having an apropriate gl version. We probably fail to detect that properly, and tell the driver to do that dispite of the extension string. And as a result the driver just bails out - it could not do different ... And no, this is not ATI specific, it is just that by accident your ATI driver misses something that you tell it to just do - which just could not work with any driver on any hardware. Thie required extensions are in the effect files. Whatever changes are done with the shaders, the effect files *must* contain the minimum condition under which gl version/extensions this shader is valid. This is complex, but the only way to make that run portable. merry christmas Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Fred, On Sunday, December 18, 2011 10:18:39 Frederic Bouvier wrote: Your patronage will be welcome. Ok. My problem is that I have too many open projects currently. So, promising to help here is something I cannot do today. But Sure, if you have questions feel free to ask. But I currently cannot invest much concrete work into this. I will in any case come back to you and this changes for fgviewer. This was the code where I wanted to introduce a different fog/sky algorithm that will decouple the atmospehric computations from the actual models. This is also something that requires rendering the actual scene into a set of fbos and was thought as a prework for what you are doing now. But I am completely happy with an other approach. I just see that we will need this kind of stuff. So, may be just one question for what you have done already again without looking into any code: You do not require float textures? As far as I can see, there is a patent issue on this extension and usually this is not strictly required. Using a fixed point representation that makes use of the usual depth buffer - one that scales differently than the usualy perspective depth - could be used instead and I think we should use this in the end. In the end this really gives even better accuracy than a float representation since floats waste some bits for the expontent, where a fixed point representation could just use all the bits for accuracy. Appart from that: merry christmas! Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)
Hi, On Saturday, December 24, 2011 11:12:10 James Turner wrote: According to this, there should be no extension required: http://lists.apple.com/archives/mac-opengl/2007/Oct/msg00108.html And 'glxinfo' reports: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Radeon HD 5770 OpenGL Engine OpenGL version string: 2.1 ATI-7.12.9 OpenGL shading language version string: 1.20 (and no 3D texturing extension token) I don't know that off hands. I would also think that the relevant docs for that is the OpenGL standard documents or the extension specification documents. both from kronos. Do we have a minimum OpenGL version requirement? 1.3 vs 1.4 vs 2.0? No, we don't. And the current code should be able to render well on pretty old versions. Even if some shaders dont' work, the old fixed function stuff should still give fine pictures. At least if the extension requirements are correct in the effect files. So, not sure if there is something we can do to make the 3d textures work on apple. Could you also double check if the osg extension check works correctly on your install? May be by just stepping into that with the debuger? That could also explain the error message you postet. That one looks to me like the texture is not found by the linker. May be because of some part of the code not setting the texture state for this texture?! Greetings Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
Hi, On Wednesday, December 21, 2011 00:42:04 Csaba Halász wrote: Really nobody else seeing this? Any ideas what I could look at to investigate further? Yes, I saw this a few weeks ago on a long flight. But I did not see a chance to reproduce what I saw. So I did not look closer... Mathias -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
Hi Stuart, On Saturday, December 17, 2011 20:14:22 you wrote: I've committed the code changes to my repository clones for the impostors, some configuration for LoD nodes, and having a geometry per cloud, with a bubble sort for ordering. It would be fantastic if people could take the time to cherry-pick these commits and see if it makes any performance difference for them. I anticipate the biggest difference being to 3D clouds generated by Global Weather, as those clouds tend to have more sprites than the Local Weather equivalents. Good to see! And in fact without testing too much I think we are on the right track. Just starting and comparing the frame rates with and without the changes gives a 3x performance boost on my setup! Well, I have started the default fgfs at LOWI with the world scenery tiles and switched on and off the 3d clouds. This is no reproducible benchmark but at least a very good sign. So, since you do not see that huge differences, it appears that your 3D driver draws way faster than mine :) For reference, what os/gpu/driver do you use? The rule is really to call as few gl functions as possible. That is do a scene that feeds all in huge batches doing just the same. And keep in mind that there is a cutoff point - mostly higher than thought at the first moment - where it gets more work on the GPU where it starts to make sense to split these batches in halfes... Just having a very quick look over the code: You still have a normal array that has 4 entries and that is set to BIND_OVERALL which makes the shader get in the end only the first member for every vertex it processes. This makes me believe that the normal is no longer used? If so, just omit the normal array completely and set the binding to OFF (I believe it is called OFF). I think this should work. Greetings Mathias -- 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] Announcing Project Rembrandt
Hi Fred, On Sunday, December 18, 2011 09:37:04 Frederic Bouvier wrote: Shaders in C++ code (CameraGroup.*xx, renderer.cxx, and in the effect code in SG - maybe I will revert that). But the ultimate goal is to make them configurable. All effects would have to be rewritten because the renderer have very specialized stages. I began writing something about the project here : http://wiki.flightgear.org/Project_Rembrandt Sources are in my gitorious clones, under the 'project/rembrandt' branches (the few data I changed still need to be pushed) Great! This is on my todo list for a long time now! We defintely need this multi pass rendering approach! Many thanks for looking into this!!! Mathias -- 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] Trying to get more performance out of the 3Dclouds!
Hi, On Sunday, December 18, 2011 12:06:22 Stuart Buchanan wrote: One question for the release managers: Do performance improvements such as these count as bug fixes or features? Should we try to get this into the 2.6.0 release, or wait until 2.8.0? Given that you have already prepared this for some time now, I would tend to accept this '1 day too late' change. Also, looking at the changes these look pretty straight forward. So, I vould vote for an exception in this case. Mathias -- 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] OSG font rendering broken
Hi, On Saturday, December 17, 2011 18:43:17 ThorstenB wrote: No idea though why this affects fonts... Hmm, no that should not affect font loading. But yes I can see the splash screen having the wrong font too. Looking into this... Mathias -- 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] OSG font rendering broken
Hi, Fixed. Mathias -- 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] Trying to get more performance out of the 3Dclouds!
Stuart, On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote: 2011/12/14 Mathias Fröhlich wrote: But, the question is how many cloud drawables do we have? The render Bin sorting bottleneck - if we run into this - is O(log(n)*n) with the n= number depth sorted drawables. Which means we need to have a huge amount of cloud drawables that this effect dominates. As you've seen from the code, at present, we have a cloud drawable per sprite, where there are multiple sprites per cloud, and 1000 clouds in a typical Cu layer. Than I assume 10 to 500 sprites in one cloud? Which makes about 1 draws for the clouds. That could explain the observations. Ok - thanks. Ok, looking into the Cloud drawable implementation, I believe that your almost first response is probably the easiest. Just without point sprites, just improoving what is currently done: Try to put that multiple draws into a single draw using array objects. Make sure that you still get a 'fast drawable'. YOu can verify this by asking the geometry if osg::Geometry::areFastPathsUsed() returns true. That is mostly: do not use any index arrays. The only indices which may be worthwhile are the indexed primitives sets. Sorting inside the drawable is then done by either redoing the arrays or probably better by using an indexed primitive set and reordering the indices. I will try this tonight. Thanks again for looking into this and helping to point me in the right direction. (BTW - I think I've managed to get Impostors working though I've still to see any performance gain) Ok, if this helps this is fine. So the granularity is one cloud per imposter? For this approach, you need to know that setting up a new fbo for draw is not exactly cheap. It's not catastropic, but again don't do too often. Also each cloud probably uses one texture of some size which will occupy memory. Having 1000 of them is probably significant. Also drawing a cloud is than not only the draw, but also the texture change state change that needs to happen on every draw. This could still be a net win. But that's what I think is good to know to balance the orders of magnitude. May be it helps to have less individual clouds where each of them is drawn with a single draw? An idea that I had yesterday. Just a dumb question: Is it possible that we have some problem so that we have more clouds in the visible scene than we really expect there? That is is there a bug that makes some of them being drawn techically but not appear on the screen where they should be? Which could make draw so expensive by drawing more than we can see? So, just because experience shows that problems have often very simple reasons compared to the first ideas what could happen ... I hope that I really guide into the right direction. Greetings Mathias -- 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
