> From: Erik Hofman
>
> Jim Wilson wrote:
>
> > Umm...not so fast. Read my problem description again. I think you can
> > still pickup the wrong plib or simgear.
>
> Did you actually try the latest version. It _should_ prevent this
> problem. If not I till have your fix to commit.
>
> Erik
Martin Spott wrote:
> Hello Josh,
>
> Josh Babcock wrote:
>
>
>>Now, is there a way I can run FG without losing my configuration every
>>time? I'd really like to get back to flying and developing airplanes,
>>but this is sort of getting in the way a little bit.
>
>
> I actually share your feel
Hello Josh,
Josh Babcock wrote:
> Now, is there a way I can run FG without losing my configuration every
> time? I'd really like to get back to flying and developing airplanes,
> but this is sort of getting in the way a little bit.
I actually share your feelings, although I didn't loose any file
I had my joystick working in 0.9.8 and upgraded to 0.9.9, and am having a
bit of trouble figuring out how things work.
I can make a joystick configuration file for my joystick, no problem. How
do I get Flightgear to reference it?
I thought, in 0.9.8, that there was a joysticks.xml file somewhere
Josh Babcock wrote:
Warning: angry ranting ahead.
OK, I've been away for a while, alternately because my graphics setup
was buggy or because I was out of the country, so I haven't been
following the list for a month or two. I just came back, installed a new
Nvidia card and compiled the latest F
> Yes, of course. I didn't say the way it's fixed is bad, or that it
> doesn't work. But as I never tried to code a FDM myself I really lack an
> understanding of the complexities, and so I ask. I'd say the question is
> the beginning of wisdom :)
>
> I do not demand an answer, but if someone has a
Warning: angry ranting ahead.
OK, I've been away for a while, alternately because my graphics setup
was buggy or because I was out of the country, so I haven't been
following the list for a month or two. I just came back, installed a new
Nvidia card and compiled the latest FG. Works great, I was r
Richard Harrison wrote:
I 100% agree with the way Jon has fixed this. Suggesting that there is
simpler way of doing it indicates a lack of understanding of the
complexities.
Yes, of course. I didn't say the way it's fixed is bad, or that it
doesn't work. But as I never tried to code a FDM mys
Hi Curt,
I suppose I'm less sensitive to the abrupt change problem as most of the
scenery both face material and triangle edges show some form of abrupt
change due the the mountainous terrain that covers most of the country.
Personally I like the blending solution for edges although this still
On January 13, 2006 08:04 pm, Ampere K. Hardraade wrote:
> The process is trivial.
>
> In each file, there are lines that represent latitude and longitude.
> http://204.108.4.16/d-tpp/0513/00375AD.PDF
>
> The user would first use a program like Inkscape to rename at least four of
> those lines to t
"Curtis L. Olson" writes:
> I was reading through the thread this morning and as it progressed there
> were more and more german words intermixed and then all german.
>
> I've been working on a large vehicle steering and guidance controller
> (snowplow/truck) for my day job and if pavement==e
Ralf Gerlich writes:
> Hi,
>
> Paul Surgeon schrieb:
> > When TerrorGear does the UV mapping calculations on the terrain polys it
> > should take the terrain slope into account.
> > Flat ground = standard resolution
> > More slope = higher resolution
>
> I think the only point where TerraGear a
Mathias Fröhlich wrote:
Hi
Aem, sorry for that noise, As Christian started to reply in german, I thought
that we have private mails
Sorry!
I was reading through the thread this morning and as it progressed there
were more and more german words intermixed and then all german.
dene maxwell wrote:
Hi Paul,
From: Paul Surgeon <[EMAIL PROTECTED]>
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important.
Pythagarus
> is more important, the distance as seen in a birds-eye view as seen
by FGSD
> is not the di
Hi
Aem, sorry for that noise, As Christian started to reply in german, I thought
that we have private mails
Sorry!
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
---
This SF.net email is sponsored by: Splunk Inc. Do
Hi,
Ja ich hatte mal in Ka angefangen und Technonmathe gemacht. Irgendwie war
mir's aber damals in Tübingen angenemer als in Karlsruhe. Drun bin ich dann
letztlich da gelandet. Hatte eigentlich nix gegen den Studiengang ...
On Sunday 15 January 2006 14:19, Christian Mayer wrote:
> Nein. Ich mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, should have been private.
Christian Mayer schrieb:
>>> Ok, so you are actually writing on your PHD?
>
> [...]
For completeness: I was just saying that I still have some exams at
university and haven't made up my mind of what comes next.
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathias Fröhlich schrieb:
> Hi,
>
> On Sunday 15 January 2006 13:33, Christian Mayer wrote:
>> Numerics is also the stuff that I do most (as well as lots of fluid
>> dynamics).
> Ok, so you are actually writing on your PHD?
Nein. Ich muß erst noch di
Hi,
On Sunday 15 January 2006 13:33, Christian Mayer wrote:
> Numerics is also the stuff that I do most (as well as lots of fluid
> dynamics).
Ok, so you are actually writing on your PHD?
> > Ok, interresting. I heared that MSVC does vectorization for some time.
>
> I've only used the .NET 2003
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathias Fröhlich schrieb:
> Hi,
>
> On Sunday 15 January 2006 13:18, Christian Mayer wrote:
>> Technomathematik (= applied mathematics)
> Karlsruhe?
Nope, TU München
> Mathematician from Tübingen, did numerical analysis, mostly timestepping.
Numeri
Hi,
On Sunday 15 January 2006 13:18, Christian Mayer wrote:
> Technomathematik (= applied mathematics)
Karlsruhe?
Mathematician from Tübingen, did numerical analysis, mostly timestepping.
> Oh, I've just seen that I didn't link the thesis yet. Should be there
> under documentation in a few minu
Christian Mayer writes:
>
> (BTW: my diploma thesis [= roughly a masters thesis] was the creation of
> cache oblivious matrix operations in C++ using the space filling Peano
> curve; I could beat the Intel Math Kernel Library in optimal cache use -
> und even performance wise when I used only x87
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathias Fröhlich schrieb:
> Hi,
>
> On Sunday 15 January 2006 12:54, Christian Mayer wrote:
>> (BTW: my diploma thesis [= roughly a masters thesis] was the creation of
>> cache oblivious matrix operations in C++ using the space filling Peano
>> curve;
Hi,
On Sunday 15 January 2006 12:54, Christian Mayer wrote:
> (BTW: my diploma thesis [= roughly a masters thesis] was the creation of
> cache oblivious matrix operations in C++ using the space filling Peano
> curve; I could beat the Intel Math Kernel Library in optimal cache use -
> und even per
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mathias Fröhlich schrieb:
>> The sg* vectors and matrices are created in such a way that they'll
>> offer the higest possible performance and compatability for using OpenGL.
> column major like fortran :)
> Well, I worked, together with some collegue
Hi,
On Saturday 14 January 2006 19:07, Ampere K. Hardraade wrote:
> That was a suggestion. I current am not working on any document regarding
> the graphic engine, so I have nothing to share. However, I along with
> several others, are working on a document regarding the architecture of FG.
>
>
Hi,
On Saturday 14 January 2006 15:08, Christian Mayer wrote:
> Mathias Fröhlich schrieb:
> > I am preparing some abstraction classes to make such a transition smooth.
> > The first thing will be to make fg independent of sg* vectors and
> > matrices. Have a set of classes in my local tree which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
dene maxwell schrieb:
> Hi all,
> my reading of the situation;
> a) No adjustment of the textures takes place at the moment for sloping
> terrain...hence the "stretch" problem.
> b) a "cylindrical" solution has been proposed(that I don't understand
>
Hi all,
my reading of the situation;
a) No adjustment of the textures takes place at the moment for sloping
terrain...hence the "stretch" problem.
b) a "cylindrical" solution has been proposed(that I don't understand the
maths of) that may/will have an unacceptable performance hit.
c) x-plane an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Paul Surgeon schrieb:
> On Sunday 15 January 2006 12:08, Christian Mayer wrote:
>> (*) unless you want to get fancy with blending the textures, etc. pp.
>> But this will create an big overhead.
>
> Well yes but a half decent scenery engine using tex
On Sunday 15 January 2006 12:08, Christian Mayer wrote:
> (*) unless you want to get fancy with blending the textures, etc. pp.
> But this will create an big overhead.
Well yes but a half decent scenery engine using texture blending like the one
in X-Plane and MSFS would do just fine and they act
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Paul Surgeon schrieb:
> It doesn't work because TerrorGear doesn't do it.
> Nothing is broken because there's no code to do it yet. :)
>
> If I'm not mistaken TerrorGear doesn't take the elevation into account at all
> when doing the UV mapping -
On Sunday 15 January 2006 11:38, dene maxwell wrote:
> this certainly seems to follow the geometric logic. One problem...it
> doesn't seem to work.
>
> Without being familiar with the code concerned, my impression is that this
> logic is not being applied in a way that produces the desired result o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ralf Gerlich schrieb:
>> One thing I have noticed, we have alot of urban areas on very steep
>> hill sides. This "draping" approach can cause some very unpleasant
>> visual effects in these instances...the terrain looks ...stretched...
>> like drawi
Hi,
Paul Surgeon schrieb:
When TerrorGear does the UV mapping calculations on the terrain polys it
should take the terrain slope into account.
Flat ground = standard resolution
More slope = higher resolution
I think the only point where TerraGear assign UV coordinates is during
generation of
Hi Paul,
From: Paul Surgeon <[EMAIL PROTECTED]>
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important.
Pythagarus
> is more important, the distance as seen in a birds-eye view as seen by
FGSD
> is not the distance of the terrain.
On Sunday 15 January 2006 10:25, dene maxwell wrote:
> Hi Paul, to my way of thinking the resolution is not important. Pythagarus
> is more important, the distance as seen in a birds-eye view as seen by FGSD
> is not the distance of the terrain. Hence if you cut a material to a
> birds-eye distance
Hi Paul, to my way of thinking the resolution is not important. Pythagarus
is more important, the distance as seen in a birds-eye view as seen by FGSD
is not the distance of the terrain. Hence if you cut a material to a
birds-eye distance of say 10 what ever units it will be stretched to say
14
38 matches
Mail list logo
