Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 22.07.12 22:40, schrieb Thomas Geymayer: > Hi Stefan, > > Am 2012-07-21 22:46, schrieb stefan riemens: >> It's obviously a long time wish to get rid of the PLIB dependency, and >> one of the main subsystems using it is the GUI. There are a couple of >> things lacking in possibilities with the current implementation: >> - Proper internationalisation. PUI doesn't support UTF-8, limiting >> i18n support tremendously. >> - Things like submenus >> - The code is pretty messy, by the looks of it mostly due to the >> oldness of PUI and its API > > Have you seen my ongoing efforts towards a unified 2D drawing system > called Canvas (http://wiki.flightgear.org/Canvas). It basically allows > drawing 2D shapes (with OpenVG) and text (using osgText::Text). > > As it uses osgText for textrendering, supporting UTF-8 is very easy. I > just tried it and with changing a single line of code now also using > UTF-8 is supported. > > Currently only drawing inside an existing (PUI) dialog is possible, but > the idea is to slowly implement the current functionally in Nasal and > get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard > interaction with Nasal will be needed. > > In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) > this approach would give much more flexibility and also the means of > modifying and creating new widgets without the need to touch any core code. > > With the Canvas system every type of widget would be possible, so that > also things like submenus can be realized. > > Another advantage of the Canvas approach is that it is heavily using the > property tree and therefore is already fully accessible from Nasal code > and also configurable with the existing xml formats. > > Switching to another scripting language or adding support for a new one, > I think would be far too much work and not worth the efforts. > > Regards, > Tom > I don’t know what is it worth to think about a GUI inside fgfs at all sometimes. When I look to what can be done i.e. with the FGx launcher, properties and now HLA/RTI I’m thinking about trying to skip the built-in GUI at all ;-) Cheers, Yves -- 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
Re: [Flightgear-devel] Switching from PUI to osgWidget
Hi Stefan, Am 2012-07-21 22:46, schrieb stefan riemens: > It's obviously a long time wish to get rid of the PLIB dependency, and > one of the main subsystems using it is the GUI. There are a couple of > things lacking in possibilities with the current implementation: > - Proper internationalisation. PUI doesn't support UTF-8, limiting > i18n support tremendously. > - Things like submenus > - The code is pretty messy, by the looks of it mostly due to the > oldness of PUI and its API Have you seen my ongoing efforts towards a unified 2D drawing system called Canvas (http://wiki.flightgear.org/Canvas). It basically allows drawing 2D shapes (with OpenVG) and text (using osgText::Text). As it uses osgText for textrendering, supporting UTF-8 is very easy. I just tried it and with changing a single line of code now also using UTF-8 is supported. Currently only drawing inside an existing (PUI) dialog is possible, but the idea is to slowly implement the current functionally in Nasal and get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard interaction with Nasal will be needed. In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code. With the Canvas system every type of widget would be possible, so that also things like submenus can be realized. Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats. Switching to another scripting language or adding support for a new one, I think would be far too much work and not worth the efforts. Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- 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
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 21 Jul 2012, at 21:46, stefan riemens wrote: > Obviously, I think the best choice of these is to switch to osgWidget, > and I'm willing to take that task upon me. > I've made a clone on Gitorious, with a osgWidget MenuBar > implementation. Its currently pretty quick and dirty, and looks > absolutely horrible, but it (mostly) works. > https://gitorious.org/~stefanriemens/fg/stefanriemens-flightgear > > Before pushing further with it, I'd like to hear other devs opinions > on how to go forwards... I've got about 25% of option 1) done in a private branch. I believe 4) (using osgWidget) is not great because osgWidget is essentially unfinished, unmaintained and has no examples of the kind of widgets we actually need - sliders, combo boxes, dials and so on. The great advantage of porting PLIB is that the we already use its API, and it already implements all the widgets we need :) I did start using osgWidget, and realised to create scrollbars, combo-boxes and sliders that work, and then port all the dialog / menu code to use the new API, was a huge amount of work, and would require updating all the dialog XML definitions. I am hopeful (though not sure) that I can make approach 1) and keep all the existing generic and aircraft-specific dialog XML files looking 'okay' and working as intended. My assumption is to make osgWidget do what we need, you will *have* to fork it (although you may be able to upstream the changes if they are generic enough) and will spend a lot of time creating all the widgets we need. If you disagree, I am more than happy to help and collaborate, but I'd like to see proof-of-concept code, say, a combo-box and scrollbar before agreeing you can do it :) James -- 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
[Flightgear-devel] commit 75087095b132ec7a42e14000c7c8b3b09147d720
Hi Tim,
The mentioned commit breaks scenegraph picking.
For reference take the c172 door handle that opens the dor but never closes it
anymore. Well, except you click at the position where the untransformed door
handle would be.
Also I have some issues with this.
I agree that we should move this into the cull stage. I wanted this also for
some time now. So, thanks for doing this.
But:
I think we should do this in a usual osg::Transform derived class in the two
methods computing the transforms.
That would make picking work again.
That would make osgUtil::CullVisitor find some already pooled RefMatrix without
the need to call new/malloc and delete/free implicitly on each of these nodes.
That would make the nodes work without the EffectCullVisitor and with a plain
osgUtil::CullVisitor. Sure this could be done by just changing the
dynamic_cast to the osgUtil::CullVisitor.
Also osg::Matrix has some methods like {pre,post}Mult{Translate,Scale,Rotate}
which works with O(n^2)~16 operations instead of O(n^3)~64 operations. Ok, the
rotate method saves less.
Greetings
Mathias
--
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
Re: [Flightgear-devel] Rendering passes question
Hi, On Sunday, July 22, 2012 01:17:43 Tim Moore wrote: > That is a big problem, but we also have CPU bottlenecks upstream too. I agree. The scenegraph structure is not well suited. But therefore at the first cut I hope to simply get less tiles and models present by a better lod structure. Therefore the below work. > I would really like to see that code! SGReaderWriterSPT. Start fgviewer without arguments. There is a meta loader for these spt files that encode the area they should cover in the file name before the spt extension. There are problems with the tiles near the poles. But this is something that the original stg database covers very bad. So the spt loader just reflects this weakness. I wanted to address this just before somebody who felt responsible for a while for the scenery quit this work. Since I would need assistance from the scenery guys for changing the tile layout at the poles ... Greetings Mathias -- 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
Re: [Flightgear-devel] Rendering passes question
>>> The depth-pass-only pass is a well known optimization, but the fact it >>> is not helping implies that our bottleneck is not in fragment >>> processing. Most of the discussion is drifting a bit over my head now, but I'm pretty sure that's not what I am talking about. I am talking about a situation in which we run a fairly detailed shading scheme on the terrain (blend three textures with a gradient bias and add a heightmap for surface roughness to it and shade it all with the atmospheric scattering framework, possibly run more evnironment-dependent effects such as wetness). In this situation my bottleneck is completely in the fragment shader (I also suspect that Rembrandt leans rather heavily on the fragment shader, because what else is there once you have rendered the whole scene to buffers?) - I can switch clouds on and off and don't see an effect in the framerate even if I draw them to 75 km distance, but I see an effect for almost every line I insert into the fragment shader. That situation is what I am interested in optimizing, and my CPU bottleneck is lightyears distant from there. Now, I've tried a dumb scheme which allows you to define a per-plane 3-parameter rectangular mask for the default cockpit view which is used to discard fragments in scenery rendering. The mask parameters are corrected outside of the rendering pipeline (currently in Nasal) for screen resolution, current fov and view axis and airplane-specific changes to the default view axis. The whole block of code doing this is ~20 lines, running once per frame the performance footprint is close to zero. The mask has no transparency problems (because it's hand-crafted), it can usually get 2/3 of the pixels occupied by the panel, the test is done inside the first pass fragment shader which assigns a low depth to everything inside the mask so that fragments falling there are never computed in the detailed 2nd scenery pass. For a plane like the A-10 which has a fairly good ground view, i get ~20% better performance in typical flight situations. For a typical airliner with quite restricted view, I get as much as 50% at cruise altitude. Just zooming into a planel view leads to almost all terrain fragments being discarded in the background and gives me a 100% performance increase, i.e. my performance is no longer restricted by the fragment shader, I'm seeing the vertex shader execution speed. Now, the mask is so simple (it's just an angular region after all) that I imagine it might as well be used to pass vertices in the excluded region through the shader without wasting any time on them, thus also boosting vertex shader performance. The same mask can also be passed to the cloud fragment shader, allowing to get rid of cloud fragment creation in the region where we don't see it. The whole scheme is in fact so successful that it's a pity it is too dumb to be implemented... * Thorsten -- 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
Re: [Flightgear-devel] DDS usage in effects files
On Sat, Jul 21, 2012 at 10:32 PM, Mathias Fröhlich wrote: > Well, for the computation time. I expect that we can observe this on startup. > May be not too much, but this could be at least measurable. With aircraft that use large PNG textures, mipgen is a *significant* proportion of the startup time -- and then often that 4K or 2K or whatever mip barely gets used, but FG had to load it, in order to compute another mip level 3 levels down... -- 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
