Re: [Flightgear-devel] ..has anyone tried testing FG build scripts in fresh trees?

[Arnt Karlsen]

On Sun, 3 Feb 2013 07:12:14 +0100, Arnt wrote in message 
<20130203071214.01dbf...@celsius.lan>:

> ..my patch needs more work, fgrun compile fails on libfltk1.3-dev:
> -- Performing Test HAVE_FLTK_1_3
> -- Performing Test HAVE_FLTK_1_3 - Failed
> CMake Error at CMakeLists.txt:228 (message):
>   FLTK 1.3 is required

..and tossing out libfltk1.1-dev to fit libfltk1.3-dev, kills 
the fgfs compile.  I need sleep now. ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..has anyone tried testing FG build scripts in fresh trees?

[Arnt Karlsen]

On Fri, 1 Feb 2013 23:18:05 -0500, Pat wrote in message 
<20130201231805.3e3875a7@spinnaker>:

> libRTI-NG.so.1 should be in test-tree/install/openrti/libRTI-NG.so.1
> 
> 
> The following works for me:
> 
> #bin/bash
> TEST_TREE=$1
> if [ "$TEST_TREE" == "" ]
> then
>   TEST_TREE="test-tree"
> fi
> mkdir -vp test-tree
> cd test-tree
> wget -c \
> http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
> sh download_and_compile.sh -j 2 |tee download_and_compile.sh--j-2.log
> sh download_and_compile.sh -a n -p n -d n -j 2 ALL |tee \
> download_and_compile.sh-a-n--p-n--d-n--j-2-ALL.log
> 
> run_fgrun.sh and Flightgear started right 
> 
> 
> after the first  download_and_compile.sh, libRTI-NG.so.1 should be in
> test-tree/install/openrti/libRTI-NG.so.1

..nope, not here:
rnt@celsius:~/FG-git$ tree install/openrti/lib/ 
install/openrti/lib/
└── x86_64-linux-gnu
...
├── libRTI-NG.so -> libRTI-NG.so.1
├── libRTI-NG.so.1 -> libRTI-NG.so.1.3.0
└── libRTI-NG.so.1.3.0

..but I'mone step closer, "now it cranks, puffs 'n smokes", do I 
need the "Enabling ATI viewport hack" with the radeon driver???: 
arnt@celsius:~/FG-git$ bash run_fgfs.sh --geometry=1600x1080 &
[1] 12795
arnt@celsius:~/FG-git$ Enabling ATI viewport hack
Animated jetways ... initialized
KMA20 audio panel initialized
KI266 dme indicator #0 initialized
loading scenario 'nimitz_demo'
Electrical system initialized
r300 FP: Compiler Error:
compiler/r500_fragprog_emit.c::emit_paired(): emit_alu: Too many
instructions Using a dummy shader instead.
r300 FP: Compiler Error:
compiler/r500_fragprog_emit.c::emit_paired(): emit_alu: Too many
instructions Using a dummy shader instead.
glLinkProgram "" FAILED
Program "" infolog:
error: fragment shader varying rawpos not written by vertex shader
.error: shader uses too many varying components (44 > 40), but the
driver will try to optimize them out; this is non-portable out-of-spec
behavior

run_fgfs.sh: line 5: 12797 Segmentation fault  ./fgfs
--fg-root=$PWD/../fgdata/ $@

[1]+  Exit 139bash run_fgfs.sh --geometry=1600x1080
arnt@celsius:~/FG-git$ 

..this compile and segfault was done on system plib and system osg:
arnt@celsius:~/FG-git$ dpkg -l |grep libplib |fmt -tu
ii libplib-dev 1.8.5-6 amd64 Portability Libraries: Development package
ii libplib1 1.8.5-6 amd64 Portability Libraries: Run-time package
arnt@celsius:~/FG-git$ dpkg -l |grep openscenegraph |fmt -tu
ii libopenscenegraph-dev 3.0.1-4 amd64 3D scene graph, development files
ii libopenscenegraph80 3.0.1-4 amd64 3D scene graph, shared libs
ii openscenegraph 3.0.1-4 amd64 3D scene graph, utilities and examples
   (binaries)
ii openscenegraph-doc 3.0.1-4 all 3D scene graph, documentation
ii openscenegraph-examples 3.0.1-4 all 3D scene graph, examples
(sources) 
ii openscenegraph-plugin-citygml-shared 0.14+svn128-1+3p0p1+4 amd64
libcitygml OpenSceneGraph plugin (shared version) 
ii openscenegraph-plugin-citygml-static 0.14+svn128-1+3p0p1+4 amd64
libcitygml OpenSceneGraph plugin (static version)
arnt@celsius:~/FG-git$ 

..my patch needs more work, fgrun compile fails on libfltk1.3-dev:
-- Performing Test HAVE_FLTK_1_3
-- Performing Test HAVE_FLTK_1_3 - Failed
CMake Error at CMakeLists.txt:228 (message):
  FLTK 1.3 is required

arnt@celsius:~/FG-git$ ll download_and_compile-1.9-4a.patch &&md5sum
download_and_compile-1.9-4a.patch -rw-r--r-- 1 arnt arnt 2853 Feb  3
06:51 download_and_compile-1.9-4a.patch
79dd3f7d7363231d705c336733073475  download_and_compile-1.9-4a.patch
arnt@celsius:~/FG-git$ 


> A side note:
>   $sh download_and_compile.sh. 
> will work even without the chmod -x download_and_compile.sh

..aye, and svn can be tossed out too, git "speaks" svn, and
I'll put fgdata in my FG-git tree root and link it home:
arnt@celsius:~/FG-git$ ll -d install/fgfs/fgdata fgdata
drwxr-xr-x 31 arnt arnt 4096 Feb  3 06:11 fgdata
lrwxrwxrwx  1 arnt arnt   24 Feb  3 06:12 install/fgfs/fgdata
-> /home/arnt/FG-git/fgdata arnt@celsius:~/FG-git$ 

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
--- download_and_compile-1.9-4.sh	2013-01-04 11:43:24.0 +0100
+++ download_and_compile-1.9-4a.sh	2013-02-03 04:27:30.598266993 +0100
@@ -18,7 +18,7 @@
 # along with this program.  If not, see .
 
 
-VERSION="1.9-4"
+VERSION="1.9-4a"
 
 #COMPILE GIT FGFS
 
@@ -272,7 +272,7 @@
 DISTRO_PACKAGES="libopenal-dev libalut-dev libalut0  libfltk1.3-dev libfltk1.3 cvs subversion cmake make build-essential automake zlib1g-dev zlib1g libwxgtk2.8-0 libwxgtk2.8-dev fluid gawk gettext libxi-dev libxi6 libxmu-dev libxmu6 libboost-dev libasound2-dev libasound2 libpng12-dev libpng12-0 libjasper1 libjasper-dev libopenexr-dev libboost-serialization-dev git-core libhal-dev libqt4-dev scons python-tk pytho

Re: [Flightgear-devel] Model shader for Atmospheric Light Scattering

[Vivian Meazza]

Stuart

> 
> On Thu, Jan 31, 2013 at 12:25 PM, Renk Thorsten wrote:
> > I've just pushed the first version of the model shader for Atmospheric
> > Light Scattering. It should do random buildings with reflections and
> > all aircraft using the model-combined.eff without normal mapping. The
> > shader still has some quirks, but they're hard to spot if you don't
> > look for them ;-)
> 
> Thanks Thorsten, and Emillian.
> 
> So, does this mean we're getting now at the point at which the Atmospheric
> Light Scattering is a complete replacement for the existing default
rendering
> scheme (with the exception of the farmland shader)?
> 
> If so, we should definitely remove the "experimental" label from the
> rendering dialog, and possibly change this to the default renderer and
have a
> discussion about whether to retire the previous scheme.  Early in the
release
> cycle would seem to be a good point to do this.
> 

I've only tested Atmospheric Light Scattering for about 10 mins - and so far
I've discovered that the Cat III scenario looks decidedly odd with a clear
circle around my aircraft on the ground and black skies. So the instant
answer must be NO.


Vivian



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Model shader for Atmospheric Light Scattering

[Stuart Buchanan]

On Thu, Jan 31, 2013 at 12:25 PM, Renk Thorsten wrote:
> I've just pushed the first version of the model shader for Atmospheric Light 
> Scattering. It should do random buildings with reflections and all aircraft 
> using the model-combined.eff without normal mapping. The shader still has 
> some quirks, but they're hard to spot if you don't look for them ;-)

Thanks Thorsten, and Emillian.

So, does this mean we're getting now at the point at which the
Atmospheric Light Scattering is a complete replacement for the
existing default rendering scheme (with the exception of the farmland
shader)?

If so, we should definitely remove the "experimental" label from the
rendering dialog, and possibly change this to the default renderer and
have a discussion about whether to retire the previous scheme.  Early
in the release cycle would seem to be a good point to do this.

-Stuart

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..has anyone tried testing FG build scripts in fresh trees?

[Pat]

libRTI-NG.so.1 should be in test-tree/install/openrti/libRTI-NG.so.1


The following works for me:

#bin/bash
TEST_TREE=$1
if [ "$TEST_TREE" == "" ]
then
TEST_TREE="test-tree"
fi
mkdir -vp test-tree
cd test-tree
wget -c \
http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
sh download_and_compile.sh -j 2 |tee download_and_compile.sh--j-2.log
sh download_and_compile.sh -a n -p n -d n -j 2 ALL |tee \
download_and_compile.sh-a-n--p-n--d-n--j-2-ALL.log

run_fgrun.sh and Flightgear started right 


after the first  download_and_compile.sh, libRTI-NG.so.1 should be in
test-tree/install/openrti/libRTI-NG.so.1

A side note:
$sh download_and_compile.sh. 
will work even without the chmod -x download_and_compile.sh

On Thu, 31 Jan 2013 07:25:39 +0100
Arnt Karlsen  wrote:

> Hi,
> 
> ..has anyone tried testing FG build scripts in fresh trees?
> 
> ..as in, "mkdir -vp test-tree ;cd test-tree ;wget -c \
> http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh
> ;chmod -x download_and_compile.sh  ;\
> sh download_and_compile.sh -a n -p n -d n -j 2 ALL ", like our recipe:
> http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu
> says is possible?  I get errors, the weird part is I can "prime" my
> test tree, and then most parts of download_and_compile.sh works, e.g.
> plib, openrti, OSG, SG and FG all builds ok, but FG bombs right out:
> ./run_fgfs.sh
> ./fgfs: error while loading shared libraries: libRTI-NG.so.1: cannot
> open shared object file: No such file or directory
> 
> 


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Release candidates

[Renk Thorsten]

> 4. Models/Weather - 76 MB - As asked are BOTH duplicate
> dds and rgb files needed, or could a release work with only
> one or the other?

> 5. And now I find in both Textures and Textures.high
> the same duplication of dds and png files. Again
> are BOTH really required for a release?

> 6. Are there other cherry picking items that could
> be removed. What about the "bunch of obsolete cloud
> models and textures" Renk mentioned? Others?

4) and 6) refer largely to the same textures. I wonder what's so difficult in 
writing 'Yes, we'd like you to dig up the list!' - after all, I offered to do 
so, just everyone seems to be talking around the issue :-)

Most cloud textures with *.dds and most textures which do not contain *sheet* 
could go - the problem is that there are few exceptions to the rule, and I want 
to be sure not to remove something that is still needed under more exotic 
weather conditions. I'm actually not sure if we still use any of the dds cloud 
textures or not for the static cloud models.

5) is rather different from 4) - the weather dds textures are the same textures 
just converted to dds, but the scenery texture set are actually different 
textures which happen to have the same name (because they're supposed to 
represent the same landclass). So 5) is equal to the previous discussion of 
shipping dds terrain textures separately.

In somewhat other matters, we (myself certainy included) have been somewhat 
sloppy in populating Textures vs. Textures.high - so we have currently some 
textures which are unique in the Textures.high/ folder and have no lower 
resolution counterpart in the Textures/ folder. Admittedly, given the 
capabilities of today's GPUs, I didn't think that using 256x256 vs. 512x512 
textures is much of an issue, and I tend to consider 1024x1024 standard and 
regard the distinction between different resolution levels as a bit of a legacy 
feature - some of our aircraft use 4096x4096 sheets after all. The bottomline 
is - simply optionally removing Textures.high will not work.

* Thorsten
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel