Re: [Flightgear-devel] Terrain Haze v1.3
The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. I don't know, it doesn't strike me as consistent. There are two control structures here: Inheritance allows to replace a generic effect with a particular effect given terrain type, for instance it allows to use some shader for terrain, but a special shader for forest. Technique allows to control overall detail level - earlier (more detailed) techniques take precedence before later (usually less detailed) techniques. The problem at hand is that the parsing creates an inconsistent state - the rule what shader is to be run is determined by technique, but the texture it gets to use is determined by inheritance even if the technique numbering says inheritance doesn't play a role. A higher number technique which is correctly recognized as 'not to be used' still gets to set parameters of the technique which actually is used. Needless to say, this is hellishly difficult to figure out (it took me four hours to understand) because there is nothing wrong at all with the structure of terrain-default.eff and yet things don't work. So, for me the expected behaviour would be that technique beats inheritance - special effects can override generic effects for certain landclasses if their technique is lower, but all their information is discarded if the technique is not lower. Forgot to mention the fact that runways have the runway effect applied to them from materials.xml, hence they obey that one and not terrain-default. That's where you are wrong - technique actually beats inheritance for everything except texture unit number (which is what causes the problems) - runways are shaded with what is specified in terrain-default.eff when it comes with a lower technique number than what is specified in runway.eff (that is the case here). The system correctly uses terrain-haze-detailed.* to shade the runway, just the snow texture gets overrideen by what is specified in runway.eff. This is fixable by changing the snow texture unit number in the terrain default, so it doesn't get overridden by the runway settings, or by changing the runway effect itself, and adding another texture unit there for the snow, and an altered technique 4 that caters for the differing texture unit numbers. I know how to fix it, but I don't know how to prevent the next person adding effects to screw it up all over again. The problem is finding an unused texture unit which nobody will overwrite anywhere in any effect file down the line. My favoured solution would be to make the parsing consistent so that shader to be used and texture to be used are taken from the same technique, but if that can't be done or should not be done for some reason I don't yet understand, maybe we can come up with general guidelines about what texture units are assigned for what (basic texture, noise, normal map, alternative textures, snow,...) so that, say, texture unit 5 is always snow and then there's no problem either. * Thorsten -- 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
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Thus if runway inherits from terrain the actual runway effect as seen by flightgear gets a technique 4 of its own (inherited from the terrain effect). So when the skydome shader is active, it's the technique 4 in this runway effect that is active, which then uses the textures specified in the runway effect, as it's supposed to. Regards, Emilian -- 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
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy? Or what is the use of the current setup in which higher techniques overwrite lower techniques? * Thorsten -- 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
On Wednesday 02 May 2012 07:55:19 Renk Thorsten wrote: No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy? Or what is the use of the current setup in which higher techniques overwrite lower techniques? * Thorsten Every other effect written so far. Better explanation: Think of the parent and the child effect as two property trees. At runtime they get merged, with any paths in the child effect overwriting the same paths in the parent, all under the heading of the child effect. The lower techniques override higher techniques. The functionality is to enable you to use different options in specific conditions that are present in the predicate section of each technique. As you are using them in the terrain effect. It's not the effects that change at runtime between those specific conditions, it's a different technique of the same effect that's used. The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Say you have shaders active, the default effect has a technique that specifies some default shaders to be used. Now you make your own effect, but you want to use different shaders in the same situation; in that case you add a lower numbered technique in your new effect, that by the order of precedence (lower numbers before higher numbers) trumps the technique used in the default, and this new technique specifies the different set of shaders that you want. By putting the sky-dome technique in a low enough place, you ensure that your new technique will not be overwritten and will be lower placed than any other in the child effects' trees, ensuring that those shaders are activated when the sky-dome is active, and that they take precedence over less strict conditions that would activate some other set of shaders/options in one of the other effects. Keep in mind though, that they will then use the merged parameters as they're specified in the child effect (this includes textures). Important note: the *texture n=x* numbers in the parameters section can be as high as you need them, but the *texture-unitunity/unit* numbers in the technique section should be kept =7 as those are the actual texture units as seen by the shader, and some impplementations oanly have 8 texture units available. *y* and *x* don't have to match. In fact you can get very creative and have 3 different *texture n=x1*, *texture n=x2*, *texture n=x3* in the parameters section that are assigned to the same *unity/unit*, each in a different technique, according to different predicates. Regards, Emilian -- 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
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. -- 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
On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers 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
On Wednesday 02 May 2012 10:53:31 Frederic Bouvier wrote: On Wednesday 02 May 2012 11:43:28 Emilian Huminiuc wrote: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same condition. Actualy this should read: The default effects usually specify their techniques with higher numbers to allow any inheriting effect to insert their own techniques below them, techniques that get activated by the same or any stricter condition. But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers Regards, -Fred I would say it's intended and it's very powerful. We only need to be careful with technique numbers. Take a look at how I worked around the binormal/tangent generator crashing for objects that are not textured in the model-combined effect: by enabling the generator for that technique only in child effects that are supposedly applied *only* to textured objects. All these with only a couple of xml entries, and not requiring a different complete effect. (Ref: Docs/model-combined.eff/)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 'Black model problem'
So far we had: start with skydome shader on and landmass set to 4: - models appear black and are not shaded properly Click on landmass slider without changing the value: - modelss jump to proper shading I've made one more observation: Do the above at noon. Then change to dawn - models remain stuck with bright daylight shading It seems to be a problem in passing parameters to the shader, apparently at least some of the parameters aren't updated by frame but only when specifically triggered. As to the underlying cause, I remain in the dark though... * Thorsten -- 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] 'Black model problem'
On Wednesday 02 May 2012 09:07:57 Renk Thorsten wrote: So far we had: start with skydome shader on and landmass set to 4: - models appear black and are not shaded properly Click on landmass slider without changing the value: - modelss jump to proper shading I've made one more observation: Do the above at noon. Then change to dawn - models remain stuck with bright daylight shading It seems to be a problem in passing parameters to the shader, apparently at least some of the parameters aren't updated by frame but only when specifically triggered. As to the underlying cause, I remain in the dark though... * Thorsten Using tied properties as uniforms? http://code.google.com/p/flightgear-bugs/issues/detail?id=445-- 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] 'Black model problem'
Using tied properties as uniforms? I don't think so, because the same parameters do get updated per frame just fine when shading the terrain. * Thorsten -- 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
On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote: But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers In fact, I used just this ability last night to modify the model-default.eff techniques to add an emissive layer for the random buildings. See Effects/buildings.eff -Stuart -- 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] 'Black model problem'
On Wednesday 02 May 2012 12:13:23 Emilian Huminiuc wrote: Using tied properties as uniforms? http://code.google.com/p/flightgear-bugs/issues/detail?id=445 This is easily solvable using a property-filter (check Environment/metarinterpolator.xml), that writes the properties to some other place, in which case they get untied and are passed properly to the shader. -- 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] 'Black model problem'
On Wednesday 02 May 2012 09:18:15 Renk Thorsten wrote: Using tied properties as uniforms? I don't think so, because the same parameters do get updated per frame just fine when shading the terrain. * Thorsten Hmm, that would be really strange, and a legitimate bug then. Worth a try with the property filter to see if that fixes them. Emilian-- 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
On Wed, May 2, 2012 at 9:53 AM, Frederic Bouvier wrote: But when two techniques use the same number, they are merged. I don't know if it was intended but one effect can modify one of it's parent without rewriting the predicate, and can lead to problems when we need to reassign numbers In fact, I used just this ability last night to modify the model-default.eff techniques to add an emissive layer for the random buildings. See Effects/buildings.eff I hope you added a comment saying that you rely on the numbering of some other technique. I see the maintenance nightmare coming very soon. 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] 'Black model problem'
Hmm, that would be really strange, and a legitimate bug then. Worth a try with the property filter to see if that fixes them. That's actually how terminator-relative-position-m (the sun position for shader purposes) is done - see Environment/local-weather-rules.xml * Thorsten -- 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] 'Black model problem'
Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. Adding the correct entry fixes it here: uniform nameterminator/name typefloat/type valueuseterminator/use/value /uniform -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Trouble compiling FG on Ubuntu 12.04 64
Hi all! This is my first mail on this list, so please forgive me newbie-mistakes. :) I've posted this request for help on the forum and had no luck with it. No one answered. So, I'll try here. I hope I'm no bother... http://www.flightgear.org/forums/viewtopic.php?f=45t=16180 My problem: I've tried to update my fgfs with brisas script for Debian/Ubuntu, as I did for years now... Sometimes there are problems, and compilation aborts. Most of the time I'm able to fix them myself, but this time, I don't even know, what the problem is, or if it is a problem... In the attachment you'll find the complete output of the compilation of OSG, SIMGEAR and FGFS. I wasn't sure if only the output of FGFS would be enough. OSG and SG built fine, no errors. Only some mysterious warnings, that some lib couldn't be found, but didn't seem to be a problem. So, I suggest you skip to the lower end of the file (~line 1450) and look for FGFS-compilation. In essence the following lines appear and bring make to a halt, funnily it continues to build after that, and halt with some similar lines: `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED1Ev[osg::TemplateArrayosg::Vec3f, (osg::Array::Type)10, 3, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED1Ev[osg::TemplateArrayosg::Vec2f, (osg::Array::Type)9, 2, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED1Ev[osg::TemplateArrayosg::Vec4f, (osg::Array::Type)11, 4, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) collect2: ld gab 1 als Ende-Status zurück make[2]: *** [utils/fgviewer/fgviewer] Fehler 1 make[1]: *** [utils/fgviewer/CMakeFiles/fgviewer.dir/all] Fehler 2 make[1]: *** Warte auf noch nicht beendete Prozesse... [ 31%] Building CXX object utils/GPSsmooth/CMakeFiles/MIDGsmooth.dir/MIDG_main.cxx.o I hope someone recognizes these lines, or knows, what the problem might be - I'd love to get back to 2.7!!! :) Thanks in advance chris [OT] ...astounding what bz2 can do... [/OT] FGcompileErrors.txt.bz2 Description: application/bzip -- 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] 'Black model problem'
Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. I'll be buggered... you're right. How embarrassing... * Thorsten -- 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] 'Black model problem'
What I think happens, is that, without the detail option on, the same shaders are used for terrain and models (terrain-haze), thus they get the terminator assigned from the teerain-default.eff. Once you enable the detailed shading for the terrain, that uniform is no longer assigned, since in terrain-haze there's another technique active, assigning the property to the terminator uniform in the terrain-haze-detailed shader, thus the terminator value seen by the terrain-haze shader active on models remains at the last value it had. This would explain why the lighting gets fixed momentarily when you move the landmass slider back and forth. -- 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] 'Black model problem'
On Wednesday 02 May 2012 10:08:07 Renk Thorsten wrote: Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. I'll be buggered... you're right. How embarrassing... * Thorsten I'll push a hot-fix then. Emilian-- 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] Trouble compiling FG on Ubuntu 12.04 64
Hi Chris, Hi all! This is my first mail on this list, so please forgive me newbie-mistakes. :) I've posted this request for help on the forum and had no luck with it. No one answered. So, I'll try here. I hope I'm no bother... http://www.flightgear.org/forums/viewtopic.php?f=45t=16180 My problem: I've tried to update my fgfs with brisas script for Debian/Ubuntu, as I did for years now... Sometimes there are problems, and compilation aborts. Most of the time I'm able to fix them myself, but this time, I don't even know, what the problem is, or if it is a problem... In the attachment you'll find the complete output of the compilation of OSG, SIMGEAR and FGFS. I wasn't sure if only the output of FGFS would be enough. OSG and SG built fine, no errors. Only some mysterious warnings, that some lib couldn't be found, but didn't seem to be a problem. So, I suggest you skip to the lower end of the file (~line 1450) and look for FGFS-compilation. In essence the following lines appear and bring make to a halt, funnily it continues to build after that, and halt with some similar lines: `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED1Ev[osg::TemplateArrayosg::Vec3f, (osg::Array::Type)10, 3, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec3fELNS_5Array4TypeE10ELi3ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED1Ev[osg::TemplateArrayosg::Vec2f, (osg::Array::Type)9, 2, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec2fELNS_5Array4TypeE9ELi2ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED2Ev' referenced in section `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED1Ev[osg::TemplateArrayosg::Vec4f, (osg::Array::Type)11, 4, 5126::~TemplateArray()]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o): defined in discarded section `.text._ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED2Ev[_ZN3osg13TemplateArrayINS_5Vec4fELNS_5Array4TypeE11ELi4ELi5126EED5Ev]' of /media/myfiles/software/games/FlightGear/git/install/simgear/lib/libsgtgdb.a(SGOceanTile.cxx.o) collect2: ld gab 1 als Ende-Status zurück make[2]: *** [utils/fgviewer/fgviewer] Fehler 1 make[1]: *** [utils/fgviewer/CMakeFiles/fgviewer.dir/all] Fehler 2 make[1]: *** Warte auf noch nicht beendete Prozesse... [ 31%] Building CXX object utils/GPSsmooth/CMakeFiles/MIDGsmooth.dir/MIDG_main.cxx.o I hope someone recognizes these lines, or knows, what the problem might be - I'd love to get back to 2.7!!! :) These messages are link error. Did you do a 'make clean' on all OSG, SG et FG ? My guess is that some files could be compiled with on version of gcc and some with 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] Trouble compiling FG on Ubuntu 12.04 64
Am Wed, 2 May 2012 14:25:09 +0200 (CEST) schrieb Frederic Bouvier fredfgf...@free.fr: These messages are link error. Did you do a 'make clean' on all OSG, SG et FG ? My guess is that some files could be compiled with on version of gcc and some with another. Regards, -Fred Hi Fred! Thanks for your answer! To my knowledge, I didn't! I also don't know, what this option (make clean) is there for :) But I believe these were compiled with the same version of gcc - unless I have multiple versions installed, and the script uses multiply versions by design... Seems a bit unlikely to me, but I'm not sure at all. How can I find out? Regards chris -- 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] Trouble compiling FG on Ubuntu 12.04 64
Hi Chris, Am Wed, 2 May 2012 14:25:09 +0200 (CEST) schrieb Frederic Bouvier fredfgf...@free.fr: These messages are link error. Did you do a 'make clean' on all OSG, SG et FG ? My guess is that some files could be compiled with on version of gcc and some with another. Regards, -Fred Hi Fred! Thanks for your answer! To my knowledge, I didn't! I also don't know, what this option (make clean) is there for :) But I believe these were compiled with the same version of gcc - unless I have multiple versions installed, and the script uses multiply versions by design... Seems a bit unlikely to me, but I'm not sure at all. How can I find out? 'make clean' means deleting all generated files and redoing the whole build from scratch, not relying on a previous build. You may change compiler version if you enable OS updates. 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] Trouble compiling FG on Ubuntu 12.04 64
Am Wed, 2 May 2012 15:02:42 +0200 (CEST) schrieb Frederic Bouvier fredfgf...@free.fr: Hi Chris, Am Wed, 2 May 2012 14:25:09 +0200 (CEST) schrieb Frederic Bouvier fredfgf...@free.fr: These messages are link error. Did you do a 'make clean' on all OSG, SG et FG ? My guess is that some files could be compiled with on version of gcc and some with another. Regards, -Fred Hi Fred! Thanks for your answer! To my knowledge, I didn't! I also don't know, what this option (make clean) is there for :) But I believe these were compiled with the same version of gcc - unless I have multiple versions installed, and the script uses multiply versions by design... Seems a bit unlikely to me, but I'm not sure at all. How can I find out? 'make clean' means deleting all generated files and redoing the whole build from scratch, not relying on a previous build. You may change compiler version if you enable OS updates. Regards, -Fred About gcc, I looked up synaptics. In the attachement is the summary of gcc packages I have installed. From what I can see, these are all the same version (4.6.3) I did upgrade my Ubuntu recently (11.10 -- 12.04). But additionally, because I earlier encountered problems after an upgrade, I usually delete the source folders and reload them from internet. And cleaning the build, sounds to me, like deleting the build-folder. Since some time, there popped out that folder build, that wasn't there before. I guess Brisa added it for these kinds of operations... I deleted it, along with the source-folders of OSG, Sg and FG. Again... Anyway, I started another build, right now it's building OSG... Maybe it's going to work now, although I don't think it's different from my last attempts. ... Hooray!!! It built through! Thanks to your idea of different gcc's on different versions of OS, it make me think about plib in the end. So I recompiled plib and there it was!!! My bad! I forgot all about plib! Thanks for your input!!! You just made one more happy flyer! :)) Cheers chrisattachment: compileerror.png-- 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 improvements - phase 2
On Tue, 1 May 2012, Stuart Buchanan wrote: Hi All, I've just committed a change that adds emissive lighting to the random buildings: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg That looks fantastic Stuart! It'll be cool when you can fly over and catch someone playing Tetris on the side of one of those buildings. :D g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- 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 improvements - phase 2
On Wed, 2 May 2012 07:17:45 -0700 (PDT), Gene Buckle wrote: On Tue, 1 May 2012, Stuart Buchanan wrote: Hi All, I've just committed a change that adds emissive lighting to the random buildings: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg That looks fantastic Stuart! It'll be cool when you can fly over and catch someone playing Tetris on the side of one of those buildings. :D Damnit, now I need to find time to model the green building at MIT and write tetris in nasal! -- Jon Stockill li...@stockill.net -- 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 improvements - phase 2
On Wed, May 2, 2012 at 4:18 PM, Björn Kesten wrote: Stu, do you have plans to regionalize the autogenerated buildings? This is already supported in the code, and just needs someone to spend some time creating textures and changing some XML. The buildings (including the texture to use) are defined in materials.xml, and you can assign different building sizes and distributions to different material types. You can already see that in the difference between Urban and Town/Suburban areas. We already have the ability to select a terrain material based on a condition statement, which is evaluated when the tile is loaded, so it is a very easy job to create a new material definition for a given region using a condition statement that checks /position/latitude-deg and /position/longitude-deg I've still to document the new lightmap texture parameter (it's called building-lightmap) but the rest of the parameters are documented in data/Docs/README.materials if you want to have a play. Thorsten Renk mentioned that he is looking at integrating Adrian's modified textures, possibly making some of them regionalized. I'm sure you could work with him on this by contributing some more realistic building definitions. Both the current building texture and the lightmap are really just proof of concepts. I'm not very talented as a texture artist, so there's plenty of scope for improving them. tigert on the IRC channel has already been looking at improving the textures, and i4dnf also mentioned he would be as well. -Stuart You can define the buildings on If so, one could lift the concept from MSFS. They assigned a letter-code to every global region (e.g. Germany and Scandinavia was K) and thus, you didn't have american wooden houses in Germany or cobblestone houses in Asia. This could be done with kind of a show up in region [A,C,D,H] tag for every model and a global regions definition file or similar. B. -- 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 -- 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 improvements - phase 2
Good to know, thanks. Texture work is not important, since there's way more people who know their way around PS/GIMP than people who can code such autogen systems. :) -- 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
On Wednesday 02 May 2012 23:47:59 Emilian Huminiuc wrote: Fred, One small question, what's with the multiple passes/ shader overrides and al sort of funky stuff (colour mask O.O) going on in terrain-default.eff. It looks like a real mess. I wanted to clear out the unneeded include_fog.vert that crept back in somehow and found that... Or is this an artefact of a messy git merge? Could you please check, or explain? Cheers, Emilian Nevermind, checked the git history, it's itended to be that way since a while ago :) Sorry for the noise Emilian -- 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 improvements - phase 2
On Wed, 2 May 2012, Jon Stockill wrote: http://www.nanjika.co.uk/flightgear/buildings-evening.jpg That looks fantastic Stuart! It'll be cool when you can fly over and catch someone playing Tetris on the side of one of those buildings. :D Damnit, now I need to find time to model the green building at MIT and write tetris in nasal! \o/ g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- 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
