On Sunday, September 22, 2013 12:34:32 Thomas Albrecht wrote:
> With my python coding for OSM buildings in FG coming along nicely, I
> recently thought about creating semi-generic bridges. Is anyone else
> working on this? Or is anyone aware of an open source procedural bridge
> generator? Searchin
On Friday, September 20, 2013 13:04:32 Stuart Buchanan wrote:
>
> If I implement a PagedLOD approach, it might reduce the memory
> footprint sufficiently that we could switch back to the OSG
> primitives.
>
I think one of the problems is that most of our objects have no concept of
different LOD
On Wednesday, September 18, 2013 19:05:22 Stuart Buchanan wrote:
> I did take a look at the PagedLOD approach - Matthias' code made a great
> template to work from.
>
>
> -Stuart
Stuart, this is totally unrelated, but what would be the price to pay to have
collision with generated buildings, an
On Wednesday, September 18, 2013 18:45:09 James Turner wrote:
> (BTW Adrian proposed something which achieves a similar end result back in
> February, the problem with his approach is it doesn't work via the OSG
> paging mechanism, and hence I don't think we should pursue it - ultimately
> we need
On Wednesday, September 18, 2013 21:06:48 Renk Thorsten wrote:
> > - a baseline texture set that is of adequate, but not high quality
> >
> > (e.g. max 1024x1024 size for landcover, or something else agreed to be
> > good enough) to be included by default in the installers
> >
> > (this w
On Tuesday, September 17, 2013 20:52:16 Curtis Olson wrote:
> If someone decides to jump into this, another feature that would be cool
> would be to stream the display out as a video stream which could then be
> played by any number of video players on a remote computer (like mplayer.)
> ffmpeg pr
On Tuesday, August 20, 2013 01:08:42 Clement de l'Hamaide wrote:
> Hi all,
>
> I've finished FGCom integration, fg/flightgear and fg/fgdata repo are ready
> for test. On FlightGear side there is a -DENABLE_IAX variable set to ON as
> default. In order to use the new feature you must add --enable-f
On Thursday, August 15, 2013 22:52:34 Clement de l'Hamaide wrote:
>
> - As main problem I see in the ranges of frequencies:
> In the new integrated FGCom ranges is dynamically calculated depending of
> the altitude of the pilot/ATC in accordance to this formula :
> http://fr.wikipedia.org/wiki/Rad
On Friday, August 09, 2013 15:47:57 Curtis Olson wrote:
> For a work project I ended up modifying a qt program (C++) to talk to the
> FlightGear interface. I pulled in the plib socket routines and used those,
> mostly because I was unaware of/unfamiliar with the qt socket routines. My
> approach
On Friday, August 09, 2013 13:21:45 James Turner wrote:
> Qt sockets are very thin wrappers around BSD / Windows sockets. More likely
> to be a character set / encoding issue? Remember you need to be explicit
> about encoding when going from 8-bit representation to a QString.
>
> That said I've no
Hi all,
I'm writing an application which uses a socket to connect to Flightgear's
telnet interface, and I have encountered the following issue:
Writing to Flightgear is fine, but while reading the socket, some properties
have weird values, and some characters are getting replaced (L is sometime
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote:
> Hi,
>
Hi all,
I have added my new code for far-tiles in a merge request for flightgear and
simgear. You can now test the code, and also check whether texture resizing is
necessary for materials which are not inside the near tiles
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote:
Hi Mathias,
> Ok, for that, I can see a lot of solutions.
>
> Having one that is may be close:
> Use the BVH tree that is used in fgelev or fgai. The fgelev one is
> parametrized like you probably need today. There is one hacky switc
On Sunday, December 16, 2012 22:38:41 Mathias Fröhlich wrote:
> Hi,
>
> On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote:
> > I am aware there are better systems out there, I'm just doing what I can
> > within the restrictions of the BTG format. I'd be mor
On Sunday, December 16, 2012 21:18:10 Stuart Buchanan wrote:
> On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote:
> > It' basically very simple. Far tiles no longer compute anything other
> > than it's own geometry, and also use a very low resolution texture set,
On Sunday, December 16, 2012 21:37:37 James Turner wrote:
> On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
> > I'm surprised there's any benefit to using a very low resolution texture
> > set. Surely the normal textures are already loaded by OSG and it's
> > cheaper just to refer
> > to those rat
On Sunday, December 16, 2012 18:39:47 Mathias Fröhlich wrote:
> Hi Adrian,
>
> The same idea is behind the osg lod based whole world model.
> Where do you store the elevation data?
>
> Greetings
>
> Mathias
>
Hi Mathias,
It's actually nothing really special about it, I'm just modifying a littl
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote:
> Hi Adrian,
>
> On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote:
> > I am presenting an experimental (WIP) method to reduce memory consumption
> > by scenery with 30%, while increasing the visibility dista
Hi all,
I am presenting an experimental (WIP) method to reduce memory consumption by
scenery with 30%, while increasing the visibility distance 4 times.
This method relies on some kind of LOD system, without mesh simplification.
People smarter than me can come up with a safe algorithm to do that,
On Friday, December 14, 2012 18:09:04 Torsten Dreyer wrote:
> Hi Adrian,
>
> you are doing an excellent job at marketing your product ;-)
>
> As I do not have the time to proof you wrong, you deserve the chance to
> proof me wrong! I'll shut up now and stop objecting against merging your
> code.
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote:
> The trees were definitely both casting and receiving shadows under
> Rembrandt in the
> past. I remember this as I was pleasantly surprised that it worked!
>
> I haven't tested recently though, so it's possible that it has been
> br
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote:
> The trees were definitely both casting and receiving shadows under
> Rembrandt in the
> past. I remember this as I was pleasantly surprised that it worked!
>
> I haven't tested recently though, so it's possible that it has been
> bro
Oh one more thing, The random buildings and trees definetly receive shadows,
but they don't cast it.
Is that the way it should be? Asking because I'm about to push the
modifications to my simgear clone.
Cheers,
Adrian
-
On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote:
> Hi Adrian,
>
> I haven't looked at your code, and I'm sure you've already taken care
> of this, but:
>
> The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings
> is probably due to my ignorance when writing the code,
On Thursday, December 13, 2012 12:44:00 Torsten Dreyer wrote:
> Hi
> - Performance
> The most important limiting factor for radio propagation on VHF and up
> is question "line of sight" or "obscured by terrain".
Hi again Torsten,
Apologising for keeping this subject up, but I rather enjoy technic
On Thursday, December 13, 2012 15:04:16 Renk Thorsten wrote:
>
> Somewhat related to the above - *if* the radio propagation model could be
> shown to be more realistic - what framerate loss would this be worth as
> compared to a faster, less realistic model? And does this question matter
> at all
Hi Torsten,
Regardless of the fact that you support or not the inclusion of this new radio
code, I have to clear up some statements which are wrong. See below.
> I spent an hour or two reviewing your code and I still think your
> implementation should not be merged into the code base. Let me e
On Thursday, December 13, 2012 01:03:45 Vivian Meazza wrote:
> Don't we need radar altitude for buildings etc. for radar altimeters, but
> probably not trees?
>
> A radar altimeter needs to sample both the terrain and "hard" objects on
> it.
>
> However, I watch this work with interest: I think
On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote:
> >> My suggestion is to include this feature, leave it off, and let anyone
> >> interested turn it on.
>
> +1
>
> There may be many reasons to reject code, but they roughly fall into two
> categories: 1) the idea itself which is coded
On Tuesday, December 11, 2012 00:40:16 Torsten Dreyer wrote:
> Hi,
>
> let me chime in here with a personal note, hoping it's not offending
> anybody.
Hi Torsten, and thanks for your detailed message. Let me explain below why
realistic radio propagation should be inside Flightgear, and aleviate
On Monday, December 10, 2012 00:39:23 James Turner wrote:
> I did a review of the code, but was travelling all last week with very
> erratic Internet access. My feeling is the code is not suitable to be
> merged as-is, due to serious structural issues. (Unrelated to the actual
> simulation math,
Hi,
Can I suggest moving the sqlite amalgamation somewhere in simgear, if it's not
too much of a bother? It seems like the proper location for it, doesn't it?
I have also transitioned some of my code to use a sqlite database, especiallly
for the landcover properties: the names are still those f
On Saturday, December 01, 2012 19:19:14 geneb wrote:
> On Sat, 1 Dec 2012, Adrian Musceac wrote:
> > Hi,
> >
> > Right now, due to some rather encouraging results I've had so far with my
> > little terrain sampling experiment, I've started a wiki page on this
Hi,
Right now, due to some rather encouraging results I've had so far with my
little terrain sampling experiment, I've started a wiki page on this topic:
http://wiki.flightgear.org/Terrain_sampling
I've included a screenshot with a demo of three radio stations each about 100
km away from the pla
> Problem is, there are no project leaders. And that worked remarkably
> well for quite a while. I think everyone involved in FlighGear is busy
> working on other things right now. I know I am, and for a good reason; I
> learned the hard way FlighGear isn't going to pay my bill so I spent all
> of
On Wednesday, November 28, 2012 09:51:06 Renk Thorsten wrote:
> > I know the advanced weather system uses a C++ random area terrain sampler
> > written by Torsten Dreyer.
>
> Yes - but the way this is currently set up it wouldn't help you - it just
> samples various averages and variances of the e
On Tuesday, November 27, 2012 15:23:13 Stuart Buchanan wrote:
>
> I recently implemented a vertical terrain clearance radar for the Douglas
> A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain
> lookups. The code is checked into git if you are interested.
>
> My main concern when
Hi,
I've seen a couple of external radar clients for Flightgear being developed
right now.
I think that these days, with the advent of Canvas and other improvements, it
should be possible and desirable to have a realistic radar station inside
Flightgear.
At the moment, I'm only concerned about
On Tuesday, November 27, 2012 14:53:07 James Turner wrote:
>
> Gitorious was down this morning, or I would have already given some review
> comments. However I see quite a few new versions of the patch, it would be
> good to know it's 'ready' from your perspective, before reviewing. I too
> would
Update: I've added new signal calculation for DME stations too. As explained
detailed in the wiki, DME uses a very high frequency range, thus it is
possible sometimes in reality to receive the VOR signal but not the DME
signal. Screenshots provided in the wiki article.
Also, TACAN reception is
On Sunday, November 25, 2012 15:55:44 Eric van den Berg wrote:
> Gentlemen,
>
> I have been looking at the atmosperic system of flightgear and altitude
> and airspeed calcs in particular. I have been checking it for
> correctness and later looked a bit in the code.
>
> I must admit that I am not
On Monday, November 26, 2012 19:18:26 James Turner wrote:
> I'll do a review if no-one beats me to it, but this definitely needs to be
> 'off-by-default' for the next release. We can add a checkbox to the
> realism dialog to enable it from the GUI, and give aircraft authors a
> chance to adapt.
>
On Monday, November 26, 2012 19:18:26 James Turner wrote:
>
> I'll do a review if no-one beats me to it, but this definitely needs to be
> 'off-by-default' for the next release. We can add a checkbox to the
> realism dialog to enable it from the GUI, and give aircraft authors a
> chance to adapt.
Hi,
I have added VOR, localizer and glideslope signal calculations for the old
(classic) navradios (navradio.cxx)
Now an ILS navaid is basically considered as two separate stations: Localizer
and glideslope, as in reality. Both these stations can have separate
parameters like transmitter power,
On Friday, October 26, 2012 13:56:02 Marcel Baltzer wrote:
> Hello folks,
>
>
>
> I just freshly started using flightgear for a university project and I
> was wondering, if there is an easy method to hard code a subsystem that
> displays a calculated route into the scenery or marks objects in t
On Friday, November 23, 2012 15:56:01 James Turner wrote:
Hi James,
> Suggestion: make a runtime switch, to build the 'new' nav-radio when the
> old one is asked for - this can be done via some logic in the instrument
> manager. This of course assumes the visible interface, i.e read / written
> p
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote:
> navradio is the current/old standard, newnavradio is the new module.
> Most aircraft use "navradio", few "newnavradio". I'm not sure if there
> is a plan to switch/replace the old radio at some point, and whether the
> new module was comp
On Friday, November 23, 2012 14:33:58 Renk Thorsten wrote:
> I'm just trying to get a working devel environment on my new machine, and
> I've succeeded in compiling simgear, but flightgear refuses the cmake
> configuration. Basically I want to have the simgear libs inside a user
> directory and not
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote:
> navradio is the current/old standard, newnavradio is the new module.
> Most aircraft use "navradio", few "newnavradio". I'm not sure if there
> is a plan to switch/replace the old radio at some point, and whether the
> new module was comp
Hi,
I've gone ahead and used the new radio code for navaids, but I have a
question: which navradio code is considered standard? newnavradio or navradio?
Right now the new radio code is used inside newnavradio and works the same for
VOR and ILS (i.e. no directional antennas yet for LOC/GS, will f
Hi,
Hate to be a nuisance, but is there any reason for this limit:
if (_last_speed_kts < 60) {
// need valid leg course and sensible ground speed to compute the turn
return;
}
in Instrumentation/gps.cxx line 770?
If I have a vehicle with a ground speed of less than 60, the route
On Wednesday, November 07, 2012 10:30:47 James Turner wrote:
> Also, everything on Thorsten's lists is things that FS-X does, or has done
> even for some time. Maybe not as good (but maybe better) as our solutions,
> but again, that's no help for catching people's initial attention.
>
> James
>
On Monday, November 05, 2012 20:25:13 James Turner wrote:
> Hmmm, no is the quick answer - if you can wait a little, I'll try to
> replicate this tomorrow.
>
> Regards,
> James
Found the reason myself: in Instrumentation/gps.cxx line 771:
if (_last_speed_kts < 60) {
// need valid leg cours
On Sunday, November 04, 2012 09:49:25 James Turner wrote:
>
> Short reply since I'm at FSWeekend still - can reply in more detail
> tomorrow. The most likely answer is that the route-manager or GPS is not
> activated - activating GPS leg mode should set the route-manger mode
> automatically, I th
Hi all and especially Torsten and Durk,
As you know, I had an older merge request containing the new and improved
radio code. Since that was ~8 months old and was outdated, I retracted it so
you don't have to try to merge in old code over new improvements in
trafficcontrol.cxx and other files.
> >
> > Could someone provide me with some clues here? Is there any specific
> > thing the GPS needs to sequence to the next waypoint?
>
> Short reply since I'm at FSWeekend still - can reply in more detail
> tomorrow. The most likely answer is that the route-manager or GPS is not
> activated -
Hi all,
I've written a little interface to control Flightgear via an OpenStreetMap
interface (at the moment, it can place the ufo at any position on the map,
place some virtual radio stations on the ground near the ufo, and also place
waypoints for the ufo to follow along a path on the map).
M
Hi there,
I'd just like to know if anybody was able to run Nasal code via a normal
telnet connection (run nasal /property/where/code/is/located ). I tried, but
couldn't manage it, and had to modify a little the code from Network/props.cxx
in order to get it to work.
Maybe I was doing it wrong,
On Saturday, June 02, 2012 22:36:17 Torsten Dreyer wrote:
> Hi,
>
> in just a bit more than two weeks from now we reach June, 17th, marking
> the first milestone for the release of next FlightGear version: the
> "feature freeze" period.
>
> If you have some great and exciting new features for Fl
On Saturday, February 25, 2012 22:36:34 Stuart Buchanan wrote:
> The new file structure is now in place. Note that the file format itself
> has not changed, so it should be fairly easy to incorporate your changes.
>
> Have a look at Materials/default/materials.xml to see how the shared
> informat
On Friday, February 24, 2012 21:38:39 Stuart Buchanan wrote:
>
> > Regional texturing is a feature which would be nice on GIT - by now, we
> > also have enough GPL-compatible textures to pull it off (a while ago,
> > Adrian posted a very impressive GLP texture pack in the forum).
> >
> > I'd be
On Thursday, February 23, 2012 01:05:07 Martin Spott wrote:
> I do, I've been the first real user of the "xplane" driver in GDAL -
> except from Even himself :-)
> BTW, I didn't say I "don't want any 850 centerlines as a base for
> this". I just wanted to make clear that there's a trap hiding b
On Wednesday, February 22, 2012 00:57:49 Martin Spott wrote:
>
> I'll leave it to Durk to commit these files when you consider them
> being ready for use. Anyhow I think we'll need some aid for tracking
> the ground networks, at least in the long run, as there'll be a lot to
> change when people
On Saturday, February 11, 2012 14:01:55 Scott wrote:
> thanks Thorsten,
>
> Now to find out why, must be a static link library somewhere that
> isn't getting updated...
>
>
> cheers
> S.
>
Hi,
I had the same problem recently, and it took me quite a long while to figure
it out. It m
Hi,
As a follow-up on yesterday's question, I now can generate in a relatively
reliable fashion groundnet files for a certain type of airport, with 9 medium-
large parking positions and an AI network which passes the Taxidraw tests (I
have randomly tested the files).
I have also tested that vis
On Thursday, February 09, 2012 13:40:49 Martin Spott wrote:
> Adrian Musceac wrote:
>
> I'm not too motivated to write such a script, simply because there's no
> benefit in it for myself, but I'd be willing to run it on The
> MapServer, if it helps. Anyhow, from
Hi,
Currently there are a number of airports with missing goundnetwork files, with
the obvious consequence that AI aircraft are placed on top of eachother at
startup, they do not use taxiways, and the ATC manager cannot assign a taxi
route to the player (also this taxi route can't be visually d
On Tuesday, February 07, 2012 18:31:26 Eric van den Berg wrote:
> Hi Adrian,
>
> Would go with 1. As you say signal strength does not have a major
> influence on the functionality itself. It works or you have a flag. Only
> of the very border of reception the respective indicator will wander
> out
Hi,
While working to add support for realistic radio capabilities of navradio
equipment, I have transitioned the radio code to a subsystem, thanks to
valuable advice from Torsten, which should remove performance issues and make
the system more flexible and useful for other development, like int
On Monday, January 30, 2012 12:45:26 Gijs de Rooy wrote:
> I do see an issue, the menu isn't scrollable and it doesn't fit on my
> laptop screen ;) It is cut of at atc-chatter.
>
> Other than that, nice work!
>
> Gijs
Right, that should be taken care of now. I'm thinking the proper location of
Hi all,
I've written a parser to generate a local API documentation for Nasal scripts
inside $FGROOT/Nasal.
Here is a preview of the result: http://ompldr.org/vY2kwNA/nasal_api.html
Is there any interest to add the parser and API doc to the repository?
Cheers,
Adrian
---
On Friday, January 20, 2012 07:55:24 Martin Spott wrote:
> Martin Spott wrote:
> > Topologically cleaned CLC2000v15 is now available on the FlightGear
> > MapServer web map and if you download Shapefiles, you'll get them from
> > the revised dataset. Please let me know if you encounter technical
>
On Sunday, January 08, 2012 01:50:50 Martin Spott wrote:
I've placed a merge request with the changes. Now it works properly, at least
on my machine.
Cheers,
Adrian
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, yo
On Sunday, January 08, 2012 01:50:50 Martin Spott wrote:
> Martin Spott wrote:
> > Cool ! I'll figure how to interface this with the download machinery.
>
> Ok, from my perspective the interface to "download.psp" works, please
> check (fill in the values you prefer):
>
>
> http://mapserver.flig
On Saturday, January 07, 2012 20:23:02 Geoff McLane wrote:
> Hi Adrian,
>
>
> No, I do NOT think they should be hidden!
>
> After the user has used the mouse selection, [s]he may choose
> to modify the fields, say rounding them, etc, which would be
> difficult, impossible with the mouse, so I t
Hi Geoff, Martin,
> and thus assume the lightmap/?lon=... URL does in fact
> point to this index.php, or something like it... but
> maybe this is not right ;=((.
>
> In fact it is clear there are some differences, but
> the source of 'lightmap' was not included in git...
Yeah, the small map is
Hi,
We've had a multiplayer session last night, and were very pleasantly surprised
to see that it's now very smooth, without the old "jitter" effect, at least
for Yasim aircraft. Maybe this is related to commit cf86d37 by Curtis?
It may be worth updating issues #120 and #202 which seem to be rel
On Wednesday, January 04, 2012 22:05:13 Martin Spott wrote:
> Vadym Kukhtin wrote:
> > Why mapserver.flightgear.org have zooming-panning map, if by "Download
> > Shapefiles" I still have to type the numbers of coordinates by hands?
>
> Because someone has to implement the feature you mention ;-)
Hi and a Happy New Year,
On Thursday, December 29, 2011 14:29:16 ThorstenB wrote:
>
> So, rather than forking development into many little subprojects, and
> finding ways to better support these forks, we should find solutions, so
> that scenery developers keep joining forces and improve our comm
On Saturday, December 17, 2011 23:19:16 Stuart Buchanan wrote:
> Great work Adrian,
>
> I had something similar working in January - I think I posted
> something to this list. My system used an AI scenario to
> create a number of ships, and then used a perl script to
> query www.marinetraffic.com
On Friday, December 16, 2011 14:57:24 Olivier wrote:
> Hi,
>
> That's a nice start! Are you grabbing data from:
> http://www.marinetraffic.com/ais/ ?
Yes. aprs.fi also has a good feed, although more oriented towards ham radio
APRS.
AisHub has very detailed NMEA data, but they require you to send
Hello everybody,
I wrote a little script to add maritime traffic from AIS static data. It's a
little crude Nasal script at the moment, but it could be done in C++ to
automate the display of traffic according to a certain range/density. I'll be
looking at that later.
For an explanation of the AI
> Thinking of most GA and business aviation aircraft I know the NAV
> antenna (VOR/LOC/GS) is always located on the vertical tail, just below
> the horizontal tail with a cross or t-tail and on top of the vert. tail
> with a low hor. tail. These are usually two antennas, one on each side
> of the
On Monday, November 28, 2011 20:20:03 Eric van den Berg wrote:
>
> That I do not know. But I do know there are long-range and short-range
> VOR-s with significantly different output levels. Not sure how to
> determine the difference easily.
> For NDB-s it is more easy. The short range ones are on
>
> The nav.dat file contains 'range' in nm for the nav-aid.
> http://data.x-plane.com/file_specs/Nav740.htm
>
> Perhaps you could use some heuristic to create a reasonable power level to
> meet the published range?
>
> Ron
>
Oh I see then, my bad, I was not aware of this fact. Of course, the
On Monday, November 28, 2011 18:31:42 Eric van den Berg wrote:
> For GA (what I have handy right now):
> The good old Garmin 400 series: VOR/LOC:-103.5dBm, GS:-87dBm
> Avidyne (EntegraII): VOR: 5uV, LOC and GS: 10uV
>
> www.repeater-builder.com/measuring-*sensitivity*/*dbm*2uv.pdf
> /for conversi
Hello everyone,
I've added a short article on the wiki with details of the features the radio
code adds, its implementation, and future intentions.
http://wiki.flightgear.org/Radio_Propagation
One possible application that I can think of besides those mentioned in the
article would be simulati
Hi there,
I'm about to start implementing navradio signal propagation, and I'd like to
know from anyone who has experience with this type of radios whether this spec
sheet performance is typical for most receivers including airline big iron, so
that I should hardcode or not the values.
https:/
Hi everybody,
I'm almost finished implementing radio propagation for ATC communications, but
there's one thing I can't figure out yet: I'm trying to set Festival voice
volume to a lower value when the radio signal is near the receiver threshold,
but all my attempts using
fgSetDouble("/sim/soun
On Tuesday, November 22, 2011 19:09:27 Erik Hofman wrote:
> That sounds about right.
>
> > I think the new work from Emilian/Vivian needs some new policy for the
> > .dds files. I see formats up to 2048 x 2048 pixel size.
>
> That might be a good idea, but it's also a good idea to check if it is
Hi Yves,
The issue here is that some of these textures are really large, and thus have
the potential to limit performance for users with lower-end machines.
Thus, I'm interested in guidelines/policies regarding texturing the terrain,
what sizes are recommended or usable etc.
I also agree about ab
> I think the solution to this whole issue is to bring fgfs-construct .btg
> generation closer to how the genapt works - keeping the material
> information around with each poly through the clipping process.
Ignore my previous e-mail on this issue, I misread the "each poly" part.
Adrian
-
Hi everybody,
I have been doing recently some terrain textures experiments, mainly using
aerial imagery from USGS and some personal photographs. I have managed to get
a number of high resolution textures, and was wondering what the official
policy is regarding terrain, and whether they would be
> I think the solution to this whole issue is to bring fgfs-construct .btg
> generation closer to how the genapt works - keeping the material
> information around with each poly through the clipping process.
Hi Peter,
I thought that was already the case? I was fooling around the other day,
mo
On Friday, November 04, 2011 01:05:25 Jon Stockill wrote:
>
> Have we changed the default data directory again? cmake outputs this:
> -- Using default data-dir: /usr/lib/FlightGear
> There doesn't appear to be any way to set it within ccmake or from te
> commandline.
>
I believe it's FG_DATA_DI
On Thursday, October 27, 2011 18:59:18 Michael Sgier wrote:
> In my git when looking at airport objects they're loaded but unloaded when
> looking elsewhere!- So there's always a huge lag when looking back on the
> airport and you can see the objects being loaded again one after the
> other. This i
On Monday, October 24, 2011 16:53:23 James Turner wrote:
>
> Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one
> (or several) paths to search - I tested that this morning and updated the
> README.
>
> As you guessed, manually setting the the detection variables
> (SIMGEAR_
On 10/20/11, ThorstenB wrote:
> Hi FlightGear,
>
> there was little input on the fgdata split and few people speaking up
> when things were started. We do see a lot of responses now - many being
> in favor of the change, but also concerns about remaining issues.
> Indeed, setting up the new repo i
On Thursday, October 06, 2011 10:22:18 thorsten.i.r...@jyu.fi wrote:
> Some observations I've made in the last couple of days:
>
> * hardcoded terrain presampling: This seems to have died on me after the
> last pull (probably even earlier?) - currently all I get out is zero
> everywhere. Since geo
On Monday, October 03, 2011 23:07:08 Gijs de Rooy wrote:
> Lots of (big) images this time, we'll have to see if that's something we'd
> like to continue with.
>
The "big" images are probably due to the wiki server missing the ImageMagick
tools that generate thumbnails. I don't know who's in char
1 - 100 of 120 matches
Mail list logo
