Re: [Flightgear-devel] terragear.git: gdalchop.cxx undef reference to sgWriteLong
Different argument types (sgWriteLong(gzFile_s*, int) and sgWriteLong(void*, int)) are different symbols in C++. On my system both 2.10 shared and 2.12 static (I haven't tried next or master, but the git history says io/lowlevel.cxx hasn't changed for 2 years) give the correct types. Did you compile libSimGearCore yourself, and do you have zlib1g-dev installed? ~$ nm -gC /home/palmer/flightgear_source/simgear-2.10.0/debian/libsimgearcore2.10.0/usr/lib/x86_64-linux-gnu/libSimGearCore.so.2.10.0 | grep sgWriteLong 0006d150 T sgWriteLong(gzFile_s*, int) 0006d240 T sgWriteLongLong(gzFile_s*, long) ~$ nm -C /home/palmer/flightgear_source/simgear-2.12.0/simgear/libSimGearCore.a | grep sgWriteLong 0450 T sgWriteLong(gzFile_s*, int) 0540 T sgWriteLongLong(gzFile_s*, long) U sgWriteLong(gzFile_s*, int) -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Thu, Sep 19, 2013 at 3:07 PM, Renk Thorsten wrote: Which would in fact not make them random buildings at all :-) It'll make them less random, certainly :) However, while the placement and size class (small, medium, large) will now be determined by the texture, there will be still be randomness for each building in terms of width, depth, number of floors and texture. I need to prototype this to understand whether that's sufficient to fool the eye or not. The other avenue I'm looking at is whether the texture scale is correct. IIRC the city1 texture is 1024x1024 and covers a 1kmx1km area. I need to measure some street widths, as I suspect that might be a bit small. It may be that we can increase the texture coverage without increasing the texture size, which would reduce the repetition. Or just decide that cities are important enough to be worth a larger texture. May I propose to think about something more ambitious? One thing which bugs me is that we have now well-working de-tiling strategies for terrain, but not really for city textures and agriculture. Forest is effectively de-tiled by placing sufficiently many random trees on top - but we still get huge tiling artefacts for large city areas or fields. Deterministic 'random' building on top of that will make the tiling problem worse, because you get repeating patterns now in both texture and objects on top, which wasn't the case with the scattergun. I think one could at least partially solve this by subdividing the terrain into individual coordinate cells and give each city texture inside the cell a random orientation of the texture. The template would be the sparse dot noise function introduced in terrain-haze-ultra.frag , but instead of creating the dot position and radius randomly, the routine would just create a rotation angle randomly. I believe this would improve city and agriculture, but for this to really work, the 'random' buildings and trees would have to be shifted by the same function - probaby at placement time. Would it be technically hard to design the system in such a way that this could be introduced? I don't have a function ready yet, but it's something I wanted to give a try at some point with running a distinct shader for 'random' and 'civilized' terrain which needs different types of overlay. At the moment, we use a shader instantiate the buildings and forests to the correct locations. That transformation could be made more complicated to allow for texture rotation. Where it would have more difficulty is in handling the random objects, which are masked as well and would need to be moved. It would also be a bit tricky to make the edges of each coordinate cell look. At the moment, the textures edges tile nicely. I guess we could mirror the translation in the C-code, but it feels a bit wrong. On Thu, Sep 19, 2013 at 5:05 PM, Adrian Musceac wrote: Stuart, this is totally unrelated, but what would be the price to pay to have collision with generated buildings, and Rembrandt shadows? Actually, this isn't completely unrelated... The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. Now, all I need to do is find the time to code all of this up!. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Friday, September 20, 2013 13:04:32 Stuart Buchanan wrote: If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. I think one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and graphics load. It should be possible to take an object and generate multiple LOD's for it automatically, but I have almost no knowledge about 3D objects. Might be worth checking it out. Cheers, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Fri, Sep 20, 2013 at 11:15 AM, Adrian Musceac wrote: I think one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and graphics load. It should be possible to take an object and generate multiple LOD's for it automatically, but I have almost no knowledge about 3D objects. Might be worth checking it out. While a good LoD system helps with graphics load, it doesn't help with overall memory load (unless it's a PagedLOD), which was the problem with the buildings. We have fairly good LoD solutions for both trees and buildings to help with the graphics loads. For example we display the large buildings are further range than the medium or small. Hopefully people never notice it because it's quite subtle. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On 20 Sep 2013, at 11:04, Stuart Buchanan stuar...@gmail.com wrote: The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. That would be my hope too, BTW. Ideally we'd set a total memory use (or vertex count, which is a proxy metric for the same) for trees+buildings and setup the PagedLOD to keep things loading (really, generating) and unloading based on that target. Then it becomes a fairly clear memory-burn vs popping tradeoff which I think most people would accept as reasonable. You don't like the pops, you buy more [V]RAM :) Instancing would help the memory burn, but OSG makes it very complex, we need to bypass large chunks of the PrimitiveSet and Arrays APIs until they get a real API internally, possibly not until OSG 3.4 (This is on the assumption that even though the buildings are random, across a tile you could have quite a few which differ only in transform and some other shader uniforms, but have the same width/breadth/height/roof-pitch/number-of-floors, and hence could be drawn using the same instance data) Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Built-in Svn client code crashing
Hello, A few people have reported crashes when using the built-in SVN client code, especially on Linux (and potentially Windows too, which would be a problem, as we shall see). Thomas identified something strange relating to whether we were using built-in or the system Expat XML parser, and I finally realised the dumb thing I'd done, and have cleaned up the problem. Hence the refactoring that occurred in SimGear last night, so that we cannot (anymore) end up in a situation where we get the Expat headers and symbols from mismatching locations. The guess/hope is that this was previously causing subtle memory corruption due to internal differences in Expat. However, it can only have been an issue on Linux, not Windows - since Windows will never have a system-supplied version. So, as I've previously asked before, I really need people running from 'next' to try with -DSG_SVN_CLIENT=1 when configuring SimGear, move their existing TerraSync dir out the way, and test, test, test. I'm sure the new code isn't 100% trouble free (in particular I think there is still the occasional time when it gets stuck not doing any more downloads until FG is restarted), but I really don't want to move forwards with the code until I have a bit more assurance it's not going to make everyone's setup crash 80% of the time, which is what some people have reported. Note this applies even if you 'don't use' terrasync since the SVN sync engine is going to be used for other pieces of data as soon as it's stable. (I will be adding a new preference to globally control whether FG works in online/offline mode, of course) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On Wed, Aug 21, 2013 at 4:45 PM, Stuart Buchanan wrote: On Tue, Aug 20, 2013 at 8:34 AM, James Turner wrote: Given that Innis has given the all-clear, what is the next step? I'm happy to simply checkout a particular branch from the repo above and commit the files to fgdata, but there are other options. Not sure what the other options are, but a simple checkout and commit to fgdata would be straightforward :). This is now checked into git, with the non-GPL sounds removed. Possible candidate for default aircraft for V3.0? Enjoy! -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
