HDR Gallery

[jtprophet]

I see now excellent clarification thank-you all.

John

[F5SLQ]

Hi all,
When I use the following parametters
--httpd=8080
--prop:double:/sim/rendering/static-lod/bare=30000
--graphics-preset=medium-quality
--prop:/sim/rendering/photoscenery/enabled=true
--prop:/sim/rendering/multi-samples=8
--compositor=Compositor/HDR/hdr
I loose the MENU and all keybord controls (no any screen even on ESC, F10, / or others...)

My conf is

/sim/version/simgear: 2020.4.0
/sim/version/openscenegraph: 3.6.5
/sim/version/build-id: 4834
/sim/version/build-number: 4834
/sim/version/build-type: Nightly
/sim/version/revision: 459242b9db0a793d9853440991bb0d29f3f3771c
/sim/rendering/gl-vendor: NVIDIA Corporation
/sim/rendering/gl-renderer: NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2
/sim/rendering/gl-version: 4.6.0 NVIDIA 537.42
/sim/rendering/gl-shading-language-version: 4.60 NVIDIA
/sim/rendering/max-texture-size: 32768
/sim/rendering/depth-buffer-bits: 24
under Win 11 22H2
Some ideas ?
Tnx in advance.

[merspieler]

With HDR that's expected, you don't have any PUI GUI, only canvas GUIs work.

[F5SLQ]

Hi merspieler
Thanks for your quick answer.

With HDR that's expected, you don't have any PUI GUI, only canvas GUIs work.

How to have a Canvas GUI with FG 2024 ?
Sorry for this probably stupid question, but I'm more mechanics than geek
Best regards.

[merspieler]

Currently afaik there's no full menu system using canvas.
So apart from a few dialogs which can be called via keyboard shortcuts, you won't have them with HDR enabled.

[F5SLQ]

Currently afaik there's no full menu system using canvas.
So apart from a few dialogs which can be called via keyboard shortcuts, you won't have them with HDR enabled.

Tnx merspieler for your explanations.
Best regards.

Laurent

[Hooray]

Currently afaik there's no full menu system using canvas.

@merspieler: just wondering: Is this really still the case ?

I am asking because we already had a working canvas menubar implementation roughly 2-3 yrs ago, and parsing the menubar (even in Nasal) isn't exactly rocket science, so just wondering what exactly is the roadblock here given the importance of having a UI in PBR mode ?

More recently, in early 2023 TheEagle implemented a full native Canvas menubar for Canvas dialogs (available via the debug menu at the time):



So what exactly is missing to make use of these building blocks ??

[Octal450]

What is missing is that nobody has made use of these building blocks.

We've had canvas menubar proposals but nobody has done it... so merspieler's statement is correct. There is no full menu system using canvas and thus PUI is still required for proper use of the sim.
 
Kind Regards,
Josh

[Hooray]

We've had canvas menubar proposals but nobody has done it

Well we've had a working menubar parser 5+ years ago, so I somehow doubt that this is currently the showstopper ?

Just look at the screen shot, the Canvas GUI system also has got the corresponding helpers to render menus - so there must be more to it than we can see given that we've had both, the parser as well as the Canvas widgets for quite some time now ?

Even in the early pui2canvas days, folks like Omega95 or Jabberwocky came up with working menubar emulations using just PUI:

https://wiki.flightgear.org/Howto:Makin ... as_Menubar




EDIT: And just checking, it seems there already is a menubar module in $FG_ROOT/Nasal/gui: https://sourceforge.net/p/flightgear/fg ... enuBar.nas
So it doesn't seem to be correct to assume that "nobody has done it", it just seems that folks are not aware of all the stuff that is already available - as usual ....

[wkitty42]

could it be, quite simply, that the average user expects the menu to appear when they hit F10 but in HDR mode, F10 does not appear to work because no menu appears? apparently no one has done the work to detect if FG is in HDR mode and switch F10 to open the canvas menu instead of the PUI one... i think that is what was meant by "no one has done it"...

[Hooray]

to be honest, I haven't been following the devel-list lately, but there have been sooo many announcements over the years basically stating that the PUI replacement was basically ready, I would doubt that there's really that much missing at this point ?

Being familiar with the Nasal/Canvas side of things, as well as TheEagle's efforts related to bringing the Canvas UI toolkit up to par with the PUI bindings used by FG, I would estimate that all that's missing at this point is at most ~ 1-3 hrs of Nasal hacking to map the menubar.xml structure to the Canvas menubar binding (assuming that the C++ code isn't yet doing exactly that already?).

Since this is likely to be in the interest of those tracking ongoing HDR/PBR work by Fernando, I would suggest to raise any open questions with him and TheEagle - based on my own understanding of the underlying systems, there should not be anything missing at this point - unless some of the core devs changes once again their UI-plans ??

For starters, someone using HDR mode might want to verify if the devel extensions Canvas menubar is working in the standalone dialog or not, if it is - we're in pretty good shape to also use the same system for the menubar in HDR mode.

(that being said, this should not even be required on MacOS systems, since FG is using a native menubar on those systems)

[TheEagle]

All code for the Canvas menubar replacement is already in place - in Nasal/canvas/gui.nas you can even find a line creating an instance of it at the bottom of the file, but it is commented out because it caused focusing issues - all this is pending is me finding the time (and the motivation to fix that one issue !

[Hooray]

Indeed, that'd be in line with my observations. Thanks for clarifying !
If you're lacking motivation, you might want to reach out to Icecode GL/Fernando, since he already mentioned in private that he was looking forward to seeing PUI being replaced by Canvas

Other than that, feel free to share more details about the focusing issue and pointers to your code, so that we can take a look - who knows, maybe I still remember some Nasal/Canvas stuff after all those years

EDIT: LOL, I just stumbled across someone offering to port PUI, which goes to explain what might have happened (once again!): https://sourceforge.net/p/flightgear/ma ... sg37884349

[icecode]

There are two different issues regarding GUI in HDR:

1. The GUI camera does not render anything (neither PUI nor Canvas). This is caused by OSG's attribute aliasing being enabled in HDR. I suspect the solution might have to do with forcing the GUI camera to use shaders instead of the fixed-pipeline. I haven't delved too deep into this yet because there are many possible places to "inject" the shader programs. It will require some trial and error and fair deal of OpenGL state debugging to fix this. I'll also have to talk to James since he seems to be the most familiar with the current way that things are setup regarding PUI and OSG.

2. PUI requires fixed-pipeline functionality, which is not available under the GL core profile. This is fixed by the Canvas GUI.

Issue number 1 is the reason why we currently have no GUI in HDR. Issue number 2 is the reason why we don't have HDR at all on AMD/Intel, as those drivers don't care about implementing the compatibility profile.

[Hooray]

I do recall James' changes relating to HiDPI and how he refactored everything to work for OSG and PUI, so that might be a low-hanging fruit to check first (?)

The other candidate to check next would seem to be James Hogan's VR work which he mentioned does support a built-in UI (?) - which should not even be using PUI at all, so might be suitable to use a template to locate the right approach to insert a Canvas cam and make it use shaders ? (I would definitely suggest to reach out to him first, since he must have thought about the problem already)

Alternatively, what about Jules' original multi-window fgcommand (part of the compositeviewer/sview cloning code IIRC): I don't remember all the nitty gritty details here, but could we render the UI to a separate window (context) that way to provide people with a compromise ?

Also: I am not sure if this is documented/mentioned anywhere on the wiki or not, but if it isn't it would be great if someone could copy it to the appropriate place - alternatively, please file a dedicated feature request, copying Fernando's posting and linking back to it here, so that this won't be lost...

PS: <brainstorming mode="on">and if everything above fails, regarding the issue of stateset debugging to locate the proper osg::Node for the GLSL portion, how about treating this like a git bisect: I do recall that we're able to dump the scene graph to disk, so how about a debug mode using BSP to split up the scene graph for a binary search and inject the shaders in different parts while observing the stateset/rendering result (FBO), would that help narrow down potential nodes/places maybe just a little (I have seen nodes containing annotations in the form of code file and line number) ?

Basically, I imagine the equivalent of the minimal startup profile rendering just a tooltip/dialog via the UI camera and then inject the shaders at different points to evaluate just how wrong the output looks in terms of rendering output and stateset changes to hopefully exclude a bunch of obvious nodes/places and locate some of the more promising ones (remember our early canvas-cam experiments not rendering the skydome?)