Activity for Megaf
-
Megaf modified a comment on ticket #2851
So, I did another test here. Enabled HTTP --httpd=5050. Created a short shell script function to take screenshots takeshot() { curl http://localhost:5050/screenshot?type=png > "FlightGear Screenshot $(date +%Y%m%d%H%M%S).png"; }. And then after started FlightGear, I made it take a screenshot every 5 seconds. while true; do takeshot; sleep 5; done. No lag in the sim at all, granted I was saving to a Ram disk, but there was no CPU/GPU penality. FG was running at constant 60 FPS 22ms/frame. Interestingly,...
-
So, I did another test here. Enabled HTTP. Created a short shell script function to take screenshots takeshot() { curl http://localhost:5050/screenshot?type=png > "FlightGear Screenshot $(date +%Y%m%d%H%M%S).png"; }. And then after started FlightGear, I made it take a screenshot every 5 seconds. while true; do takeshot; sleep 5; done. No lag in the sim at all, granted I was saving to a Ram disk, but there was no CPU/GPU penality. FG was running at constant 60 FPS 22ms/frame. Interestingly, on average...
-
So, I did another test here. Enabled HTTP. Created a short shell script function to take screenshots takeshot() { curl http://localhost:5050/screenshot?type=png > "FlightGear Screenshot $(date +%Y%m%d%H%M%S).png"; }. And then after started FlightGear, I made it take a screenshot every 5 seconds. while true; do takeshot; sleep 5; done. No lag in the sim at all, granted I was saving to a Ram disk, but there was no CPU/GPU penality. FG was running at constant 60 FPS 22ms/frame. Interestingly, on average...
-
So, I did another test here. Enabled HTTP. Created a short shell script function to take screenshots takeshot() { curl http://localhost:5050/screenshot?type=png > "FlightGear Screenshot $(date +%Y%m%d%H%M%S).png"; }. And then after started FlightGear, I made it take a screenshot every 5 seconds. while true; do takeshot; sleep 5; done. No lag in the sim at all, granted I was saving to a Ram disk, but there was no CPU/GPU penality. FG was running at constant 60 FPS 22ms/frame. Interestingly, on average...
-
[Request] Add some metadata to saved jpg screenshots.
-
[Request] Use Screenshot function from Phi instead of SimGear.
-
Actually, using Nasal one could simply parse geo data from the property list and add strings as lines to the png/jpg file after it was saved. Trivial and oversimplified example. s/word1/word2/ file, or echo "string" >> file.
-
I was further investigating this... For LIPA in specific. On the file Objects/e010n40/e012n46/3154434.stg, line 308, In OBJECT_SHARED Models/Airport/BAK12.xml 12.5868115 46.0251522 100.28 311.5 I reduced the vertical position from 100.28 to 100.00, and this seems to have fixed the issue entirely, for this wire in particular at least. And it looks much better.
-
Here we have an example of another pilot experiencing the same issue at another base, I think it is at KLSV or somewhere else in the surroundings.
-
Using TerraSync scenery. Many of the airports/bases where this model is in use, if not all of them. One example, Runway 05 at LIPA. Perhaps, the issue is that the model is too high above the runway?
-
Interesting, because I have a similar segfault, when increasing LOD, but only when random vegetation is enabled.
-
--edited--
-
we never found a way to trigger it reliably Set: Basic Weather, Fair Weather --prop:/sim/rendering/static-lod/detailed=20000 --prop:/sim/rendering/static-lod/rough-delta=40000 --prop:/sim/rendering/static-lod/bare-delta=40000 --prop:/local-weather/config/asymmetric-buffering-flag=true --prop:/local-weather/config/distance-to-load-tile-m=10000 --prop:/local-weather/config/distance-to-remove-tile-m=20000 --prop:/local-weather/config/max-vis-range-m=40000 --visibility=40000 And set random vegetation...
-
Yep, what I could gather, indicates either a race condition or something trying to clear memory when that memory was already cleaned. osg::BufferObject::removeBufferData() is trying to remove buffer that has already been cleaned. (I guess) flightgear::SceneryPager::PagerRequest::doRequest() tries to access a tile that was already cleaned?
-
Yep, what I could gather, indicates either a race condition or something trying to clear memory when that memory was already cleaned.
-
we never found a way to trigger it reliably Set: Basic Weather, Fair Weather --prop:/sim/rendering/static-lod/detailed=20000 --prop:/sim/rendering/static-lod/rough-delta=40000 --prop:/sim/rendering/static-lod/bare-delta=40000 --prop:/local-weather/config/asymmetric-buffering-flag=true --prop:/local-weather/config/distance-to-load-tile-m=10000 --prop:/local-weather/config/distance-to-remove-tile-m=20000 --prop:/local-weather/config/max-vis-range-m=40000 --visibility=40000 And set random vegetation...
-
Can you try again with random vegetation disabled? It might be related to this issue I just posted https://sourceforge.net/p/flightgear/codetickets/2831/
-
Crash when generating random vegetation. heap-use-after-free
-
I figured out what was causing these two bufferoverflows in specific, it was the SimGear cmake flag -DENABLE_SIMD_CODE:BOOL=ON that I was using. The memory leaks when closing FG persist though.
-
Stack Buffer Overflow and Memory Leaks
-
Segfault on startup when Phi is enabled.
-
FlightGear fails to link with clang even on clean building environment Scanning dependencies of target UGsmooth [ 10%] Linking CXX executable fgelev [ 10%] Building CXX object utils/GPSsmooth/CMakeFiles/UGsmooth.dir/UGear.cxx.o [ 10%] Building CXX object utils/fgviewer/CMakeFiles/fgviewer.dir/fgviewer.cxx.o /usr/bin/ld: CMakeFiles/fgelev.dir/fgelev.cxx.o: in function `main': fgelev.cxx:(.text+0x8b): undefined reference to `osg::ArgumentParser::read(std::__1::basic_string<char, std::__1::char_traits<char>,...
-
FlightGear fails to link with clang even on clean building environment Scanning dependencies of target UGsmooth [ 10%] Linking CXX executable fgelev [ 10%] Building CXX object utils/GPSsmooth/CMakeFiles/UGsmooth.dir/UGear.cxx.o [ 10%] Building CXX object utils/fgviewer/CMakeFiles/fgviewer.dir/fgviewer.cxx.o /usr/bin/ld: CMakeFiles/fgelev.dir/fgelev.cxx.o: in function `main': fgelev.cxx:(.text+0x8b): undefined reference to `osg::ArgumentParser::read(std::__1::basic_string<char, std::__1::char_traits<char>,...
-
Latest FlightGear Stable won't build with clang either. It fails to link. [ 13%] Building CXX object utils/fgpanel/CMakeFiles/fgpanel.dir/FGFontCache.cxx.o [ 13%] Building C object 3rdparty/iaxclient/lib/CMakeFiles/iaxclient_lib.dir/libspeex/sb_celp.c.o [ 13%] Linking CXX executable fgelev /usr/bin/ld: CMakeFiles/fgelev.dir/fgelev.cxx.o: in function `main': fgelev.cxx:(.text+0x8b): undefined reference to `osg::ArgumentParser::read(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>...
-
FlightGear fails to build with clang on Linux
-
[ 14%] Building CXX object CMakeFiles/fgfsObjects.dir/src/Network/generic.cxx.o [ 14%] Building CXX object CMakeFiles/fgfsObjects.dir/src/Network/HTTPClient.cxx.o In file included from /home/reglnx/FGDC/Sources/FG/src/Network/HTTPClient.cxx:40: /home/reglnx/FGDC/FlightGear-Next/include/simgear/nasal/cppbind/Ghost.hxx: In substitution of ‘template<class _Result, class _Func, class ... _BoundArgs> typename std::_Bindres_helper<_Result, _Func, _BoundArgs>::type std::bind(_Func&&, _BoundArgs&& ...) [with...
-
simgear/nasal/cppbind/Ghost.hxx:773:38: internal compiler error: Segmentation fault
-
This is what it looks like, this is just loading scenery around on a clean start. In this case, I spawned at SBFN. This happens regardless of the airport however. 3.61 [WARN]:OSG error pixelFormat = 83f1 3.61 [WARN]:OSG error pixelFormat = 83f1 3.61 [WARN]:OSG error pixelFormat = 83f1 3.61 [WARN]:OSG error pixelFormat = 83f1 3.61 [WARN]:OSG error pixelFormat = 83f1 3.61 [WARN]:OSG error pixelFormat = 83f1 3.76 [WARN]:OSG error pixelFormat = 83f1 3.76 [WARN]:OSG error pixelFormat = 83f1 3.76 [WARN]:OSG...
-
error pixelFormat = 83f1
-
Try changing some settings in the launcher, disable or reduce things as much as you can and see if it still crashing. Also, try different aircraft.
-
Rubber spheres on arresting wires are hot.
-
Interesting, fgms seems to only start at 100% of CPU if I run it from systemd. Below is my systemd fgms service file. [Unit] Description=mpserver87 FlightGear Multiplayer Server [Service] User=reglnx WorkingDirectory=/home/reglnx/fgms ExecStart=/home/reglnx/fgms/fgms -c /home/reglnx/confs/fgms-mpserver87.conf -l /home/reglnx/logs/fgms-mpserver87.log Restart=Always [Install] WantedBy=multi-user.target
-
100% CPU use
-
For some reason the topic title is gone, it was supposed to be "Open Cameraatrix Room"
-
Hi everyone, The Room I just created a room on Matrix for those who want to chat in real time IRC like. The room is public and searchable and everyone is welcome to join at #opencamera:matrix.org. Or from the web browser https://matrix.to/#/#opencamera:matrix.org The Matrix Matrix is a cool Open Source protocol for communication. It can be used for group chat in a very similar way as Discord and alike or for IM like WhatsApp. Depending on the client it has some very nice features. I recommend Element...
-
I've noticed that some parameters no longer work from a config file, but if you use --prop as a command line argument it will work. Other example of a parameter that wont work unless specified in the command line is the --prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext --prop:/sim/gui/current-style=0 Affects branch release/2020.3 as well
-
I've noticed that some parameters no longer work from a config file, but if you use --prop as a command line argument it will work. Other example of a parameter that wont work unless specified in the command line is the --prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext --prop:/sim/gui/current-style=0
-
I've noticed that some parameter no longer work from a config file, but if you use --prop as a command line argument it will work. Other example of a parameter that wont work unless specified in the command line is the --prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext --prop:/sim/gui/current-style=0
-
Use Shaders settings not persisting between sessions.
-
Shaders settings broken since .3.9
-
-DCMAKE_INSTALL_PREFIX. still not working in the master branch at least.
-
So now-a-days we have 128 thread CPUs, with CPUs with 256 threads coming. We have superfast SSDs capable of handling many IO operations at the same time. It is my belief that is more pertinent than ever to pay close attention to multi-threading, specially in operations like loading textures. I don't see a reason why this couldn't be done in parallel.
-
FIXED Ticket can be closed.
-
FIXED Ticket can be closed.
-
UPDATE I've found a work around that greatly improves canvas performance on integrate GPUs. I noticed that the majority of aircraft displays, using map framework or not, are displayed at 2048x2048 pixels or higher, and ran at max possible FPS. This for sure chokes the little GPUs and saturates the whole system IO. By reducing the canvas displays size to something more reasonable, like 512x512, which should be more than adequate on 5" to 10" virtual screens, and limiting the frame rate from unlimited...
-
UPDATE: Issue 1- Camera breaks when switching airport is Cessna 172p specific and getting fixed under https://github.com/c172p-team/c172p/issues/1374 Issue 4 - Also Cessna specific. Dealt on https://github.com/c172p-team/c172p/issues/1373
-
That still doesn't solve the issue of them not having a proper directory to be, but go ahead and close the ticket if you want.
-
.fgtapes flooding/spamming
-
It seems like that issues 2 and 3 only happen when using XWayland.
-
Not too long ago we could get almost the same visual we have now, on Rembrand and ALS on much older hardware and with much better performance. Now, apart from global shadows, FG requires a powerful GPU and even then it doesn't run with a decent FPS and without any sort of stability. Just ask the FGUK guys on their last event, many of the pilots were experiecing dreadful FPS and frequent crashes.
-
FlightGear is becoming unplayable on Intel GPUs
-
Controlling camera with mouse broken
-
Nope, clean git snapshot, clean building directory, destination folder deleted. No cache. Still not building with clang.
-
I tried again with GCC 11, built without issues.
-
Thanks for the answer, And is clang version 11.0.1 broken as well?
-
clang fails to compile too.
-
It's even worse when compiling with CLANG! #====== Compiling SimGear. -- CMAKE Build type: Release -- version is 2020 dot 4 dot 0 -- Library installation directory: lib -- SimGear mode: NORMAL -- Sound support: OpenAL -- Using built-in expat code -- RTI: DISABLED -- Library building mode: STATIC LIBRARIES -- Configuring done -- Generating done -- Build files have been written to: /dev/shm/FlightGear-Next/SimGear [ 3%] Built target FGExpat [ 7%] Built target FGUdns Scanning dependencies of target...
-
And it is crashing at different times. Upon rerunning it, it's a different file. Scanning dependencies of target SimGearCore [ 7%] Building CXX object simgear/CMakeFiles/SimGearCore.dir/io/HTTPClient.cxx.o [ 7%] Building CXX object simgear/CMakeFiles/SimGearCore.dir/scene/tsync/terrasync.cxx.o [ 8%] Linking CXX static library libSimGearCore.a [ 54%] Built target SimGearCore [ 54%] Building CXX object simgear/CMakeFiles/SimGearScene.dir/canvas/elements/CanvasImage.cxx.o In file included from /home/reglnx/FlightGear-Next_Source_Files/SimGear/simgear/canvas/elements/CanvasImage.hxx:23,...
-
stdc-predef.h:32:89: internal compiler error: Segmentation fault
-
I think installing qtdeclarative5-dev fixes the issue, perhaps we could make cmake check for it before compiling.
-
I think installing qtdeclarative5-dev fixes the issue, false alarm.
-
fatal error: QJSValue: No such file or directory
-
@cgdae
-
did you forget to ‘#include <mutex>’?
-
By the way, wouldnt it be better to release .7 instead and make it the LTS?
-
Bug confirmed by more people in totally different system from mine. https://github.com/Zaretto/fg-aircraft/issues/129#issuecomment-772455591
-
Well, you can use anything with canvas, or create a dummy canvas and test then, I don't think it's 787 specific. I don't know how NASAL nor Canvas, so can't help much, sorry.
-
You can try the 787-8 from FGADDON. Though it will show a slightly different behaviour, it simply wont show the degree symbol or any accents at all. In the file 787-8/Models/Instruments/HEAT.xml search for lines <format type="string"></format> Replace with anything you want. In this image I replaced ENG 1 TEMP with 32°C and ENG 2 TEMP with ñ, it simply wont show them. Same will happen if you type "°" or "ñ" in chat, it wont show anything. Hence, me stating, FG doesn't support UTF-8.
-
This issue can be closed now, since the bug was "cause by me" when I disabled canvas. Though IMHO using canvas for interface items is a mistake, specially because it negatively affects all intel GPU users, it's getting to a point when I simply can't fly FG anymore. Well, I had 20 years of flying in FG, it's time to move on maybe.
-
@jmturner I think a dummy canvas window could be used indeed, it would display some symbols and then we see if that work or not. As Iskender said in the post above, swapping the font didn't fix the issue. And I do agree with him, it must be some bug in FG, since you can't use any symbols in the chat either.
-
I don't have much of a choice for Intel driver do I? I tested different versions of the kernel, from 3.x all the way to 5.x, all with the same problem. And 2 of my computers are laptops and the third one, well, I can't afford a GPU at this time, so using integrated Intel, and that wouldn't fix the bug anyway. The other laptop is a third gen i5 and the desktop is a fourth gen i5. All show the same issue.
-
UFO lat and lon 0, No canvas map = 167 FPS With canvas map = 107 FPS About debugging, I have no clue where to start. The GPU is an Intel HD3000 from a second gen i7. Could Canvas be using some shader or something that this GPU doesn't have?
-
The FG1000 PFD/MFD on its own causes the same performance impact.
-
Notice that I disabled all shaders and objects/models, also reduced the LOD and set weather to basic fair weather with 2D clouds. Just to be sure the only variable was canvas.
-
https://sourceforge.net/p/flightgear/codetickets/2544/
-
Canvas causes 60%+ FPS drop.
-
Without Canvas I can easily reach 100+ FPS, with Canvas in some cases it drops to 2 FPS. Should I open a new issue to report that? Even though I'm sure that won't be fixed since it has been like that for a decade.
-
The devs of the 787 seem to have lost interest on this bug. We may close this report in my opinion since they are no longer interested.
-
It seems to have "fixed itself" on recent commits. I'm still testing.
-
I disabled it. I usually have it disabled as canvas is an insane FPS hog on all my 4 computers. It easily eats 40+ FPS bringing the thing to slideshow levels, always had. So I rather fly aircraft with a with displays disabled than not flying it at all. But now this setting is causing the reported issue, weird.
-
I cloned this tag https://sourceforge.net/p/flightgear/flightgear/ci/version/2020.3.6/~/tree/ which doesnt have that commit. The branch 2020.3 does have that commit, perhaps the tag needs updating?
-
2020.3.5 and Next build fine.
-
[2020.3.6] ‘Instrumentation::CommRadioImpl’ does not have any field named ‘_atis_enabled_prev’
-
Very weird, I managed to track down the cause of this on my system! The following is what causes this weirdness! It affects 2020.3.5 too! --prop:/nasal/canvas/enabled=false
-
Attached. 707, F-14, c172p... Bellow. FlightGear version: 2020.4.0 Revision: 3233f8583319c04f71673f4dd43251034005d318 Build-Id: none Build-Type: Dev SimGear version: 2020.4.0 OSG version: 3.6.5 PLIB version: 185 FG Commit -> 76215698346fa81fa7ed1f21bd0542fc11f4369c SG Commit -> a7a53921e44e33a442d9367c906fa19e9e47ab96 DATA Commit -> ac63f6b9c3fccbc1db79ce0dcdcada8ddcccff60
-
401.96 [ALRT]:nasal Nasal runtime error: No such member: tooltip 401.96 [ALRT]:nasal at /home/reglnx/FlightGear-Next/data/Nasal/gui.nas, line 146 401.96 [ALRT]:nasal called from: /home/reglnx/FlightGear-Next/data/Nasal/multiplayer.nas, line 116 401.96 [ALRT]:nasal called from: /home/reglnx/FlightGear-Next/data/Nasal/multiplayer.nas, line 135 401.96 [ALRT]:nasal called from: /home/reglnx/FlightGear-Next/data/Nasal/multiplayer.nas, line 89 401.96 [ALRT]:nasal called from: /home/reglnx/FlightGear-Next/data/Nasal/globals.nas,...
-
In the log I see lots of 69.17 [WARN]:general command not found: 'clear-message' 140.69 [WARN]:general command not found: 'show-message'
-
In the log I see lots of 140.69 [WARN]:general command not found: 'show-message'
-
"shift + _" for mpchat broken.
-
I agree. So this issue can be closed ya?
-
I agree. So this issue can be close ya?
-
Still happening here. It doesn't seem to happen everywhere, I notice with just a single object. There's a multirole ship on the northwest of the island at SBFN that becomes invisible as we approach it.
-
By recent I meant no more than a couple of days from the date of posting it, So maybe something between 10/01 and 20/01. The framedrop is much smaller with minimal settings. Changing default settings to the following almost eliminates framedrop, couldnt isolate which one of those that is to blame. Again, but even on absolute minimal settings and all disabled it is still impossible to reach FPS levels of before. <?xml version="1.0"?> <PropertyList> <sim> <rendering> <horizon-effect type="bool">true</horizon-effect>...
-
By recent I meant no more than a couple of days from the date of posting it, So maybe something between 10/01 and 20/01. The framedrop is much smaller with minimal settings. Changing default settings to the following almost eliminates framedrop, couldnt isolate which one of those that is to blame. <?xml version="1.0"?> <PropertyList> <sim> <rendering> <horizon-effect type="bool">true</horizon-effect> <distance-attenuation type="bool">true</distance-attenuation> <specular-highlight type="bool">true</specular-highlight>...
-
Substantial framerate drop on recent builds/commit
-
s/Confirmed on Windows/Confirmed on macOS I tested in LOWI and EDDF.
-
s/Confirmed on Windows/Confirmed on macOS
-
Memory leak on next builds.
-
Particles still enabled by default
-
Compositor is causing the png texture to cast a shadow, you fix that on an aicraft basis, one by one by setting the shadow texture to <noshadow></noshadow>
1 >
