[Flightgear-devel] Functions to textures?
First of all, a big thanks to Tim - Akenine-Moller Co. is indeed quite an interesting read, and in addition to gaining a better understanding, I've so far experimented successfully with a heightfield for parallax and normal mapping and a simple irrandiance map instead of the ambient term in lighting. For those not inclined to read through a longer email, my question up front: I have a function, I want a texture holding the function values pairs - how do I map this without editing every pixel offline? And can we do this also online? Where is for instance the 3d noise texture defined and filled - is it simple to change the procedure? For those interested in the context: I have managed to create quite compelling terrain visuals from close-up (see here http://www.flightgear.org/forums/viewtopic.php?f=47t=16884start=15#p162613 for two examples), but rendering seems to get too slow too soon for anything really fancy (of course, a big roadblock is that I'm implementing all this on top of atmospheric light scattering which is slow to begin with - I think in the default light and fog scheme it might run with decent speed). One problem that really kills framerate is de-tiling. In order to de-tile properly, one needs to mix noise from different wavelengths such that the interference creates a pattern with a much larger periodicity. Three wavelengths usually do the job well, two are marginally acceptable, one is quite bad. So, for each texture component (snow, gradient texture, detailed texture, height map, fog) I ideally need three noise wavelengths. In the current 3d noise, noise[0] contains structures with a qualitatively different distribution, so I have to discard that component. noise[3] is too fine and runs into texture resolution problems, so I have to discard that as well. Since the noise pattern associated with different texture components needs to be uncorrelated (otherwise there's yet another form of tiling around the corner) I need to do different noise lookups for every texture component, arranging them in a slightly different wavelength interval. And that's a lot of texture3D() calls which really make the system slow. I could do it in half the time if I would get 4 useful components for every texture3D() call, but that requires that I either create a suitable texture offline or change the way it is done in the code (I'm also exploring if there is perhaps a function that evaluates faster than a texture lookup call...). Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. However, I have no clue how to dump the function into a texture without hand-crafting every pixel. Finally, I think given that we have cloud position and sizes available, it'd be fairly trivial to cast that into a function that defines a shadow-map for clouds (I would not render the clouds to create that map, first because of transparency, second because they're really billboards and likely to come out wrong, third because the map wouldn't change fast and finally because it's faster to do one analytical function per cloudlet than to go through the 40 texture sheets that are in a cloudlet. So, any pointers along that front would be appreciated for a number of reasons... Thanks in advance! * 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] Switching from PUI to osgWidget
Hi all, Thanks for the feedback, and especially thanks to James for the offer! I think your request for POC code is very reasonable, so let me get back to you on that when I have some (although a combobox is already almost there, as it is basically just a menu with a changing header). Obviously, it will take a lot of time to implement all the needed widgets, but I don't think it will be necessary to create a complete osgWidget fork. From what I've seen it's pretty flexible (just lacking a lot of widgets ;). My hope is to be able to upstream most of the yet-to-be-made widgets. My hope is to keep at least the current gui xml format, which I think should be doable. Failing that, let's at least have the changes scriptable ;) I must admit I forgot to look at the nasal API, am going to take a closer look at that shortly. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Regarding librocket, that would mean adding another dependency to FlightGear. I thought the consensus was that that is not something to be taken lightly. And then again, it would require updating all of the gui definitions. Stefan 2012/7/23 Jacob Burbach jmburb...@gmail.com: On Sun, Jul 22, 2012 at 6:42 PM, HB-GRAL flightg...@sablonier.ch wrote: 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 Might be worth having a look at http://librocket.com, looks to be a very powerful and well done gui system. Uses html/css based files for creating, laying out, and styling the gui...has some support for interfacing script engines (ie nasal), localization, etc. This is the route I'd probably go personally if I were to do this...or any game/sim/3d project needing a gui... -- 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/ ___
Re: [Flightgear-devel] Switching from PUI to osgWidget
On 24 Jul 2012, at 13:22, stefan riemens wrote: Thanks for the feedback, and especially thanks to James for the offer! I think your request for POC code is very reasonable, so let me get back to you on that when I have some (although a combobox is already almost there, as it is basically just a menu with a changing header). Obviously, it will take a lot of time to implement all the needed widgets, but I don't think it will be necessary to create a complete osgWidget fork. From what I've seen it's pretty flexible (just lacking a lot of widgets ;). My hope is to be able to upstream most of the yet-to-be-made widgets. Okay - my personal feeling was it's flexible but some of the design choices make a few things harder than they need to be. Again, I've made slow progress on porting PUI, so if you have proof-of-concept stuff for some widgets already, you can convince me quite easily :) Oh, I remembered the other 'difficult' widget - the scrolling lists and (related) multi-line text. My feeling was that osgText was going to handle multi-line text fairly badly, and this might be an issue. We don't have many multi-line text widgets, but they're some useful ones - e.g. the Nasal console. My hope is to keep at least the current gui xml format, which I think should be doable. Failing that, let's at least have the changes scriptable ;) Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility. I must admit I forgot to look at the nasal API, am going to take a closer look at that shortly. I don't think there's a major issue here - so long as you keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Right, canvas makes more sense for the map-widget and replacing the old OpenGL calls in the HUD is my feeling; to build something compatible with the current GUI using the canvas might be possible, but is a lot of work. Regarding librocket, that would mean adding another dependency to FlightGear. I thought the consensus was that that is not something to be taken lightly. And then again, it would require updating all of the gui definitions. Agreed on all counts - of course it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is. 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
Re: [Flightgear-devel] Switching from PUI to osgWidget
Am 2012-07-24 15:43, schrieb James Turner: Oh, I remembered the other 'difficult' widget - the scrolling lists and (related) multi-line text. My feeling was that osgText was going to handle multi-line text fairly badly, and this might be an issue. We don't have many multi-line text widgets, but they're some useful ones - e.g. the Nasal console. I have just experimented a bit with osgText and multi-line text. So far I didn't notice any problems. Regarding canvas, I think that that is definitively the way to go for stuff like the map widget, but to be honest I have my doubts whether it would be suitable for the entire gui. I must admit though, so far I've only read the documentation on the wiki, so I haven't played around with it yet. Right, canvas makes more sense for the map-widget and replacing the old OpenGL calls in the HUD is my feeling; to build something compatible with the current GUI using the canvas might be possible, but is a lot of work. But using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... I've done a quick proof of concept for a tabbed and scrollable widget (including some UTF-8 chars): http://youtu.be/1a6wtPVPWc4 https://gitorious.org/~tomprogs/fg/toms-fgdata/blobs/canvas/gui/dialogs/canvas-demo.xml 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 24 Jul 2012, at 16:45, Thomas Geymayer wrote: I have just experimented a bit with osgText and multi-line text. So far I didn't notice any problems. My concern was about calculating sane vertical heights allowing for line-wrap, but that appears to work, based on your demo below! But using the Canvas also for the GUI would give us the advantage of a unified rendering backend for any type of GUI/text rendering and also the ability to use the same widgets everywhere - eg. use them also inside aircrafts for CDU GUIs or other displays... I've done a quick proof of concept for a tabbed and scrollable widget (including some UTF-8 chars): That's quite a convincing demo :) Especially since we'd factor the createXYZ functions into a helper, or even C++, depending on how much customisability we're looking for. I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI. Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) Stefan, what's your opinion? Obviously Thomas knows the Canvas code since he created it - I've looked at the source but not used it properly (and probably no-one else has a chance to either, yet), but it has the advantage that it's already checked in, and offers a very lightweight solution potentially. (We could could allow aircraft dialogs to include custom widgets, although that might be unwise for other reasons) 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
Re: [Flightgear-devel] Functions to textures?
On Tue, 24 Jul 2012 07:02:44 +, Renk wrote in message e495a106ff5f31448739e79d34138c19196d3...@mbs1.ad.jyu.fi: First of all, a big thanks to Tim - Akenine-Moller Co. is indeed quite an interesting read, and in addition to gaining a better understanding, I've so far experimented successfully with a heightfield for parallax and normal mapping and a simple irrandiance map instead of the ambient term in lighting. For those not inclined to read through a longer email, my question up front: I have a function, I want a texture holding the function values pairs - how do I map this without editing every pixel offline? And can we do this also online? Where is for instance the 3d noise texture defined and filled - is it simple to change the procedure? For those interested in the context: I have managed to create quite compelling terrain visuals from close-up (see here http://www.flightgear.org/forums/viewtopic.php?f=47t=16884start=15#p162613 for two examples), but rendering seems to get too slow too soon for anything really fancy (of course, a big roadblock is that I'm implementing all this on top of atmospheric light scattering which is slow to begin with - I think in the default light and fog scheme it might run with decent speed). One problem that really kills framerate is de-tiling. In order to de-tile properly, one needs to mix noise from different wavelengths such that the interference creates a pattern with a much larger periodicity. Three wavelengths usually do the job well, two are marginally acceptable, one is quite bad. So, for each texture component (snow, gradient texture, detailed texture, height map, fog) I ideally need three noise wavelengths. In the current 3d noise, noise[0] contains structures with a qualitatively different distribution, so I have to discard that component. noise[3] is too fine and runs into texture resolution problems, so I have to discard that as well. Since the noise pattern associated with different texture components needs to be uncorrelated (otherwise there's yet another form of tiling around the corner) I need to do different noise lookups for every texture component, arranging them in a slightly different wavelength interval. And that's a lot of texture3D() calls which really make the system slow. I could do it in half the time if I would get 4 useful components for every texture3D() call, but that requires that I either create a suitable texture offline or change the way it is done in the code (I'm also exploring if there is perhaps a function that evaluates faster than a texture lookup call...). Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. However, I have no clue how to dump the function into a texture without hand-crafting every pixel. Finally, I think given that we have cloud position and sizes available, it'd be fairly trivial to cast that into a function that defines a shadow-map for clouds (I would not render the clouds to create that map, first because of transparency, second because they're really billboards and likely to come out wrong, third because the map wouldn't change fast and finally because it's faster to do one analytical function per cloudlet than to go through the 40 texture sheets that are in a cloudlet. So, any pointers along that front would be appreciated for a number of reasons... Thanks in advance! ..maybe this is a place for Lisp? http://www.paulgraham.com/icad.html http://www.paulgraham.com/avg.html -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) 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] Functions to textures?
Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. That depends a lot on the GPU, and how coherent the texture coordinates are across a triangle. You also need enough ALU work elsewhere in the shader to mask the latency of the texture lookup. For the existing noise texture generation, take a look at make3DNoiseImage in scene/material/TextureBuilder.cxx in the simgear tree. This particular texture is filled CPU-side, but if you're more comfortable expressing things in a shader, you/someone could rig up some FBO wiring to quickly render a shader-defined function into a texture. -- Chris -- 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 Thomas, Hi James This looks promising in a technical/coding perspective of having this and that common GUI feature available also for flightgear. But for me personally one of the big problems of the FlightGear GUI is that it is inside the only and one main window. There is no possibility to have a separate window to not cover the main content, the scenery and the cockpit? This would make the GUI much more practical. I would really like to run flightgear with one window view and other windows for the program (options). This will improve the usability of all the menus, dialogs etc. a lot in my opinion. Cheers, Yves Am 25.07.2012 um 00:11 schrieb Thomas Geymayer tom...@gmail.com: Am 2012-07-24 19:35, schrieb James Turner: Thomas, one issue I can guess at (though PLIB is also really bad at it, and osgWidget is not much better!) - text selection. Do you think you'd be able to handle a blinking insertion point and a standard draggable text selection area in this approach? Obviously it might need some additional C++ helpers but that's okay since text-editing is a pretty specialised behaviour. Yes :) http://youtu.be/CIS8UyuJLgM I have just added some property change listeners to get the position of the next character at a given position. The highlighting happens only from Nasal. What is currently missing is the possibility to also change the color of the selected text and to actually get the selected text, but this shouldn't be too hard to implement. One goal of mine for the GUI is to get platform native copy-and-paste working, BTW ;) This has already been on my wish/todo list :P Obviously Thomas knows the Canvas code since he created it [...] Currently documentation is not too detailed, but looking at the different demos and maybe also the Nasal API and source code should help. If not, don't hesitate to ask :) 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 -- 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] Functions to textures?
On Wed, Jul 25, 2012 at 12:16 AM, Chris Forbes chr...@ijw.co.nz wrote: Somewhat inversely, I'm also wondering if a simple texture1D() lookup might not be faster than evaluating the light function e / pow((1.0 + a * exp(-b * (x-c)) ),(1.0/d)) three times to get an (rgb)-triplet. That depends a lot on the GPU, and how coherent the texture coordinates are across a triangle. You also need enough ALU work elsewhere in the shader to mask the latency of the texture lookup. For the existing noise texture generation, take a look at make3DNoiseImage in scene/material/TextureBuilder.cxx in the simgear tree. This particular texture is filled CPU-side, but if you're more comfortable expressing things in a shader, you/someone could rig up some FBO wiring to quickly render a shader-defined function into a texture. Actually, the code that creates the texture is in scene/util/StateAttributeFactory.cxx, but you would have to do something similar to the noise texture code in TextureBuilder to access your texture from a texture. It would be nice if the Effects framework had a way to load arbitrary textures and make them available to effects. These days you aren't limited to 8 bit texture components. There is a rich set of data formats for textures: 32 bit floats, 16 bit floats, exotic combinations of different length floats per RGB component... I don't know if there is a better way to create your texture offline than write C++ code in simgear. OSG will read a TIFF file with 32bits per component as a floating point texture... assuming you can create such a thing. Tim -- 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
