Board index FlightGear Development Scenery

EHAM problem

Questions and discussion about enhancing and populating the FlightGear world.

Re: EHAM problem

Postby merspieler » Mon Sep 27, 2021 10:49 pm

Can't reproduce here...
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2228
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: EHAM problem

Postby wkitty42 » Mon Sep 27, 2021 11:27 pm

V12 wrote in Mon Sep 27, 2021 8:24 pm:Another test of the freshly compiled FG2020.4.0 daily. I used unmodified D/C script, on LUbuntu 20.04 after completly removed Terrasync folder :

please also provide screenshot of rendering settings in-sim...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: EHAM problem

Postby V12 » Tue Sep 28, 2021 3:56 am

I will provide screenshot with rendering settings this evening. IMHO, the problem is not in the rendering settings, because if You better check the last screenshot, You will see airplanes on that strange hills. Light cone models behave as terrain.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: EHAM problem

Postby portreekid » Tue Sep 28, 2021 5:31 am

I had the same problem with that model at EGPE. So just fix the Model.
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

Re: EHAM problem

Postby V12 » Tue Sep 28, 2021 9:26 am

I have dual boot - WIn10 and LUbuntu 20.04. I do not understand why on the same machine with same fgdata and same terrasync data for 2020.4.0 is EHAM rendered correctly on Win, but on Linux not. There is not problem fix the model, important is reason of this error.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: EHAM problem

Postby portreekid » Tue Sep 28, 2021 9:41 am

Understanding how the light cone is built in this model and why it doesn't happen with other lights just might put you on the right track of finding the effect being applied or not applied. As stated I had that problem with this model and just used a different one.
portreekid
 
Posts: 651
Joined: Tue Jan 14, 2014 4:36 pm
Location: Leipzig
Callsign: PORTREE
Version: 2020.2.1
OS: Windows 10

Re: EHAM problem

Postby V12 » Tue Sep 28, 2021 4:14 pm

Light cone is object with name lightvolume and in the XML has <enable-hot type="bool">false</enable-hot>. According to https://wiki.flightgear.org/Howto:Anima ... Enable-hot this tag disables colisions vehicles vs the model. But this doesn't work on Linux FG2020.3.11 / 2020.4.0, but works in Win10 FG 2020.4.0.

Problem solved - I deleted lightvolume object from .ac and set read_only attribute to this file.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: EHAM problem

Postby wkitty42 » Wed Sep 29, 2021 3:53 pm

V12 wrote in Tue Sep 28, 2021 4:14 pm:But this doesn't work on Linux FG2020.3.11 / 2020.4.0, but works in Win10 FG 2020.4.0.
you are using the proper and separate FGData directories for these, right? 2020.4.0 (aka next) uses a different FGData than 2020.3 uses...

V12 wrote in Tue Sep 28, 2021 4:14 pm:Problem solved - I deleted lightvolume object from .ac and set read_only attribute to this file.

ouch... if it doesn't fit, force it, eh?

but you also made me check and... well... i don't see the problem here... i am using self-built (via dnc) OSG 3.6.5, though... not system supplied one...
this shot is from similar position to your's...
Image

turns out we're also at the same FG commit... can't tell about your FGData and any others, though...
Code: Select all
OSG 3.6: df21f597
Simgear: 0f946abc
FGFS   : 3e7e970e
FGData : a24ed9ad
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9123
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: EHAM problem

Postby ludomotico » Wed Sep 29, 2021 4:09 pm

The interesting thing is not that the lightcone is rendered as a grey pyramid, but that V12 reports that vehicles behave like it is an actual pyramid. That suggests this is not a rendering problem or some issue with the OSG library. As he said, it seems like FG is not reading the configuration in the XML.

I can't see anything wrong in the XML, but it could be the XML parser changed somehow. Are XML files parsed using any external library? I don't know

V12, since you are the only one experimenting this bug, maybe you can try modifying the XML until you are able to detect the offending line... if any.

Let's see if someone can reproduce this bug.
User avatar
ludomotico
 
Posts: 1269
Joined: Tue Apr 24, 2012 2:01 pm
Version: nightly
OS: Windows 10

Re: EHAM problem

Postby V12 » Wed Sep 29, 2021 6:41 pm

wkitty42 :
Yes, I use correct fgdata - one for Win10 FG2020.4.0 shared with LUbuntu FG2020.4.0, another for LUbuntu FG2020.3.11

ludomotico :
In the XML is animation with test for Rembrandt renderer. If I changed this property manually via property browser, nothing changed in the renderer.

I do not know, where is my problem, because EHAM is :
- machine 1 - LUbuntu 20.04 / FG2020.3.4 - flawless
- machine 2 - LUbuntu 20.04 / FG2020.3.11 - pyramids
- machine 2 - LUbuntu 20.04 / FG2020.4.0 - pyramids
- machine 2 - Win10 / FG2020.3.11 - flawless
- machine 2 - Win10 / FG2020.4.0 - flawless

IMHO, LUbuntu on machine 2 has some strange problem.

EDIT :
I tested EHAM few minutes ago, in the night time and I observed light area changes after manual change property in the browser. This is evidence that FG reads .XML file for this model and problem is in OSG, because lightcone has disabled collisions. And Willis Jeep can climb on light cone :)
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: EHAM problem

Postby PH-JAKE » Tue Oct 26, 2021 6:49 pm

Yep, same issue here. Running Debian testing (=bookworm/sid) at the moment.

/sim/version/flightgear: 2020.3.6
/sim/version/simgear: 2020.3.6
/sim/version/openscenegraph: 3.6.5
/sim/version/build-id: none
/sim/version/build-number: 0
/sim/version/build-type: Dev
/sim/version/revision: none
/sim/rendering/gl-vendor: NVIDIA Corporation
/sim/rendering/gl-renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
/sim/rendering/gl-version: 4.6.0 NVIDIA 470.74
/sim/rendering/gl-shading-language-version: 4.60 NVIDIA
/sim/rendering/max-texture-size: 16384
/sim/rendering/depth-buffer-bits: 24
PH-JAKE
 
Posts: 156
Joined: Wed Mar 12, 2014 12:53 am
Callsign: PH-JAKE
Version: 2020.3.18
OS: Debian trixie

Re: EHAM problem

Postby IskenderWang » Tue Apr 05, 2022 7:39 am

I'm having this issue to this day!! on both 2020.3.13 AND nightly, on Windows w/ an nvidia card – never understood why it has remained like this for me. Back when I was on Mac I never had this problem. The culprit seems to be the EHAM_lichtmastdubbelgroot model but even the latest on terrasync (assuming that's working properly for me) has all the lights still messed up in this fashion
IskenderWang
 
Posts: 2
Joined: Mon Aug 24, 2020 4:48 am

Previous

Return to Scenery

Who is online

Users browsing this forum: No registered users and 4 guests