Re: [Flightgear-devel] Musings on the range animation
Sure - would you like a guess where my shader code largely comes from? :-) But there are limits: I asked before doing any work if the existing system can be used to get me a cloud to a predefined location - Stuart's answer was a clear 'no', and since I wanted to have precisely that capability, I had to write the whole control structure myself. Since all you can control from Nasal are ac models, the system is now based on those. Which has the added benefit that one can stack textures in a pre-defined configuration, i.e. always use a diffuse small one above a structured opaque one, or that cloudlet textures don't have to fit on a m x n grid but can retain as much detail as I can extract. What could we do to integrate your work with that system? I've made a fairly lengthy writeup of what I would see as useful and what properties I use here: http://wiki.flightgear.org/index.php/A_local_weather_system#Feature_requests_on_the_C.2B.2B_side This reminds me that people found similar animation patterns for 'common' Scenery models to be pretty expensive as well. Interesting... I guess it depends on numbers - if you have a detailed airport with 1500 different buildings, cars, aircraft, crates, lampposts, fences,... then you should have the same problem - and I guss the same solution, i.e. a sloppy range check which only probes every n frames should offer the same performance gain. * Thorsten -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
Interesting... I guess it depends on numbers - if you have a detailed airport with 1500 different buildings, cars, aircraft, crates, lampposts, fences,... then you should have the same problem - and I guss the same solution, i.e. a sloppy range check which only probes every n frames should offer the same performance gain. Looking at the animation code, I am thinking about adding some kind of priority property to animations. This might give us the chance to run some animations on every frame, others on every n-th frame. This might be configurable at a global scope (rotate animations run every frame, LOD- animations every 10th frame or so) and can locally be overridden for every instance of an animation. I think, I'll do some testing during this week... Torsten -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
On Sun, Sep 5, 2010 at 7:01 AM, wrote: I've recently come across some interesting phenomenon with regard to the range animation. Hi Thorsten, One very generic comment about scene graphs is that typically, range animations (and scene culling in general) works best if you arrange your scene hierarchically. So instead of having 100 leaf nodes and each one of them requires a range test, arrange the objects in something like a quad tree, so larger sub-trees (with all the spatially related leaf nodes) can all be rejected together as a group. Tiling sounds like a good first step in that direction. Usually you don't need to create a very deep quad-tree to get near optimal results (and if you add too many more intermediate nodes, there will be some overhead in traversing all those extra scene elements.) Are you placing your range animation node above each tile or above each object in each tile? I suspect that some careful scene graph organization could yield better results than nasal ... but the same general principle applies either way ... avoiding wasted work is a key element of graphics optimization. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
Hi Curt, Are you placing your range animation node above each tile or above each object in each tile? One has to work with the tools available - or write one's owns... with range animation I literally mean the xml-tag in the wrapper of a model: animation typerange/type min-m0/min-m max-m31000/max-m /animation Using that tool, you can't organize a scene in subnodes with models spawned from Nasal (or maybe you can and I just don't know how). I suspect that some careful scene graph organization could yield better results than nasal ... I have organized clouds in a quadtree structure I wrote for Nasal and in arrays when I need it for different purposes. For the problem at hand, I want to limit the amount of possible models written into the scenery (which is by far the slowest operation) - so the quadtree doesn't buy me much - in my scheme I have 10 range comparisons per frame (at the expense of not processing everything every frame - which I don't need anyway) - the quadtree would need much more (but would process everything every frame). I tend to use the quadtree representation for things which need to be fast, on a per-frame basis, and the array representation for things which can be slow and be dragged out over many frames. The quadtree isn't so good to solve slow problems - which, surprisingly, exist in rendering :-) * Thorsten -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
On Sun, Sep 5, 2010 at 6:01 PM, thorsten.i.r...@jyu.fi wrote: Hi Curt, Are you placing your range animation node above each tile or above each object in each tile? One has to work with the tools available - or write one's owns... with range animation I literally mean the xml-tag in the wrapper of a model: There's an existing 3D cloud animation system which has had a lot of optimization work done on it. Have you looked at this at all? What could we do to integrate your work with that system? Tim typerange/type min-m0/min-m max-m31000/max-m /animation Using that tool, you can't organize a scene in subnodes with models spawned from Nasal (or maybe you can and I just don't know how). I suspect that some careful scene graph organization could yield better results than nasal ... I have organized clouds in a quadtree structure I wrote for Nasal and in arrays when I need it for different purposes. For the problem at hand, I want to limit the amount of possible models written into the scenery (which is by far the slowest operation) - so the quadtree doesn't buy me much - in my scheme I have 10 range comparisons per frame (at the expense of not processing everything every frame - which I don't need anyway) - the quadtree would need much more (but would process everything every frame). I tend to use the quadtree representation for things which need to be fast, on a per-frame basis, and the array representation for things which can be slow and be dragged out over many frames. The quadtree isn't so good to solve slow problems - which, surprisingly, exist in rendering :-) * Thorsten -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on the range animation
thorsten.i.r...@jyu.fi wrote: One has to work with the tools available - or write one's owns... with range animation I literally mean the xml-tag in the wrapper of a model: animation typerange/type min-m0/min-m max-m31000/max-m /animation This reminds me that people found similar animation patterns for 'common' Scenery models to be pretty expensive as well. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
