Re: [Flightgear-devel] Rembrandt on old cards
--enable-rembrandt --prop:/sim/rendering/shadows/enabled=true --prop:/sim/rendering/shadows/num-cascades=1 --prop:/sim/rendering/shadows/cascade-far-m=50 should be: --prop:/sim/rendering/shadows/cascade-far-m[0]=50 --prop:/sim/rendering/shadows/map-size=2048 --prop:/sim/rendering/shadows/filtering=2 (or 1 for no filtering) --prop:/sim/rendering/use-color-for-depth=true -Fred -- 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] Rembrandt on old cards
Voila, your weekly screenshot(s): http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_04.0.png http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_04.1.png Looks like there is some progress, isn't it ? Debian Linux/AMD64, Nvidia GeForce 7950 GT, closed source driver version 295.40. Omitting shaders/quality-level, shaders/skydome and random-vegetation doesn't make a visual difference. These settings should have been recorded as user data, so are persistent from one run to another. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hi Heiko, What do I miss? Where am I wrong? Do we get something like back with the next release in less than 3 months? In case you didn't notice, Thorsten screenshots are from altitude, not from the ground, with more clouds on screen, and at dusk or dawn. Put yourself in the same conditions to do the comparison Regards, -Fred -- 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] using property values as indexes for other property references in a animation XML file.
Scott,
I searched and can't find anything to do this, but just wanted to
make sure it doesn't exist.
I have a property /instruments/b/index let's say it has a int value
of 1 In my animation XML file I need to access an array, with the above
property being used as the index.
something like;
text
property/instruments/b/a[ {/instruments/b/index}
]/value/property
Is there anything in PropertyList text processing that allows me to
reference another property inside referencing a property like the
above?
The property path syntax only allow digits between square brackets.
You have to write a Nasal script that resolve the index first and
format a correct property path.
Regards,
-Fred
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif Regards -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif The only place models get the effect is if they go via Effects/model-default.eff if they're using their own effect file they are not in the scheme. I was speaking about the terminal, not the random buildings. But you already saw my previous message :) -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Presumably all these effects could actually be done as one screenspace pass? Please elaborate -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I usually commit Thorsten's work. Will have a look in the next days. This is in git now, with the duplicated technique removed -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Is this anything I could have caused? Because I have no idea where to look for a potential fix. I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? What I did was : 1. open the shader custom configuration and put the landmass slider to the right. 2. stop FG with the quit menu to record my settings, 3. restart at KSFO and see the maintenance and terminal buildings with weird lighting. 4. open the shader dialog and click on the landmass slider thumb: the lighting comes back. That doesn't happen if the slider in in the left position. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? For some (yet to be determined) reason the shader settings are not archived on Flightgear exit in my local devel branch since my next-to-last update three weeks ago. That could explain why I never really saw the problem, because I start with landmass slider initialized to 3 and always shift it to 4 by hand - so I always touched it in my tests before the shader came on. I'll try later today to set the shader quality via commandline and see what happens then (I'm at the wrong computer to try at the moment...) Maybe you already know that, but closing the window using the windows manager close decoration bypass setting saving here. The default value in preferences.xml is 1, so if you start at 3, either you changes preferences.xml locally, or you have your private settings loaded. Maybe they are now read-only. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Do you reproduce the problem I see ? Okay, found the problem with userarchive and eliminated it Now I see the same thing you describe, the model shader doesn't start up correctly, but all goes well once one just clicks the slider. The model shader doesn't seem to be doing anything at all, I can't fog the buildings either. I wonder why the terrain shading starts up the right way though - if any parameters passed to the shader would not be ready, then the terrain should show the same problem, but that isn't happening. This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? Yes. You can disable shadows and see what is the delta in fps. Usually I get 5 more. Regards, -Fred -- 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 Stuart, On Wed, Apr 25, 2012 at 10:33 AM, Renk Thorsten wrote: Hm... I'm getting good performance, but the rendering of the random buildings do not seem to go via model-default.eff - they respond to the normal visibility, but not to the terrain haze layer, so they remain visible when I turn on heavy ground fog. Is there a conceptual problem, or can this be fixed? You are correct - they aren't using model-default.eff or indeed any part of the Effects system right now (which is why they don't work properly with Rembrandt either). There's no conceptual problem - I just haven't worked out how to integrate the Effects properly yet. I'm sure it's a five minute job for someone who knows more about the Effects C++ code than I do. Is there a reason it could be different than for the trees ? Look in TreeBin.cxx to see how it was done. This was my example to do light animations btw. Regards -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Regards, -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Thorsten, One comment - to avoid any problems with merge requests being lost/ignored - who is this 'aimed' at? I.e who needs to review it and decide? I don't feel qualified, for example :) (But maybe I just merge it and see who complains ;) Not that you need to pick on any one person, but if everyone is busy, the ball gets dropped, and you (Thorsten) feel like work is being ignored, which is bad for everyone. I usually commit Thorsten's work. Will have a look in the next days. The direct link to the merge request is usually handy. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? Regards, -Fred -- 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 Thorsten, Can you get a backtrace? I can try if you tell me what I need to do... I've made a change to the startup sequence, yesterday, but I would expect it to crash later (after scenery loading), ten seconds sounds too early. Misunderstanding: After scenery loading and I find myself in the cockpit, I have 10 seconds to look around, then comes the crash. I had similar problem this weekend, and a full rebuild (simgear + flightgear) solved the issue. I have the sentiment that changes to SGReferenced (in simgear) could have created this instability Regards, -Fred -- 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 James, just a guess here, but in the past, I had to fix issues brought when converting raw pointers to smart pointers and ending up deleting the pointer given by the smart pointer explicitly. For example : SGSharedPtrMyClass myPtr = new MyClass; then delete myPtr; or delete myPtr.get(); afterward, the destructor of SGSharedPtrMyClass does another delete on the same memory and may crash, depending the system and the memory layout Regards, -Fred -- 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
James, I wasn't affected by a crash until I realized that hashForAirport was never called. Then I enabled animated jetways and the segfault came, after few successful calls. I am not able to tell why though HTH -Fred -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Water shader issues
Emilian, All the sine stuff happens in the fragment shader, so performance is directly related to the amount of screen pixels covered by water, not on the amount of vertices. Maybe just testing the pixel depth against the fog distance might bring some performance in fogged scenarios, where you won't compute the sine waves beyond visible range, for the few pixels that fall into that category. You missed the point Thorsten is making. At distance, one pixel covers many wavelength and you only get aliases when spending all the computing power on that computation, when a simple random() call would have the same effect (and maybe that would remove aliasing). The fragment shader could stop computing waves when the eye coordinate distance if greater than a particular threshold. I think it's the strategy followed by Bruneton when he transitions from wave geometry to normal mapping to special BRDF in is ocean simulation. The same thing should apply to the urban shader although the area covered is far less than ocean Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
De: Martin Spott Frederic Bouvier wrote: This shader error affects shadow rendering and for now, I don't have a replacement. The only thing I can propose for this kind of card, is to disable shadow rendering : --prop:/sim/rendering/shadows/enabled=false Here's your weekly screenshot from 1 hour old GIT: jive: 11:14:57 ~ find .fgfs* find: No match. jive: 11:15:06 ~ env | grep \^FG FG_HOME=/opt/FlightGear FG_ROOT=/home/martin/SCM/FlightGear/fgdata jive: 11:15:10 ~ fgfs --timeofday=noon --enable-rembrandt --prop:/sim/rendering/shaders/quality-level=0 --prop:/sim/rendering/shaders/skydome=false --prop:/sim/rendering/random-vegetation=0 --prop:/sim/rendering/no-16bit-buffer=true --prop:/sim/rendering/shadows/enabled=false|tee fgfs-rembrandt_03.txt http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_03.png http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_03.txt Reminder, this is on stable Debian Linux/AMD64, Nvidia GeForce 7950 GT, closed source driver version 295.40. Although the shadows are disabled, the shadow map is allocated in case you want to see them in flight. To save memory, add --prop:/sim/rendering/shadows/map-size=2 to your list of starting options (instead of 4096 by default). I also updated base effects, so you can try with an updated fgdata. I have crash on my 7600GT that seem related to VASI (and point sprite). I also have the rather harsh fog that seem to improve by increasing visibility (z key). Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
Gene Buckle On Thu, 12 Apr 2012, Frederic Bouvier wrote: Here is a video with a steady view to see shadow stability. http://youtu.be/JtEXIn2yL94 I also added 3 different sequences with different levels of filtering. Filtering is not yet configurable but is selectable in the sunlight shader with simple code modification. Fred, is there a reason the shadows on the instrument faces are so jumpy? Probably :) one reason is the moving sun that few other games have (not speaking of flight simulators, of course) -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
Will try. In any case, the information that some fallback code is probably be running is helpful already, I should be able to check this easily by setting gl_FragColor to blue in the shader that ought to be running and investigate from there. If you can post a screenshot with the buffers displayed, that might help to locate the problem. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
De: Renk Thorsten To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Okay thanks, then I am safe. Btw (spotted this while checking) - is there any particular reason to compute a normal from gl_Normal in the vertex shader, use a full varying vec3 to pass it to the fragment shader and add noise there? I mean, this is a water surface, it ought to be flat up to tiny corrections before adding noise... Apart that the earth is a sphere and ocean tiles are large pieces of terrain where the curvature is quite apparent, how whould you define flat ? In which reference frame ? The simplest way is to think that before applying normal mapping and noise perturbation, the surface of things is perpendicular to its the normal. Emilian can testify that the current water shader is extremely difficult to convert to Rembrandt because it doesn't have a clear reference frame. It seems to work in object space but with assumptions on the object-to-world transformation. My gut feeling is that it was originally a demo from another project and added to FG without much thought, and a lot of trials and errors. As the writer of the urban shader, I am thinking of rewriting the Rembrandt version of the water shader in the same spirit. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader - Environment interfacing issues
Actualy it makes assumptions about the lighting scheme used, and it boosts the visible reflection of the sun using a texture instead of the light's specular in the specular pass. That gets to be less aparent in the Rembrandt specular pass.(That would be easily converted by using the sun position, but we don't have that in the geometry pass :( ) One other issue that needs to be investigated is the changing specular position related to camera direction in Rembrandt (the leads to the ugly black banding in other objects too). It's visible on any object at certain surface to camera angle. I pushed a different way to encode normals, with a shader to collect utility functions (see normal_encode and normal_decode in gbuffer-functions.frag). That may improve the banding. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
De: James Turner On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Glad to see someone else if able to make the correct diagnosis :) If the internal buffer are not correct, lighting equations done in the ambient, sunlight and fog pass will work on bogus inputs. I'll add that you get that either if an effect not converted to Rembrandt is used, or if the default shader has a build error and OSG fallback to fixed functions. So if the lightfield or the skydome is not enabled, check the console for a shader build error. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 10:35 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 10:29 +0200, Erik Hofman wrote: On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote: On 12 Apr 2012, at 08:24, Renk Thorsten wrote: 3) On my box, all three panels in the screen edges show the same image - not so on Fred's videos - is this the intended behaviour? This is the important one - it means the multiple render targets isn't working, so you have no chance of seeing anything sensible with Rembrandt. (As I understand it) Also I see that --prop:/sim/rendering/no-16bit-buffer=true falls back to 8-but normal buffers. That might be just a bit to low for normal buffers. And it looks that way, Replacing GL_RGBA8 with GL_RGBA16 removes the flickering and still got me a working system. even GL_RGB16 works. For all the buffers or only the normal buffer ? You're not supposed to have multiple render target of different element size. RGBA8 = 32bits, as well as RG16. What is your card brand and model ? I came across a blog post that compares multiple ways to compress the normals in an 8bit texture and I will try that shortly. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
The driver is somewhat older - as with anything which works fine on my computer, I'm reluctant to fiddle with it because on past occasions I have found myself struggling for a few days just to restore the previous state of the system when an update went wrong, and I simply don't have the time. I don't think it will change anything as NVidia is not making driver updates for this model of GPU for a long time. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
De: Erik Hofman On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote: De: Erik Hofman e...@ehofman.com On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote: What is your card brand and model ? It's a NVidia GeForce 9600GT I think Emilian has the same card and I don't think he had these problems. Maybe it's a good idea to collect user experience with Rembrandt on a Wiki page ? I'm using Linux, maybe that's the difference? BTW today there was a driver update but that didn't change anything regarding this 'problem'. Updates are now for newer cards -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
I came across a blog post that compares multiple ways to compress the normals in an 8bit texture and I will try that shortly. That might be a good idea, at least to save texture memory. This blog entry is now cited as reference in the Rembrandt wiki page. -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
Thorsten, I'll add that you get that either if an effect not converted to Rembrandt is used, or if the default shader has a build error and OSG fallback to fixed functions. So if the lightfield or the skydome is not enabled, check the console for a shader build error. Another possibility is that an extension check fails for you : extension-supportedGL_ARB_texture_rg/extension-supported Try to locate that line in Effects/model-default.eff and Effects/terrain-default.eff and remove it or comment it out Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Now Rembrandt here...
1) The shadows around the aircraft have a ragged egde. That I understand is a function of the shadow map size. I can't go beyond 4096, I get an error on the console trying to go higher - but 4096 works fine with acceptable framerates, the edge is just a limit of my GPU and that is okay. 2) I see shadows flickering (I tried the Cub cockpit for comparison) when I'm in level flight where they shouldn't move - the effect is a bit like a shadow cast by a candle flickering in the wind. In Heiko's video that is sometimes visible (he doesn't fly straight much, and when the shadows actually move the effect is masked). I've never seen it in Fred's videos - is it not there, or just not in the video? Personally, I find that flickering maddening - I've ended my test flight after 5 minutes because I was starting to get a headache. Here is a video with a steady view to see shadow stability. http://youtu.be/JtEXIn2yL94 I also added 3 different sequences with different levels of filtering. Filtering is not yet configurable but is selectable in the sunlight shader with simple code modification. Regards, -Fred -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No Rembrandt here...
De: Erik Hofman On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote: The first line says it all. Okay... so what does it mean? It means that a required Framebuffer Object failed to setup and the fallback isn't OK for Rembrandt. I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem persists. Also when I use small shadow map in addition to 800x600 window no success (leaving aside the fact that Flightgear running in a window of less than a quarter of my screen isn't really thrilling...) . Maybe this may help developers, it's about the same message: http://forum.openscenegraph.org/viewtopic.php?t=8905 This issue is related to iOS and OGL ES, that is a bit different. There is the concept of implicit attachment in OSG, so INCOMPLETE_ATTACHMENT shouldn't occur if an attachment was missing in the first place. I am thinking of an explicit attachment that failed silently. There is a way to increase the OSG log level, but I don't remember it for the moment. I have to make guess as I don't have a card that exhibit that issue. You can try to edit fg/src/Main/renderer.cxx and change GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to add the --bpp=32 option to the fgfs command line. Last, make sure that you didn't enable multithreading in preferences.xml (AutomaticSelection or something else) Plus, so far with one exception (landmass effect at high quality) pretty much everything so far ran just fine out of the box with very acceptable framerates. So, I have a feeling that Rembrandt might be going to leave a lot of folks with blank screens at this point. I don't want to be negative here, maybe it is a trivial problem, but this isn't really a shader which I don't really need to see, this gives me an unusuable Flightgear. Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer should work for everybody. Regards, -Fred -- 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] No Rembrandt here...
Hi Erik, De: Erik Hofman On Wed, 2012-04-11 at 10:18 +0200, Frederic Bouvier wrote: I have to make guess as I don't have a card that exhibit that issue. You can try to edit fg/src/Main/renderer.cxx and change GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to add the --bpp=32 option to the fgfs command line. Last, make sure that you didn't enable multithreading in preferences.xml (AutomaticSelection or something else) None of these seems to help but when I apply the attached patch (as suggested by http://markmail.org/message/yfuz7je43bdzt6h2) at least the warnings are gone and I see the scenery (but not yet perfect). With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. Regards, -Fred -- 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] No Rembrandt here...
On Wed, 2012-04-11 at 13:35 +0200, Frederic Bouvier wrote: Hi Erik, With this patch you are trading a bug for a bug. Assigning the same attachment to three buffers as the same effect than assigning three different values to the same variable. I was already afraid something like that was happening. Try --prop:/sim/rendering/no-16bit-buffer=true although the symptoms were a bit different Regards, -Fred -- 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] FGbuild for MS Windows
I presume you need to start cmake in the correct VS2010 environment. If you try to enter cl in the command line and it replies Command not found, you need to locate vsvars32.bat and run it in your command line session. Jenkins build log, available here (for build 216) : http://flightgear.simpits.org:8080/job/SimGear-Win-Cmake/216/console says : call C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat Otherwise, the Wiki page suggest to use the Cmake GUI. VC2010 express is only able to generate 32bit programs Regards, -Fred - Mail original - De: castle 64 castle...@comcast.net À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mardi 10 Avril 2012 19:24:11 Objet: Re: [Flightgear-devel] FGbuild for MS Windows OK, think I see the problem. running a bare cmake shows there is no generator install on this laptop for Visual studio 10, versions 6 through 9 and Win64 are avalable to generate project files but no 10. Loaded VC10c++ express, but guess the generator is a different animal. John - Mail original - From: castle 64 castle...@comcast.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 11:12:38 AM Subject: Re: [Flightgear-devel] FGbuild for MS Windows Thanks to all, getting closer, started to build simgear, did not get very far with following error c:\fgbuild\projects\msvc100\SimGearcmake C:\fgbuild\simgear -G Visual Studio 10 -DMSVC_3RDPARTY_ROOT=C:\fgbuild\dependencies -DCMAKE_INSTALL_PREFIX:PATH= C:\fgbuild\dependencies\install\msvc100\SimGear CMake Error: Could not create named generator Visual Studio 10 Tried to follow all the instructions precisely, but something is amiss. name or path problem?? syntax?? directory structure?? delete the quotation marks?? John - Mail original - From: Gijs de Rooy gijsr...@hotmail.com To: FlightGear Development list flightgear-devel@lists.sourceforge.net Sent: Tuesday, April 10, 2012 9:22:28 AM Subject: Re: [Flightgear-devel] FGbuild for MS Windows http://wiki.flightgear.org/Building_using_CMake_-_Windows in combination with https://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC did it for me. Together with some help on IRC ;-) I'll see if I can improve the wiki a bit more. Gijs -- 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 -- 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 -- 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 -- 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] No Rembrandt here...
Hi Thorsten, The first line says it all. I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 or reduce the window size : --geometry=800x600 to reduce the memory footprint. You have a laptop right ? Maybe you have shared memory between the CPU and the GPU (NVidia calls that TurboCache) and you didn't reserve enough memory for the GPU. This is a BIOS setting. Allocate the more you can to the GPU and retry. Regards, -Fred - Mail original - De: Renk Thorsten Just freshly pulled and compiled GIT, fresh FGData master, trying to start with --enable-rembrandt results in garbage on the screen and an impressive list of errors - (I've omitted messages with meaning known to me in the following as well as repetitions). Running without Rembrandt looks fine to me on first glenace. Graphics card is an NVIDIA GeForce 8600M running under Linux with the nvidia driver. Cheers, * Thorsten RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6 Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple olor outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple olor outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple olor outputs. Failed to create beacon for unknown runway 'KONT 26L OM'. Failed to create beacon for unknown runway 'KONT 26R OM'. Failed to create beacon for unknown runway 'KSAV 01 OM'. Failed to create beacon for unknown runway 'KSAV 10 OM'. Failed to create beacon for unknown runway 'PAYA 11 OM'. Failed to create beacon for unknown runway 'WARQ 26 OM'. Failed to create beacon for unknown runway 'WARR 10 OM'. Failed to create beacon for unknown runway 'ZULS 27R OM'. Failed to create beacon for unknown runway 'EDDB 07 MM'. Failed to create beacon for unknown runway 'EDDB 25 MM'. Failed to create beacon for unknown runway 'KIAD 01C MM'. Failed to create beacon for unknown runway 'KONT 08L MM'. Failed to create beacon for unknown runway 'KONT 26L MM'. Failed to create beacon for unknown runway 'KONT 26R MM'. Failed to create beacon for unknown runway 'KSAV 01 MM'. Failed to create beacon for unknown runway 'KSAV 10 MM'. Failed to create beacon for unknown runway 'PAED 06 MM'. Failed to create beacon for unknown runway 'PAYA 11 MM'. Failed to create beacon for unknown runway 'WADD 27 MM'. Failed to create beacon for unknown runway 'WALL 25 MM'. Failed to create beacon for unknown runway 'WAOO 10 MM'. Failed to create beacon for unknown runway 'WAOP 34 MM'. Failed to create beacon for unknown runway 'WARJ 09 MM'. Failed to create beacon for unknown runway 'WARQ 26 MM'. Failed to create beacon for unknown runway 'WARR 10 MM'. Failed to create beacon for unknown runway 'WIDD 04 MM'. Failed to create beacon for unknown runway 'WIHH 24 MM'. Failed to create beacon for unknown runway 'KIAD 19C IM'. Failed to create beacon for unknown runway 'KONT 26L IM'. RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6 Warning: detected OpenGL error 'invalid enumerant' at end of SceneView::draw() Loading local weather routines... Animated jetways ... initialized loading scenario 'nimitz_demo' Image /home/fgfs/FGData/fgdata/Textures/Water/waves-ver10-nm.dds uses compressed textures which cannot be supported on some systems. Please decompress this texture for improved portability. (...) RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6 Warning: detected OpenGL error 'invalid enumerant' at start of State::apply() (...) -- 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 -- 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] FGbuild for MS Windows
Hi Olaf, De: Olaf Flebbe f...@oflebbe.de VC2010 express is only able to generate 32bit programs Regards, -Fred Hi, One can use the Windows SDK http://www.microsoft.com/download/en/details.aspx?displaylang=enid=8442 GRMSDKX_EN_DVD.iso to generate 64 Bit Windows Executables. This integrates with VS2010 Express as well. Really ? Do you manage to build 64bit executables with VS Express ? Does it come with a 64bit compiler ? Regards, -Fred -- 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] Apologies to Fred - more feedback
I won't get the chance to fix this until after the weekend, but in the meantime at least the Rembrandt performance problems with random vegetation should be resolved. Already fixed ;) Regards, -Fred -- 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
[Flightgear-devel] Rembrandt aircraft and fgrun
I should raise the point now before things get too complicated to change. In case you didn't notice, aircraft with Rembrandt lights now exhibit big grey blobs in the 3d preview of fgrun. So we should think of a way to identify these objects and remove them in fgrun. The simplest way is a naming convention, because fgrun doesn't use the fg animation system, and can't find the cull mask of objects set in animations. What do you think ? Regards, -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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] Rembrandt aircraft and fgrun
That's a possibility (I forgot that one) but it only apply to submodels, right ? -Fred - Mail original - De: Clement de l'Hamaide clem...@hotmail.fr À: flightgear-devel@lists.sourceforge.net Envoyé: Jeudi 5 Avril 2012 15:59:18 Objet: [Flightgear-devel] Rembrandt aircraft and fgrun Hi Fred, In order to disable the big grey blobs in the 3d preview of fgrun, just need to add /nopreview in XML file of the object. You can test it with the last version of Tecnam P92 for Rembrandt here : http://clemaez.fr/flightgear/Tecnam-P92-rembrandt.tar.gz For exemple : ?xml version=1.0 encoding=UTF-8? PropertyList pathlight.ac/path nopreview/ /PropertyList Cheers, Clément -- 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 -- 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] Rembrandt aircraft and fgrun
I don't remember every thing I did 5 years ago. Thank you for refreshing my memory So please, aircraft developers (Vivian, Gijs, Emilian, ...), use the nopreview/ tag Regards, -Fred - Mail original - De: Clement de l'Hamaide clem...@hotmail.fr À: flightgear-devel@lists.sourceforge.net Envoyé: Jeudi 5 Avril 2012 18:58:10 Objet: [Flightgear-devel] Rembrandt aircraft and fgrun Do you have really forgot that one? because you are the author of this feature :P http://comments.gmane.org/gmane.games.flightgear.general/17849 You are a joker developers ;) Your implementation takes effect with animation and model. Thus you can use it like : animation object-nameailes/object-name nopreview/ /animation But since you are the author of this feature I think I don't need to explain you how to use your feature ;) Cheers, Clément -- 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 -- 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] More Rembrandt Feedback
- Scenery-terrain seems to cast shadows. Visible especially shortly before dawn or shortly after dusk. Great feature if so, but seems also need a lot of perfomance. Maybe it can be made switchable? - Comparing different aircraft-models showed me, that not the general number of vertices or even faces is the limiting factor, but the number of objects. Especially instruments which makes use of many objects, so using non-shadow animation would be very recommended for instruments. -I do like when scenery objects cast shadows. But Do we need that in a far distance? Maybe we can have a distance limitation additional to Stuarts proposal? The cost of shadows is the difference in fps between night and day, as shadow rendering is disabled at night. The scene is rendered in the shadow map with front face culling on, so the terrain is only draw in the shadow map when the sun is near the horizon. Regards, -Fred -- 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] More Rembrandt Feedback
- Scenery-terrain seems to cast shadows. Visible especially shortly before dawn or shortly after dusk. Great feature if so, but seems also need a lot of perfomance. Maybe it can be made switchable? - Comparing different aircraft-models showed me, that not the general number of vertices or even faces is the limiting factor, but the number of objects. Especially instruments which makes use of many objects, so using non-shadow animation would be very recommended for instruments. -I do like when scenery objects cast shadows. But Do we need that in a far distance? Maybe we can have a distance limitation additional to Stuarts proposal? The cost of shadows is the difference in fps between night and day, as shadow rendering is disabled at night. The scene is rendered in the shadow map with front face culling on, so the terrain is only draw in the shadow map when the sun is near the horizon. I should add that the shadow map is rendered 4 times to preserve details in the near range while seeing shadows in a reasonable distance. Ranges are : - 0.2 - 5m, intended for the cockpit - 5 - 50m, for the outside view, - 50 - 500m - 500 - 5000m for buildings surrounding the viewer We could imagine to reduce the number of cascade. Increasing the individual ranges would result in more blocky shadows, but a small control on distances may be considered. Regards, -Fred -- 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] Apologies to Fred - more feedback
Hi James, a quick reply, to say that most likely, the shader with a problem is sunlight.frag Regards, -Fred - Mail original - De: James Turner zakal...@mac.com À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mercredi 4 Avril 2012 15:49:33 Objet: [Flightgear-devel] Apologies to Fred - more feedback Before I say anything else, please know this work is hugely appreciated, and if there's any more I can do to help, just ask. With latest everything, as of a few minutes ago, something odd has happened: http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png Note - the normal and specular buffers seem to have gone 'wrong' - but the actual shadow is being drawn without the previous Z-fighting issues (especially if I go for a drive) - the general lighting has gone weird - especially runway surfaces are very bright, and if I rotate the camera around the aircraft, at more than 180) degrees of views, the shadow is invisible. In the log I'm getting: can't find Effects/ambient.eff = Using default, builtin, Effects/ambient And (much) later on: GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft Initializing Nasal Electrical System Loading tile 2892906.stg Loading stg file /Users/jmt/Library/Application Support/FlightGear/TerraSync/Objects/w010n50/w004n55/2892906.stg FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:18: Left-hand-side of assignment must not be read-only glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled ... we really need to fix something to include the shader code or file name or something :) James -- 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 -- 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] Apologies to Fred - more feedback
Too quick. If the 3 buffers show the same image, it's because Multi Render Target (MRT) is not in action. The cause may be that technique 10 of model-default or terrain-default is not chosen. If technique 11 or 12 are used, because of a failed predicate. You get that. The shadow is rendered in the image in sunlight.frag so this is not the problem but the inputs are weird, so is the lighting. You disabled *all* shaders, right ? Regards, -Fred - Mail original - De: Frederic Bouvier fredfgf...@free.fr À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mercredi 4 Avril 2012 16:31:02 Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback Hi James, a quick reply, to say that most likely, the shader with a problem is sunlight.frag Regards, -Fred - Mail original - De: James Turner zakal...@mac.com À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mercredi 4 Avril 2012 15:49:33 Objet: [Flightgear-devel] Apologies to Fred - more feedback Before I say anything else, please know this work is hugely appreciated, and if there's any more I can do to help, just ask. With latest everything, as of a few minutes ago, something odd has happened: http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png Note - the normal and specular buffers seem to have gone 'wrong' - but the actual shadow is being drawn without the previous Z-fighting issues (especially if I go for a drive) - the general lighting has gone weird - especially runway surfaces are very bright, and if I rotate the camera around the aircraft, at more than 180) degrees of views, the shadow is invisible. In the log I'm getting: can't find Effects/ambient.eff = Using default, builtin, Effects/ambient And (much) later on: GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft GPS: someone accessed a deprecated property:/instrumentation/gps/wp/wp[1]/altitude-ft Initializing Nasal Electrical System Loading tile 2892906.stg Loading stg file /Users/jmt/Library/Application Support/FlightGear/TerraSync/Objects/w010n50/w004n55/2892906.stg FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:18: Left-hand-side of assignment must not be read-only glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled ... we really need to fix something to include the shader code or file name or something :) James -- 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 -- 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 -- 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] Apologies to Fred - more feedback
Thank you James, Can you push that to gitorious ? Regards, -Fred - Mail original - De: James Turner zakal...@mac.com À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mercredi 4 Avril 2012 17:51:13 Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: The shadow is rendered in the image in sunlight.frag so this is not the problem but the inputs are weird, so is the lighting. You disabled *all* shaders, right ? Just made (and pushed) a Simgear tweak to identify the shader names :) FRAGMENT glCompileShader /Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag FAILED FRAGMENT Shader /Users/Shared/FGFS/data/Shaders/deferred-gbuffer.frag infolog: ERROR: 0:18: Left-hand-side of assignment must not be read-only Which apparently is: ecNormal = (2.0 * gl_Color.a - 1.0) * ecNormal; Guessing that writing to a 'varying' might be the issue, I made a temporary: vec3 normal2 = (2.0 * gl_Color.a - 1.0) * ecNormal; gl_FragData[0] = vec4( (normal2.xy + vec2(1.0,1.0)) * 0.5, 0.0, 1.0 ); And now everything looks good! The intermediate buffers, the shadows, yes. Regards, James -- 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 -- 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] Apologies to Fred - more feedback
You may also want to disable vegetation for better performance : --prop:/sim/rendering/random-vegetation=0 Regards, -Fred - Mail original - De: Gijs de Rooy gijsr...@hotmail.com À: flightgear-devel@lists.sourceforge.net Envoyé: Mercredi 4 Avril 2012 17:53:31 Objet: Re: [Flightgear-devel] Apologies to Fred - more feedback No FG at hand, but from memory: that doesn't disable the skydome shader. You can use --prop:/sim/rendering/shaders/skydome=false (IIRC) for that. From: zakal...@mac.com Date: Wed, 4 Apr 2012 16:04:11 +0100 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Apologies to Fred - more feedback On 4 Apr 2012, at 15:56, Frederic Bouvier wrote: You disabled *all* shaders, right ? --prop:/sim/rendering/shaders/quality-level=0 In my fgfsrc. James -- 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 -- 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 -- 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] Apologies to Fred - more feedback
On 4 Apr 2012, at 17:00, Frederic Bouvier wrote: Thank you James, Can you push that to gitorious ? Done. Looking at the language docs, 'varying' in a fragment shader really is a synonym for 'in', and hence, it makes sense (to me) that assignment to an input is disallowed. But I'm curious, if *no one* else saw this issue, how tolerant most drivers are. So far I have the impression my drivers (that's Ati / Apple) are: - strict about the language compared to nVidia (or fglrx? or Ati Windows?) - have lower limits than other people's hardware / platforms - aren't very up to date! (in terms of supported GLSL version) Taken together, this does *not* make me happy - but so long as we can find a solution to each problem It was part of a fix I pushed late yesterday night. My NVidia driver didn't protest though. Thank you for finding this and for the debugging help. Regards, -Fred -- 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] Apologies to Fred - more feedback
Hi Stuart, On Wed, Apr 4, 2012 at 5:05 PM, Frederic Bouvier wrote: You may also want to disable vegetation for better performance : --prop:/sim/rendering/random-vegetation=0 Regards, -Fred Fred, I'd like to help out fixing bugs/limitations in Rembrandt. Given I wrote the random vegetation code, is this somewhere where I could lend a hand? I had a look at the code last night, and tried just setting the shadow camera to cull the vegetation nodes, but it didn't improve performance in any significant way. Have you any thoughts about how this should be fixed? BTW - very much appreciate the top quality puns from the last couple of days! The first thing to do it to convert the tree shader in a way it outputs correctly normals and colors to the 3 buffers. As long as you can see identically shaded objects in all three buffers, it's not good. You may want to look into deferred-gbuffer[.vert/.frag] shaders to see how to use gl_FragData instead of gl_FragColor. It's important to leave out all kind of shading. If you want the trees look cylindrical (put a better word here) and not flat, you may bake a normal that is not strictly toward the viewer, as it is really a flat billboard, but you can leave that for later. I updated the wiki page to describe the new buffer layout. As for the performance, I have a vague recollection that you say that the trees are first drawn alpha-tested and then alpha-blended. Can you elaborate on this if it's true ? Don't hesitate to ask if something is not clear or incomplete. Regards, -Fred -- 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] Apologies to Fred - more feedback
On 4 Apr 2012, at 17:22, Frederic Bouvier wrote: It was part of a fix I pushed late yesterday night. My NVidia driver didn't protest though. Thank you for finding this and for the debugging help. No problem, delighted to help any way I can. I wasn't complaining at you, more at the state of GLSL where it seems the combination of 'what works' varies for each person who tries - but everything seems to work on nVidia ;) NV 7xxx and below have a broken opengl (at least in glsl) that impedes shadows for the moment. I have to admit they improve lately ;-) -Fred -- 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] [SPAM] Re: Apologies to Fred - more feedback
De: Anders Gidenstam On Wed, 4 Apr 2012, James Turner wrote: Guessing that writing to a 'varying' might be the issue, I made a temporary: vec3 normal2 = (2.0 * gl_Color.a - 1.0) * ecNormal; gl_FragData[0] = vec4( (normal2.xy + vec2(1.0,1.0)) * 0.5, 0.0, 1.0 ); And now everything looks good! The intermediate buffers, the shadows, yes. One thing: I think ecNormal should be normalized before use - IIRC the interpolation between the vertex shader output and the input to individual fragments might change the length of the normal (since it typically is linear in each dimension). Good point Anders. Can push that fix ? Thank you -Fred -- 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] [Rembrandt] the plan
De: Martin Spott Frederic Bouvier wrote: You can try the last code with --prop:/sim/rendering/no-16bit-buffer=true jive: 12:18:06 ~ find .fgfs* find: No match. jive: 12:18:17 ~ env | grep \^FG FG_HOME=/opt/FlightGear FG_ROOT=/home/martin/SCM/FlightGear/fgdata jive: 12:18:19 ~ fgfs --prop:/sim/rendering/shaders/quality-level=0 --timeofday=noon --enable-rembrandt --prop:/sim/rendering/no-16bit-buffer=true Starts with a funnily flickerling splash screen and results in this image - still not perfect, but a lot better now: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.png Log: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.txt This shader error affects shadow rendering and for now, I don't have a replacement. The only thing I can propose for this kind of card, is to disable shadow rendering : --prop:/sim/rendering/shadows/enabled=false this property is settable at run time. It can also help people with performance problems. Regards, -Fred -- 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] Apologies to Fred - more feedback
De: Stuart Buchanan stuar...@gmail.com On Wed, Apr 4, 2012 at 5:40 PM, Frederic Bouvier wrote: As for the performance, I have a vague recollection that you say that the trees are first drawn alpha-tested and then alpha-blended. Can you elaborate on this if it's true ? Yes. There's some documentation describing how it works in Effects/tree.eff: Trees are drawn in two passes. The first draws the opaque parts with z writes enabled. The second draws the the transparent bits with z testing enabled and z writes disabled. The transparent tree silhouettes will blend correctly against the opaque geometry. They may cause artifacts when blending against other edges, but the overall forest is supposed to be nice and fuzzy. There might also be artifacts when blending over other transparent objects, but that's mostly unavoidable. Note: no sorting needed! Tim Moore was responsible for it, so I don't have any further insight. By toggling the /sim/rendering/shadows/enabled, we can see that the performance problem is with rendering into the shadow maps. It is significant when the density is high Regards, -Fred PS: is there a volunteer to restore shadow settings in the GUI ? For the moment, there is the map size and the global toggle. There are properties in the preferences that we can try to reimplement later. There are also new parameters like the number of cascades (1 to 4) and the ranges for each cascade that would be interesting to have. -- 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] More Rembrandt Feedback
Hi, We have a comics here where the main character is named Lucky Luke. He is a cowboy who run after the evil Dalton brothers and is famous to fire faster than his shadow. Do we want objects ahead of their shadows and play Lucky Luke in fg ? Rendering half the scene in the shadow map is not possible. Once the shadow map is cleared to render moving objects, you have to render everything again or it will not cast shadows. Regards, -Fred - Mail original - De: TDO Brandano tdo_brand...@hotmail.com À: Flightgear Devel List flightgear-devel@lists.sourceforge.net Envoyé: Mardi 3 Avril 2012 17:41:24 Objet: Re: [Flightgear-devel] More Rembrandt Feedback Actually, what I wonder is, do we need the scenery cast shadows to be calculated on each frame? Is there a way that they can be stored and just updated every few minutes for static objects? Date: Tue, 3 Apr 2012 13:53:08 +0100 From: aeitsch...@yahoo.de To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] More Rembrandt Feedback Hello, Does anyone know whether FG is unique amongst desktop simulators in offering this? I have no experience of X-Plane nor FS-X. Yes, X-Plane 10 also makes use of deferred shading. They just named it Global Lighting/HDR. Framerates aren't better there as in FGFS as now. The difference is only that landinglights there looks much smoother (no hard edges), the same for the shadows. But we have a really good start as a non-commercial product. Very promising, especially as an OpenSource-project. Thanks Fred for your great work! Can't tell about FS-X, but I guess it is a similar technic. I've noticed significant slowdown on my computer in the following circumstances: - Forests (e.g. KHAF). Having not looked at the code, my guess is that some NodeVisitor for the rending is delving too deeply into the OSG tree for the random vegetation. - Urban areas. My guess here is that is purely due to the number of models being rendered, each of which is casting a shadow. I know that there are still optimisations to be made, but could I suggest a property switch to limit shadowing to the user's aircraft? IMO the self-shadowing in the aircraft cockpit is the most impressive part of Rembrandt, and the combination of that plus shadowing on the ground might be an acceptable frame-rate compromise for many users. Agree to Stuart. - Forest seems to need much more perfomance than before. Other things I noticed: - Scenery-terrain seems to cast shadows. Visible especially shortly before dawn or shortly after dusk. Great feature if so, but seems also need a lot of perfomance. Maybe it can be made switchable? - Comparing different aircraft-models showed me, that not the general number of vertices or even faces is the limiting factor, but the number of objects. Especially instruments which makes use of many objects, so using non-shadow animation would be very recommended for instruments. -I do like when scenery objects cast shadows. But Do we need that in a far distance? Maybe we can have a distance limitation additional to Stuarts proposal? To my surprise it isn't very difficult to make aircraft rembrandt-compatible. The combined-shader is already converted and especially the IAR80 looks really cool with shadows. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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] More Rembrandt Feedback
Each aircraft in the inventory needs checking for 2 sided faces, panel lights need converting, and nice to have are nav. lights and landing lights. Much of the shared and scenery models need similar checking: the windsock is an obvious one. Can you imagine the task for USS Vinson? Hopefully two sided issue is fixed. I don't think it was rocket science though. Regards, -Fred -- 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] More Rembrandt Feedback
Yes, X-Plane 10 also makes use of deferred shading. They just named it Global Lighting/HDR. Framerates aren't better there as in FGFS as now. The difference is only that landinglights there looks much smoother (no hard edges) This is just designers' art. The light poles don't have hard edges. With a carefully designed light volume and well tune attenuation parameters, the hard edges will disappear after some iterations. Regards, -Fred -- 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] [Rembrandt] the plan
De: Martin Spott Frederic Bouvier wrote: You can try the last code with --prop:/sim/rendering/no-16bit-buffer=true jive: 12:18:06 ~ find .fgfs* find: No match. jive: 12:18:17 ~ env | grep \^FG FG_HOME=/opt/FlightGear FG_ROOT=/home/martin/SCM/FlightGear/fgdata jive: 12:18:19 ~ fgfs --prop:/sim/rendering/shaders/quality-level=0 --timeofday=noon --enable-rembrandt --prop:/sim/rendering/no-16bit-buffer=true Starts with a funnily flickerling splash screen and results in this image - still not perfect, but a lot better now: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.png Log: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_02.txt There is still a problem with the lighting shader, but the fbo problem went away Regards, -Fred -- 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] Rembrandt - Some Feedback
With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. I believe it was fixed by these commits : https://gitorious.org/fg/flightgear/commit/8a382cd536743e4cef5b16b37a11fa1282441c5b https://gitorious.org/fg/fgdata/commit/e5d226b26ff4390cdbc1a47706ff735eb3ad6df9 Nevertheless, I am not able to reproduce this behavior here now. Regards, -Fred -- 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] [Rembrandt] the plan
P.S.: If you'd like me to test on the Nvidia 7950 GT again, please yell at me. You can try the last code with --prop:/sim/rendering/no-16bit-buffer=true Regards, -Fred -- 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] [Rembrandt] the plan
The light animation is now functional. As an example, the airport light pole has been converted, and is visible near the maintenance building at KSFO. A new option: /sim/rendering/no-16bit-buffer=true is available for GPU that emit 0x8cda at FBO setup. It should produce ugly specular though. Regards, -Fred The lighting problem has been fixed and the shadows are in since this morning. Shadow resolution is configurable in the preferences by changing /sim/rendering/shadows/map-size before starting fgfs. I'll try to add a listener to make it settable at run-time. Next step will be to add lighting example in the repository. Martin: I know you prefer to handle shared model modification but I would like to commit a quick example : the apt-light model. So please forgive me :) The first batch of sources has been pushed to gitorious. These commits are intended mainly to check that the classical (forward) renderer is not broken and works as usual. They will also permit one to challenge his GPU and see how it behaves in front of the beast. In the plan exposed previously (see below), I skipped step 3. (define an XML format for a configurable renderer) as it appears to be more involved than expected. So what you have is a buggy step 5. :) Buggy because for some reason, sun light depends on the orientation of the camera. But you should get an image. The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. Now that the introduction of Rembrandt next, provided that the current operation is retained, has been accepted, it is time to outline the plan that I intend to apply: 1. update SimGear with additions made on the effects and animations (done). The changes include the creation of positioned uniforms, ie on which applies a MODELVIEW matrix transformation, which serve to indicate the position of light sources in the shaders, and light animations (spot and point). 2. modify the Renderer class to separate from the scenegraph, terrain and models on one hand, the skydome and stars on the other, and finally the clouds. These three elements are passed to the CameraGroup class in order to be treated separately in the new rendering engine (and put together in the current one). 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). 4. modify the base effects for defining the techniques that apply to one or the other renderers (a request for assistance has already been sent to prepare the work and ensure that existing effects does not apply to new rendering mode). 5. implement in the new rendering engine the basic lighting equation (ambient + diffuse + specular) 6. add the shadows 7. add light management 8. with the help of Thorsten, add atmospheric scattering, haze and the light field 9. add the ancillary effects (ambient occlusion and glow) 10. help migrate models and effects I certainly forgot something. Let the discussion plug the holes -- 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] [Rembrandt] the plan
The lighting problem has been fixed and the shadows are in since this morning. Shadow resolution is configurable in the preferences by changing /sim/rendering/shadows/map-size before starting fgfs. I'll try to add a listener to make it settable at run-time. Next step will be to add lighting example in the repository. Martin: I know you prefer to handle shared model modification but I would like to commit a quick example : the apt-light model. So please forgive me :) Regards, -Fred The first batch of sources has been pushed to gitorious. These commits are intended mainly to check that the classical (forward) renderer is not broken and works as usual. They will also permit one to challenge his GPU and see how it behaves in front of the beast. In the plan exposed previously (see below), I skipped step 3. (define an XML format for a configurable renderer) as it appears to be more involved than expected. So what you have is a buggy step 5. :) Buggy because for some reason, sun light depends on the orientation of the camera. But you should get an image. The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. Now that the introduction of Rembrandt next, provided that the current operation is retained, has been accepted, it is time to outline the plan that I intend to apply: 1. update SimGear with additions made on the effects and animations (done). The changes include the creation of positioned uniforms, ie on which applies a MODELVIEW matrix transformation, which serve to indicate the position of light sources in the shaders, and light animations (spot and point). 2. modify the Renderer class to separate from the scenegraph, terrain and models on one hand, the skydome and stars on the other, and finally the clouds. These three elements are passed to the CameraGroup class in order to be treated separately in the new rendering engine (and put together in the current one). 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). 4. modify the base effects for defining the techniques that apply to one or the other renderers (a request for assistance has already been sent to prepare the work and ensure that existing effects does not apply to new rendering mode). 5. implement in the new rendering engine the basic lighting equation (ambient + diffuse + specular) 6. add the shadows 7. add light management 8. with the help of Thorsten, add atmospheric scattering, haze and the light field 9. add the ancillary effects (ambient occlusion and glow) 10. help migrate models and effects I certainly forgot something. Let the discussion plug the holes Regards, -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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 -- 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 -- 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] [Rembrandt] the plan
Hi Martin, - Mail original - De: Martin Spott Martin Spott wrote: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.png Default console output is here - nothing particularly exciting: http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.txt The interesting part is here : RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cda Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. Warning: RenderStage::runCameraSetUp(State) Pbuffer does not support multiple color outputs. 0x8cda is FRAMEBUFFER_INCOMPLETE_FORMATS_EXT Can you check that your card support extension ARB_texture_rg ( glxinfo | grep ARB_texture_rg ) ? What kind of NVidia card is it ? Regards, -Fred -- 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] [Rembrandt] the plan
What is the exact g-buffer format rembrandt tries to set up? NV4x/NV5x have some serious restrictions. 1 attachment is RG16 (normals.xy) 2 attachments are RGBA8 (diffuse color, and monochrome specular, emissive and shininess) 1 GL_DEPTH_COMPONENT32 (depth) Regards, -Fred -- 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] [Rembrandt] the plan
The first batch of sources has been pushed to gitorious. These commits are intended mainly to check that the classical (forward) renderer is not broken and works as usual. They will also permit one to challenge his GPU and see how it behaves in front of the beast. In the plan exposed previously (see below), I skipped step 3. (define an XML format for a configurable renderer) as it appears to be more involved than expected. So what you have is a buggy step 5. :) Buggy because for some reason, sun light depends on the orientation of the camera. But you should get an image. The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. Regards, -Fred Now that the introduction of Rembrandt next, provided that the current operation is retained, has been accepted, it is time to outline the plan that I intend to apply: 1. update SimGear with additions made on the effects and animations (done). The changes include the creation of positioned uniforms, ie on which applies a MODELVIEW matrix transformation, which serve to indicate the position of light sources in the shaders, and light animations (spot and point). 2. modify the Renderer class to separate from the scenegraph, terrain and models on one hand, the skydome and stars on the other, and finally the clouds. These three elements are passed to the CameraGroup class in order to be treated separately in the new rendering engine (and put together in the current one). 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). 4. modify the base effects for defining the techniques that apply to one or the other renderers (a request for assistance has already been sent to prepare the work and ensure that existing effects does not apply to new rendering mode). 5. implement in the new rendering engine the basic lighting equation (ambient + diffuse + specular) 6. add the shadows 7. add light management 8. with the help of Thorsten, add atmospheric scattering, haze and the light field 9. add the ancillary effects (ambient occlusion and glow) 10. help migrate models and effects I certainly forgot something. Let the discussion plug the holes Regards, -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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 -- 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] [Rembrandt] the plan
De: James Turner On 25 Mar 2012, at 18:49, Frederic Bouvier wrote: The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. On Ati 5770 / Mac / OSG 3.0.1, this is basically alive. Getting the following at startup which worries me: (the version not supported error): = End of harmless warning messages on effects not found Initializing splash screen FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:1: '' : version '130' is not supported glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled Warning: detected OpenGL error 'invalid operation' at After Renderer::compile It means that the driver doesn't support version 1.30 of glsl. I'll try to simplify the shader Regards, -Fred -- 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] [Rembrandt] the plan
- Mail original - De: James Turner zakal...@mac.com À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Dimanche 25 Mars 2012 21:51:19 Objet: Re: [Flightgear-devel] [Rembrandt] the plan On 25 Mar 2012, at 20:39, Frederic Bouvier wrote: It means that the driver doesn't support version 1.30 of glsl. I'll try to simplify the shader Given that it's latest Mac OS-X, with a card purchased three months ago, that's worrying :) In other news, the Intel 3000-HD actually seems to work, with --enable-rembrandt - not what I expected at all! Wait the shadows ;) -Fred -- 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] Rembrandt feedback (was: Project Rembrandt - next steps)
Thanks, I prefer that one ;-) -Fred - Mail original - De: Olaf Flebbe f...@oflebbe.de À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Vendredi 9 Mars 2012 23:00:47 Objet: Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps) Hi Fred, I found the correct extension for unsigned uniforms: --- a/src/Main/CameraGroup.cxx +++ b/src/Main/CameraGroup.cxx @@ -906,6 +906,7 @@ const char *ssao_vert_src = const char *ssao_frag_src = #version 120\n +#extension GL_EXT_gpu_shader4 : enable\n #line TOSTRING(__LINE__) 2\n uniform sampler2D normal_tex;\n uniform sampler2D depth_tex;\n Greetings, Olaf -- 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,
De: Erik Hofman On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote: Martin wrote: On my (my wife's) system (Linux Nvidia proprietary driver) this change turns PAPI/VASI lights into huge, illuminated baloons. Therefore I strongly propose to just revert this change. Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0ZI1_Wk/s1024/fgfs-screen-055.png I believe their size used to be distance dependent in the past. The change is mine, and is not specific to Rembrandt. Maybe the size should be tweaked again, and maybe some shared size should be segregated. But my opinion is that their size was ridiculously small on the runway. Just wanted to break the statu quo Regards, -Fred -- 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
De: thorsten i renk I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? You don't have to create a parameter for the properties you want to test in the predicate. But you're right, all the parameters of all pass of all techniques of an effect need to be declared in a single section. A pass is a state set: all the OpenGl attribute of the geometry. When you declare multiple pass, it's because you want the same geometry be drawn several times. You may want to initialize the stencil buffer in one pass (you don't need material properties then) and then draw the object with the stencil test enabled. If you play with the render bins and the draw order that are settable in each pass you can achieve effect such as the light cone (pre - Rembrandt) Regards, -Fred -- 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] Lightfields to GIT - some more advice?
Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Thanks Frederic - this seems to be (sort of) working. I can only get it to work properly if I throw the new technique at index 7 (or lower) though. Otherwise all terrain types which have a special shader do not accept lightfield shading even if that special shader is off, and only by dragging down the index to 7 does this problem go away. No wonder I couldn't make it work before... Techniques are tested in ascending index order. The first technique with a predicate that succeed is used for the effect. If you want your technique be the first tested, you have to use the lowest number possible. But beware, there is an inheritance scheme (with the keyword inherits-from) where, for example, the urban effect inherits from the terrain-default effect. If terrain-default use 10 and 11 for technique index, urban has to use 9 at most. And someone can create an effect that inherits from the urban effect. It would have to use an index lower than the one used by the urban effect. If you use 0, you leave no room for inheritance. Regards, -Fred -- 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 Lauri, Hi all. 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 would like to extend the format to avoid duplicating the stages when you have more than one viewport. What I see is to specify a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport Regards, -Fred -- 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] [Rembrandt] the plan
Now that the introduction of Rembrandt next, provided that the current operation is retained, has been accepted, it is time to outline the plan that I intend to apply: 1. update SimGear with additions made on the effects and animations (done). The changes include the creation of positioned uniforms, ie on which applies a MODELVIEW matrix transformation, which serve to indicate the position of light sources in the shaders, and light animations (spot and point). 2. modify the Renderer class to separate from the scenegraph, terrain and models on one hand, the skydome and stars on the other, and finally the clouds. These three elements are passed to the CameraGroup class in order to be treated separately in the new rendering engine (and put together in the current one). 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). 4. modify the base effects for defining the techniques that apply to one or the other renderers (a request for assistance has already been sent to prepare the work and ensure that existing effects does not apply to new rendering mode). 5. implement in the new rendering engine the basic lighting equation (ambient + diffuse + specular) 6. add the shadows 7. add light management 8. with the help of Thorsten, add atmospheric scattering, haze and the light field 9. add the ancillary effects (ambient occlusion and glow) 10. help migrate models and effects I certainly forgot something. Let the discussion plug the holes Regards, -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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] [Rembrandt] Help request
So may I ask a kind soul with write access to the data repository, or capable of submitting a merge request, to review all effect files and add the test of the new property to every technique of every effect, and add a new predicate to technique not having one for the moment. The code snippet to add to an existing predicate is : Please discard and forget that request. I was finally hit by the light and understood the purpose of not providing the not operator -Fred -- 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] Rembrandt feedback (was: Project Rembrandt - next steps)
Hi Olaf, not all shader are converted, so you'd better disable all of them (Hinted by the error in GEOMETRY that is not used in Rembrandt) The 'unsigned' error shows that the driver is lacking, or maybe a declaration is missing. OSG defines an uniform of type 'unsigned int' The error on image file is harmless. Please ignore it for the moment Thanks for the feedback Regards, -Fred - Mail original - De: Olaf Flebbe f...@oflebbe.de À: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Envoyé: Mardi 6 Mars 2012 23:09:20 Objet: Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps) Hi Fred, I tried Rembrandt on my Macbook Pro 2011 (13): it created a view and than parts of the screen got white. Th kernel log told me that some internal buffer had an overrun. I changed the Property /sim/rendering/shadows/map-size in preferences.xml to 128 and now Rembrandt seems to work (!), at first sight. However I get lots of errors/warnings. Here some of the unusual ones: FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 2:922: 'unsigned' : Reserved word. ERROR: 2:922: 'unsigned' : syntax error syntax error glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled Warning: detected OpenGL error 'invalid operation' at After Renderer::compile RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd PixelBufferCocoa :: realizeImplementation not implemented yet RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd PixelBufferCocoa :: realizeImplementation not implemented yet RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd PixelBufferCocoa :: realizeImplementation not implemented yet no image file, maybe the reader did not set the filename attribute, using white for type '2d' on '', in /technique[11]/pass[0]/texture-unit[0] FRAGMENT glCompileShader FAILED FRAGMENT Shader infolog: ERROR: 0:18: No operator '-' exists taking 'int' and 'float' (and no implicit type conversion allowed in GLSL 1.10) ERROR: 0:20: Use of undeclared identifier 'texel' ERROR: 0:25: Use of undeclared identifier 'texel' glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled Initializing Nasal Electrical System GEOMETRY glCompileShader FAILED GEOMETRY Shader infolog: ERROR: 0:43: Indirect index into implicitly-sized array ERROR: 0:44: Indirect index into implicitly-sized array ERROR: 0:48: Indirect index into implicitly-sized array ERROR: 0:82: Indirect index into implicitly-sized array ERROR: 0:83: Indirect index into implicitly-sized array glLinkProgram FAILED Program infolog: ERROR: One or more attached shaders not successfully compiled no image file, maybe the reader did not set the filename attribute, using w Greetings, Olaf -- 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 -- 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] Rembrandt feedback (was: Project Rembrandt - next steps)
Am 06.03.12 23:09, schrieb Olaf Flebbe: PixelBufferCocoa :: realizeImplementation not implemented yet Hi Fred Just curious about this line, do you think recent osg cocoa windowing under OSX will be supported by rembrandt? Sorry Yves, I have no idea. This error message seems to imply that not all of OSG has been implemented by the Cocoa adapter. But I don't think Rembrandt would work with a Pixel Buffer. Rembrandt relies on Framebuffer Objects (fbo) and if the driver is not able to provide them, there will be no Rembrandt on that platform. But from the full log message : Warning: detected OpenGL error 'invalid operation' at After Renderer::compile RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd PixelBufferCocoa :: realizeImplementation not implemented yet the fbo setup error message may disappear if I lower my requirement (float textures, number of attachment). But no promises ( status= 0x8cdd means FRAMEBUFFER_UNSUPPORTED_EXT ) Regards, -Fred -- 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 feedback (was: Project Rembrandt - next steps)
Hi Olaf, maybe I can tell you from a screenshot. From memory, we need at least GL_ARB_framebuffer_object and float_texture I don't know what extension or declaration is required to have unsigned int uniforms (osg_FrameNumber in src/Main/CameraGroup.cxx) Regards, -Fred - Mail original - De: Olaf Flebbe Hi Fred, I did see a composited view in the window (with different views at the edges of the window). Isn't the FBO necessary for this? May the allocation of just one of the FBO's fail? Do you know which Extension has to be present? My system announces to have: GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB Olaf Sorry Yves, I have no idea. This error message seems to imply that not all of OSG has been implemented by the Cocoa adapter. But I don't think Rembrandt would work with a Pixel Buffer. Rembrandt relies on Framebuffer Objects (fbo) and if the driver is not able to provide them, there will be no Rembrandt on that platform. But from the full log message : Warning: detected OpenGL error 'invalid operation' at After Renderer::compile RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd PixelBufferCocoa :: realizeImplementation not implemented yet the fbo setup error message may disappear if I lower my requirement (float textures, number of attachment). But no promises ( status= 0x8cdd means FRAMEBUFFER_UNSUPPORTED_EXT ) -- 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 -- 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 Thorsten, De: thorsten i renk I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Yes please. Or if someone could just help in creating an effect structure thatone can switch these things on and off so that installing the lightfields doesn't have to overwrite everything and that it would be on GIT? Then we can worry about how to merge later? Lightfields would work optionally, there's no fundamental obstacle here. I know there's the idea to get everything perfectly merged in an elegant way by factoring out light and haze functions, but I'd be happy with a simple optional structure now and the rest later. Be sure that I am extremely interested in merging your work into Rembrandt. It is just too early for me, and as the discussion raised the point of the compatibility with older hardware, the mockup (from by clone) can't be merged as is. So, in order to have the less disturbing migration path as possible, things will take even more time. But i will come back to you to see how decoupling light and haze can be done in the future framework. It's getting somewhat frustrating... Not so much for myself, but for others who want to try it, and it's starting to look silly when I have to tell everyone who is interested 'Sorry, it's ready since a month ago, but we haven't been able to put it on GIT yet, so you still need to go through a tricky manual installation process'. Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Technically it could, but at the expense of forcing everyone to use lightfield shaders. It overwrites for instance the default terrain and model shaders. The reason why this is implemented in that way is that I have no clue how an effect file should be properly structured. I can change an existing effect file to insert new property-to-unifrom mappings, I can change the filename of the shader to be used, but my attempts to do more have so far gone terribly wrong and broken the effect. So what needs to be done for a clean commit is: * rename the special shader files where they overlap with default files * add conditionals to the effect files that if skydome scattering shader is on the lightfield files should be used, otherwise the defaults as they are (* not essential, but currently true camera altitude above MSL is obtained from Nasal and written into the tree - I'm fairly sure we have it somewhere better, I just don't know where) It's not much work, but it requires some better knowledge of how effect files work. Which is the point where I need help. I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. As I received no objections, I will commit my addition to simgear later in the day. You'll be warn ;-) Regards, -Fred -- 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 Curt, De: Curtis Olson On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier wrote: As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. As I received no objections, I will commit my addition to simgear later in the day. You'll be warn ;-) Speaking not-as-a-git-guru, would it make sense to push the rembrandt changes into a separate rebrandt branch initially and keep that merged with the next branch? It would make it easier for developers to check out that branch and build it and if things look pretty reasonable we could merge things into next? Just trying to be helpful here, and not make things any more complicated. ... and keep that merged with the next branch I don't understand what you mean. Do you want me to commit the work to a new Rembrandt branch and then merge it to the next branch ? I am only speaking of enhancement to the effect system and the new light animations that will be useless until the right code is committed in flightgear. The only noticeable thing will be the point sprite size increase for runway lighting that I find way more realistic. Regards, -Fred -- 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
But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your What I always do, before pushing an update for the next branch is: As stated previously, a code that is not run is unlikely to be debugged. To avoid branch glitches and given the estimated risk of these changes, I decided to commit them to next. People are requested *not* to use the features introduced until noticed because there is no Rembrandt code in the flightgear repository. Regards, -Fred -- 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] [Rembrandt] Help request
Hi, in preparation to the introduction of Rembrandt in the main branch, we should ensure that effect will be compatible with the current renderer. For that, I added a new property to preferences.xml and modified Effects/model-default.eff to test this new property. It will be also available to animations to, for example, conditionally select the fake shadow when the current renderer is in action. So may I ask a kind soul with write access to the data repository, or capable of submitting a merge request, to review all effect files and add the test of the new property to every technique of every effect, and add a new predicate to technique not having one for the moment. The code snippet to add to an existing predicate is : predicate and +not + property/sim/rendering/rembrandt/property +/not property/sim/rendering/shaders/generic/property or The code snippet to add a new predicate is : /technique technique n=11 + predicate + not + property/sim/rendering/rembrandt/property + /not + /predicate pass lightingtrue/lighting As an example, I modified Effects/model-default.eff : https://gitorious.org/fg/fgdata/commit/e9fbd620bb71e94d6589a15be1448511f21bacb6 Thank you -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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 feedback (was: Project Rembrandt - next steps)
De: Torsten Dreyer Hi Fred, today, I tried Rembrandt on two Linux machines, both running 64bit openSUSE 12.1 (this is Linux) with nvidia'd driver 295.20. FlightGear ist started in windows mode. 1.) My Notebook having a Intel dual core@1.6GHz, 4GB RAM and a GeForce Go 7400 with 256MB RAM. FlightGear starts, after some time, I see the four corners rendering the stages and the main scene but with strange colors. After just a few seconds seconds, my kernel panics and I have to reboot. 2.) Our big, fat presentation machine with 2 CPU, 24 cores, 8GB RAM, currently one nvidia GTX460 with 1GB RAM. FlightGear starts without an issue and without any noticable frame rate impact (limited to 60fps due to sync-to-vblank). I can see the aircraft shadow and the shadow of some scenery objects (not all, though). The aircraft shadow seems to be disapearing depending on the view angle. The rendering stages can be hidden with the new item in the debug menu. Can you produce screenshots that exhibit the glitches you see on your second machine ? For your 1st machine, you can try to lower the value of /sim/rendering/shadows/map-size in preferences.xml *before* you start fgfs (changing in the property browser has no effect) Regards, -Fred -- 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
De: Torsten Dreyer Am 02.03.2012 19:03, schrieb Frederic Bouvier: Now that release 2.6 is out, perhaps it is time to discuss further developments concerning project Rembrandt. Although it may already produce pretty images when used by a talented designer (see for example the P92), it is however, not usable by most people. The Wiki page summarizes the list of things to do. For wider use, we must first convert the shaders to 'Rembrandt' rules. It also seems there are problems with shadows in multi-threaded modes. Finally, the multi screen should be reviewed (I'll leave spherical projection and stereo for another time). The other points are are less important and can be treated in the next branch. Remains the problem of conversion of aircraft models. One of the constraints of Rembrandt is that each model should be modified, or at least reviewed: * Remove the fake shadow * Remove ambient occlusion from textures * Register all transparent surfaces * Review the use of emissive colors Maybe we need to create a label Works with Rembrandt and report models that do not comply. thoughts ? The best time for adding such a huge change is at the beginning of a release cycle - which is now. Adding a tag marking the initial commit might be a good idea, though. If Rembrandt breaks nearly all aircraft, maybe we should also split off aircraft from FGDATA before/not later than the start of Rembrandt? The aircraft rating system can hold a Rembrandt-ready label. Is there any chance to make Rembrandt switchable (on/off) at startup? That should be doable, but not done for the moment. Changes are located in CameraGroup.[ch]xx and Renderer.cxx for the flightgear side, in sgmaterial.lib for the simgear side and in Effects/ and Shaders/ for the data side, not speaking of any model converted or enhanced with lights. The main problem to solve would be the duplication of resources. How a plane or another model would be compatible to both renderer ? But just curious : how many of you reviewed the current code ? Regards, -Fred -- 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
- Mail original - De: Torsten Dreyer tors...@t3r.de Am 03.03.2012 12:33, schrieb Frederic Bouvier: But just curious : how many of you reviewed the current code ? n+1 Just checked out your project/rembrandt branches. Code compiles fine on 64bit openSUSE 12.1 with OSG from trunk. Running fgfs spits out many messages, most prominent are: can't find Effects/ssao.eff can't find Effects/blur.eff can't find Effects/blur.eff can't find Effects/sunlight.eff can't find Effects/blur.eff can't find Effects/blur.eff and dozens of no image file, maybe the reader did not set the filename attribute, using white for type '2d' on '', in /technique[11]/pass[0]/texture-unit[0] The screen stays white with three black corners (top right, bottom right and bottom left). No splash screen. I can exit after some time with (Esc)-(Enter). GPU is GeForce Go 7400 with latest driver. Anything I can do to help debugging? Nothing wrong with all of that (or at least it is expected). Did I mentionned I wrecked the splashscreen that doesn't appear in windowed mode and badly flash in fullscreen. Otherwise, the messages are expected for the moment. Ensure you checked out project/rembrandt in simgear, flightgear and fgdata, and be patient until the scene appears. It doesn't support multi-threading mode (in preferences.xml) but that don't prevent to have an image Regards, -Fred -- 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
De: ThorstenB Also, the project is quite good in finding issues, once new stuff is in git. But, generally we are not so good in fixing problems then. Notoriously, everyone has just too little spare time ;-), so a lot of issues just starve in the tracker. And with hard-core OSG stuff, there's even fewer people than usual who could help anyway. So, make an honest estimate of how much work is really left, including fixing reported issues, and whether you have the time to complete this in the next months. Or whether you maybe need to bail out in a few weeks for personal reasons, and we might be getting stuck (your wife/girlfriend isn't pregnant or something? :-D ). If we are certain that everything will be well and stable within reasonable amount of time, then it should go into next. Otherwise, we should think about maintaining separate branches (one of the main advantages of git anyway). Indeed, the latter would probably mean it would not be part of the August release. The key question is: would it be ready? As I said in my first post, I don't consider the code as fully ready for prime time. I made shortcuts to demonstrate the feasibility of the renderer and many things no longer works or at least should be reviewed again. I can't promise I won't be hit by the proverbial bus, but as long as the project is endorsed by the community, there is no reason I bail out in the next months. As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. That may take time though. Enough time to split the aircraft repository ;-) Regards, -Fred -- 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] terragear not building and installing genapts
Maybe there is a missing dependency that silently discard genapt from the build Regards, -Fred - Mail original - De: Jason Cox À: flightgear-devel@lists.sourceforge.net Envoyé: Samedi 3 Mars 2012 23:41:41 Objet: [Flightgear-devel] terragear not building and installing genapts Hi all, just checking out the lattest code as of 15min ago and found that genapts is not being built/installed. I checked my build process and found no errors and the program was missing can anyone help? localhost terragear-cs # make install [ 3%] Built target poly2tri [ 10%] Built target Geometry [ 15%] Built target Polygon [ 16%] Built target Output [ 18%] Built target gshhs [ 19%] Built target gshhs_debug [ 20%] Built target DEM [ 21%] Built target demchop [ 21%] Built target Array [ 22%] Built target fillvoids [ 24%] Built target HGT [ 25%] Built target hgtchop [ 26%] Built target srtmchop [ 27%] Built target testassem [ 28%] Built target deminfo [ 30%] Built target raw2ascii [ 44%] Built target vpf [ 46%] Built target TriangleJRS [ 47%] Built target e00 [ 48%] Built target e00lines [ 49%] Built target findcorners [ 50%] Built target photo [ 51%] Built target wgs84offset [ 53%] Built target shape [ 54%] Built target noaa-decode [ 55%] Built target shape-decode [ 56%] Built target tgvpf [ 62%] Built target Terra [ 65%] Built target terra_bin [ 66%] Built target terrafit [ 67%] Built target tguserdef [ 68%] Built target test_array [ 69%] Built target test_hgt [ 70%] Built target Optimize [ 71%] Built target teste00 [ 72%] Built target landcover [ 73%] Built target test_landcover [ 74%] Built target dbfadd [ 75%] Built target dbfcreate [ 76%] Built target dbfdump [ 77%] Built target shpadd [ 78%] Built target shpcreate [ 79%] Built target shpdump [ 80%] Built target shptest [ 81%] Built target shputils [ 82%] Built target vpf-dump [ 83%] Built target vpf-summary [ 84%] Built target vpf-topology [ 87%] Built target Osgb36 [ 88%] Built target testosgb36 [ 89%] Built target fgfs-tools-client [ 90%] Built target fgfs-tools-server [ 92%] Built target Triangulate [ 94%] Built target Clipper [ 95%] Built target testclipper [ 96%] Built target GenOutput [ 97%] Built target Match [ 99%] Built target fgfs-construct [100%] Built target fgfs-master Install the project... -- Install configuration: Release -- Up-to-date: /usr/local/bin/gshhs -- Up-to-date: /usr/local/bin/gshhs_debug -- Up-to-date: /usr/local/bin/demchop -- Up-to-date: /usr/local/bin/hgtchop -- Up-to-date: /usr/local/bin/srtmchop -- Up-to-date: /usr/local/bin/fillvoids -- Up-to-date: /usr/local/bin/testassem -- Up-to-date: /usr/local/bin/deminfo -- Up-to-date: /usr/local/bin/raw2ascii -- Up-to-date: /usr/local/bin/e00lines -- Up-to-date: /usr/local/bin/photo -- Up-to-date: /usr/local/bin/wgs84offset -- Up-to-date: /usr/local/bin/findcorners -- Up-to-date: /usr/local/bin/shape-decode -- Up-to-date: /usr/local/bin/noaa-decode -- Up-to-date: /usr/local/bin/tgvpf -- Up-to-date: /usr/local/bin/terrafit -- Up-to-date: /usr/local/bin/tguserdef -- Up-to-date: /usr/local/bin/test_array -- Up-to-date: /usr/local/bin/fgfs-tools-server -- Up-to-date: /usr/local/bin/fgfs-tools-client -- Up-to-date: /usr/local/share/TerraGear/default_priorities.txt -- Up-to-date: /usr/local/bin/fgfs-construct -- Up-to-date: /usr/local/share/TerraGear/usgsmap.txt -- Up-to-date: /usr/local/bin/fgfs-master localhost terragear-cs # Jason Cox -- 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 -- 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] Project Rembrandt - next steps
Now that release 2.6 is out, perhaps it is time to discuss further developments concerning project Rembrandt. Although it may already produce pretty images when used by a talented designer (see for example the P92), it is however, not usable by most people. The Wiki page summarizes the list of things to do. For wider use, we must first convert the shaders to 'Rembrandt' rules. It also seems there are problems with shadows in multi-threaded modes. Finally, the multi screen should be reviewed (I'll leave spherical projection and stereo for another time). The other points are are less important and can be treated in the next branch. Remains the problem of conversion of aircraft models. One of the constraints of Rembrandt is that each model should be modified, or at least reviewed: * Remove the fake shadow * Remove ambient occlusion from textures * Register all transparent surfaces * Review the use of emissive colors Maybe we need to create a label Works with Rembrandt and report models that do not comply. thoughts ? Regards, -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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
De: Anders Gidenstam On Fri, 2 Mar 2012, Frederic Bouvier wrote: * Register all transparent surfaces Just a quick question: Doesn't OSG already detect translucent meshes and treat them differently from the rest during rendering? Hence, couldn't this classification be done more or less automatically and only require manual intervention in special cases? (Maybe I misunderstood what you meant above but to me it does seem like you are suggesting that all all such objects should be enumerated in the model XML file - something that IMO seems both error-prone and inconvenient. There must be a better way.) Do I look forward to implement cockpit lighting with real lights. OSG doesn't detect transparent surfaces. It offers Render Bins that allow to control rendering order. Primitives put in RenderBin are sorted by their OpenGL state only and are for opaque objects. Primitives put in DepthSortedBin are sorted back to front and are used for transparent objects. If you put opaque objects in a transparent bin, it has only a performance impact, but has no effect on the rendered scene. The inverse is not true. Now something has to put primitives in the right bins. This is done by the loader. It use material color and texture to do that : if an alpha channel is found and has values less than 1.0, the object goes to the transparent bin. But usually you use few texture images to map the entire model. You can have the windshield in the same texture than the wings. With the loader strategy, the windshield is put in the transparent bin, which is good, and also the wings, which is not so good in the context of Rembrandt. Rembrandt use deferred rendering and the technique only apply to opaque surfaces. For transparent objects, it fallbacks to traditional rendering. If all objects are flagged as transparent, it defeats the purpose of Rembrandt. Transparent objects are detected by their membership to the transparent bins, so it is important to have the right classification. To override the selection made by the loader, Rembrandt use effect declaration to set the bin. Effects for opaque objects use alpha testing, and effects for transparent objects will use alpha blending after all lights are rendered. Transparent objects don't cast shadows and are not lit by additional lights. So registering all transparent surfaces means setting a effect for transparency to those surfaces, regardless of the presence of an alpha channel in the texture of the object. Regards, -Fred -- 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] Stuart and Curt, live on FSBreak!
Curt and Stuart are promoting FligthGear live right now! Do they have a recording available for download ? Try : http://fr.twitch.tv/fsbreak/b/309747803 -Fred -- 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] Jenkins thrashing...
Hi Gene, It appears that the windows-release target rebuilds _everything_ regardless of whether or not it's necessary. This build gets triggered multiple times for some reason and due to disk thrashing, renders the machine basically unusable until it's done. Since this machine also hosts the VM that runs my mail server, you can imagine how annoyed I get. :) I've disabled the MSVC build host until this can be resolved. (Fred?) I see you disabled the Windows-release task that is fine until we start a new release cycle. The MSVC machine is also disconnected. Is it intended ? I think the problem is that a build is redone every time fgrun is changed because there is no release branch, and it rebuilds everything because Jenkins touch files when it copies artifacts. One solution could be to split the task : one for building binaries, one for packaging. Regards, -Fred -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RE : Looking at a nice project from outside
I just don't understand why these submissions are not just refused with a baked reply. You all are burning yourself and then will blame the community as a whole in anger. Please enforce the rules ! Regards, -Fred Gijs de Rooy gijsr...@hotmail.com a écrit : Oliver wrote: Goind to post it again on the newsletter and on the forums. Made it a Forum announcement, so it shows up on top :) Anyway, as RTFM (Read The FlightGear Manual) is clearly not the strongest part of our community, I doubt it will help much. I've got exactly the same problem with the livery database: made a nice list of criteria/rules, and what do I get? Packages without thumbnails, non-realistic liveries etc. It's just the way it is I guess... -- 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] RE : Did anyone test the 2.6.0 release on Windows 7 64 Bit?
Hi, I am away from my computer so I can comment specifically any point, but I have few questions : 1. did these problem occurs in the release candidates or are specific to the final version ? 2. We know that you didn't install in Program Files but we don't know where exactly. Could there be a special german character in the path, or any non purely ascii character ? 3. what happen if you install in Program Files as suggested by the installer ? 4. Did you install the 64bit binaries or have forced the 32bit install ? 5. Can you find the flightgear.org directory in \Users and check that fgrun.prefs has write privileges ? The save button is only there to save another set of options and it's normal that a file name is requested. For the current set of options, it goes to flightgear.org\fgrun.prefs but this file should be writable. It is created at install and contains the default path that you shouldn't have to set by hand. Regards, -Fred kreuzritter2000 kreuzritter2...@gmx.de a écrit : Yesterday i tried to run the new FlightGear version on Windows 7 64 Bit Prof and it run awful. There are several fatal major bugs in this release i never had before, though i used WinXP 32 Bit in the time of the older releases before and not Win7 64 Bit, so i am not sure if this is win7 related. I installed FlightGear in another folder than C:\Programs files as admin and run FlightGear with normal user privileges. This might be an important information to reproduce some of the bugs. I am here on a linux system now, so i can't test it again, but here is a small listing of some of the bugs and usability issues i can remember from yesterday: 1. FGRun can't find the progamm, scenery and data folders, i have to set them manually at the first start. That shouldn't be the case, FGRun should know where to search for the files after FlightGear has been installed. An inexperienced computer user would give up here and uninstall FlightGear. 2. It is impossible to set the Terrasync folder in FGRun, the button to set the terrasync folder has no function. The terrasync mode can't be used when there is no directory set. BTW, terrasync should use the user directory by default, it's evil to use the progamm folder for that when a user has limited privileges on that directory. Usability hint: When there is a default directory set there is no need to annoy the user with asking the user for a directory location. I suggest to use %APPDATA%/Roaming/flightgear.org/terrasync as default location. If users don't like that, they should be able to change it after installation. But setting a default location is a must in my opinion to improve usability. 3. FGRun doesn't use the user folder to save the settings, instead it asks me where to place it. That's bad usability. 3. Several 3d Models (777-200, F-14b and others) aren't displayed. They're missing in the sim and in FGRun. 4. In flightGear the 3d cockpit controls do not work. For example in the b1900d clicking on them has no effect. In the past on earlier releases that worked. 5. Worst Bug. The sim has strange flickering effects, the result is that the clouds are not displayed. They flicker sometimes up, but only in 1-4 of 60 frames. (My system: Geforce GTX 550 Ti + driver version 280.26) The console shows some error message about OpenGL and a function, but the text is cut, so there's no real info about it. 6. BTW this is only a minor usability issue, but i'll mention it here for for the sake of completeness. FGRun has long loading times to display the 3d aircraft models. In my opinion that is too long for a selection list like that. In my opinion bugs 3, 4 and 5 are the worst in that list and 1 and 2 are serious usability issues all of them harm the reputation of FlightGear more than a new release version with new features do good to it. I can't recommend to offer FlightGear in that condition for download for windows users. Why where there no release candidates or beta releases? Bad release candidates or beta releases do not harm a project so badly like a real release with fatal bugs does. Best Regards, Oliver C. -- 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 -- 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.
Re: [Flightgear-devel] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. FWIW, I saw with gDebugger that the sky dome is made of more than 23000 vertices, even if a small amount of them are really displayed on screen. In Rembrandt, several pass are done on 1/16th of the size of the screen (1/4th of each dimension), relying on the mag filter to cover the whole screen. This is the case of the blur pass in the AO or Bloom effects. Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Pushing most of the haze shader computation from the vertex to the fragment level would seem to suggest an approximately constant cost for the haze for the same view regardless of scenery complexity since the number of hazy fragments remain about the same. Thanks for the explanations - that was *really* helpful to understand what is going on. FWIW, I saw with gDebugger that the sky dome is made of more than 23000 vertices, even if a small amount of them are really displayed on screen. In Rembrandt, several pass are done on 1/16th of the size of the screen (1/4th of each dimension), relying on the mag filter to cover the whole screen. This is the case of the blur pass in the AO or Bloom effects. BTW, in my other terrain engine project, the sky is drawn with a quad (4 vertices at the corners of the screen). The view direction is computed in the vertex shader and then interpolated in a varying and renormalized in the fragment shader. That way there is no wasted computation (except the region overdrawn by the terrain, but that could be optimized with a stencil buffer) -Fred -- 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] FG scam resurfaces...
And they even have an old screenshot of FGSD showing LFPX (the airfield where I used to fly in RL) ROFL -Fred -- 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] fgdata version in master branch
Hi Robert, De: Robert Hi everybody, since one or two weeks I have the following problem: When I start fgfs it tells me that it needs version 2.7.0 of fgdata and quits immediately. I am using SimGear/Flightgear next branch, and fgdata master branch. After maually changing the version-file in fgdata from 2.5.0 to 2.7.0 everything is okay. It would be nice if someone could change the version number to 2.7.0 in the master branch. Already done for awhile. See yourself : https://gitorious.org/fg/fgdata/blobs/master/version https://gitorious.org/fg/fgdata/commit/49283115c5042d42c68939b2942eeda7760df5fc Regards, -Fred -- 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] LaRCsim broken?
You can try to switch on ENABLE_UIUC_MODEL too as one of the undefined relates to uiuc -Fred - Mail original - De: D-NXKT Objet: [Flightgear-devel] LaRCsim broken? Hello Fred, thanks for your reply. I wasn't aware of this option. I assume configuring fg with Cmake means setting ENABLE_LARCSIM:BOOL=ON in CMakeCache.txt. After doing this LaRCsim is compiled with some warnings but during linking I get the following errors: Linking CXX executable fgfs ../FDM/libfgFDM.a(LaRCsim.cxx.o): In function `FGLaRCsim::copy_from_LaRCsim()': LaRCsim.cxx:(.text+0xad0): undefined reference to `aircraft_' LaRCsim.cxx:(.text+0xb91): undefined reference to `aircraft_' LaRCsim.cxx:(.text+0xbe7): undefined reference to `aircraft_' LaRCsim.cxx:(.text+0xc19): undefined reference to `aircraft_' ../FDM/libfgFDM.a(LaRCsim.cxx.o): In function `FGLaRCsim::update(double)': LaRCsim.cxx:(.text+0xf03): undefined reference to `aircraft_' ../FDM/libfgFDM.a(LaRCsim.cxx.o):LaRCsim.cxx:(.text+0x1660): more undefined references to `aircraft_' follow ../FDM/libfgFDM.a(ls_step.c.o): In function `uiuc_init_vars': ls_step.c:(.text+0x1b): undefined reference to `uiuc_init_aeromodel' ls_step.c:(.text+0x26): undefined reference to `uiuc_initial_init' ... ... ... Is there something else I should know? Will LaRCsim be on or off in the upcoming release? (And how do I reply to messages correctly? I'm not familiar with mailing- lists. Just found your message in Flightgear-devel Archives.) Thanks for your effort D-NXKT -- Make sure that LaRCsim is selected when configuring fg with Cmake Regards, -Fred - Mail original - De: D-NXKT D_NXKT@... À: flightgear-devel@... Envoyé: Mardi 31 Janvier 2012 01:02:27 Objet: [Flightgear-devel] LaRCsim broken? Hello, could it be that LaRCsim is broken or switched off? I noticed that the LaRCsim planes don't work since a while (for me). Following message appears during the start procedure: Fatal error: Unrecognized flight model 'larcsim', cannot init flight dynamics model. Tested with ASW20, wrightFlyer and airwaveXtreme150. FlighGear, SimGear and fgdata are up to date (next-branch). -- 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 -- 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] LaRCsim broken?
Make sure that LaRCsim is selected when configuring fg with Cmake Regards, -Fred - Mail original - De: D-NXKT d_n...@yahoo.de À: flightgear-devel@lists.sourceforge.net Envoyé: Mardi 31 Janvier 2012 01:02:27 Objet: [Flightgear-devel] LaRCsim broken? Hello, could it be that LaRCsim is broken or switched off? I noticed that the LaRCsim planes don't work since a while (for me). Following message appears during the start procedure: Fatal error: Unrecognized flight model 'larcsim', cannot init flight dynamics model. Tested with ASW20, wrightFlyer and airwaveXtreme150. FlighGear, SimGear and fgdata are up to date (next-branch). -- 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
