Re: [Flightgear-devel] Textures sizes, DDS
On Sunday 06 November 2011 21:08:22 Jacob Burbach wrote: On Sun, Nov 6, 2011 at 7:17 PM, Robert dogg...@googlemail.com wrote: I hope that all you guys involved in the dds transition use nvidia-texture-tools because: 1. It is Free/OpenSource and platform independent 2. The compression quality is much higher than with the dds-plugin for GIMP However, and correct me if I'm wrong, the nvidia tools do not let you use pre-defined mip maps do they? I prefer the nvidia tools if for no other reason than they are command line and I can easily script and automate batch jobs. But if you do need pre defined mip maps I don't believe you have a choice except the gimp plugin..on linux anyway. cheers There is the version of nvidia's dds utilities that can be found here http://developer.nvidia.com/sites/default/files/akamai/tools/files/DDS_Utilities_8.31.1127.1645.exe that can be installed under wine. stitch exe from that package allows you to use custom mipmaps. That's how I've created the forest and grass textures. I've converted each of the mipmaps with nvcompress (with the -nomips option), then I've used stitch.exe to put them together. I've found the gimp plugin to be very unreliable. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future structure of fgdata (was: Textures sizes, DDS)
On Sun, 6 Nov 2011, HB-GRAL wrote: But I didn?t spoke out what Gary, Jacob and Anders write here. This is exactly what I meant and it was no vote against every improvement of the old shaders where I contributed too. Me and myself would be very happy when we get a directory structure with origins (maybe still png?s, state: before compressing) and with deployed .dds files. For models, aircrafts and scenery textures. And when I think that i.e. in one HANGAR you can have only ONE src/dev directory for all your origins, but I will stop now ... Let me just state here that I think the hangar as repository concept is a bad idea. The composition and ownership of the contents of a hangar is likely to change over time as people join and leave the project and since rewriting history to rearrange the repositories (transfer aircraft between hangars) is something to be avoided[1] it is IMO far better to use one aircraft per repository as the structure for a split fgdata. [1] The alternative delete and add approach would preserve history but waste space in both repositories and make the full history of an aircraft/file difficult to retrive. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
James Turner wrote: This is fixed now, though I don't really understand how it ever worked - rawdem.c wasn't checking a particular return code nicely, now it does. Thanks a lot, things are looking much better now ! I'll perform a few more tests and will report back. In the meantime we managed to established a method to reliably create topologically clean !! CORINE land cover from the publicly available sources, thus we just (TM) need to find out how - reliably - not to crash 'fgfs-construct' when processing these detailed datasets at large scale ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Call for Betatesters (OpenAL Linux)
Hi, Some of you might already be aware of the fact that have been developing a 3D audio library for quite some time. Now is the time to call for a larger group of beta testers. The software is a replacement for OpenAL on linux and consists of two components: 1. the AeonWave Audio eXtentions library (or AeonWave for short). 2. an OpenAL emulation layer library. AeonWave has a quite extensive features list (many supported data formats, several filters and effects, sub-mixing capable audio-frames to name a few) but the most important feature for OpenAL (and for FlightGear users at this time) is that it can render sound sources 5 to 7 times faster than either OpenAL-Soft or OpenAL-Sample. This leaves more CPU power for simulation and graphics rendering. AeonWave comes in two variants; the Lite version (limited but free) is a great start for OpenAL enabled software, and the HD version which is not yet offered but will not be free of charge (the price will be sub $10,- though). Anyone who is willing to give it a try can get the software from: http://www.adalin.com Download and install AeonWave and AeonWave-OpenAL and you are ready to go. Any other software is optional. Please don't reply here if you wish to give feedback but reply to me directly (preferable with AeonWave in the subject) Any help would be highly appreciated! Erik -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On 7 Nov 2011, at 11:33, Martin Spott wrote: Thanks a lot, things are looking much better now ! I'll perform a few more tests and will report back. In the meantime we managed to established a method to reliably create topologically clean !! CORINE land cover from the publicly available sources, thus we just (TM) need to find out how - reliably - not to crash 'fgfs-construct' when processing these detailed datasets at large scale ;-) Excellent news. As ever, if you can tell me idiot-proof steps to make it crash, I'll be happy to dive in. Of course, if the problem turns out to be GPC, we have some further work to do :) James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott martin.sp...@mgras.net wrote: James Turner wrote: This is fixed now, though I don't really understand how it ever worked - rawdem.c wasn't checking a particular return code nicely, now it does. Thanks a lot, things are looking much better now ! Indeed, valgrind seems to be happy now. -- Csaba/Jester -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sunday 06 November 2011 13:35:11 Anders Gidenstam wrote: Now that we have per-aircraft repositories I plan to add my source material (blender, svg, datcom, octave, gerris etc files) below a dev directory in the aircraft's repository. Probably further structured in FDM, models, ... subdirectories. If we use a small set of names (I'd suggest dev, development or src) for the base directory of such files it shouldn't be too hard to make the aircraft packaging script(s) omit these files from the release .zip files. I do this now with a folder I call Resources/ in the root of the aircraft directory. I also make a Resources/Local which I add to .gitignore so I can keep non-gpl data with the aircraft on my hard-drive but out of the repository. Ron -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
Jon Stockill wrote: On 04/11/11 00:00, Martin Spott wrote: Jon Stockill wrote: Simgear doesn't seem to install to the correct directory on 64 bit systems any more - there doesn't seem to be any way to tell it to use /usr/lib64 instead of /usr/lib That's in LIB_POSTFIX. Try: # ~ cmake -D CMAKE_INSTALL_PREFIX=/usr -D LIB_POSTFIX=64 [...] OK, just tried that (after a make clean first just to be sure), it still installs to /usr/lib (and neither ccmake nor cmake -LH make any mention of that option). Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as expected ;-/ Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cmake
On 7 Nov 2011, at 17:07, Martin Spott wrote:
Ok, I conclude: LIB_POSTFIX im Simgear doesn't work as expected ;-/
I think we have a 'thinko' in the module - looking at the code, we're using:
install (TARGETS ${libName} ARCHIVE DESTINATION lib${LIB_SUFFIX})
... my guess is if this was LIB_POSTFIX instead, it would do exactly what you
want ... set it to '64' and simgear will install to lib64
But I also suspect there's a smarter, automatic way to deal with this by
default.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future structure of fgdata
Am 07.11.11 11:12, schrieb Anders Gidenstam: On Sun, 6 Nov 2011, HB-GRAL wrote: But I didn?t spoke out what Gary, Jacob and Anders write here. This is exactly what I meant and it was no vote against every improvement of the old shaders where I contributed too. Me and myself would be very happy when we get a directory structure with origins (maybe still png?s, state: before compressing) and with deployed .dds files. For models, aircrafts and scenery textures. And when I think that i.e. in one HANGAR you can have only ONE src/dev directory for all your origins, but I will stop now ... Let me just state here that I think the hangar as repository concept is a bad idea. The composition and ownership of the contents of a hangar is likely to change over time as people join and leave the project and since rewriting history to rearrange the repositories (transfer aircraft between hangars) is something to be avoided[1] it is IMO far better to use one aircraft per repository as the structure for a split fgdata. [1] The alternative delete and add approach would preserve history but waste space in both repositories and make the full history of an aircraft/file difficult to retrive. Cheers, Anders Hi Anders My intention is not a better split of fgdata somehow, not a technical perspective perhaps, it is a model to give more responsability to aircraft developers who wants to build (or keep) there own developing units, all under the same licence, the hangar still belongs to the community, but the single aircraft developers will get more power. I think you can’t give people more responsability when you miss to give more power too. I confess I was not thinking about how to prevent people from deleting history or add/delete aircrafts. But also I do not understand why one could split to single aircraft repos without loosing history and this should not be possible for hangars, today and/or in future. The idea of hangars did not collect that much encouraging feedback, so I think I give it up now ;-) Thanks for checking the idea anyway. Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear now sans plib
Martin Spott wrote: Thanks a lot, things are looking much better now ! I'll perform a few more tests and will report back. Can confirm the fix as well. It works all as expected. Waiting for your last feedback now, Martin, before preparing the merge. In the meantime we managed to established a method to reliably create topologically clean !! CORINE land cover from the publicly available sources, thus we just (TM) need to find out how - reliably - not to crash 'fgfs-construct' when processing these detailed datasets at large scale ;-) That sounds good, but I still don't know what/where the tile border elevation inaccuracies exactly come from... Chris -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
