Re: [Flightgear-devel] Project Rembrandt - next steps
On Wed, 7 Mar 2012 07:46:37 +1300, Chris wrote in message cah3ygc2-urb3gpvhuj-cuhn8sosjgvwcns9wyr6ndjp8hog...@mail.gmail.com: On 7/03/2012 4:42 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 03 Mar 2012 21:17:30 +0100, Torsten wrote in message 4f527c5a.5060...@t3r.de: The screen stays white with three black corners (top right, bottom right and bottom left). No splash screen. I can exit after some time with (Esc)-(Enter). GPU is GeForce Go 7400 with latest driver. Anything I can do to help debugging? ..try the nouveau driver, it _might_ work here, and will in any case give a different set of error messages. I doubt you're going to have an acceptable experience ..now, _that_ would be a very nice surprise. ;o) using a deferred renderer on a go7400 ..there is another and preferred renderer for it? , regardless of driver bugs. There's not a lot of fillrate there. ..ok, my point was try get _another_ set of error etc messages with the nouveau driver, if it as a bonus works better than Nvidea's driver, _celebrate_. ;o) -- ..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. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? Thanks, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
De: thorsten i renk I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? You don't have to create a parameter for the properties you want to test in the predicate. But you're right, all the parameters of all pass of all techniques of an effect need to be declared in a single section. A pass is a state set: all the OpenGl attribute of the geometry. When you declare multiple pass, it's because you want the same geometry be drawn several times. You may want to initialize the stencil buffer in one pass (you don't need material properties then) and then draw the object with the stencil test enabled. If you play with the render bins and the draw order that are settable in each pass you can achieve effect such as the light cone (pre - Rembrandt) Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
I doubt you're going to have an acceptable experience using a deferred renderer on a go7400, regardless of driver bugs. There's not a lot of fillrate there. On 7/03/2012 4:42 AM, Arnt Karlsen a...@c2i.net wrote: On Sat, 03 Mar 2012 21:17:30 +0100, Torsten wrote in message 4f527c5a.5060...@t3r.de: The screen stays white with three black corners (top right, bottom right and bottom left). No splash screen. I can exit after some time with (Esc)-(Enter). GPU is GeForce Go 7400 with latest driver. Anything I can do to help debugging? ..try the nouveau driver, it _might_ work here, and will in any case give a different set of error messages. -- ..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. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Hi Thorsten, De: thorsten i renk I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Yes please. Or if someone could just help in creating an effect structure thatone can switch these things on and off so that installing the lightfields doesn't have to overwrite everything and that it would be on GIT? Then we can worry about how to merge later? Lightfields would work optionally, there's no fundamental obstacle here. I know there's the idea to get everything perfectly merged in an elegant way by factoring out light and haze functions, but I'd be happy with a simple optional structure now and the rest later. Be sure that I am extremely interested in merging your work into Rembrandt. It is just too early for me, and as the discussion raised the point of the compatibility with older hardware, the mockup (from by clone) can't be merged as is. So, in order to have the less disturbing migration path as possible, things will take even more time. But i will come back to you to see how decoupling light and haze can be done in the future framework. It's getting somewhat frustrating... Not so much for myself, but for others who want to try it, and it's starting to look silly when I have to tell everyone who is interested 'Sorry, it's ready since a month ago, but we haven't been able to put it on GIT yet, so you still need to go through a tricky manual installation process'. Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Technically it could, but at the expense of forcing everyone to use lightfield shaders. It overwrites for instance the default terrain and model shaders. The reason why this is implemented in that way is that I have no clue how an effect file should be properly structured. I can change an existing effect file to insert new property-to-unifrom mappings, I can change the filename of the shader to be used, but my attempts to do more have so far gone terribly wrong and broken the effect. So what needs to be done for a clean commit is: * rename the special shader files where they overlap with default files * add conditionals to the effect files that if skydome scattering shader is on the lightfield files should be used, otherwise the defaults as they are (* not essential, but currently true camera altitude above MSL is obtained from Nasal and written into the tree - I'm fairly sure we have it somewhere better, I just don't know where) It's not much work, but it requires some better knowledge of how effect files work. Which is the point where I need help. * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Monday 05 March 2012 12:02:26 Frederic Bouvier wrote: Hi Thorsten, De: thorsten i renk I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Yes please. Or if someone could just help in creating an effect structure thatone can switch these things on and off so that installing the lightfields doesn't have to overwrite everything and that it would be on GIT? Then we can worry about how to merge later? Lightfields would work optionally, there's no fundamental obstacle here. I know there's the idea to get everything perfectly merged in an elegant way by factoring out light and haze functions, but I'd be happy with a simple optional structure now and the rest later. Be sure that I am extremely interested in merging your work into Rembrandt. It is just too early for me, and as the discussion raised the point of the compatibility with older hardware, the mockup (from by clone) can't be merged as is. So, in order to have the less disturbing migration path as possible, things will take even more time. But i will come back to you to see how decoupling light and haze can be done in the future framework. It's getting somewhat frustrating... Not so much for myself, but for others who want to try it, and it's starting to look silly when I have to tell everyone who is interested 'Sorry, it's ready since a month ago, but we haven't been able to put it on GIT yet, so you still need to go through a tricky manual installation process'. Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Regards, -Fred No it can't. The fog/light functions need to be extracted and put into include_fog.*, and there needs to be a check in that one that switches between the different models based on the sky shader setting. There is an important issue though, the functions appear to be different for objects and terrain. That's not quite optimal IMHO, and will lead again to diverging fog models (what I've been trying to avoid by using a common fog function). And just throwing them in and splattering all the other shaders with fog functions in them will triple the work required later. So it's better to do this right from the beggining. Regards, Emilian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
There is an important issue though, the functions appear to be different for objects and terrain. What?? Both model-default.eff and terrain-default.eff refer to terrain-haze.vert/frag as shaders - how can the fog function be different if they're using the same shader code??? I think you're mistaken here. The fog function is different for clouds and rain layers (because clouds and fog are the same stuff, so there need to be different rules) and for the skydome (because the atmosphere fogs in a different way looking straight up than looking straight down). Cheers, * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Do you mean that v1.1 as posted on the forum can't be committed as is to git ? Technically it could, but at the expense of forcing everyone to use lightfield shaders. It overwrites for instance the default terrain and model shaders. The reason why this is implemented in that way is that I have no clue how an effect file should be properly structured. I can change an existing effect file to insert new property-to-unifrom mappings, I can change the filename of the shader to be used, but my attempts to do more have so far gone terribly wrong and broken the effect. So what needs to be done for a clean commit is: * rename the special shader files where they overlap with default files * add conditionals to the effect files that if skydome scattering shader is on the lightfield files should be used, otherwise the defaults as they are (* not essential, but currently true camera altitude above MSL is obtained from Nasal and written into the tree - I'm fairly sure we have it somewhere better, I just don't know where) It's not much work, but it requires some better knowledge of how effect files work. Which is the point where I need help. I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Regards, -Fred -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Monday 05 March 2012 13:27:00 thorsten.i.r...@jyu.fi wrote: There is an important issue though, the functions appear to be different for objects and terrain. What?? Both model-default.eff and terrain-default.eff refer to terrain-haze.vert/frag as shaders - how can the fog function be different if they're using the same shader code??? I think you're mistaken here. The fog function is different for clouds and rain layers (because clouds and fog are the same stuff, so there need to be different rules) and for the skydome (because the atmosphere fogs in a different way looking straight up than looking straight down). Cheers, * Thorsten Sorry, my bad, I remembered something like that, but it was in fact me thinking that it would need a separate function for objects. Anyway, first thing i noticed while looking more carefully at the code is this (terrain-haze.vert line 126): // now the light-dimming factor earthShade = 0.9 * smoothstep(terminator_width+ terminator, - terminator_width + terminator, yprime_alt) + 0.1; which has undefined behaviour. smoothstep(a, b, x) requires specificaly that a b. Also, all light terms should have alpha 1.0 not 0.0. Will report more as i find them :) Cheers, Emilian -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sat, 2012-03-03 at 22:52 +, Stuart Buchanan wrote: On Sat, Mar 3, 2012 at 1:36 PM, Erik Hofman wrote: Personally I would think adding Project Rembrandt will call for FlightGear version 3.0. So if it is added I would create two branches, version 3.0 and version 2.7 in which the later is switched to bug fixes only. Surely a bug-fix 2.7.0 branch is simply just the 2.6.0 maintenance branch? I'm not aware of any significant development on next so far beyond RTI from Matthias and some materials work that I've been doing. That's the idea indeed. just take what is in next now and push it into bugfix only mode. If 3.0 turns out to require more time than expected (I probably know the answer to that one) then there's always a really stable version 2.8 which can be released. Sounds like a reasonably plan, but let's aim for success :) I probably should have specified that 3.0 (I realized later it is actually 2.9) will be called 'next' in git :) Erik -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. As I received no objections, I will commit my addition to simgear later in the day. You'll be warn ;-) Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier fredfgf...@free.fr wrote: As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. As I received no objections, I will commit my addition to simgear later in the day. You'll be warn ;-) Speaking not-as-a-git-guru, would it make sense to push the rembrandt changes into a separate rebrandt branch initially and keep that merged with the next branch? It would make it easier for developers to check out that branch and build it and if things look pretty reasonable we could merge things into next? Just trying to be helpful here, and not make things any more complicated. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Hi Curt, De: Curtis Olson On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier wrote: As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. As I received no objections, I will commit my addition to simgear later in the day. You'll be warn ;-) Speaking not-as-a-git-guru, would it make sense to push the rembrandt changes into a separate rebrandt branch initially and keep that merged with the next branch? It would make it easier for developers to check out that branch and build it and if things look pretty reasonable we could merge things into next? Just trying to be helpful here, and not make things any more complicated. ... and keep that merged with the next branch I don't understand what you mean. Do you want me to commit the work to a new Rembrandt branch and then merge it to the next branch ? I am only speaking of enhancement to the effect system and the new light animations that will be useless until the right code is committed in flightgear. The only noticeable thing will be the point sprite size increase for runway lighting that I find way more realistic. Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sun, Mar 4, 2012 at 9:59 AM, Frederic Bouvier wrote: ... (Curt wrote) and keep that merged with the next branch. (Fred wrote) I don't understand what you mean. Do you want me to commit the work to a new Rembrandt branch and then merge it to the next branch ? Hi Fred, As I mentioned in my past message, I'm not trying to make things more complicated. If the changes to SimGear are additive and don't break the current FlightGear, then that sounds pretty safe. In terms of merging with next ... what I meant is this (and let me answer by example.) I have a local branch I've created here for some experimentation. When ever I do a git pull from the gitorious repository, I do that in the next/master branches. Then I switch to my local branch and type git merge next (or master) to make my local branch up to date with the main development head. There may be a better way to do that, but it's what was suggested to me, and seems to work and I've stuck with it. What I meant with my original comments was to suggest thinking about doing something similar on gitorious -- create a branch for rembrandt, and then keep it synced with the main-line changes. But it sounds like we don't really need that for simgear -- but maybe for FlightGear if the changes are a bit more intrusive over there? Personally, I'd be more likely to checkout out a branch and test something there, than to run around looking for patches and patch my own tree -- the more automatic process seems like it would save some time. But as I also mentioned in my previous message, I'm not a git-guru, and I don't claim any special knowledge of git-best-practices, so there are probably more clever ways to do whatever I'm suggesting that the git-guru's here could suggest, or perhaps as you have suggested, what I'm suggesting does not need to be suggested at all. I am only speaking of enhancement to the effect system and the new light animations that will be useless until the right code is committed in flightgear. The only noticeable thing will be the point sprite size increase for runway lighting that I find way more realistic. That sounds pretty safe -- thanks! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Curtis Olson wrote: I have a local branch I've created here for some experimentation. When ever I do a git pull from the gitorious repository, I do that in the next/master branches. Then I switch to my local branch and type git merge next (or master) to make my local branch up to date with the main development head. There may be a better way to do that, but it's what was suggested to me, and seems to work and I've stuck with it. For the sake of completeness and (possibly) nicer git history in the future let me say this: There IS indeed a better way for exactly your use-case: When switching back to your local branch after git pull in next, use git rebase next (or master) on your local branch. This makes sure your changes are always on top of your local branch and prevents those Merge commit XXX messages in the git history. HTH Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sunday 04 March 2012 17:30:41 Christian Schmitt wrote: Curtis Olson wrote: I have a local branch I've created here for some experimentation. When ever I do a git pull from the gitorious repository, I do that in the next/master branches. Then I switch to my local branch and type git merge next (or master) to make my local branch up to date with the main development head. There may be a better way to do that, but it's what was suggested to me, and seems to work and I've stuck with it. For the sake of completeness and (possibly) nicer git history in the future let me say this: There IS indeed a better way for exactly your use-case: When switching back to your local branch after git pull in next, use git rebase next (or master) on your local branch. This makes sure your changes are always on top of your local branch and prevents those Merge commit XXX messages in the git history. But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your branch (which happens with a simple git pull from the main repo), his get gets confused by the changed history. Stefan -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 04.03.2012 19:00, schrieb Stefan Seifert: But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your What I always do, before pushing an update for the next branch is: git checkout next git pull git rebase origin/next (likewise works with master or other branches). This rebases my local next branch - and places all my local changes on top of the history of the remote next branch (= origin/next). Also, this cannot change any history being already part of the published remote - since anything pushed to the server is already in origin/next, which remains unaltered (it's the base). branch (which happens with a simple git pull from the main repo), his get gets confused by the changed history. If someone managed to mess up the published history, he wouldn't be able to push to our gitorious repository though. Pushing a change of history requires a forced push, which is disabled for our gitorious repos. It's not a mistrust in anyone's git skills, but just to be really safe ;-). cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your What I always do, before pushing an update for the next branch is: As stated previously, a code that is not run is unlikely to be debugged. To avoid branch glitches and given the estimated risk of these changes, I decided to commit them to next. People are requested *not* to use the features introduced until noticed because there is no Rembrandt code in the flightgear repository. Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Yes please. Or if someone could just help in creating an effect structure that one can switch these things on and off so that installing the lightfields doesn't have to overwrite everything and that it would be on GIT? Then we can worry about how to merge later? Lightfields would work optionally, there's no fundamental obstacle here. I know there's the idea to get everything perfectly merged in an elegant way by factoring out light and haze functions, but I'd be happy with a simple optional structure now and the rest later. It's getting somewhat frustrating... Not so much for myself, but for others who want to try it, and it's starting to look silly when I have to tell everyone who is interested 'Sorry, it's ready since a month ago, but we haven't been able to put it on GIT yet, so you still need to go through a tricky manual installation process'. Cheers, * Thorsten -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
De: Torsten Dreyer Am 02.03.2012 19:03, schrieb Frederic Bouvier: Now that release 2.6 is out, perhaps it is time to discuss further developments concerning project Rembrandt. Although it may already produce pretty images when used by a talented designer (see for example the P92), it is however, not usable by most people. The Wiki page summarizes the list of things to do. For wider use, we must first convert the shaders to 'Rembrandt' rules. It also seems there are problems with shadows in multi-threaded modes. Finally, the multi screen should be reviewed (I'll leave spherical projection and stereo for another time). The other points are are less important and can be treated in the next branch. Remains the problem of conversion of aircraft models. One of the constraints of Rembrandt is that each model should be modified, or at least reviewed: * Remove the fake shadow * Remove ambient occlusion from textures * Register all transparent surfaces * Review the use of emissive colors Maybe we need to create a label Works with Rembrandt and report models that do not comply. thoughts ? The best time for adding such a huge change is at the beginning of a release cycle - which is now. Adding a tag marking the initial commit might be a good idea, though. If Rembrandt breaks nearly all aircraft, maybe we should also split off aircraft from FGDATA before/not later than the start of Rembrandt? The aircraft rating system can hold a Rembrandt-ready label. Is there any chance to make Rembrandt switchable (on/off) at startup? That should be doable, but not done for the moment. Changes are located in CameraGroup.[ch]xx and Renderer.cxx for the flightgear side, in sgmaterial.lib for the simgear side and in Effects/ and Shaders/ for the data side, not speaking of any model converted or enhanced with lights. The main problem to solve would be the duplication of resources. How a plane or another model would be compatible to both renderer ? But just curious : how many of you reviewed the current code ? Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Stuart Buchanan wrote: Given that we have 400+ aircraft that need to be updated, I think we also need clear documentation (on the wiki?) describing the steps you outline above, and in particular how to register the transparent surfaces. That probably needs to be in place before the code goes into next. Yes, then we can make aircraft after aircraft Rembrandt ready so that we have a nice pool of planes for the next release. IMO we should bite the bullet and get it into next this week if possible. There's obviously some risk to our 6 month release schedules that we'll just have to accept. I agree here. Let's merge the Rembrandt work into next so that every git user has to work with it, can find glitches and adapt shaders. There are people holding back their shader improvements in anticipation of Rembrandt. We have to merge it anyway sooner or later. Now, the likeliness of conflicts is lower and the speed of development will be faster. Cheers Chris -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Is there any chance to make Rembrandt switchable (on/off) at startup? That should be doable, but not done for the moment. Changes are located in CameraGroup.[ch]xx and Renderer.cxx for the flightgear side, in sgmaterial.lib for the simgear side and in Effects/ and Shaders/ for the data side, not speaking of any model converted or enhanced with lights. The main problem to solve would be the duplication of resources. How a plane or another model would be compatible to both renderer ? Sorry for being unclear, my idea was to have the renderer switchable at startup. Selecting the aircraft with/without Rembrand-feature does not make sense. That way one could use the old renderer for old aircraft and the new renderer with Remprand-Ready aircraft. But just curious : how many of you reviewed the current code ? I had a look at the code but never compiled, let alone ran it locally due to lack of time. Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Hi Fred, On Friday, March 02, 2012 19:03:13 Frederic Bouvier wrote: thoughts ? Since we are now at the beginning of a release cycle, I would think now is the right time. For the question to preserve both renderers, compatibility of models I think that we need to preserve both if we cannot guarantee that your new approach runs on a wide varity of drivers. Given the complexity of this kid of change I doubt that we can iterate this out completely within this current release cycle. Also I believe you told that you are using float textures. And again this is the other patent problem lingering in OpenGL. This extension will not be supported for a long time. But again I think that any rescaled fixed point representation that works based on an integer datatype should do its job as well. The changes to make this work should be limited. And no, I have not really reviewed the changes. Any yes this is the problem, there is a lot of work left to do to integrate this kind of change, but I think too little people will try if we do not push this into mainline. Consequently not iterating out anything. The only other option could be doing something incremental. May be like this? 1. Move the renderer into a pre render camera using the current shaders. 2. Set up the depth texture and normals and make them available for a composition step. 3. Remove fog from the models, do this in the composition step. 4. Build up the shadow and light map texture. 5. Incorporate this into the composition step Or may be with modifications - just scratching in my head how I could imagine tackling this with smaller steps. Really just thinking about an idea that might not be a good one. But tell me if you think this is reasonable??? Greetings Mathias -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sat, 2012-03-03 at 07:25 -0600, Curtis Olson wrote: I agree that we should merge the project rembrandt work sooner rather than later. However, we should also take some time and effort to make sure Thorsten's sky/haze/horizon effects are accounted for as well. I don't know what issues we will find when trying to merge these two efforts, but they both need to be considered together. Personally I would think adding Project Rembrandt will call for FlightGear version 3.0. So if it is added I would create two branches, version 3.0 and version 2.7 in which the later is switched to bug fixes only. If 3.0 turns out to require more time than expected (I probably know the answer to that one) then there's always a really stable version 2.8 which can be released. Erik -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
-Original Message- From: Erik Hofman Sent: Saturday, March 03, 2012 1:36 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Project Rembrandt - next steps Personally I would think adding Project Rembrandt will call for FlightGear version 3.0. So if it is added I would create two branches, version 3.0 and version 2.7 in which the later is switched to bug fixes only. If 3.0 turns out to require more time than expected (I probably know the answer to that one) then there's always a really stable version 2.8 which can be released. Erik I think that you have hit the nail on the head there. Alan -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 03.03.2012 12:43, schrieb Christian Schmitt: Stuart Buchanan wrote: IMO we should bite the bullet and get it into next this week if possible. There's obviously some risk to our 6 month release schedules that we'll just have to accept. I agree here. Let's merge the Rembrandt work into next so that every git user has to work with it, can find glitches and adapt shaders. There are people holding back their shader improvements in anticipation of Rembrandt. We have to merge it anyway sooner or later. Now, the likeliness of conflicts is lower and the speed of development will be faster. Just be sure the new concept will work for everyone, even for the majority not owning the latest high-end GPU, e.g there is an option to disable, reduce load/quality etc. Also, the project is quite good in finding issues, once new stuff is in git. But, generally we are not so good in fixing problems then. Notoriously, everyone has just too little spare time ;-), so a lot of issues just starve in the tracker. And with hard-core OSG stuff, there's even fewer people than usual who could help anyway. So, make an honest estimate of how much work is really left, including fixing reported issues, and whether you have the time to complete this in the next months. Or whether you maybe need to bail out in a few weeks for personal reasons, and we might be getting stuck (your wife/girlfriend isn't pregnant or something? :-D ). If we are certain that everything will be well and stable within reasonable amount of time, then it should go into next. Otherwise, we should think about maintaining separate branches (one of the main advantages of git anyway). Indeed, the latter would probably mean it would not be part of the August release. The key question is: would it be ready? cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
-Original Message- From: Frederic Bouvier Sent: Saturday, March 03, 2012 11:33 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Project Rembrandt - next steps De: Torsten Dreyer I don´t know if that already been covered, but is it possible to make a model that is compatible with both current and Rembrandt systems? Alan -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Fri, 2 Mar 2012 20:51:59 + Stuart Buchanan stuar...@gmail.com wrote: Given that we have 400+ aircraft that need to be updated, Looks like an aircraft needs some maintenance over time. This somehow bothers the question whether it is wise to collect 300+ rudimentary aircraft with no further use, in the hope they might become finished in the year 2018... -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 03.03.2012 12:33, schrieb Frederic Bouvier: But just curious : how many of you reviewed the current code ? n+1 Just checked out your project/rembrandt branches. Code compiles fine on 64bit openSUSE 12.1 with OSG from trunk. Running fgfs spits out many messages, most prominent are: can't find Effects/ssao.eff can't find Effects/blur.eff can't find Effects/blur.eff can't find Effects/sunlight.eff can't find Effects/blur.eff can't find Effects/blur.eff and dozens of no image file, maybe the reader did not set the filename attribute, using white for type '2d' on '', in /technique[11]/pass[0]/texture-unit[0] The screen stays white with three black corners (top right, bottom right and bottom left). No splash screen. I can exit after some time with (Esc)-(Enter). GPU is GeForce Go 7400 with latest driver. Anything I can do to help debugging? Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
- Mail original - De: Torsten Dreyer tors...@t3r.de Am 03.03.2012 12:33, schrieb Frederic Bouvier: But just curious : how many of you reviewed the current code ? n+1 Just checked out your project/rembrandt branches. Code compiles fine on 64bit openSUSE 12.1 with OSG from trunk. Running fgfs spits out many messages, most prominent are: can't find Effects/ssao.eff can't find Effects/blur.eff can't find Effects/blur.eff can't find Effects/sunlight.eff can't find Effects/blur.eff can't find Effects/blur.eff and dozens of no image file, maybe the reader did not set the filename attribute, using white for type '2d' on '', in /technique[11]/pass[0]/texture-unit[0] The screen stays white with three black corners (top right, bottom right and bottom left). No splash screen. I can exit after some time with (Esc)-(Enter). GPU is GeForce Go 7400 with latest driver. Anything I can do to help debugging? Nothing wrong with all of that (or at least it is expected). Did I mentionned I wrecked the splashscreen that doesn't appear in windowed mode and badly flash in fullscreen. Otherwise, the messages are expected for the moment. Ensure you checked out project/rembrandt in simgear, flightgear and fgdata, and be patient until the scene appears. It doesn't support multi-threading mode (in preferences.xml) but that don't prevent to have an image Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
De: ThorstenB Also, the project is quite good in finding issues, once new stuff is in git. But, generally we are not so good in fixing problems then. Notoriously, everyone has just too little spare time ;-), so a lot of issues just starve in the tracker. And with hard-core OSG stuff, there's even fewer people than usual who could help anyway. So, make an honest estimate of how much work is really left, including fixing reported issues, and whether you have the time to complete this in the next months. Or whether you maybe need to bail out in a few weeks for personal reasons, and we might be getting stuck (your wife/girlfriend isn't pregnant or something? :-D ). If we are certain that everything will be well and stable within reasonable amount of time, then it should go into next. Otherwise, we should think about maintaining separate branches (one of the main advantages of git anyway). Indeed, the latter would probably mean it would not be part of the August release. The key question is: would it be ready? As I said in my first post, I don't consider the code as fully ready for prime time. I made shortcuts to demonstrate the feasibility of the renderer and many things no longer works or at least should be reviewed again. I can't promise I won't be hit by the proverbial bus, but as long as the project is endorsed by the community, there is no reason I bail out in the next months. As a migration path, I verified that my changes to simgear are compatible with the current next branch. If there is no objection, I will commit these changes to gitorious and begin to prepare the flightgear code in a way that would allow to keep the current renderer. That may take time though. Enough time to split the aircraft repository ;-) Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Sat, Mar 3, 2012 at 1:36 PM, Erik Hofman wrote: Personally I would think adding Project Rembrandt will call for FlightGear version 3.0. So if it is added I would create two branches, version 3.0 and version 2.7 in which the later is switched to bug fixes only. Surely a bug-fix 2.7.0 branch is simply just the 2.6.0 maintenance branch? I'm not aware of any significant development on next so far beyond RTI from Matthias and some materials work that I've been doing. If 3.0 turns out to require more time than expected (I probably know the answer to that one) then there's always a really stable version 2.8 which can be released. Sounds like a reasonably plan, but let's aim for success :) On the subject or Rembrandt Ready aircraft, I'd prefer not adding this explicitly to the aircraft status. If Rembrandt is the rendering technology for FG 2.8.0 (or 3.0.0), then aircraft maintainers are responsible for ensuring their aircraft work with the release, as they would be for any other change to FDM format etc. Instead, I'd prefer the approach we'd take with any other change that requires work by aircraft maintainers. I thought I saw a wiki article explaining how this was managed, but I can't find it at present other than this: http://wiki.flightgear.org/Aircraft_maintenance IIRC maintainers are given a reasonable time to make changes themselves, after which FG core devs go in with a pick-axe and make the changes themselves. Or am I making that up? I'm sure with enough volunteers we can split up the 400 aircraft and churn through them one at a time given a well-defined process from Fred. I'd guesstimate 1hr per aircraft. -Stuart -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Fri, 2 Mar 2012, Frederic Bouvier wrote: * Register all transparent surfaces Just a quick question: Doesn't OSG already detect translucent meshes and treat them differently from the rest during rendering? Hence, couldn't this classification be done more or less automatically and only require manual intervention in special cases? (Maybe I misunderstood what you meant above but to me it does seem like you are suggesting that all all such objects should be enumerated in the model XML file - something that IMO seems both error-prone and inconvenient. There must be a better way.) Do I look forward to implement cockpit lighting with real lights. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Fri, Mar 2, 2012 at 6:24 PM, Anders Gidenstam wrote: On Fri, 2 Mar 2012, Frederic Bouvier wrote: * Register all transparent surfaces Just a quick question: Doesn't OSG already detect translucent meshes and treat them differently from the rest during rendering? Hence, couldn't this classification be done more or less automatically and only require manual intervention in special cases? I think you may be thinking of the code we have to put objects that use an RGBA texture into a separate rendering bin. Unfortunately because most aircraft use a single texture for both opaque and translucent objects, I don't think that heuristic will work. -Stuart -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
On Fri, Mar 2, 2012 at 6:03 PM, Frederic Bouvier wrote: Now that release 2.6 is out, perhaps it is time to discuss further developments concerning project Rembrandt. Although it may already produce pretty images when used by a talented designer (see for example the P92), it is however, not usable by most people. The Wiki page summarizes the list of things to do. For wider use, we must first convert the shaders to 'Rembrandt' rules. It also seems there are problems with shadows in multi-threaded modes. Finally, the multi screen should be reviewed (I'll leave spherical projection and stereo for another time). The other points are are less important and can be treated in the next branch. Remains the problem of conversion of aircraft models. One of the constraints of Rembrandt is that each model should be modified, or at least reviewed: * Remove the fake shadow * Remove ambient occlusion from textures * Register all transparent surfaces * Review the use of emissive colors Maybe we need to create a label Works with Rembrandt and report models that do not comply. thoughts ? The first question is whether this is something that we want in the 2.8.0 release. We have just over 130 days until the next code freeze, which isn't a huge amount of time. OTOH, that's as much time as we're ever going to have between releases :) So, the question becomes where it can be release-ready in 130 days, or it needs to wait until the following release. If we want it in 2.8.0, then it needs to be in the next branch ASAP. That's the only way to ensure that every developer is working with it. The danger of leaving it in a separate branch is that developers can just ignore it. My recollection of the OSG work was that it was only when it became part of the main cvs code that people really started filling in the feature gaps compared with plib. Given that we have 400+ aircraft that need to be updated, I think we also need clear documentation (on the wiki?) describing the steps you outline above, and in particular how to register the transparent surfaces. That probably needs to be in place before the code goes into next. IMO we should bite the bullet and get it into next this week if possible. There's obviously some risk to our 6 month release schedules that we'll just have to accept. -Stuart -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
De: Anders Gidenstam On Fri, 2 Mar 2012, Frederic Bouvier wrote: * Register all transparent surfaces Just a quick question: Doesn't OSG already detect translucent meshes and treat them differently from the rest during rendering? Hence, couldn't this classification be done more or less automatically and only require manual intervention in special cases? (Maybe I misunderstood what you meant above but to me it does seem like you are suggesting that all all such objects should be enumerated in the model XML file - something that IMO seems both error-prone and inconvenient. There must be a better way.) Do I look forward to implement cockpit lighting with real lights. OSG doesn't detect transparent surfaces. It offers Render Bins that allow to control rendering order. Primitives put in RenderBin are sorted by their OpenGL state only and are for opaque objects. Primitives put in DepthSortedBin are sorted back to front and are used for transparent objects. If you put opaque objects in a transparent bin, it has only a performance impact, but has no effect on the rendered scene. The inverse is not true. Now something has to put primitives in the right bins. This is done by the loader. It use material color and texture to do that : if an alpha channel is found and has values less than 1.0, the object goes to the transparent bin. But usually you use few texture images to map the entire model. You can have the windshield in the same texture than the wings. With the loader strategy, the windshield is put in the transparent bin, which is good, and also the wings, which is not so good in the context of Rembrandt. Rembrandt use deferred rendering and the technique only apply to opaque surfaces. For transparent objects, it fallbacks to traditional rendering. If all objects are flagged as transparent, it defeats the purpose of Rembrandt. Transparent objects are detected by their membership to the transparent bins, so it is important to have the right classification. To override the selection made by the loader, Rembrandt use effect declaration to set the bin. Effects for opaque objects use alpha testing, and effects for transparent objects will use alpha blending after all lights are rendered. Transparent objects don't cast shadows and are not lit by additional lights. So registering all transparent surfaces means setting a effect for transparency to those surfaces, regardless of the presence of an alpha channel in the texture of the object. Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 02.03.2012 19:03, schrieb Frederic Bouvier: Now that release 2.6 is out, perhaps it is time to discuss further developments concerning project Rembrandt. Although it may already produce pretty images when used by a talented designer (see for example the P92), it is however, not usable by most people. The Wiki page summarizes the list of things to do. For wider use, we must first convert the shaders to 'Rembrandt' rules. It also seems there are problems with shadows in multi-threaded modes. Finally, the multi screen should be reviewed (I'll leave spherical projection and stereo for another time). The other points are are less important and can be treated in the next branch. Remains the problem of conversion of aircraft models. One of the constraints of Rembrandt is that each model should be modified, or at least reviewed: * Remove the fake shadow * Remove ambient occlusion from textures * Register all transparent surfaces * Review the use of emissive colors Maybe we need to create a label Works with Rembrandt and report models that do not comply. thoughts ? The best time for adding such a huge change is at the beginning of a release cycle - which is now. Adding a tag marking the initial commit might be a good idea, though. If Rembrandt breaks nearly all aircraft, maybe we should also split off aircraft from FGDATA before/not later than the start of Rembrandt? The aircraft rating system can hold a Rembrandt-ready label. Is there any chance to make Rembrandt switchable (on/off) at startup? Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
