Please test the 3.6 RC

[Warty]

Hi Warty, For the new afterburner effect from Thorsten, there is a known problem with the GNU/Linux radeon open source video drivers, which AMD is slowly working on to fix (I hope). To see if the problem is related to what I see, could you try the following change in FGData: . . .

Well, that's easy for you to say, Bugman I'm guessing that this is about changing source code or the compilation process?? I just got it as a completed disk image (.dmg) via the link at the OP. I'm ok with creating modifying XML and nasal files but this doesn't look like that to me The only occurrence I can find of a "thrustflame-ALS.frag" file is in the F-15 folder of my 3.4 version. Sorry I can't help as it stands - any other suggestions?

Cheers, Warty

[bugman]

I'm guessing that this is about changing source code or the compilation process??

It should be in one of the data files of FGData (in $FG_ROOT). In this case, I guess that the whole FlightGear binaries and data files are all together in that *.dmg file.

I just got it as a completed disk image (.dmg) via the link at the OP. I'm ok with creating modifying XML and nasal files but this doesn't look like that to me The only occurrence I can find of a "thrustflame-ALS.frag" file is in the F-15 folder of my 3.4 version. Sorry I can't help as it stands - any other suggestions?

I guess you'll find it in the *.dmg file. Do you have the ability to go in there and edit files? I think I have done that before on my Mac test machine (which unfortunately I cannot use for FG testing). If so, that would be the way to test it. It will be in some directory + Shaders/thrustflame-ALS.frag. Unfortunately I don't know what that base directory would be, so it might take a bit of searching.

Cheers,

Edward

[enrogue]

Warty - on Macs the FGDATA directory is a part of the App directory structure:

Say you have the FlightGear App installed in /Applications on your Mac - the FGDATA directory would then be:

/Applications/FlightGear.app/Contents/Resources/data

you can right click the app icon & select 'show contents' which will put you in the .app directory in finder

the fragment shader file that Edward is talking about is just a text file - you should be able to edit it with text editor - I'm an old Unix geek, so I use vi

[Warty]

That seems to have fixed it, by commenting out the following lines in
FlightGear.app/Contents/Resources/data/Shaders/thrustflame-ALS.frag

Code: Select all

//float Noise3D(in vec3 coord, in float wavelength);
//float Noise2D(in vec2 coord, in float wavelength);


and

Code: Select all

//if (use_noise ==1)
//   {
//   noise = Noise2D(vec2(pos.x - osg_SimulationTime * 30.0 , d_rad), noise_scale);
//   }


Cheers!

[Hooray]

Unfortunately I don't know what that base directory would be, so it might take a bit of searching.

Code: Select all

var path=getprop("/sim/fg-root");
print( path );


Should that not work on Mac, too ?

[bugman]

That seems to have fixed it, by commenting out the following lines in
FlightGear.app/Contents/Resources/data/Shaders/thrustflame-ALS.frag

Great So this affects both the GNU/Linux AMD radeon open source driver and the Mac OS X Intel Iris driver. Hopefully Thorsten reads this thread and knows a quick workaround (maybe loading different *.frag files for certain blacklisted graphics drivers?).

Cheers,

Edward

[Hooray]

do you actually need to remove all references to Noise2D(), or does it suffice to change the conditional block to if(0) or even just stop calling the function ?
Knowing that, would tell us if there is a workaround, such as using a different function/implementation for creating noise, or if this is a linking problem ?
Also, are there are glsl errors shown anywhere ?

[bugman]

do you actually need to remove all references to Noise2D()

Yes, because this is a register allocation problem - more registers are being asked for than exists on the GPU. Normally the graphics driver should handle this register problem, but some drivers don't and the effect fails. So the initialisation part must be nuked. I guess it's the combination of Noise2D, Noise3D, and the afterburner effect which pushes the register requirement too far.

Regards,

Edward

[Hooray]

if registers are spilling, the question is where exactly - i.e. the expression after the conditional could be easily moved to a sub-routine that would get its own execution context. But if it's already the two prototypes at the top of the file, the problem is much more serious - and one would have to look at the whole compilation unit.
Otherwise, my suggestion would be to simplify complex expressions and introduce/use constants or pre-cache things to see if that makes any difference. Equally, an array with pointers may be easier to deal with for a buggy compiler than separate variables of the same type

llvm is generally a very robust piece of software, so it should be possible to come up with a workaround that works for people, without having to patch shaders - if in doubt, we could provide separate shaders, or even just use pre-processor flags, matched against the glsl-compiler string (about dialog)

https://bugs.freedesktop.org/show_bug.cgi?id=75276

[bugman]

But if it's already the two prototypes at the top of the file, the problem is much more serious - and one would have to look at the whole compilation unit.

This bug can only be solved by commenting out the two prototypes, so, yes it is serious The other lines naturally have to be commented out after doing this.

Regards,

Edward

Edit: Note that AMD have confirmed that there is a bug in their graphics driver here (it was mentioned on the OSG mailing lists, from memory)! I didn't realise the Intel Mac driver was also problematic.

[Richard]

There is now a fix for the F-14 in FGAddon 3.6 release branch r923; I'd messed up the pathnames so it relied on the effect file from the F-15

This may well be in addition to the driver problems.

[KL-666]

Yet another day flying 3.6, and i found out how MP crashes the program. I find it weird that MP can crash a program at all. Just think of the possibilities for a malignant MP user. But anyway, here are the findings.

1) Cockpit/interior view can crash the program. I crashed and could not restart the program at a certain airport where an a330 spawned. Only after setting LOD cockpit/interior to 0, i succeeded.

2) 3.6 is extremely sensitive to having "conflicting" aircraft. When a erj-195 appeared at an airport i was at, i crashed and could not restart there. Until i removed the embraer-family, leaving the embraer-195, then i could restart again at that airport.

Still the terrasync problem remains, that it does not load new objects at an airport you have been to already. Today i had two cases where only after advising to delete terrasync data, they could see new buildings at an airport they have been to before.

Kind regards, Vincent

[wkitty42]

@KL-666: sounds like you are running into the existing problem of meeting craft that have more detail than your system can handle... there are numerous folks that have to remove detailed craft like the 747 and up for this reason... they have to fly amongst them with them looking like the yellow glider...

[KL-666]

Sorry wkitty, system is not at all a problem here. i7, 12gb, gtx 670 mx. Please learn for the better of flightgear from the test work i do.

Kind regards, Vincent

[legoboyvdlp]

Actually, wkitty you can replace the glider with any model you want. KSFO terminal 2. The daedelus. The f-14. Whatever