Hello.
Latest GIT from Terragear has 2 memory leaks in terrafit.cc and
Terra/greadyinsert.
Heap size increases from 0 to hero in under 2 minutes given enough files
are thrown at it.
Patches attached. Notify upstream, close main shuttle bay doors.
--
Adrian
diff --git
On Tue, 2010-10-05 at 07:29 +0300, Adrian Musceac wrote:
Hello.
Latest GIT from Terragear has 2 memory leaks in terrafit.cc and
Terra/greadyinsert.
Heap size increases from 0 to hero in under 2 minutes given enough files
are thrown at it.
Patches attached. Notify upstream, close main
On Wed, 2010-12-22 at 23:16 +, Martin Spott wrote:
Depends on your very individual point of view. In contrast, I was
confirmed that providing a seamless Terrain sounds quite appealing.
I agree completely with you on this issue.
Instead, having to assemble Scenery from a lot of
Hello,
I have found a couple of YASim issues, more details here:
https://code.google.com/p/flightgear-bugs/issues/detail?id=302
https://code.google.com/p/flightgear-bugs/issues/detail?id=303
Would anyone still maintaining YASim please have a look and provide
some feedback?
Cheers,
Adrian
On Thursday, April 14, 2011 21:40:10 Gary Neely wrote:
Adrian,
Great catch on the fuel and glideslope issues. You're right--
despite
parsing the fuel attributes and supplying defaults if necessary,
it
has the defaults hard-coded right in the Airplane::compile block.
It
seems to consider
Possibly , I think you've probably looked deeper into the code than i
have there . Thought I'd bring up the idea in case it hadn't been
tried .
I,ve also tried to trigger that gear up crash but haven't been able
too , (with my aerostar) , it does a belly landing and the crash
property
On Friday, April 15, 2011 20:43:45 syd adams wrote:
One small ,narrow fuselage piece inside and at the bottom of the main
fuselage doesnt make a difference here, you don't need a lot . And
they don't seem to trigger a crash like gear does.
The gear only triggers a crash when its absolute
On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote:
I had a fix locally but with the patch fixing the YASim issue I have now to
begin again. I see the problem in the airfoil, but a change to this means
that I have to change a lot of other parameters as well to keep the
behavior 100%
On Monday, April 18, 2011 20:51:17 ThorstenB wrote:
And you also checked that approach glide angle isn't used? Otherwise,
the new default cruise angle (0.0) might not match the original approach
angle setting...
No mention of approach glide angle either. I have no idea how this applies to
On Saturday, May 07, 2011 16:13:01 ThorstenB wrote:
On 18.04.2011 23:13, Maik Justus wrote:
By the way: I would prefer to use the old default values for the gear
solver. The spring constants of a gear should not be a function of the
approach fuel settings. Maybe some gears would need some
On Sunday, June 26, 2011 17:27:06 xsaint wrote:
Hello All...
I am trying to better understand how YASIM calculates its contacts
points
Hi there, I'll try to answer, see below:
1) As from my experience, the SIM crashes when some part of the wings
comes in contact with a building or
On Monday, July 04, 2011 13:16:33 TDO_Brandano - wrote:
If the scope is to show off the capabilities, I'd really consider the
IAR-80 too.
Alessandro
I agree, the Mig-15b and IAR-80 are really well done and the ASK13 is the best
glider imo.
Adrian
Fixed faulty frame transformation of moment of inertia.
#348 related: More places where missing files were not reported properly
#!/usr/bin/env python
# Copyright (C) 2011 Adrian Musceac
#
# This program is free software: you can redistribute it and/or modify
On Wednesday, July 06, 2011 18:15:45 Torsten Dreyer wrote:
Hi,
Actually the correct script is the one attached here (it's late).
Hope it helps.
Adrian
#!/usr/bin/env python
# Copyright (C) 2011 Adrian Musceac
#
# This program is free software: you can redistribute it and/or modify
On Sunday, August 14, 2011 15:20:10 Durk Talsma wrote:
Hi Adrian,
I realize that it's almost three quarters of a year since your message was
posted, but it wasn't until today that it caught my attention.
Hi Durk,
As they say, it's never too late to fix a bug. I remember encountering these
Hi,
I have noticed that when enabled, the ground network is displayed above the
airport, at a variable height, depending on the airport's elevation above sea
level. This is mostly due to the fact that the elevation is in feet instead of
meters.
I have attached a patch that corrects this
Hi,
This message is mostly meant for Durk, but I expect suggestions from anyone
who knows the scenery subsystem of Flightgear.
I have started to implement radio signal attenuation into the ATC subsystem,
with the goal to later move this to it's own location.
I have chosen the Irregular Terrain
On Sunday, September 04, 2011 17:09:43 Torsten Dreyer wrote:
Hi Adrian,
this all sounds very interesting and not only for AI Aircraft but also
for the navigation radios. I am currently refactoring the navradio code
and I'd really like to have a better propagation model than our current
On Monday, September 05, 2011 20:01:29 Durk Talsma wrote:
I'm a little pressed for time this week, so I have to keep my response a
little on the short side. In essence, I think that this would be any
extremely cool feature to have. Do you already have a working copy that
you would consider
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 charge
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
On 10/20/11, ThorstenB bre...@gmail.com 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
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
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 is
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_DIR, as
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,
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.
Ignore my previous e-mail on this issue, I misread the each poly part.
Adrian
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
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
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.
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
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 conversion
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 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 or
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
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
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 a
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 using
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 common
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 ;-)
Feel
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
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 not
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 think
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):
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,
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
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 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
this
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
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
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 my perspective the solution
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
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 may be
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 add
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 because
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 willing to
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
information
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 FlightGear
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,
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).
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 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.
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 think.
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 course and
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
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
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
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 compatible
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 compatible
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
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 the
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
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.
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 quite
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
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
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
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
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
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 my
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
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
topic: http://wiki.flightgear.org
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
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,
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 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 is not
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 it might
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
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 technical
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, and I
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 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
broken
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
broken
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. I
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
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 distance 4 times.
This method
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 little the
1 - 100 of 114 matches
Mail list logo
