Re: [Flightgear-devel] Random Buildings - memory consumption
Hi,
I don't have any clue of the opengl and simgear based stuff, so I looked only
at the struct Building and how to optimize that.
In the attachment you can find 3 structs representing the data.
The original is yours.
'small' is a very small optimization that doesn't require you to map floats to
discrete values. The flags variable holds bool pitched and the building type. I
assumed floors not to be bigger than 65k, so I reduced it to 16 bit ;).
In 'aggressive' I replaced the floats which I think doesn't require the full 4
byte precision of a float. However the mapping from float-int int-float can
take much time depending on the translation function you use. If normal float
division/multiplication is too slow, you could write some functions to directly
accessing the float (shifting the fraction depending on the exponent)
(http://en.wikipedia.org/wiki/Single_precision ).
However just ideas on that struct. Sizes in bytes:
original: 44
small: 36
aggressive: 28
Regards,
scosu
On 23.05.2012 11:37, Stuart Buchanan wrote:
Hi All,
Emilian and Vivian have pointed out a problem with the random
buildings - they gobble memory. I'd like to get some advice on
whether there's any solution, and also to ask someone with more C++
knowledge than myself to take a look at the code and check I'm not
doing something stupid.
The specific problem scenario is starting a KLAX (Los Angeles) which
is in the middle of a massive urban area.
Using the default random building density, the tiles that are loaded
initially when sitting on the runway generates ~ 340k random
buildings. Each building consists of between 9 and 12 quads (we have a
basement at the bottom to handle slopes, 4 walls, and a roof which
may be pitched). In turn, each quad has 4 corners, each of which has
a position (vec3), a normal (vec3) and a texture coordinate (vec2).
So, the absolute minimum memory occupancy of the data for the random
buildings is 340k * 10 * 4 * 8 = 108MB. On top of that will be some
OSG overhead and the building texture itself.
Once you start flying more tiles are loaded (presumably well before
any old tiles are unloaded?) so memory occupancy rapidly increases.
Flying east from KLAX is particularly bad.
Using a higher building density makes the problem much worse, as you
need 4X the number of buildings to get double the linear density. I
ran out of memory on a 4GB system pretty quickly (and tile loading
takes an age - something I need to look at again).
So
- Does anyone have any bright ideas on what I can do to reduce the
base memory occupancy? One option might be to not generate the
basement if the terrain is level.
- Could a fresh pair of eyes take a look at the obj.cxx, mat.cxx and
SGBuildingBin.[ch]xx code to see if I've missed something obvious.
Thanks,
-Stuart
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
#include stdint.h
#include stdio.h
enum BuildingType {
SMALL = 0,
MEDIUM,
LARGE
};
struct building_original {
enum BuildingType type;
float position[3];
float width;
float depth;
float height;
int floors;
float rotation;
bool pitched;
float radius;
};
#define BUILDING_FLAGS_SMALL 0x01
#define BUILDING_FLAGS_MEDIUM 0x02
#define BUILDING_FLAGS_LARGE 0x04
#define BUILDING_FLAGS_PITCHED 0x08
struct building_small {
uint16_t flags;
uint16_t floors;
float position[3];
float width;
float depth;
float height;
float rotation;
float radius;
};
#pragma pack(push,1)
struct building_aggressive {
float position[3];
uint16_t width;
uint16_t depth;
uint16_t height;
uint16_t rotation;
uint16_t floors;
uint8_t alignment_no_data; // to get better access times for variable radius
uint8_t flags;
uint32_t radius;
};
#pragma pack(pop)
int main(void) {
printf(original: %lu\n, sizeof(struct building_original));
printf(small: %lu\n, sizeof(struct building_small));
printf(aggressive: %lu\n, sizeof(struct building_aggressive));
}
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https
Re: [Flightgear-devel] updates to nav.dat.gz
On Tue 10 Apr 2012 10:23:23 PM CEST, ThorstenB wrote: Am 10.04.2012 21:08, schrieb Martin Spott: And there's still one thing to consider: Having one central set of apt./nav.dat files in the Base Package still doesn't address the trend of the FlightGear project and Scenery development proceeding asynchronously. But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). And we cannot expect all users to run the same FG version - or to even update their FG setups (base packages) on the same day. A bunch of Linux distros still haven't switched to FG 2.6.0... As far as I know terrasync uses svn. So for every release we could fork a new branch which is automatically selected by the terrasync client. This would prevent all version conflicts and issues. Since we somehow hard-code navigation data into the generated scenery tiles, it really makes sense to couple them closely. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). This would avoid consistency issues, unless the nav data format itself changes - like it will with the 810/850 change. But this seems a less frequent event - hopefully not happening every 3 months or every year. It wouldn't help with any individual, regional scenery projects though: these could still rely on different, conflicting versions of nav data - and we can only load one version into FG. But we probably don't need to (nor could, maybe neither should ;-) ) address this anyway... Beside serving a global nav.dat/apt.dat through terrasync, we could extend fgfs with the possibility to load custom scenery specific nav.dat. For example through patch files which are applied to the terrasync nav.dat when fgfs starts. cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Best Regards, scosu -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] fgdata chat message highlighting
Hi,
Sorry if this is not the right list for the patch.
The idea was to implement a small script to highlight chat messages in which
the multiplayer-callsign is mentioned. This should make multiplayer
communication with many pilots easier.
The message is highlighted in red.
scosudiff --git a/Nasal/screen.nas b/Nasal/screen.nas
index 2d572aa..bfebdeb 100644
--- a/Nasal/screen.nas
+++ b/Nasal/screen.nas
@@ -458,6 +458,47 @@ _setlistener(/sim/signals/fdm-initialized, func {
# functions that make use of the window class (and don't belong anywhere else)
##
+# translates a string to lower case
+var tolower = func (str) {
+ for (var i = 0; i size(str); i = i+1) {
+ if (str[i] = `A` and str[i] = `Z`)
+ str[i] = str[i] - `A` + `a`;
+ }
+ return str;
+}
+
+# highlights messages with the multiplayer callsign in the text
+var msg_mp = func (n) {
+ if (!getprop(/sim/multiplay/chat-display))
+ return;
+ var msg = tolower(n.getValue());
+ var call = tolower(getprop(/sim/multiplay/callsign));
+ var matching = 0;
+ var found = 0;
+ for(var i = 0; i size(msg); i = i + 1) {
+ if (msg[i] == ` ` or msg[i] == `,` or msg[i] == `.` or msg[i] == `;` or msg[i] == `:` or msg[i] == ``) {
+ if (matching == size(call)) {
+found = 1;
+break;
+ }
+ matching = 0;
+ continue;
+ }
+ if (matching = size(call)) {
+ matching = matching + 1;
+ continue;
+ }
+ if (call[matching] == msg[i]) {
+ matching = matching + 1;
+ } else {
+ matching = 0;
+ }
+ }
+ if (found == 1 or matching == size(call))
+ screen.log.write(n.getValue(), 1.0, 0.5, 0.5);
+ else
+ screen.log.write(n.getValue(), 0.5, 0.0, 0.8);
+}
var msg_repeat = func {
if (getprop(/sim/tutorials/running)) {
@@ -557,9 +598,7 @@ _setlistener(/sim/signals/nasal-dir-initialized, func {
func(n) map(copilot, n.getValue(), 1.0, 1.0, 1.0));
listener.ai_plane = setlistener(m ~ ai-plane,
func(n) map(ai-plane, n.getValue(), 0.9, 0.4, 0.2));
- listener.mp_plane = setlistener(m ~ mp-plane,
- func(n) map(ai-plane, n.getValue(), 0.5, 0.0, 0.8,
- func getprop(/sim/multiplay/chat-display)));
+ listener.mp_plane = setlistener(m ~ mp-plane, msg_mp);
});
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] fgdata chat message highlighting
Hi,
Thank you, I searched for this function but didn't find it. I replaced the
'tolower' function with the string.lc calls in the patch.
scosu
On Sun, 22 Jan 2012 16:46:30 +0100
Melchior FRANZ mfr...@aon.at wrote:
Hey,
your proposed function screen.tolower() is redundant, because there
is already string.uc() (named after Perl's function uc() for upper
case).
m. (who wrote screen.nas)
diff --git a/Nasal/screen.nas b/Nasal/screen.nas
index 2d572aa..26e1508 100644
--- a/Nasal/screen.nas
+++ b/Nasal/screen.nas
@@ -458,6 +458,38 @@ _setlistener(/sim/signals/fdm-initialized, func {
# functions that make use of the window class (and don't belong anywhere else)
##
+# highlights messages with the multiplayer callsign in the text
+var msg_mp = func (n) {
+ if (!getprop(/sim/multiplay/chat-display))
+ return;
+ var msg = string.uc(n.getValue());
+ var call = string.uc(getprop(/sim/multiplay/callsign));
+ var matching = 0;
+ var found = 0;
+ for(var i = 0; i size(msg); i = i + 1) {
+ if (msg[i] == ` ` or msg[i] == `,` or msg[i] == `.` or msg[i] == `;` or msg[i] == `:` or msg[i] == ``) {
+ if (matching == size(call)) {
+found = 1;
+break;
+ }
+ matching = 0;
+ continue;
+ }
+ if (matching = size(call)) {
+ matching = matching + 1;
+ continue;
+ }
+ if (call[matching] == msg[i]) {
+ matching = matching + 1;
+ } else {
+ matching = 0;
+ }
+ }
+ if (found == 1 or matching == size(call))
+ screen.log.write(n.getValue(), 1.0, 0.5, 0.5);
+ else
+ screen.log.write(n.getValue(), 0.5, 0.0, 0.8);
+}
var msg_repeat = func {
if (getprop(/sim/tutorials/running)) {
@@ -557,9 +589,7 @@ _setlistener(/sim/signals/nasal-dir-initialized, func {
func(n) map(copilot, n.getValue(), 1.0, 1.0, 1.0));
listener.ai_plane = setlistener(m ~ ai-plane,
func(n) map(ai-plane, n.getValue(), 0.9, 0.4, 0.2));
- listener.mp_plane = setlistener(m ~ mp-plane,
- func(n) map(ai-plane, n.getValue(), 0.5, 0.0, 0.8,
- func getprop(/sim/multiplay/chat-display)));
+ listener.mp_plane = setlistener(m ~ mp-plane, msg_mp);
});
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
