On 18 Sep 2012, at 22:33, Thomas Geymayer wrote:
> While searching for the reason of crashing FlightGear if trying to
> remove the nodes of the previously selected airport in the new Select
> Airport Dialog I stumbled upon a problem with the behavior of
> SGPropertyNode::removeChild. If you remov
On 18 Sep 2012, at 11:56, Stuart Buchanan wrote:
> Feedback and comments are welcome as always, particularly if any
> aircraft developers would like any enhancements
> made.
Fantastic!
James
--
Live Security Virtual C
On 17 Sep 2012, at 17:07, Alasdair wrote:
> CMake Error: The following variables are used in this project, but they are
> set to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake
> files:
> SIMGEAR_SCENE_LIBRARY_RELEASE (ADVANCED)
>
> cmake version is 2.8.
On 16 Sep 2012, at 15:59, David Van Mosselbeen wrote:
> Objects in custom_scenery/Models aren't loaded anymore. For example, the
> cli output:
>
> some_path/dvanmosselbeen_flightgear-custom-scenery/Objects/e000n50/e004n50/3023649.stg:
> Failed to load OBJECT_SHARED 'Models/metal_baril_red.ac'
>
On 11 Sep 2012, at 16:29, Stuart Buchanan wrote:
>
> I've created a wiki page collecting the reasons for not changing the license
> in the following (protected) wiki article:
Thanks Stuart, this is much appreciated (at least by me!)
James
-
On 6 Sep 2012, at 09:54, Martin Spott wrote:
> _But_ the same model is already available in the Scenery path:
>
> jive: 10:40:08 ~> ls -l
> /export/share/FGScenery/Test/Models/Misc/entrepotblanc-ba.xml
> -rw-r--r-- 1 martin user 946 6. Okt 2011
> /export/share/FGScenery/Test/Models/Misc/entr
On 5 Sep 2012, at 21:13, ThorstenB wrote:
> The XML reader relies on osgDB to resolve paths now. If
> osgDB::findDataFile cannot find the file, it returns "", in which case
> SGModelLib::findDataFile cannot search any additional directories.
> So, maybe osgDB::findDataFile doesn't know about ex
On 5 Sep 2012, at 09:06, Stuart Buchanan wrote:
> On a practical note I'd also point out that some FG development has
> been paid for through the commercial use of FG. In the past I've been
> paid to develop simulations for my local museum of flight, the results
> of which have been fed back int
On 4 Sep 2012, at 23:09, Flightgear-commitlogs wrote:
> commit 6745d27691039e2ce477b2e823dbae6c59bc5d00
> Author: ThorstenB
> Date: Tue Sep 4 23:57:25 2012 +0200
>
>#858: Fix loading issue with aircraft models in "--fg-aircraft" directories
>Something after FG 2.8.0 has broken loading
On 4 Sep 2012, at 11:43, Alasdair wrote:
> Further research shows that for the b1900d & SenecaII, this problem goes
> way back to 2.6.0. It has only become apparent (in my case) for the
> c172p in recent git pulls. I will attempt to find exactly when, but I am
> having to learn git as I go :-( Si
Please open a bug for this, if there is not one already (it sounds similar to
one existing issue), and include all the information below - especially when it
broke, OSG versions, graphics cards and so on.
Cheers,
James
On 2 Sep 2012, at 20:07, Alasdair wrote:
> On Sun, 2012-09-02 at 12:26
On 29 Aug 2012, at 06:09, Flightgear-commitlogs wrote:
> - Log -
> commit 26664aaff0e2f97db916909218d849b51636ccc0
> Author: Mathias Froehlich
> Date: Mon Aug 27 20:51:16 2012 +0200
>
>Push SGMaterial use into these classes th
Hi,
For some time, Simgear has had the option to build shared libraries (DLLs on
Windows) - this is only really useful for developers, since it can reduce link
times. However, when I made this change, I organised Simgear into 'core' and
'scene' libraries; the 'core' part is also what we call 'h
On 22 Aug 2012, at 00:59, BARANGER Emmanuel wrote:
> src/Airports/groundnetwork.cxx -> Line 40 #include
> must be #include
>
This was my fault, already fixed since last night (I hope).
https://gitorious.org/fg/flightgear/commit/8a087582bcf6bda954dee70ed1f48fe64a09aac2
James
-
On 11 Aug 2012, at 18:21, Tim Moore wrote:
> This is what osg::PagedLOD does, though we often forget that the
> paging of the higher LODs is triggered in the cull phase.
>> I can't recall what scene modifications are / are not permitted inside a
>> cull-callbacl, however.
> You would want to let
On 12 Aug 2012, at 20:44, Martin Spott wrote:
>> But it's not an either/or. There could be an FGCom binary that uses the same
>> code as the built-in FGCom.
>
> Which environment would be set up to build this separate binary ?
The fgfs one, but I don't think that's a particularly onerous requi
On 11 Aug 2012, at 22:52, Martin Spott wrote:
>> 3) Scenery. Terrasync is now built into FG, and we have nice UI to
>> configure it in-sim. However, it still requires users to set up a
>> separate directory and configure FG_SCENERY before it can be used. It
>> would be great if the standard in
On 9 Aug 2012, at 21:49, Stuart Buchanan wrote:
>>> Do we have any ideas addressing these issues?
Random thought, hopefully someone with more OSG knowledge can confirm or deny:
Can we create the geometry (and unload it) in the cull-callback? I.e set an
appropriate bounding volume for the LOD n
On 2 Aug 2012, at 20:32, Erik Hofman wrote:
> Hi,
>
> Seems like Canvas causes a reproducible segfault with the latest git
> version (master). I'm using 32 bit Ubuntu 12.04
Yep, this is my fault for causing a naming clash. Just comment out
initNasalCanvas in NasalSys.cxx for now, I'll pus
On 31 Jul 2012, at 15:50, Thomas Geymayer wrote:
>
> Maybe we should create different categories/priorities (just a numeric
> value) of windows where one window can only raise to the top inside a
> category.
Right, that's a pretty standard system in window ordering.
>
> The more I think about
On 30 Jul 2012, at 13:31, Thomas Geymayer wrote:
> I have now pushed some updates to my branch. It is now possible to
> create windows (texture rectangles) with just using the property tree
> and place a canvas texture onto it.
>
> Mouse events are passed to the active window (=the window the cu
On 30 Jul 2012, at 11:39, stefan riemens wrote:
> On a different note: window management.
> I've seen that in Tom's private branch, he has started on a window
> class (albeit, it is just a skeleton currently).
> I think we indeed want a c++ window manager, which is basically just a
> dumb "visibl
On 27 Jul 2012, at 16:37, Geoff McLane wrote:
> For a long, LONG time the small utility program
> metar.exe has failed to work in windows...
>
> It turns out WSAStartup() is NOT called, thus the
> HTTP request always fails...
>
> Applied this simple patch below, and all is
> well ;=))
>
> H
On 26 Jul 2012, at 11:28, James Turner wrote:
>> Maybe we can use some ideas from it :) Basically we only need to pass
>> mouse/keyboard events and handle dragging/resizing and input
>> focus/stacking order of multiple dialogs.
>
> This is certainly where things need
On 26 Jul 2012, at 11:09, Thomas Geymayer wrote:
> I didn't meant to replace the existing way, but instead only changing
> the implementation to use the Canvas system in Nasal space. Just
> mapping the existing dialog-show command to a Nasal function which
> creates a window and parses a GUI xml
On 25 Jul 2012, at 17:27, Thomas Geymayer wrote:
>
> We could for example just add some more parseXXX functions (like
> parsesvg) which parse a dialog/hud/whathever file and create a canvas
> from it. So we would just have to modify eg. the show-dialog command
> to create a canvas and call the p
On 25 Jul 2012, at 12:38, James Turner wrote:
> Okay, I think Stefan and I are convinced :)
Apologies for send 'the same email' twice, I'm on an erraitc connection and
thought the first one had managed to not send, but also be deleted from my
outbox, drafts /and/ sent ma
On 25 Jul 2012, at 11:42, stefan riemens wrote:
> This is very convincing! Congratulations, that looks really neat.
> Having seen this, I think we'd better go with the canvas approach. It
> would require quite a lot of code to get osgWidget to produce that...
Indeed!
Thomas, can we have a discu
On 25 Jul 2012, at 11:42, stefan riemens wrote:
> This is very convincing! Congratulations, that looks really neat.
> Having seen this, I think we'd better go with the canvas approach. It
> would require quite a lot of code to get osgWidget to produce that...
Okay, I think Stefan and I are convi
On 24 Jul 2012, at 23:11, Thomas Geymayer wrote:
>> Do you think
>> you'd be able to handle a blinking insertion point and a standard
>> draggable text selection area in this approach? Obviously it might
>> need some additional C++ helpers but that's okay since text-editing
>> is a pretty special
On 25 Jul 2012, at 00:42, ys wrote:
> This looks promising in a technical/coding perspective of having this and
> that common GUI feature available also for flightgear. But for me personally
> one of the big problems of the FlightGear GUI is that it is "inside" the only
> and one main window.
On 24 Jul 2012, at 16:45, Thomas Geymayer wrote:
> I have just experimented a bit with osgText and multi-line text. So far
> I didn't notice any problems.
My concern was about calculating sane vertical heights allowing for line-wrap,
but that appears to work, based on your demo below!
> But us
On 24 Jul 2012, at 13:22, stefan riemens wrote:
> Thanks for the feedback, and especially thanks to James for the offer!
> I think your request for POC code is very reasonable, so let me get
> back to you on that when I have some (although a combobox is already
> almost there, as it is basically
On 21 Jul 2012, at 21:46, stefan riemens wrote:
> Obviously, I think the best choice of these is to switch to osgWidget,
> and I'm willing to take that task upon me.
> I've made a clone on Gitorious, with a osgWidget MenuBar
> implementation. Its currently pretty quick and dirty, and looks
> abso
On 20 Jul 2012, at 07:22, Tim Moore wrote:
> We could use the stencil buffer without copying anything: render the
> near scene first, setting stencil bits, then enable the stencil test
> for the far scene. I believe that the stencil test has been extremely
> fast for years.
Oooh, yes - I was for
On 19 Jul 2012, at 14:32, Tim Moore wrote:
>> Do we really not run the terrain fragment shader when the terrain is seen
>> through the cockpit floor (my system seems to slow down even though no
>> terrain is seen in the event and the framerate responds to my shader quality
>> settings)?
>
> T
On 3 Jul 2012, at 11:25, Stuart Buchanan wrote:
> I don't think I saw any response to this either for or against.
>
> I realize it's a bit late, but I'd still like to do this for the 2.8.0
> release. Any
> objections?
Happy to do this in terms of risk (i.e it's trivia to back out) - and it's t
On 1 Jul 2012, at 14:47, ThorstenB wrote:
> After 2.8, I'm going to add a cmake warning for builds inside the source
> tree. Some other projects even disallow such builds (throw a
> configuration error). Maybe we should do the same some day - and then
> get rid of the ".gitignore" magic.
+1 t
On 1 Jul 2012, at 15:00, ThorstenB wrote:
> To be frank, I don't think that's the case. All new users don't know
> anything (yet). So, showing outlines which don't really mean anything to
> them, just adds to their confusion - whatever the colour (and every new
> user is already a bit confused
I happen to have a spare 8800GT (512MB, 64k rom - NOT suitable for Mac use)
First person to say they want it for something useful gets it. Ideally you'd
PayPal me the price of posting it to wherever you are in the world.
If something useful includes making shaders work better on 'slightly-older'
On 23 Jun 2012, at 19:50, syd adams wrote:
> Back when i started the ATC 'aircraft' , Csaba added an autohide
> feature to 2d panels . This keeps them on the display regardless of
> view direction. 0 needs to be added to the base
> panel xml file. Aircraft/ATC/MP-ATC-panel.xml uses it.
Except, i
On 23 Jun 2012, at 10:56, D-NXKT wrote:
> for me it's a feature and not a bug!
> I often find it useful to watch the instruments while NOT sitting in the
> cockpit. And since the panel can be switched off interactively it's up to the
> user or aircraft author to enable it or not. Indeed I would
On 23 Jun 2012, at 08:16, Catherine James wrote:
> I recently found a bug in some of the latest git build (next branch, June 13
> and later). When flying planes such as the T-38 with a 2D panel, the 2D
> panel is always displayed even when you are using an outside view. This bug
> did not ex
On 17 Jun 2012, at 20:14, Torsten Dreyer wrote:
> today is June, 17th and this marks our feature freeze for the sources of
> SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being
> part of the base package are not part of the feature freeze. Maintainers
> for those aircraft ar
On 29 May 2012, at 22:03, Thomas Geymayer wrote:
> The code is already include into flightgear/next, but some fixes and the
> Nasal API are waiting to be merged into flightgear and fgdate respectively.
>
> I have already tested many scenarios but it would be great if you can
> try it out on your
On 23 May 2012, at 13:09, Erik Hofman wrote:
>
> Hi,
>
> Year ago I added xmlgrep to the utils directory of flightgear and I have
> been developing it since. But I think it is time to remove it from the
> flightgear package and reference it tot the new location instead
> (http://www.adalin
On 20 May 2012, at 17:59, Vivian Meazza wrote:
>
> "The current implementation is a simple mark/sweep collector, which should
> be acceptable for most applications. Future enhancements will include a
> "return early" capability for latency-critical applications. The collector
> can be instructe
On 12 May 2012, at 14:37, Frederic Bouvier wrote:
> Tell me if I broke something
All working here on Mac, with and without rembrandt enabled on Mac.
BTW should there be any performance changes from this or other changes?
James
On 11 May 2012, at 19:59, Anders Gidenstam wrote:
> It doesn't solve the bigger problem of the current Nasal GC needing to
> run uninterrupted and in mutual exclusion - but I see very few GC runs in
> the main loop here (the patch prints "** Nasal GC in main thread **"
> in the console when tha
On 7 May 2012, at 07:56, Renk Thorsten wrote:
> In a fresh pull of everything as of this morning, I lost the ability to
> re-locate by choosing an airport from the list. Trying to do so results in
>
> command 'presets-commit' failed with exception
>message:invalid leg index (from Flight
On 5 May 2012, at 20:10, ThorstenB wrote:
> This is actually showing to be a really bad issue. We have loads of XML
> files with invalid encodings. Also, there's many files which even
> explicitly state
>
> so they are explicitly asking for UTF-8 decoding - but then these files
> still
On 5 May 2012, at 18:35, Geoff McLane wrote:
> Failed to load xml: not well formed (invalid token)
> at C:/fg/15/fgdata/Aircraft/c172p/Modules/Immat/imatt.xml
> line 65, column 31
> Failed to load submodel: not well formed (invalid token)
> at C:/fg/15/fgdata/Aircraft/c172p/Modules/Immat/imatt.xm
On 5 May 2012, at 09:00, Martin Spott wrote:
>> Ganael Laplanche: fix include dependencies for FreeBSD support
>
> Cool ! I'm checking the FreeBSD port almost every week, but until
> recently it's still been at 2.4, looks like this will change soon :-)
Yep, if any CMake assistance is requir
On 4 May 2012, at 14:21, Alan Teeder wrote:
> At the moment it seems to me that FG requirements are increasing faster than
> the performance of affordable computers. A few months ago I was getting
> over 60 fps with an Intel i5-2500k CPU @3.30GHz, 8Gb Ram, Nvidia GTS 450
> combination. This
On 28 Apr 2012, at 20:10, Stuart Buchanan wrote:
> 3) I've reduce the number of Drawables generated by reducing the quad
> tree depth from 3 to 2, and reducing the number of LoD leaf nodes from
> 10 to 4. James Turner - I'd be very interested if this change improves
> your
On 26 Apr 2012, at 13:20, Renk Thorsten wrote:
>
> I've just created a merge request containing the recent work I've done for
> the haze shaders (haze in water shader, dust effect, Mie scattering on
> clouds, ...).
>
> The procedure described in the wiki to create a merge request did not work
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote:
> If you're going to be looking in the code anyway, the depth of the
> quad tree is set in some constants at the top of the SGBuildingBin.cxx
> file, and (IIRC) the LoD range is also set up there, so you could see
> if reducing the depth makes a di
On 25 Apr 2012, at 14:56, Stuart Buchanan wrote:
> One benefit is better culling. The other is that we can have
> buildings gradually appear rather than all springing into view at once
> when you get within the LoD range of the center of the time (where
> objects at the edge might be significant
On 25 Apr 2012, at 14:22, Stuart Buchanan wrote:
> Perhaps I should be using a QUAD_STRIP instead. Don't know if that
> would make much difference though.
Doubtful, I'd say, if they are already in a single primitive set.
>
> The extra 300 Drawables are from the quadtree that is generated to a)
On 25 Apr 2012, at 13:35, James Turner wrote:
> Other suggestions most welcome.
Emilian suggested I check random vegetation (which generates many more quads),
at LOWI with vegetation off/onthe difference is from 50 fps down to 30ish, and
quad count goes from 100k to 200k - but nothing l
On 25 Apr 2012, at 12:56, James Turner wrote:
> Right, I can see that too. The draw / GPU times increases proportionally as
> the tiles (re-)load with buildings.
>
> It points to the actual geometry being the limiting factor, which is very
> odd.
http://files.goneabitb
On 25 Apr 2012, at 12:35, Stuart Buchanan wrote:
> I must admit that I've only tested Edinburgh and San Francisco, which
> may simply not have as much Urban area as Berlin. I'll try Berlin
> when I get the chance, but could you see if the same problem occurs at
> EGPH and KSFO?
>
Yep, second ru
On 25 Apr 2012, at 11:53, Vivian Meazza wrote:
> Removed in Git
Alas this makes no difference.
Performance drop is roughly linear in the building density, though I won't
claim it's strictly linear. Given that this is an Ati 5770, I would be
*extremely* surprised if I'm fill-rate limited.
Ver
I'm overhauling how we expose FMS related data to Nasal, to hopefully make
FMS/CDU construction in Nasal easier, but also re-using the C++ code we already
have, since many systems tie into the data.
Along the way, I'm learning a lot about the easiest way to expose C++ data to
Nasal, and I'm als
On 24 Apr 2012, at 22:09, Stuart Buchanan wrote:
> Feedback is welcome as always.
For me, the builds are extremely expensive - no idea why. The actual density
doesn't make a huge different (1.0 vs 2.0, I will experiment more later).
Eg my draw + GPU times go from 15msec to 100msec when I enab
On 25 Apr 2012, at 08:15, Durk Talsma wrote:
> 1). On my machine I'm actually experiencing an extremely startup during the
> "reading airport/nav data" stage (~up to minute or so). This usually only
> happens when I try to load flightgear for the first time. Once these files
> are buffered eve
On 25 Apr 2012, at 07:04, Renk Thorsten wrote:
> A quick 3 minute test flight with the ufo looks very promising - I didn't see
> any obvious issues with the version pulled 10 minutes ago. I will do longer
> tests later toady.
Thanks Thorsten!
James
--
On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote:
> I could by the length of the thread not exactly find what is going wrong and
> how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I
> can see that this does not match the intented use of SGReferenced.
> I have checked in
On 24 Apr 2012, at 16:50, Curtis Olson wrote:
> If an FGAirport object was ref-counted and deleted because the ref-count went
> to zero, then why would FGAirport::findClosest() still be returning a
> pointer to it it as the closest airport? Is it not getting fully/properly
> deleted or remov
On 24 Apr 2012, at 16:31, Curtis Olson wrote:
> Based on two runs with out crashing, that seems to prevent the crash ...
Okay, so that's good but leaves me wondering why it doesn't crash on Mac
the same way. And also, how I've got the ref-counting wrong.
James
--
On 24 Apr 2012, at 15:57, Curtis Olson wrote:
> I tried running with valgrind and the error didn't happen -- hmmm...
>
> Trying it again, but a valgrind startup is excruciatingly slow ...
It's probably a reference counting issue. FGAirport is a FGPositioned and hence
reference counted. The Nas
On 24 Apr 2012, at 14:39, Curtis Olson wrote:
> For what it's worth, I'm seeing nearly the same thing ... similar back
> trace-- crashing in hashforairport() about 10-15 seconds after the splash
> screen has been removed and the sim presented for use.
Okay, that's good news since it rules out
On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
> It doesn't depend - I got a crash at TNCM as well, also using both c172p and
> the ufo. So this must be something more generic.
>
>> Just to check, you have updated simgear as well? There's a bugfix in
>> there I applied at the same time.
>
>
On 24 Apr 2012, at 11:41, Renk Thorsten wrote:
> Here's the output:
>
> (gdb) bt
> #0 0x5e3d9a08 in ?? ()
> #1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
>at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
> #2 0x088ddc29 in f_airportinfo (c=0x13bedd28, m
On 24 Apr 2012, at 11:31, Renk Thorsten wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x5e3d9a08 in ?? ()
> Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386
> glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386
> libXdmcp.i386 l
On 24 Apr 2012, at 09:45, Durk Talsma wrote:
> I'll have a look at it later today. I guess this change was slowly but
> increasingly becoming necessary. I'll let you know if I see any undesirable
> side effects.
Well, the main thing needed is to break apart the 'finishInit' into more steps,
t
On 24 Apr 2012, at 09:20, Renk Thorsten wrote:
>> Can you get a backtrace?
>
> I can try if you tell me what I need to do...
(re-)Build fgfs with debug symbols:
-DCMAKE_BUILD_TYPE=Debug
when running cmake, might need to make clean + make again
then run fgfs
gdb fgfs
run --log-level=
On 24 Apr 2012, at 08:28, ThorstenB wrote:
> If data needs to be loaded anyway (airport codes/positions), then
> distributing it to tons of individual files may not help with start-up
> delays either.
>
> James really needs to comment on nav data things though, since I never
> touched this ar
Just so people know, I made a change to how AI traffic is started (so you can
ignore this email if you run with traffic turned off) to avoid the long pause
during 'initialising subsytems' when all the XML schedules are parsed and
loaded.
This has a few effects - the app doesn't go unresponsive
On 24 Apr 2012, at 09:04, Renk Thorsten wrote:
> I've just pulled and compiled simgear and flightgear and pulled a fresh
> FGData to start package the next lightfield shader version, but it turns out
> the resulting binary is unstable.
>
> I get segfaults about 10 seconds after startup with th
On 22 Apr 2012, at 15:06, Vic Marriott wrote:
> James, I think you have an advantage in that you run Linux on your Mac, so
> you can utilise the best of both worlds.
Actually I don't - it's OS-X all the way for me, in terms of running FG. I have
Linux VMs to check builds, but there's no OpenGL
On 22 Apr 2012, at 03:14, Flightgear-commitlogs wrote:
>Bravo updates.changed map range select;property-cycle too buggy
Something to be fixed here?
(In a backwards compatible way...)
James
--
For Developers, A Lo
On 19 Apr 2012, at 09:50, Vic Marriott wrote:
> I have discussed this with Tat, and he has managed somehow (I don't even
> understand what most developers are talking about) to make each new release
> work on my machine.
>
> I have a 3 year old iMac running OS X 10.6. I don't consider this to
On 19 Apr 2012, at 21:48, Gene Buckle wrote:
> I updated the Jenkins machine today - BIG jump - went from 1.42 to 1.460,
> picking up a ton of bug fixes in the process.
Excellent, thanks Gene.
>
> James - the Mac slave may need to be updated to the latest Jenkins code.
>
> If anyone spots a
On 18 Apr 2012, at 10:25, Stuart Buchanan wrote:
> There are still some bugs to be worked out before this can be pushed
> to git, but I'm hoping to get it checked in over the weekend.
Fantastic.
And, the performance numbers confirm many discussions here - the batched
geometry with no state ch
On 18 Apr 2012, at 10:00, ThorstenB wrote:
> Indeed. It got broken when the evaluation of command-line options was
> restructured. I'm adding this to the bug report...
Whoops, my bad.
Will take a look.
James
--
Bette
On 14 Apr 2012, at 09:48, Olaf Flebbe wrote:
> I had a texture-size limiter for flightgear in the past. I have to dig it out
> first.
Okay, I think it would be a good thing to have anyway, since people have wildly
varying amounts of GPU ram
>
> But please have a look at these textures. I do
On 14 Apr 2012, at 10:10, Mathias Fröhlich wrote:
> But every image goes through our hands. We can just rescale this under
> certain
> conditions. At least the uncompressed textures are unproblematic.
> I would introduce some property that is evaluated in the image load callback
> than. Today
On 13 Apr 2012, at 23:28, Chris Forbes wrote:
> Presumably you could just ask osg or the gl to discard the top mip level(s)
> rather than altering the source art to work around apple's driver bugs?
Yeah, unfortunately I think people want the high-res art for a reason - this
needs a runtime tes
On 12 Apr 2012, at 14:54, gap...@gapalp.net wrote:
> I did note the results were slow. It can take up to 5 - 10 seconds to
> generate the list.
>
> I am looking for a list of ICAOs that branch out from one's current airport
> within a radius. The below method returns what I want, albeit a bi
On 12 Apr 2012, at 08:24, Renk Thorsten wrote:
> 3) On my box, all three panels in the screen edges show the same image - not
> so on Fred's videos - is this the intended behaviour?
This is the important one - it means the multiple render targets isn't working,
so you have no chance of seeing
On 11 Apr 2012, at 20:48, gap...@gapalp.net wrote:
> pos = SGGeod::fromDeg(lonn->getDoubleValue(), latn->getDoubleValue());
> apt = FGAirport::findClosest(pos, maxRange, &filter);
> string id = apt->ident();
>
> The above results in id being the single nearest ICAO. Throw this in a loop
> and i
On 4 Apr 2012, at 17:22, Frederic Bouvier wrote:
> It was part of a "fix" I pushed late yesterday night. My NVidia driver
> didn't protest though.
>
> Thank you for finding this and for the debugging help.
No problem, delighted to help any way I can.
I wasn't complaining at you, more at the s
On 4 Apr 2012, at 17:00, Frederic Bouvier wrote:
> Thank you James,
>
> Can you push that to gitorious ?
Done.
Looking at the language docs, 'varying' in a fragment shader really is a
synonym for 'in', and hence, it makes sense (to me) that assignment to an input
is disallowed.
But I'm curi
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote:
> The shadow is rendered in the image in sunlight.frag so this is not the
> problem but the inputs are weird, so is the lighting.
>
> You disabled *all* shaders, right ?
Just made (and pushed) a Simgear tweak to identify the shader names :)
FRA
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote:
> You disabled *all* shaders, right ?
--prop:/sim/rendering/shaders/quality-level=0
In my fgfsrc.
James
--
Better than sec? Nothing is better than sec when it comes
Before I say anything else, please know this work is hugely appreciated, and if
there's any more I can do to help, just ask.
With latest everything, as of a few minutes ago, something odd has happened:
http://files.goneabitbursar.com/fg/rembrandt-ati-mac-040412.png
Note
- the no
On 30 Mar 2012, at 16:03, Frederic Bouvier wrote:
> The lighting problem has been fixed and the shadows are in since
> this morning. Shadow resolution is configurable in the preferences
> by changing /sim/rendering/shadows/map-size before starting fgfs.
Basically works here, but the shadow seem
On 28 Mar 2012, at 12:21, HB-GRAL wrote:
> I had some problems compiling simgear release/2.6.0 using zlib 1.2.6 on
> OSX. Looks like the main problem is here (independent of platform?):
>
> lowlevel.hxx
>
> void sgReadString ( gzFile fd, char **var ) ;
>
> lowlevel.cxx
> -
On 26 Mar 2012, at 21:05, Frederic Bouvier wrote:
> I presume I am drawing to the front buffer instead of the back buffer
Same here on Mac/Ati BTW, I did guess it was a temporary draw to the wrong
buffer.
James
--
Th
301 - 400 of 1287 matches
Mail list logo
