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
Hi Jason,
Ok my 5426688.btg.gz took about 5 hours to
generate. And most of the near final console
output shows -
...
center = [ -4.63734e+06, 2.55623e+06, -3.54361e+06 ] radius = 16282.1
dumping normals = 94646
creating 497 fans of type 0
creating 169 fans of type 1
creating 1470 fans of type 2
Hi Core (and the rest of the entire organism of course)
Why not splitting up the Aircraft folder into hangars as collection of
aircrafts as plug-ins, collection of big teams or small but heavy
industries ?
--- fgdata
|
Aircraft
||
|
Geoff,
thanks for looking at this.
I think that the swerllies have actually gone and are now replaced by
spaghetti.
the old behavior was the terrain being stretched inside a triangle
incorrectly followed by tile not being produced at all. in FGFS this
would also bottom out the rendering at <1 fps.
George Patterson wrote:
> Btw, Berlios is closing on 31/12/2011 so grab what you need now. I am
> not sure if Mathias has moved the above project to another host.
I'm sure Mathias will speak about the details himself, but aside from
that I can confirm he's aware of the implications. In case of d
On 25 October 2011 01:47, Torsten Dreyer wrote:
>
> Hi Geoff,
>
> you need a RTI implementation. I can recommend the OpenRTI implentation
> from our fellow FlightGear developer Mathias:
> http://developer.berlios.de/projects/openrti/
> which you can clone from
> git://git.berlios.de/openrti
>
Btw
After spending half an evening trying to wrap my head around the ocean
problem, here's what I found out:
Just to be sure, I moved the geometry back into the fragment part - this
indeed seems to work more accurately. Then I switched ground layer effects
off and computed just with distance attenu
Hi Jason,
Have just completed a new fgfs build, and a TG tool
build, and have downloaded your -
34169132 newScenery-YSSY.tar.bz2
149396748 newScenery.tar.bz2
And yes, when I load that scenery in fgfs all
I see are spaghetti strips, like in your
work/fgfs-screen-001.png image...
I unloaded it
On Monday 24 October 2011 18:48:38 thorsten.i.r...@jyu.fi wrote:
> Okay, got it - thanks - mean one.
>
> Basically, you're never looking at the top of the layer, you're looking
> about one attenuation length into the layer - but under a shallow angle,
> that is essentially the layer top.
>
> Now
-Original Message-
From: James Turner
Sent: Monday, October 24, 2011 2:53 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
As you guessed, manually setting the the detection variables
(SIMGEAR_VERSION_OK, etc) is a bad idea, unless
> I'm using 100-300m thick layers with visibility anywhere between 200 to
> 600
> meters, in the layer.. then I play with the global visibility using
> z/shift-z.
> Problems arise with increased global visibility, at higher altitudes.
Okay, got it - thanks - mean one.
Basically, you're never look
>
> Thanks for the reply, but if you look a little
> closer, I AM building simgear, SIMGEAR!, when I get
> this error ;=((
>
> Maybe it would have been better, clearer, if I had
> said
>
> Having just successfully compiled the latest
> SimGear git, in Ubuntu 10.04, using the default,
> which is -D
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
> OSG
Hi James,
Thanks for your reply, and from Mathius and
Alan...
> Does that help at all?
Well, there is no doubt I could 'simplify' the
situation by NOT appending an extra path items
after 'install', but I should not have to!
If I wanted such a 'simple' single install path,
why not install tho
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 CMakeL
Hi folks, and a quick hello, myself being new to this list. :)
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 CMakeLists.txt, it
would fail on missing symbols on libz otherwise.
After this fgpanel (and the
On Sun, 2011-10-23 at 20:50 +0200, ThorstenB wrote:
> Am 23.10.2011 20:12, schrieb Geoff McLane:
>
> > Having just successfully compiled the latest
> > SG git, in Ubuntu 10.04 decide to try
> > -D ENABLE_RTI=ON, passed to CMake, but only
> > get to -
> > Ok, clearly I am missing RTI.hh
> >
> > I t
On Monday 24 October 2011 12:09:33 thorsten.i.r...@jyu.fi wrote:
> As for matching the horizon - it did in all my tests which were not at
> sunrise/sunset - which combination of visibility-m ground-visibility-m and
> ground-haze-thickness are we talking? I have just tried a few realistic
> cases
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 wh
> 1. You forget the fact that in the end this all gets applied to faces
> (triangles), and a point inside the triangle will have a value
> interpolated
> between the values of the three corners. I don't think that's a linear
> function anymore.
Then the fragment shader would never get correctly in
On Monday 24 October 2011 11:27:11 thorsten.i.r...@jyu.fi wrote:
>
> * Thorsten
Forgot to add to my previous message that the new version is much better than
the first, with a couple of issues.
The edge between fog/unfogged areas is too hard now, and it still doesn't
match the horizon.
---
Heiko Schulz wrote:
> To my surprise they showed a picture of one of their simulators- and
> it does shows Flightgear! (obviously KSFO 28R)
Yup, quite a few serious research projects are using FlightGear for
visualization - but, as far as I can tell, none of them is using any of
FlightGear's int
On Monday 24 October 2011 11:27:11 thorsten.i.r...@jyu.fi wrote:
> > Yes, doing stuff once per vertex rather than once per pixel is faster,
> > but also
> > may lead to poor results. The more stuff you do in the vertex shader the
> > more
> > visible the mesh grid will be.
>
> Maybe someone can re
I just added a comment to a merge request for "terragear-cs" on
Gitorious and I think this might be of general interest. Therefore I'm
posting the same comment as a followup to this thread:
- snip -
Increasing the ressource limits i
> Yes, doing stuff once per vertex rather than once per pixel is faster,
> but also
> may lead to poor results. The more stuff you do in the vertex shader the
> more
> visible the mesh grid will be.
Maybe someone can really enlighten me on this point:
My understanding is that
* the vertex shade
> Also there's a bigger issue here. The number of varyings is limited (in
> fact
> it's the most constraining limit of all the limits present), and
> integrating
> this with other shaders will become problematic. Moving stuff in the
> vertex
> shader has the unwanted effect of requiring more varyi
On Monday 24 October 2011 10:46:42 thorsten.i.r...@jyu.fi wrote:
>
> I've also transferred some things into the vertex shaders - I have the
> impression that is a bit faster.
>
> Cheers,
>
> * Thorsten
Also there's a bigger issue here. The number of varyings is limited (in fact
it's the most c
On Monday 24 October 2011 10:46:42 thorsten.i.r...@jyu.fi wrote:
> My current setup can be found here
>
> http://www.phy.duke.edu/~trenk/files/terrain-haze-shader24102011.tgz
>
> I've now tested a few more things: There are still some issues with ocean
> tiles left - I *think* throwing in more ve
Geoff
I see the same problem with windows cmake gui.
My solution was to define SIMGEAR_VERSION_OK as boolean true in the
flightgear cmake.
This seems to bypass the bug and satisfy cmake.
Alan
-Original Message-
From: Geoff McLane
Sent: Sunday, October 23, 2011 6:47 PM
To: FlightGear de
On 24 Oct 2011, at 08:46, thorsten.i.r...@jyu.fi wrote:
> I've now tested a few more things: There are still some issues with ocean
> tiles left - I *think* throwing in more vertices will fix this, or
> Emilian's hack of testing point altitude against layer altitude rather
> than doing trigonomet
My current setup can be found here
http://www.phy.duke.edu/~trenk/files/terrain-haze-shader24102011.tgz
I've now tested a few more things: There are still some issues with ocean
tiles left - I *think* throwing in more vertices will fix this, or
Emilian's hack of testing point altitude against lay
31 matches
Mail list logo
