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
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
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
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 varyings...
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 shader
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 really
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
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.
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
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 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 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 think this is
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
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
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
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
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
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 looking
-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
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, the
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
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
On 25 October 2011 01:47, Torsten Dreyer tors...@t3r.de 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
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
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
||
|
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
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
27 matches
Mail list logo
