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] About the bug 385
Am 04.03.2012 00:09, schrieb jean pellotier: BTW, whitch OSG version do i have to use? last devel version is ok? Any version that reproduces the issue for you. If it still occurs with OSG trunk, then that's also interesting. If it wasn't, well, then you have a solution ;-). But I already have a suspicion on a timing/sequence issue inside FG itself, so OSG probably won't matter. 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] Adding an R/C pilot view
On Saturday 03 March 2012 21:14:45 Ian Dall wrote: On Fri, 2012-03-02 at 12:39 -0600, Curtis Olson wrote: Hi Ian, If you wish to set your own tower position, it's pretty straight forward and can be done manually or via nasal or probably a few other mechanisms. By default flightgear will set the tower position to the nearest airfield, so to disable that, set: /sim/tower/auto-position = 0 Then you can set /sim/tower/longitude-deg, /sim/tower/latitude-deg, and /sim/tower/altitude-ft Ah, my significant effort comment was more to do with making an R/C Flying Field as an airport than with tweaking the tower position. Also people might not want the list of recognised airports cluttered up with fake airports. What I am trying to a achieve is an interface a kid can operate with no more difficulty than selecting a view (and preferably automatic). Manually figuring out what latitude and longitude will give an offset of a few meters in the right direction is definitely in the too hard basket. I think Curt was trying to point out a way you could make something work from nasal without getting into core code. The locate tower with a mouse click suggested by Gijs is closer to the mark (though the link to the script doesn't work for me). Anyway, the point is not so much how to implement the right view, as how the user should invoke it. A view with the right characteristics seems to be the best solution. An alternative, which you seem to suggest, would be to customise the existing Tower View. ... For RC views, you may also wish to play around with auto-zooming -- either to help keep the aircraft large enough to see, or help keep the horizon in view -- either can be useful at times with RC flying. Good point. I had though of (but not implemented) the keep the aircraft large enough aspect but not the keep horizon in view one. Actually I have just found your forum comment on this exact issue: http://www.flightgear.org/forums/viewtopic.php?f=49p=151251 I assume one would implement auto-zooming by adding nasal update methods in view.nas. There is no existing support? Have you looked at the Fly-by view? It pans, rotates and moves itself to follow the aircraft already. It might be exactly what you're looking for if you were to adjust it so the moves weren't so random, its a bit disorienting when it jumps from side to side and above and below the model. If it always stayed at ground level and to the same side of the aircraft when moving it might make a nice automatic R/C view. Ron -- 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
[Flightgear-devel] Rembrandt feedback (was: Project Rembrandt - next steps)
Hi Fred, today, I tried Rembrandt on two Linux machines, both running 64bit openSUSE 12.1 (this is Linux) with nvidia'd driver 295.20. FlightGear ist started in windows mode. 1.) My Notebook having a Intel dual core@1.6GHz, 4GB RAM and a GeForce Go 7400 with 256MB RAM. FlightGear starts, after some time, I see the four corners rendering the stages and the main scene but with strange colors. After just a few seconds seconds, my kernel panics and I have to reboot. 2.) Our big, fat presentation machine with 2 CPU, 24 cores, 8GB RAM, currently one nvidia GTX460 with 1GB RAM. FlightGear starts without an issue and without any noticable frame rate impact (limited to 60fps due to sync-to-vblank). I can see the aircraft shadow and the shadow of some scenery objects (not all, though). The aircraft shadow seems to be disapearing depending on the view angle. 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
[Flightgear-devel] [Rembrandt] Help request
Hi, in preparation to the introduction of Rembrandt in the main branch, we should ensure that effect will be compatible with the current renderer. For that, I added a new property to preferences.xml and modified Effects/model-default.eff to test this new property. It will be also available to animations to, for example, conditionally select the fake shadow when the current renderer is in action. So may I ask a kind soul with write access to the data repository, or capable of submitting a merge request, to review all effect files and add the test of the new property to every technique of every effect, and add a new predicate to technique not having one for the moment. The code snippet to add to an existing predicate is : predicate and +not + property/sim/rendering/rembrandt/property +/not property/sim/rendering/shaders/generic/property or The code snippet to add a new predicate is : /technique technique n=11 + predicate + not + property/sim/rendering/rembrandt/property + /not + /predicate pass lightingtrue/lighting As an example, I modified Effects/model-default.eff : https://gitorious.org/fg/fgdata/commit/e9fbd620bb71e94d6589a15be1448511f21bacb6 Thank you -Fred http://wiki.flightgear.org/Project_Rembrandt -- 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] Rembrandt feedback (was: Project Rembrandt - next steps)
De: Torsten Dreyer Hi Fred, today, I tried Rembrandt on two Linux machines, both running 64bit openSUSE 12.1 (this is Linux) with nvidia'd driver 295.20. FlightGear ist started in windows mode. 1.) My Notebook having a Intel dual core@1.6GHz, 4GB RAM and a GeForce Go 7400 with 256MB RAM. FlightGear starts, after some time, I see the four corners rendering the stages and the main scene but with strange colors. After just a few seconds seconds, my kernel panics and I have to reboot. 2.) Our big, fat presentation machine with 2 CPU, 24 cores, 8GB RAM, currently one nvidia GTX460 with 1GB RAM. FlightGear starts without an issue and without any noticable frame rate impact (limited to 60fps due to sync-to-vblank). I can see the aircraft shadow and the shadow of some scenery objects (not all, though). The aircraft shadow seems to be disapearing depending on the view angle. The rendering stages can be hidden with the new item in the debug menu. Can you produce screenshots that exhibit the glitches you see on your second machine ? For your 1st machine, you can try to lower the value of /sim/rendering/shadows/map-size in preferences.xml *before* you start fgfs (changing in the property browser has no effect) 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] Adding an R/C pilot view
I am not sure I understand what you are trying - but: -we use something like that in ATCing -- keeping Target in view -- zooming -- relocating tower etc. -- saving and retrieving settings You may try my test ATC-ML model. Download from http://emmerich-j.de/FGFS/ATC-ML.zip see inside the description README.pdf and the model-nasal. joe On Sun, 2012-03-04 at 14:44 +1030, Ian Dall wrote: On Fri, 2012-03-02 at 12:39 -0600, Curtis Olson wrote: Hi Ian, If you wish to set your own tower position, it's pretty straight forward and can be done manually or via nasal or probably a few other mechanisms. By default flightgear will set the tower position to the nearest airfield, so to disable that, set: /sim/tower/auto-position = 0 Then you can set /sim/tower/longitude-deg, /sim/tower/latitude-deg, and /sim/tower/altitude-ft Ah, my significant effort comment was more to do with making an R/C Flying Field as an airport than with tweaking the tower position. Also people might not want the list of recognised airports cluttered up with fake airports. What I am trying to a achieve is an interface a kid can operate with no more difficulty than selecting a view (and preferably automatic). Manually figuring out what latitude and longitude will give an offset of a few meters in the right direction is definitely in the too hard basket. The locate tower with a mouse click suggested by Gijs is closer to the mark (though the link to the script doesn't work for me). Anyway, the point is not so much how to implement the right view, as how the user should invoke it. A view with the right characteristics seems to be the best solution. An alternative, which you seem to suggest, would be to customise the existing Tower View. But to achieve the ease of use I was looking for would need some additional menu, available when in Tower View, which would allow it to be customised and for those customisations to be saved. For RC views, you may also wish to play around with auto-zooming -- either to help keep the aircraft large enough to see, or help keep the horizon in view -- either can be useful at times with RC flying. Good point. I had though of (but not implemented) the keep the aircraft large enough aspect but not the keep horizon in view one. Actually I have just found your forum comment on this exact issue: http://www.flightgear.org/forums/viewtopic.php?f=49p=151251 I assume one would implement auto-zooming by adding nasal update methods in view.nas. There is no existing support? As I said, I have an initial implementation and I am happy to do some more work, perhaps adding an auto-zoom function. What I would like to know is whether this is likely to be adopted. If there is a feeling that we have enough views, or that R/C is out of scope for FlightGear then I'll probably just keep it as a local hack. Regards, Ian -- 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] Adding an R/C pilot view
On Sun, 2012-03-04 at 07:13 -0700, Ron Jensen wrote: I think Curt was trying to point out a way you could make something work from nasal without getting into core code. I see I may have misled by mentioning a core view. This might have been taken to mean changing the C++ core although I tried to be clear that the implementation was by changes to $FG_ROOT/preferences.xml and $FG_ROOT/Nasal/view.nas. So what is the term for the XML and Nasal stuff which is in in $FG_ROOT but NOT $FG_ROOT/Aircraft? Clearly this is easier to change than the C++ code, but equally, it is still core in the sense that changes would have a pervasive effect unlike changes to individual aircraft. Regards, Ian -- Ian Dall i...@beware.dropbear.id.au -- 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
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
