Re: [Flightgear-devel] OpenRTI / HLA

2013-03-17 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Low visibility issues

2013-02-21 Thread Mathias Fröhlich
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)

Re: [Flightgear-devel] fgviewer preview

2013-01-31 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Flightgear Multiplayer jitter using Matlab/Simulink

2013-01-31 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Color-shifts for textures

2013-01-28 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Color-shifts for textures

2013-01-27 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Color-shifts for textures

2013-01-23 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Heads up: release branches are ready,

2013-01-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Color-shifts for textures

2013-01-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Slave flightgear as external view to monitor traffic

2013-01-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] 2.10.0 Changelog - help required

2013-01-20 Thread Mathias Fröhlich
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

[Flightgear-devel] Bucket change

2013-01-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Color-shifts for textures

2013-01-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] The state of Wayland and Flightgear

2013-01-17 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] OpenRTI / HLA

2012-12-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] (JSBsim) body accelerations

2012-12-22 Thread Mathias Fröhlich
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 =

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Scenery manager

2012-12-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Canvas reuse/restructuring

2012-10-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Shader optimization

2012-10-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-06 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] custom_scenery/Models objects aren't loaded anymore

2012-09-16 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format

2012-09-08 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] FlightGear at TU Delft

2012-09-08 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. 26664aaff0e2f97db916909218d849b51636ccc0

2012-08-29 Thread Mathias Fröhlich
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 ...

Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format

2012-08-27 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Compute ground elevation dynamically for STG format

2012-08-26 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format

2012-08-26 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Compute ground elevation dynamically for STG format

2012-08-24 Thread Mathias Fröhlich
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?

Re: [Flightgear-devel] Rendering passes question

2012-07-22 Thread Mathias Fröhlich
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.

[Flightgear-devel] commit 75087095b132ec7a42e14000c7c8b3b09147d720

2012-07-22 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Rendering passes question

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Rendering passes question

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS usage in effects files

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS usage in effects files

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS usage in effects files

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS usage in effects files

2012-07-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Slow frame rates

2012-06-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Slow frame rates

2012-06-19 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Random Buildings - memory consumption

2012-05-26 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Random Buildings - memory consumption

2012-05-24 Thread Mathias Fröhlich
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,

Re: [Flightgear-devel] Random Buildings

2012-04-26 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] FG vesion 2.6 breaks distortion code

2012-04-19 Thread Mathias Fröhlich
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 ...

Re: [Flightgear-devel] Random Buildings

2012-04-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Random Buildings

2012-04-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-14 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-14 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-14 Thread Mathias Fröhlich
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.

Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000

2012-04-14 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] OSG caching and other OSG issues

2012-04-01 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-20 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-11 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-09 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-09 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] scenery loading cleanup

2012-03-09 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,

2012-03-07 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] [Rembrandt] the plan

2012-03-07 Thread Mathias Fröhlich
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

[Flightgear-devel] scenery loading cleanup

2012-03-07 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Project Rembrandt - next steps

2012-03-03 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Looking at a nice project from outside

2012-02-25 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Announcing Project Rembrandt

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Announcing Project Rembrandt

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-15 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-11 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2012-01-01 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees buildings)

2012-01-01 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] DDS texures (Was: Improving random trees

2012-01-01 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Announcing Project Rembrandt

2012-01-01 Thread Mathias Fröhlich
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

[Flightgear-devel] DDS texures (Was: Improving random trees buildings)

2011-12-30 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2011-12-29 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2011-12-29 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2011-12-29 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)

2011-12-28 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2011-12-28 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)

2011-12-28 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Improving random trees buildings

2011-12-27 Thread Mathias Fröhlich
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,

Re: [Flightgear-devel] deteriorating cull performance kills fps

2011-12-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)

2011-12-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Announcing Project Rembrandt

2011-12-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Debugging an Ati shaders issue (with 3d textures, again)

2011-12-24 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] deteriorating cull performance kills fps

2011-12-21 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!

2011-12-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Announcing Project Rembrandt

2011-12-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!

2011-12-18 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] OSG font rendering broken

2011-12-17 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] OSG font rendering broken

2011-12-17 Thread Mathias Fröhlich
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

Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!

2011-12-14 Thread Mathias Fröhlich
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

  1   2   3   4   5   >