Found the cause:
This happen with the AI demo
AI/refueling_demo.xml
IT does not use any Flightplan
the others _demo_1 and _demo_2 does
they don't make any error message.
Does it mean right now, every AI aircraft tankers wants a Flightplan ?
With FG 2.12 it was not necessary.
Thanks
On 13 Oct 2013, at 12:04, Flightgear-commitlogs mar...@hypersphere.calit2.net
wrote:
+catch(...)
+{
+ naRuntimeError(c, Unknown exception in method call.);
+}
+
I am slightly concerned about catching all exceptions this way - I agree
2013/10/14 James Turner zakal...@mac.com:
+catch(...)
+{
+ naRuntimeError(c, Unknown exception in method call.);
+}
+
I am slightly concerned about catching all exceptions this way - I agree
catching std::exception is worthwhile, with the
Hello,
with FG 2.99 Data i am getting
Nasal runtime error: No such member: asin
at /devel/fgdata_git/Nasal/geo.nas, line 173
called from: /devel/fgdata_git/Nasal/view.nas, line 306
called from: /devel/fgdata_git/Nasal/view.nas, line 265
called from: /devel/fgdata_git/Nasal/view.nas, line
On Mon, 14 Oct 2013, grtuxhangar team wrote:
Hello,
with FG 2.99 Data i am getting
Nasal runtime error: No such member: asin
at /devel/fgdata_git/Nasal/geo.nas, line 173
called from: /devel/fgdata_git/Nasal/view.nas, line 306
called from: /devel/fgdata_git/Nasal/view.nas, line 265
called
http://www.kickstarter.com/projects/technicalillusions/castar-the-most-versatile-ar-and-vr-system
The castAR stands to do a LOT to improve the visuals for both DIY and
commercial flight simulators. Because it's AR and not VR, it can also
be used to generate in-cockpit displays by covering the
Geoff,
Thanks for testing this.
I left a set -x on line 371 which causes the double output you're
seeing on -h. I've removed it.
Also, I've changes the svn
for plib to http://svn.code.sf.net/p/plib/code/trunk/.
OSG and PLIB are slated for different treatment in a future version.
If the
Hello Anders,
Thanks for the quick reply, yes we had some sync issue with our Git.
right now that's OK
Kind regards,
Ahmad
On 14 October 2013 14:15, Anders Gidenstam anders-...@gidenstam.org wrote:
On Mon, 14 Oct 2013, grtuxhangar team wrote:
Hello,
with FG 2.99 Data i am getting
Following a 'tradition', I'd like to remind of a few issues which I think
should perhaps be sorted out before 3.0, partially have been discussed
previously and involve me asking for some help on the C++ side.
1) rain layers still do not drift with the wind and will be eventually
displaced
7) runway signs in ALS still rendered as terrain and have assigned texture
of rocks/cliffs.
2013/10/13 Renk Thorsten thorsten.i.r...@jyu.fi
Following a 'tradition', I'd like to remind of a few issues which I think
should perhaps be sorted out before 3.0, partially have been discussed
On 13 Oct 2013, at 12:02, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
1) rain layers still do not drift with the wind and will be eventually
displaced from their cap clouds. I've discussed this previously with James
who suggested that a generic way of spawning AI objects (which can get a
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote:
This is to give a heads up on some changes that I'm planning for
Random Buildings for the V3.0 release, and to allow for
comments/suggestions/ideas.
I've now got the new system broadly working on a private build:
On Fri, 11 Oct 2013, Stuart Buchanan wrote:
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote:
This is to give a heads up on some changes that I'm planning for
Random Buildings for the V3.0 release, and to allow for
comments/suggestions/ideas.
I've now got the new system broadly
Hi Tim,
On Fri, Oct 11, 2013 at 12:55 PM, Tim Moore wrote:
Cool stuff. Are those all individual models, or instanced geometry, or what?
:)
The vast majority are instanced geometries, though there are some random
models interspersed.
As mentioned previously, I'd like to move back to the
Not sure what went wrong but i get this error consistently now:
Nasal runtime error: props.setValue() with non-number
at /media/FG/fgdata/Nasal/props.nas, line 29
called from: __dlg:gps, line 20
called from: __dlg:gps, line 134
Segmentation fault (core dumped)
On Fri, Oct 4, 2013 at 1:48
It's now getting on for a week since the build on Simgear was broken for Win
64/MSVC by this mistake. Any chance of a fix sometime soon?
Vivian
From: James Turner [mailto:zakal...@mac.com]
Sent: 03 October 2013 22:53
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel]
On 9 Oct 2013, at 10:23, Vivian Meazza vivian.mea...@lineone.net wrote:
It’s now getting on for a week since the build on Simgear was broken for Win
64/MSVC by this mistake. Any chance of a fix sometime soon?
Yes, was just about to push one - however you can always push such a fix
yourself!
James
Sorry, but the patch failed. It also needs the change suggested by Gijs, with
“double x,y;”
e.g.
static naRef f_round(naContext c, naRef me, int argc, naRef* args)
{
double x,y;
naRef a = naNumValue(argc 0 ? args[0] : naNil());
naRef b = naNumValue(argc 1 ? args[1] :
On 9 Oct 2013, at 12:05, Alan Teeder ajtee...@v-twin.org.uk wrote:
Sorry, but the patch failed. It also needs the change suggested by Gijs, with
“double x,y;”
e.g.
Ah, I really hate C89 :)
Fix coming up.
James--
On Wed October 9 2013 12:23:56 James Turner wrote:
On 9 Oct 2013, at 12:05, Alan Teeder ajtee...@v-twin.org.uk wrote:
Sorry, but the patch failed. It also needs the change suggested by Gijs,
with “double x,y;” e.g.
Ah, I really hate C89 :)
Fix coming up.
Two same. Why not compile in cxx
Hey,
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the same
box that runs pypy buildbots aurora/ananke.
If you need integration testing for Windows, please respond either here or
privately.
The buildbot is Ivy Bridge i7 HT on, with 32 gigs-o-RAM. Only eight (?) are
On Wed, 9 Oct 2013, Stanisław Halik wrote:
Hey,
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the same
box that runs pypy buildbots aurora/ananke.
I take it you're not aware of http://flightgear.simpits.org:8080 ?
g.
--
Proud owner of F-15C 80-0007
On Wed October 9 2013 06:26:40 geneb wrote:
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the
same box that runs pypy buildbots aurora/ananke.
I take it you're not aware of http://flightgear.simpits.org:8080 ?
Yeah but i4dnf on IRC said win32 one is turned off.
-sh
On Wed, 9 Oct 2013, Stanisław Halik wrote:
On Wed October 9 2013 06:26:40 geneb wrote:
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the
same box that runs pypy buildbots aurora/ananke.
I take it you're not aware of http://flightgear.simpits.org:8080 ?
Yeah but i4dnf
On Wed October 9 2013 06:56:18 geneb wrote:
On Wed, 9 Oct 2013, Stanisław Halik wrote:
On Wed October 9 2013 06:26:40 geneb wrote:
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the
same box that runs pypy buildbots aurora/ananke.
I take it you're not aware of
On Wed, 9 Oct 2013, Stanisław Halik wrote:
On Wed October 9 2013 06:56:18 geneb wrote:
On Wed, 9 Oct 2013, Stanisław Halik wrote:
On Wed October 9 2013 06:26:40 geneb wrote:
I can run a win32 buildbot with either MSVC 2008[1] or mingw-w64 on the
same box that runs pypy buildbots
James
Seems all OK now.
Thanks
Alan
P.S. MSVC has no compilation problems with the other commits you made today
wlEmoticon-winkingsmile[1].png
Description: Binary data
--
October Webinars: Code for Performance
Free
Am Mittwoch, 9. Oktober 2013, 01:37:27 schrieb syd adams:
Not sure what went wrong but i get this error consistently now:
Nasal runtime error: props.setValue() with non-number
at /media/FG/fgdata/Nasal/props.nas, line 29
called from: __dlg:gps, line 20
called from: __dlg:gps, line 134
No , Im not sure what caused the segfault... but the error message appears
every time i try to use gps navigation ( with the b1900d).Another change in
behavior is the heading needle deflection is extremely sensitive now when
using nav1 slaved to gps. I could be wrong , i dont have the docs in
If its any help , the error message pops up the instant the gps dialog is
opened.The dialog seems to work regardless , so Im not sure what the
problem is.
Syd
On Wed, Oct 9, 2013 at 1:20 PM, syd adams adams@gmail.com wrote:
No , Im not sure what caused the segfault... but the error message
Also, double x; needs to be declared at the top of the function (and then you
will have x = round(a.num / b.num); of course).
Cheers,
Gijs
--
October Webinars: Code for
James,
On 10/04/2013 08:43 PM, James Turner wrote:
I haven't taken a copy of the libsubversion and
forked/edited/trimmed it - it's completely unrelated code.
Aha, I wasn't aware of that. Sounds like a different story, then.
Does that still cause problems under to policies described above?
Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote:
The improved-issue1164 is ready.
https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887:
Thanks, looks good and
On 4 Oct 2013, at 19:29, Markus Wanner mar...@bluegap.ch wrote:
That smells like trouble from a packaging standpoint. It's usually not
acceptable, because most of the time, the integrated library isn't
getting the amount of support the original does.
For Debian, I'll certainly have to
On 3 Oct 2013, at 12:38, Saikrishna Arcot saiarcot...@gmail.com wrote:
Just to check, is the built-in SVN code effectively replacing the
external SVN code (from libsvn-dev), or does it add something?
Replaces it - one of the big motivations is that the libsvn dependency is
becoming
Hi James,
The improved-issue1164 is ready.
https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887:
Dirk
Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner:
- please make a helper function for the great-circle XTK error function,
with some sane
On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com wrote:
The improved-issue1164 is ready.
https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887:
Thanks, looks good and pushed.
Unfortunately I now need to fix the route-path code to
Re commit ad83e70cf5983c7b307847aa2cb92c40e42bc534
Author: James Turner
Date: Thu Oct 3 17:40:17 2013 +0100
Extend built-in Nasal math.
James
Sorry, but MSVC does not have a round function. ;(
Alan
--
On 3 Oct 2013, at 22:20, Alan Teeder ajtee...@v-twin.org.uk wrote:
Sorry, but MSVC does not have a round function. ;(
Yes, C99 is a cutting-edge spec :)
I'll add a replacement for MSVC, thanks for spotting my mistake.
Kind regards,
James
http://wiki.flightgear.org/Talk:Nasal_Style_Guide
On Thu, Oct 3, 2013 at 9:38 PM, James Turner zakal...@mac.com wrote:
On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
wrote:
The improved-issue1164 is ready.
Can I make a suggestion..
What I want to do is create a simg...@freeflightsim.org as an user.
The idea is to knock out the latest bleeding edge docs and changes to
simgear..
Example is here..
http://docs.freeflightsim.org/simgear/
But I prefer a sub domain..
On the server,
Doxygen is installed
Hello everybody,
I'm experimenting with the Bumpmap/Specmap Shader on my Aircraft and got
to a point where it is necessary to change the specmap file with the
selected Livery.
Especially with partly aluminium finished Aircraft it would be good to
swap the specmap file used to properly display
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote:
branche fix-issue1164 @ my clone
https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b:
Hi Dirk, this is looking pretty good, just some small nitpicks:
- please make a helper
Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner:
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote:
branche fix-issue1164 @ my clone
https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b:
Hi Dirk, this is looking
On 1 Oct 2013, at 22:34, Dirk Dittmann dirk.dittmann@gmail.com wrote:
I understand and will make the improvements. Thx for the hind ! I squash the
commit and improve readability. Is there any code convention documentation ?
Which I could read?
No, there's rules, since the codebase
Hello,
Improved the Cross track error according to the great circle.
http://williams.best.vwh.net/avform.htm#XTE.
And make the overflight sequence configurable for the aircraft. The default is
the same.
/instrumentation/gps/config/over-flight-arm-angle-deg 90
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote:
Improved the Cross track error according to the great circle.
http://williams.best.vwh.net/avform.htm#XTE.
Great,.
And make the overflight sequence configurable for the aircraft. The default
is
the same.
Am Montag, 30. September 2013, 09:00:19 schrieb James Turner:
On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com wrote:
Improved the Cross track error according to the great circle.
http://williams.best.vwh.net/avform.htm#XTE.
Great,.
And make the overflight sequence
It actually does solve issue 1164 (which I started).
When one switches to the next waypoint, the active leg course and x-track-error
relate to the leg between the previous and active waypoint of the flightplan
(as it should in LEG mode). Previously the leg (-course and x-track-error) was
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote:
It actually does solve issue 1164 (which I started).
When one switches to the next waypoint, the active leg course and
x-track-error relate to the leg between the previous and active waypoint of
the flightplan (as
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com wrote:
The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design
a lot easier.
Incidentally if you (Dirk) are looking at this code, the really great thing
would be to get the turn-anticipation code
To be honest I did not put any CDI in (yet). And it is coded in JSBSim, not
Nasal (want to keep the plane flyable on my not so top-of-the-notch computer).
I just turn the aircraft for a certain period of time (based on groundspeed,
turn rate, ground track, nex leg course) and than switch over
Am Montag, 30. September 2013, 12:52:08 schrieb James Turner:
On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com
wrote:
The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP
design a lot easier.
Incidentally if you (Dirk) are looking at this code, the
Here is a quick heads up for everyone.
On October 2, at about 8pm USA Eastern Time Zone (GMT-5), the main
FlightGear server will be down for scheduled maintenance for about 30-60
minutes. The physical hardware is being relocated to a larger facility.
Thanks for your patience!
Curt.
--
Curtis
Ok, it was my mistake, sorry for false alarm.
The problem was that OSG was build without Freetype support (headers
weren't installed) - this caused the message about not found font though
the real problem was that freetype plugin was missing. And default font
whatever it was didn't have Unicode
Hello,
The docs say that FG supports Unicode. However I tried to use degree sign
in the tooltip (inserted it literally to XML in UTF-8) and load some SVG to
canvas with UTF-8 text - in both cases Unicode text simply isn't shown,
thought everything else is OK. BTW when starting FG I get the
Either way, that error message is wrong.
Cole Johnson
-- E-mail: coleharrisjohn...@gmail.com
-- Twitter: @5urd
Hexware, LLC
-- Twitter: @HexwareLLC
On Sat, Sep 28, 2013 at 9:59 AM, Tomash Brechko tomash.brec...@gmail.com
wrote:
Hello,
The docs say that FG supports Unicode. However I
Recently I was told that some planes have liveries of so high resolution
that you have to install low resolution versions to have a decent fps
during multiplay. But doesn't FG use mipmaps for liveries? If not then
are there plans to do so? Or should the livery be prepared in a certain
On 26 Sep 2013, at 07:18, Renk Thorsten thorsten.i.r...@jyu.fi wrote:
Mipmaps for textures are pretty generic for the rendering process. If you
would not mipmap textures, they'd create flickering Moire patterns whenever
the texture resolution is higher than the screen resolution as
On Thu, Sep 26, 2013 at 8:27 AM, James Turner wrote:
Just to say, Thorsten has in this case saved me writing an email, thanks.
To re-iterate - GPU VRAM is a precious commodity, so we should spend it on
texels you can actually see.
One further point to make is that we do have the AI/Aircraft
On 26 Sep 2013, at 11:22, Stuart Buchanan stuar...@gmail.com wrote:
One further point to make is that we do have the AI/Aircraft directory
specifically
used for low-poly/resolution models.
So, if there are specific aircraft that are causing problems, arguably
the correct
way to resolve
Kindly tell me the platform and code for only simulating the some aircraft
like jaguar graphics. My interest is to simulate flight by giving string of
aircraft data necessary for flight like velocity, acceleration, roll,
pitch, yaw and control surface positions.
Thanks
Please reply on this mail-id
I'm not trying to convince anyone to use hi-res liveries. But several
people reported that hi-res aircrafts break fps in MP, and downscaling
liveries solves the problem (and this follows from Stuart's email). But if
mipmap _is_ applied to liveries, then why we have to have lo-res liveries
On 09/26/2013 12:30 PM, James Turner wrote:
Some of the folks on the fourm have been doing greta work up the AI
models of our transport-category aircraft, mostly to improve appearance
of Traffic. The A320 and A330 have had overhauls and now look great, and
I believe the Boeings are next on
I was reviewing the current menu structure and would like to propose a couple
of changes. Partly because we have too many menus, all quite short, but also to
remove some bad terminology.
Each of these changes is independent, comments explicitly requested:
- merge 'Autopilot' into the
On 26 Sep 2013, at 11:33, Erik Hofman e...@ehofman.com wrote:
On that topic, there's a static 737 on the taxi tracks that's there
since the old days when there was no AI traffic, it is probably a good
idea to remove it from the scenery now.
Mostly i agree, but it's sort of a piece of FG
On 09/26/2013 12:47 PM, James Turner wrote:
On 26 Sep 2013, at 11:33, Erik Hofman e...@ehofman.com
mailto:e...@ehofman.com wrote:
On that topic, there's a static 737 on the taxi tracks that's there
since the old days when there was no AI traffic, it is probably a good
idea to remove it from
I always thought it was a 737 hulk used for fire crew training.
I think there's no reason why mipmaps could not be pre-generated for formats
other than DDS, nothing stops FGFS from defining a texture as a combination of
a series of images and a snippet of XML code describing the way these are
Stuart Buchanan stuar...@gmail.com hat am 26. September 2013 um 12:22
geschrieben:
[snip]
Perhaps we should mandate that aircraft over a certain size should have an AI
version created?
There is an alternative to an AI Version. For Aircraft with Livery Select it is
possible to have
On 26 Sep 2013, at 13:04, Erik Hofman wrote:
On 09/26/2013 12:47 PM, James Turner wrote:
On 26 Sep 2013, at 11:33, Erik Hofman e...@ehofman.com
mailto:e...@ehofman.com wrote:
On that topic, there's a static 737 on the taxi tracks that's there
since the old days when there was no AI
Hi Satish,
On Thu, Sep 26, 2013 at 10:50 AM, Satish Srivastava wrote:
Kindly tell me the platform and code for only simulating the some aircraft
like jaguar graphics. My interest is to simulate flight by giving string of
aircraft data necessary for flight like velocity, acceleration, roll,
Also the question to GPU gurus: I think most aircrafts that have hi-res
liveries do so because of several small signs here and there. So does it
makes sense to have a lo-res opaque texture that paints aircraft's body,
and then a hi-res transparent one that places signs on top of the first?
This
But several people reported that hi-res aircrafts break fps in MP, and
downscaling liveries solves the problem (and this follows from Stuart's
email). But if mipmap _is_ applied to liveries, then why we have to have
lo-res liveries separately? Won't one of mipmap levels do the same?
Le 26/09/2013 12:30, flightgear-devel-requ...@lists.sourceforge.net a
écrit :
Message: 8
Date: Thu, 26 Sep 2013 06:18:53 +
From: Renk Thorstenthorsten.i.r...@jyu.fi
Subject: Re: [Flightgear-devel] Mipmapping of liveries
To: FlightGear developers discussions
On Thu, Sep 26, 2013 at 11:45 AM, James Turner wrote:
I was reviewing the current menu structure and would like to propose a couple
of changes. Partly because we have too many menus, all quite short, but also
to remove some bad terminology.
Each of these changes is independent, comments
2013/9/26 Renk Thorsten thorsten.i.r...@jyu.fi
Full GPU memory leads to performance deterioration.
Well, I'm not entirely convinced that plus-munis some tens of MBs made a
difference in one case I heard of (tu154b, five 1024x1024 textures for the
exterior). Yet I'm convinced that mipmap alone
Keep in mind that texture resolution alone doesn't tell you much unless you
know how much surface area is fitted into it. Some planes fit both sides
of wings, fuselage, gears and much more into a single rectangle so it being
of hi-res doesn't mean that you can see every grain of sand on a tire.
Another approach could be the use of multiple UV layers, like other game
engines, err, scenegraphs use. One base texture, and one or more uv layers for
decals, with the possibility to define in the material properties if a texture
repeats or not. the limit here is posed by the use of a model
On Thu, 26 Sep 2013 11:45:38 +0100
James Turner wrote:
The Autopilot menu change does make sense (although there may possibly be a
case for keeping such a flight-critical menu rapidly accessed at the top level?)
- potentially rename 'Environment' to 'World'
If most of the AI stuff moves to
On 26 Sep 2013, at 16:21, AJ MacLeod aj-li...@adeptopensource.co.uk wrote:
That's exactly what the word environment means though, isn't it! I really
don't think there's any point at all in changing the name of that menu entry;
the current one perfectly accurately describes things around
The Autopilot menu change does make sense (although there may possibly be a
case for keeping such a flight-critical menu rapidly accessed at the top
level?)
I don't see this need. When I'm in a hurry, I use my left hand to enter a
keyboard shortcut, rather than taking my right hand off the
Hi,
- merge 'Autopilot' into the Equipment menu, as a section (probably the
first section)
I have no objection with this.
- potentially rename 'Environment' to 'World'
Environment word looks fine to me.
A quick search on Google reveal that X-Plane use Environment but FSX use
World.
You know one of the things that needs to happen with light-year is that the
menus need to be accessible for the visually impaired it is very difficult to
get to the menus we need to see the menus on the menu bar and have a little
more accessibility to this because I use this mostly by keyboard
Just because I opened this thread - let me close it:
The PPA works beautiful now - thanks a million to Saikrishna.
For details you may see
http://www.flightgear.org/forums/viewtopic.php?f=20t=20884p=190573#p190573
jomo
On Tue, Sep 24, 2013 at 6:04 PM, Tomash Brechko
tomash.brec...@gmail.com wrote:
Hello,
Recently I was told that some planes have liveries of so high resolution
that you have to install low resolution versions to have a decent fps during
multiplay. But doesn't FG use mipmaps for liveries? If
Why limit yourself to only one downscale level? Mipmap can go several
levels down, so it doesn't make much difference whether you started 4096 or
2048 (leaving space issues aside).
I suppose mipmaps aren't used for liveries in FG. What would be the cost
to do so? It doesn't sound right that
On Wed, Sep 25, 2013 at 3:37 PM, Tomash Brechko
tomash.brec...@gmail.com wrote:
Why limit yourself to only one downscale level? Mipmap can go several
levels down, so it doesn't make much difference whether you started 4096 or
2048 (leaving space issues aside).
I used the first mipmap level
Ah, I see your point now, sorry. Still, crunching 256x256 texture to
produce a 10-pixel image of a plane at a distance is surely a lot better
than crunching original 4096x4096.
2013/9/26 Gary Neely grne...@gmail.com
I used the first mipmap level as an example of the effect at any given
On second thought I'm starting to have doubts about what you are saying
being true. I thought that the engine chooses right mipmap size based on
the estimate of the dimensions of the resulting screen projection. And if
it works like you describe than there should be some absolute scale for all
100 / cos(45), but you get the idea ;)
2013/9/26 Tomash Brechko tomash.brec...@gmail.com
On second thought I'm starting to have doubts about what you are saying
being true. I thought that the engine chooses right mipmap size based on
the estimate of the dimensions of the resulting screen
On Wed, Sep 25, 2013 at 4:46 PM, Tomash Brechko
tomash.brec...@gmail.com wrote:
100 / cos(45), but you get the idea ;)
OK, I see what you're getting at now-- the selection of the mipmap for
rendering rather than the memory footprint. Yes, that makes sense to
me-- the engine should be able to
But high res liveries already there, so the choice is between using more
memory or having low fps. I think the choice should be obvious: if you do
have spare memory, not using it doesn't make you any good.
Quite recently there was a discussion about 2048x2048 textures for scenery,
and I'm sure
Almost..
Just got this message.. when installing the apt...
E:
/var/cache/apt/archives/flightgear-data-base_2.12.0-0ubuntu1~ppa3_all.deb:
trying to overwrite
'/usr/share/games/flightgear/Scenery/Terrain/w130n30/w123n37/942035.stg',
which is also in package fgfs-scenery-base 2.10.0-0ppa3
Not
Le 25/09/2013 23:39, Gary Neely a écrit :
I've felt my machine come to a crawl while
certain planes are loaded in MP-- I had to remove some because they
were too much of a hit for my poor aging system.
it's the same here, FG take age sometimes to load 3D stuff, mostly
because it create the
You need to first remove the older packages: sudo apt-get remove
flightgear simgear fgfs-base fgfs-models-base fgfs-scenery-base
fgfs-aircraft-*
On Wed 25 Sep 2013 05:48:35 PM EDT, Pedro Morgan wrote:
Almost..
Just got this message.. when installing the apt...
E:
2013/9/26 jean pellotier jean.pellot...@wanadoo.fr
it's the same here, FG take age sometimes to load 3D stuff, mostly
because it create the mipmap on the fly,
At this point I'm kinda lost :). Back to my original question then: does
FG mipmaps liveries by default, or does it not? It's not
Thats whats happening..
So another 2 hours download here in wales on a clean machine..
Broadband is sooo slw here..
;-)
On Thu, Sep 26, 2013 at 12:15 AM, Saikrishna Arcot saiarcot...@gmail.comwrote:
You need to first remove the older packages: sudo apt-get remove
On 26/09/2013 01:16, Tomash Brechko wrote:
2013/9/26 jean pellotier jean.pellot...@wanadoo.fr
mailto:jean.pellot...@wanadoo.fr
it's the same here, FG take age sometimes to load 3D stuff, mostly
because it create the mipmap on the fly,
At this point I'm kinda lost :). Back to my
Tried this out myself . A work of art ! I agree this should be one of the
default aircraft.
On Sat, Sep 21, 2013 at 3:48 PM, James Turner zakal...@mac.com wrote:
On 20 Sep 2013, at 22:16, Stuart Buchanan stuar...@gmail.com wrote:
Possible candidate for default aircraft for V3.0?
Just had
Hello,
Recently I was told that some planes have liveries of so high resolution
that you have to install low resolution versions to have a decent fps
during multiplay. But doesn't FG use mipmaps for liveries? If not then
are there plans to do so? Or should the livery be prepared in a certain
1 - 100 of 36130 matches
Mail list logo
