On 24 Dec 2011, at 14:06, Vivian Meazza wrote:
The model-combined shader uses EXT_texture3D
Right, I've gained a bit more understanding from digging in the OSG sources:
The error:
OpenGL extension 'GL_EXT_texture3D' is not supported.
is a red-herring; the Texture3D class in
On 28 Dec 2011, at 15:40, Mathias Fröhlich wrote:
Can you post the output from glxinfo -l.
OpenGL limits:
GL_MAX_ATTRIB_STACK_DEPTH = 16
GL_MAX_CLIENT_ATTRIB_STACK_DEPTH = 16
GL_MAX_CLIP_PLANES = 6
GL_MAX_COLOR_MATRIX_STACK_DEPTH = 10
GL_MAX_ELEMENTS_VERTICES = 1048575
On 28 Dec 2011, at 16:04, Frederic Bouvier wrote:
GL_MAX_TEXTURE_UNITS_ARB = 8
...
GL_MAX_TEXTURE_COORDS_ARB = 8
It looks like the texture unit of the noise texture is beyond the limits of
your card
Indeed. What I find strange (but probably due to lack of knowledge) is that the
On 28 Dec 2011, at 16:15, Csaba Halász wrote:
Since we are talking about shaders, aren't the limits
GL_VERTEX_SHADER_ARB:
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 16
On 26 Dec 2011, at 10:00, Jari Häkkinen wrote:
I don't have access to my Lion right now so I cannot check but I think
the 10.6 SDK is included already.
It does - and Jenkins is set to use the correct SDK for OSG, SG and FG -
unfortunately at link time we're selecting the system libapr over
On 26 Dec 2011, at 00:54, Gary Neely wrote:
For quite some time many models will endlessly spew the following
warning to the console:
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..)
I'm having something which *may* be similar. To check if it's the same
On 25 Dec 2011, at 22:45, Jari Häkkinen wrote:
The FlighGear package created in Build #871 (Dec 25, 2011 12:05:44 PM)
does not run on two of my macs.
1. On the Snowleopard machine I get:
What version of Xcode/Mac OS X is the Jenkins server using?
It's my local box, running 10.7/Lion. I
On 24 Dec 2011, at 08:32, Mathias Fröhlich wrote:
Thie required extensions are in the effect files. Whatever changes are done
with
the shaders, the effect files *must* contain the minimum condition under
which
gl version/extensions this shader is valid.
This is complex, but the only
I'm having the dreaded 'invalid operation after ' errors from OSG, which makes
seeing other debug output. Once again, it relates to 3D textures, and is
presumably Ati specific.
Details:
- latest Git of fg+sg+fgdata, OSG 3.0.1
- card is a Radeon 5770, with the official Apple
On 21 Dec 2011, at 02:47, Csaba Halász wrote:
Recompiled with fresh OSG/SVN and cull times were now stable at least
for the duration of the 30 minute parked test.
I will re-enable eye candy and do some flights tomorrow, but I hope
the mysterious problem is fixed.
Apologies for keeping quiet
On 18 Dec 2011, at 11:06, Stuart Buchanan wrote:
One question for the release managers: Do performance improvements such as
these count as bug fixes or features? Should we try to get this into
the 2.6.0 release,
or wait until 2.8.0?
I think the answer is 'it depends', but given that you
On 18 Dec 2011, at 16:44, Flightgear-commitlogs wrote:
#479: avoid issues due to trailing path separators
Cut trailing separators when converting from string to sgpath.
Also, SGPath::fix does NOT replace :. It only replaces \ with /,
so the i!=1 check for Windows made no sense
Since 'a day or two ago', all OSG text is rendering for me in the 'missing'
font (built-in bitmap font, scaled). PLIB .txt appears fine. I've already
checked rolling back flightgear to a couple of weeks ago, with no difference,
so I think the issue is in simgear or fgdata or 'something weird'
On 17 Dec 2011, at 17:43, ThorstenB wrote:
Yes, same here - fonts also broken on Linux. It's back to normal when
rewinding simgear to a92ea7f822bf175df15fc05a2425f6e94dc520f3, so first
commit with the issue is
No idea though why this affects fonts...
Any chance it's related to
On 17 Dec 2011, at 18:14, Mathias Fröhlich wrote:
Fixed.
Another 'interesting' behaviour of OSG readerWriters :)
James
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows
A note for people committing code:
Please don't *ever* merge from next to a topic / local branch, and then merge
that branch back to the public next. Doing so makes the history much more
confusing than it needs to be. Rebase your local topic branches onto next
periodically when you wish to
On 14 Dec 2011, at 09:32, Anders Gidenstam wrote:
If your topic is freshly rebased it will just be a fast-forward merge,
that is, your new commits are just added to the history of master.
Nice and linear IMHO.. :)
Yes, sorry, I didn't express that clearly at all - thanks Anders!
James
On 14 Dec 2011, at 14:49, Stuart Buchanan wrote:
(BTW - I think I've managed to get Impostors working though I've still to see
any performance gain)
That's very interesting, because if we had truly generic impostors working,
they could also be used to push out the scenery rendering
On 2 Dec 2011, at 21:44, Erik Hofman wrote:
sound support is broken here (GIT of today). When I start with the UFO
at an airport with AI traffic, e.g. KSFO, then I hear a roar for a few
seconds during start-up - but then there is silence for the rest of the
simulation. No sound when the
On 30 Nov 2011, at 14:07, Stuart Buchanan wrote:
I'm interested in peoples opinions on this, and in particular what
their view is of the current forest and urban shader performance. It
may be that my system is unique in that one is cheap and the other
expensive, and this is all pointless!
On 1 Dec 2011, at 12:33, Heiko Schulz wrote:
Anyone knows why?
The Windows slave is offline, and I keep forgetting to poke Gene to see why.
Probably the Windows box needs restarted / tickled / fed chocolate.
James
On 29 Nov 2011, at 23:14, ThorstenB wrote:
On 29.11.2011 23:59, Jon Stockill wrote:
I've just noticed that the README files are being installed to /usr/doc
since the switch to cmake. This should be /usr/doc/flightgear
Right. Also noticed this recently. The correct location also depends on
On 21 Nov 2011, at 13:01, Gijs de Rooy wrote:
Thanks for the feedback/ideas so far! Hope to get some more throughout the
week.
Just to add my opinion (since this was partly my suggestion)
My key concern is that most people (even developers) don't care about 'material
shaders', so long as
On 19 Nov 2011, at 19:54, HB-GRAL wrote:
Thank you very much. Is it also possible to interpret OpenGL/GPU load
somehow this way ?
OSG already has this - exposed via the Debug menu in FG.
(Well, not in much detail about the GPU - normally that kind of information
comes from separate tools -
On 18 Nov 2011, at 07:12, ThorstenB wrote:
I don't know where exactly the BTG loading code starts. But at least the
function generating the mentioned We detected an error message
(SGBinObject::read_bin) doesn't have a version check. It does read the
version and then makes
On 17 Nov 2011, at 21:44, ThorstenB wrote:
Oh yes! Latest TerraGear + FG were fixed, so they no longer cause weird
display issues with highly detailed scenery. When you use the latest TG
to generate scenery, which is so detailed so that it needs the new
feature, then you also need latest
On 13 Nov 2011, at 10:04, Martin Spott wrote:
I'm just a bit unhappy that I'd have to check various _repositories_
(_plus_ various branches therein) in order to get an update about what
peple are actually doing about TerraGear. Experimental stuff is pretty
much what Git branches (or
On 12 Nov 2011, at 13:59, Maxime Guillaud wrote:
I have had pretty good luck building complex scenery with a modified version
of
fgfs-construct. Here is what I did:
snip
Okay, this all sounds like good news indeed. Martin, Chris, Peter - I think the
steps need to be as follows - get a
On 10 Nov 2011, at 07:36, HB-GRAL wrote:
- Approach Fix
- Intermediate Fix
- Final Fix
- MAPT
- Step down
- Fly-by
- Fly-over
- Co-located
- Speed limit (?)
Is there any possibility to classify the bare 8.50 fix database
somehow, i.e. by name ? I can also start to provide other
On 9 Nov 2011, at 08:33, Vivian Meazza wrote:
You need ALL of the following:
CMAKE_PREFIX_PATH - path/to/simgear e.g. D:/Cygwin/simgear
SIMGEAR_INCLUDE_DIR - path/to/simgear/include e.g. D:/Cygwin/simgear/include
SIMGEAR_LIBRARIES - SIMGEAR_LIBRARIES-NOTFOUND
SIMGEAR_VERSION_OK - true
On 9 Nov 2011, at 15:32, Geoff McLane wrote:
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to cmake build...
On 8 Nov 2011, at 09:57, Christian Schmitt wrote:
Done. If someone could remove the cmake branches, that'd be nice. :)
I'll do so, thanks for the merge.
Onwards with fixing the fgfs-construct crashes!
James
--
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Brilliant, thanks Fred.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
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
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
On 6 Nov 2011, at 09:43, Eric van den Berg wrote:
So we now have a Terragear version that produces nice and more detailed
terrain, but can only be seen with current GIT flightgear. As the
fraction of people using older FG versions is large (95%?...just a
guess, correct me if you have an
On 5 Nov 2011, at 11:25, HB-GRAL wrote:
Maybe how to set this flags for OSX should go to the readme once. I
think some OSX users will end up with linking errors because simgear
compiles well with x86_64, but then you run into a lot of problems
trying to compile flightgear, on OSX. Btw. I
On 3 Nov 2011, at 18:51, James Turner wrote:
... going to be something really obscure when we track this down, I guess
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.
James
On 4 Nov 2011, at 00:41, Jon Stockill wrote:
I believe it's FG_DATA_DIR, as observed here:
https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9
Thanks - that worked (well, it returns the correct details when you run
cmake with that option, I've yet to test
On 3 Nov 2011, at 23:05, Jon Stockill wrote:
There's doesn't seem to be any way to enable the jpg-httpd server.
(Under autoconf it was enabled by default if Simgear was built with jpeg
factory support).
-DJPEG_FACTORY=1
... except, hmm, that only seems to exist for Simgear let me
On 2 Nov 2011, at 19:48, Martin Spott wrote:
Fixed now, at least, it generated a ton of .dem files for me.
Really ? And you're on simgear/next and terragear-cs/cmake-integration
without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to
On 3 Nov 2011, at 13:19, Christian Schmitt wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
On 3 Nov 2011, at 16:37, Vadym Kukhtin wrote:
Couple weeks ago I tried build FG with ccmake, but fail. I wrote about it to
ML, but no response. And I continuue build with ./configure.
I apologise, I thought I had responded to your original email.
So, SG compiles with ccmake like a charm,
On 2 Nov 2011, at 18:33, Martin Spott wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
James
On 2 Nov 2011, at 18:51, James Turner wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
Fixed
Hello,
A bit later than planned, the automake build system has been removed from Git.
There's very likely some edge cases and unusual combinations that the Cmake
system doesn't handle still, so please report any problems or omissions you
encounter, and we'll do our best to fix them up.
If you
On 29 Oct 2011, at 18:36, Durk Talsma wrote:
I think that it's a fairly recent commit that broke this: I'm using the
--start-date-gmt option quite frequently, and it wasn't until earlier this
week that I noticed an inconsistency (although I hadn't conciously noted any
time shift yet, I
On 30 Oct 2011, at 10:38, ThorstenB wrote:
Durk, for me, it does still work. However, it's all a bit fragile. The
are no error messages and any typo warps you to some random time. Also,
we're using signed 32bit integers for the time offset - so things will
break on 2038:01:19 ;-).
I
On 30 Oct 2011, at 11:49, Durk Talsma wrote:
It turns out that I had the option --time-match-local included in my .fgfsrc
file. Commenting out this option from .fgfsrc makes both --timeofday=dawn,
as well as --start-date-gmt work again. Originally, the order of precedence
was that
On 30 Oct 2011, at 16:07, BARANGER Emmanuel wrote:
About maps ZKV1000, I sincerely believe that the use of osgearth solve
many problems. Unfortunately, for a long time when I suggest something,
no one is listening. And I'm tired of fighting.
I don't know about your other suggestions, but
On 29 Oct 2011, at 02:37, Scott wrote:
SimGear
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/SimGear/simgear-2.6/
-DCMAKE_PREFIX_PATH=/usr/ ../simgear/
As far as I know, /usr should be on the prefix path automatically, so I'm
surprised you needed that, trailing slashes or otherwise. H
So
On 26 Oct 2011, at 19:24, Geoff McLane wrote:
Maybe, as you have suggested, this is over kill,
setting BOTH SIMGEAR_DIR in the environment,
AND passing SIMGEAR_INCLUDE_DIR to cmake,
and when I feel comfortable, I will eliminate
one or the other for further testing...
BUT now I have
On 27 Oct 2011, at 01:28, Gary Neely wrote:
The #1 reason I haven't added my projects (MD-81, Grumman Goose,
Edgley Optica, Velocity XL RG) to the repository is that I have no
ability to perform my own commits. Possibly I haven't earned the right
and I can understand that. But I would like
On 27 Oct 2011, at 10:35, Heiko Schulz wrote:
The procedure is to ask :)
Aha, really?- in the 5-6 years I'm contributing to FlightGear-Project I did
this twice. I never got an answer. And until now I can only guess what was
the reasons for.
Problem is, as you already realised - *I* don't
On 26 Oct 2011, at 13:13, Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with cmake-integration/CMake, cmake-integration/Autoconf
but master/Autoconf is
On 26 Oct 2011, at 13:34, Martin Spott wrote:
I was interrupted when writing the above As an addition I'd
propose to separate the de-PLIB-ifying from the 'cmake-integration'
into a separate branch/topic/whatever because the move to CMake as a
build system appears to be successful.
A
On 26 Oct 2011, at 18:43, Martin Spott wrote:
I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating subdirectories and/or files. Anyhow I'd like to hear from
others being more successful with using recent versions of the
On 25 Oct 2011, at 09:39, Adrian Musceac wrote:
Hi James, and thanks for updating the readme. I may be blind or just stupid,
but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works.
Adding it to environment variables does not do anything, and cmake fails to
find the
On 25 Oct 2011, at 14:30, syd adams wrote:
I haven't thought it out too deeply , but
maybe in this format :
Aircraft: Citation-X
Author: Syd
Licence: GPL
URL: git clone or download url
Splash: path/url to thumbnail
It would be up to the aircraft developers to fill it in and maintain
On 25 Oct 2011, at 15:20, Geoff McLane wrote:
need to see the arguments / environment
passed to CMake, to understand why.
But in each case I have explicitly given you
the exact exports and cmake commands used...
What more do you need?
The problem is you've confused me, with all the
On 24 Oct 2011, at 10:09, thorsten.i.r...@jyu.fi wrote:
Yes, the angles between eye and sun are constants per frame throughout the
scene :-) So is hazeColor. My problem is not passing the value from the
property tree, my problem is getting it there - I'm not a C++ coder, I
have no clue where
On 24 Oct 2011, at 11:54, tuomas.kuosma...@gmail.com wrote:
Hi folks, and a quick hello, myself being new to this list. :)
Hello, and welcome!
Here's just a quick note when compiling from git on ubuntu 11.10, I had to
add SIMGEAR_LIBRARIES to the linking section on utils/fgpanel
On 24 Oct 2011, at 13:17, Geoff McLane wrote:
In my case I like to be able to compile
against different versions of say OSG - like -
OSG301=1# stable release 3.0.1 - default
OSG283=0# general release 283 - option
OSG299=0# another development release
OSGTRUNK=0
On 25 Oct 2011, at 03:03, Geoff McLane wrote:
You can find it here -
http://geoffair.org/tmp/5426688.btg.gz
So tomorrow to try to discover is the problem in
the fgfs-contruct output, the write, or in the
fgfs read and rendering...
I'll take a look too :)
All the info above looks very
On 23 Oct 2011, at 09:31, Erik Hofman wrote:
CMake worked like a charm but I did notice that the special purpose
FDM's don't get included anymore. I believe I did see it mentioned in
the CMake configuration but leaving code out on a development system
might introduce a chance of bit-rot.
Hello again,
Barring last-minute objections, I would like to declare CMake 'the' build
system, from tomorrow onwards. Since my last email I've added a README.cmake to
flightgear, and I'm working on ensuring the 'make dist' features of automake
are replicated in CMake (via CPack) so when 2.6
On 22 Oct 2011, at 16:09, Curtis Olson wrote:
It might be a bit extra work, but it would be good to take the source.tar.gz
files that cmake creates, unpack them in a new directory and just make sure
we can do a clean build from them. This always seems to expose a file or
two, or a header
On 22 Oct 2011, at 16:26, S Andreason wrote:
Is there any recommended way to reference instruments outside the
aircraft's directory?
Currently I am using
path../../../Instruments-3d/alt-2/alt2.ac/path
and
texture../../../Generic/Effects/smoke.png/texture
etc.
Please use:
On 23 Oct 2011, at 00:41, Jason Cox wrote:
I can now build more scenery but still hit the spaghetti network
around YSSY.
Was the change that you made only to a 32bit int?
What do i need to do to change to 64bit int?
I'd be pretty suspicious of this - much more likely, there's a bug in my
On 22 Oct 2011, at 23:20, S Andreason wrote:
I know you'll say everybody must upgrade, but I still see a lot of
downloads of my models for older Fg versions. (Which does make sense for
older graphics hardware.)
Yep - I would say upgrade - but I understand there's reasons not too. If
On 20 Oct 2011, at 09:48, Jason Cox wrote:
I am trying to test some builds around YWLM and just need to know if the
changes for higher detailed scenery that you spoke of is in the repo?
How do I tell the changes that were made to sg_binobj.cxx as I do not
understand how to drive GIT to
On 18 Oct 2011, at 23:21, dave perry wrote:
2. Assuming the answers are no, yes, to #1, will all these repositories
be centrally located so one can track new or modified ac of interest?
3. Is there any interest in creating repositories by ac class/type?
e.g. historical,
On 19 Oct 2011, at 10:15, Edheldil wrote:
Is there any written spec on this system? I got frustrated when looking
for a specific aircraft in fgrun :) and so I suggested something similar
several days ago on IRC, but it got confused with a/c rating.
If I understand you correctly, submit a/c
On 19 Oct 2011, at 11:53, syd adams wrote:
while the central repository is a fine
idea , after the move to git , I lost any commit rights to my own
work, so after a time i gave up on the idea of maintaining them and
started my own repositories . I would have happily continued to
On 19 Oct 2011, at 12:27, thorsten.i.r...@jyu.fi wrote:
Most of us are adult people, and most of the time we are able to act like
civilized people, i.e. we can work out things in a reasonable way without
invoking the law and waving license around. There are some rules for
emergency cases
On 19 Oct 2011, at 16:27, Curtis Olson wrote:
Right now we've replaced a one-line command with several weeks of manual
work. (Or so it appears.) I understand the reasons, and we need to move
forward, but I think this is a logic gap here -- an unforeseen side effect,
and a problem we
On 19 Oct 2011, at 17:47, Curtis Olson wrote:
One more super module question: if I start plowing through 350 aircraft by
hand, and then next week you come out with a super module, will that require
me to redownload everything, or can that be retrofitted on top of the modules
I've already
On 17 Oct 2011, at 18:38, Curtis Olson wrote:
Would it be possible to write a quick howto for doing some basic
coding/developer things in cmake. Like: how to add a new source file to the
project. Or how to add a new module/library to the project.Maybe a
few quick summeries of how to
It's been a month since I announced the intention, to switch all the main FG
platforms to use CMake, and to deprecate and remove the other build systems
from Git. There's been many small improvements in the Cmake files since then,
which I hope have eased some people's concerns about the
On 15 Oct 2011, at 15:22, HB-GRAL wrote:
I think the only solution is to make GPC obsolete - either by replacing
GPC by something different but functional equivalent or simply (TM ;-)
by avoiding any polygon clipping in 'fgfs-construct' overall.
Martin.
Hi Martin
Are there any
On 14 Oct 2011, at 23:42, Jason Cox wrote:
I then did a git pull just to make sure that it wasn't a file that i
missed but it reports that i am up to date.
I've been doing some TerraGear hacking recently, so I'm the most likely person
to have caused this, but on both my systems (Linux and
On 11 Oct 2011, at 21:09, Flightgear-commitlogs wrote:
Reduce AI/MP lags when removing models
Move load of removing OSG objects to the OSG pager thread
Excellent, nice work Thorsten.
(Thread-safety for the win :)
James
On 7 Oct 2011, at 19:24, Martin Spott wrote:
This is what happens when running 'genapts' with a modified
'simgear-cs' on a _really_ simple airport layout (EDKA, consisting of
just one runway and two windsocks):
Starting program: /home/martin/install_headless/bin/genapts
On 6 Oct 2011, at 18:17, ThorstenB wrote:
However, when someone writes to the tied property using the normal
property interface (setprop in Nasal or via the C++ SGProperty::setValue
methods), then property's change listeners should fire normally.
So, it depends on how a value is changed.
On 4 Oct 2011, at 13:53, James Turner wrote:
Of course, I can't confirm or deny that suspicion until I upgrade the writer
code path too :)
I've committed an updated BTG reader/writer to simgear/next, which supports the
current format, and a higher-versioned format with 32-bit indices. Based
On 2 Oct 2011, at 19:00, J. Holden wrote:
Still, as a scenery developer and not a programmer, I'm still wondering what
the limit is before the swirlies start floating around. Is it vertices?
Fans? Triangles?
It's 65536 vertices per BTG, in total. Strictly, this isn't true - the BTG
format
On 4 Oct 2011, at 13:34, Curtis Olson wrote:
Here's a random idea on the writer side:
Would it be possible to do something like:
if (size of any of my structures are 65535) then
write_32bit_index_btg()
else
write_16bit_index_btg()
endif
Then we'd be spending are larger
On 30 Sep 2011, at 19:52, Michael Robson wrote:
Essentially what I am looking to do is create some instruments of my own with
some detailed generation of graphical entities that are being continually
updated. I am therefore assuming that a 'dynamic texture' is the way to go
with this.
On 1 Oct 2011, at 03:33, Curtis Olson wrote:
That could very well be true ... and I don't think it would be a huge coding
change ... but it should be done in a way that bumps up the btg version
number and picks a new packet id so as to maintain backwards compatibility
with all the
On 1 Oct 2011, at 15:37, Curtis Olson wrote:
We need to modify the loader in simgear as well as the format generation code
in terragear. Right now the indices are packed as 2-byte short ints in the
binary .btg file so of course making a change only to the simgear side will
do nothing to
On 30 Sep 2011, at 11:56, Martin Spott wrote:
Hah, I managed to find the web page I've been searching
for weeks, Bruce did a pretty nice writeup of the problem:
http://www.cullam.com/flightgear.htm
A very useful description, yes!
James
On 28 Sep 2011, at 21:14, Curtis Olson wrote:
I suppose it would make sense to grep through the code, but as far as I know,
the primary uses of the visibility value is to properly set the OpenGL fog
parameters and determine how many rings of tiles to load centered on the
current location.
On 25 Sep 2011, at 09:10, James Turner wrote:
2. After about 1hour of flying, FG seems to go into a endless loop; the
sound continues to play, however the screen is frozen (goes to black if you
minimise then re-maximise it), and all network activity drops off (ie: you
disappear from multi
On 27 Sep 2011, at 09:00, Francesco Angelo Brisa wrote:
ok, now I will cmake fgfs too and send the new script to Thorsten.
Thaank you !
That's good news indeed!
James
--
All the data continuously generated in
On 25 Sep 2011, at 08:36, Scott Hamilton wrote:
2. After about 1hour of flying, FG seems to go into a endless loop; the
sound continues to play, however the screen is frozen (goes to black if you
minimise then re-maximise it), and all network activity drops off (ie: you
disappear from
On 24 Sep 2011, at 09:04, Mathias Fröhlich wrote:
Yes, I can see that libGL and libz is just pulled indirectly which no longer
works on very new linux ld variants.
Arrgh, really? That's news to me.
James
--
All of
On 22 Sep 2011, at 09:07, Jason Cox wrote:
I am having an issue with compiling the lattest git version due to a
lack of a libhal on my system
after check the web site for libhal
(http://www.freedesktop.org/wiki/Software/hal) I found that it now in
maintenance mode and they are switching
On 20 Sep 2011, at 19:35, Francesco Angelo Brisa wrote:
something like ALT + m to be added to the keyboard.xml.
I have found the map useful, specially for a short look out, which if
best used using a key press.
Here my xml adding to the keyboard.xml if ok.
key n=109
namem/name
On 16 Sep 2011, at 10:37, Andreas Gaeb wrote:
I just tried to run with real weather fetch, but the network cable was
not plugged. This produced a segfault after about a minute, see below.
Somewhere the information that the lookup has finally failed seems to
get lost. After re-plugging the
On 14 Sep 2011, at 12:00, Stuart Buchanan wrote:
OK. We've got something similar already in the C code for exactly this
purpose. Might be more efficient to simply expose that over Nasal, but
I'm not sure how easy that would actually be.
Pretty trivial, for a function such as sg_random,
401 - 500 of 1199 matches
Mail list logo
