Re: [Flightgear-devel] Depth buffers, render bins and passes
On Thursday, October 04, 2012 06:42:30 Renk Thorsten wrote: > > You know that rendering a transparent object twice alter its > > transparency. > > Of course, you can avoid to render it in the color buffer using write > > mask in one pass. > > What I do with the trees is render just the opaque bits early on as white > with essentially no light and fog computations to set the z-buffer and > discard all transparent pixels in the first pass, then render the rest in > detail with lequal comparison later. > > The first pass has just one texture lookup in the fragment shader, but what > this saves is rendering the terrain pixels (and other trees) covered by the > tree, and the terrain has a lot of complicated light and fog equations to > solve, as well as up to four texture lookups and lots of noise generation. > To trade that against an additional pass for trees which is essentially > trivial turns out to be a really good deal. > > Of course, here's the part I don't know: All this makes perfect sense as > long as the fragment shader is the bottleneck. But the first tree pass also > needs the geometry computations in the vertex shader, and in an environment > where the vertex shader is the bottleneck, it would make matters actually > worse. > > So, the framerate gain for me personally left aside - what should I do with > such things? Commit them and hope a majority will benefit? Not commit them? > Make them optional and create a complicated rendering dialog? Test them and > gather feedback? > > The idea with clouds is still to slip rectangles in which cover most of the > opaque core of a cloud, render them into the z-buffer early on while > passing through the normal clouds through vertex shading and discarding > them in the fragment shader, and then render the rest of the clouds and the > terrain with lequal comparison onto that depth buffer. > > I don't know if it actually works, but at least I'm pretty sure I understand > now what is expensive about cloud rendering - funnily enough, it's fogging > them. In a layer looking forward, we can have hundreds of cloud sheets > overlapping all drawn from outside in, and so the fogging means we compute > hundreds of exponential functions for every pixel... Depth buffering should > definitely help here. > > * Thorsten Hi, Take a look here http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide_G80.pdf pages 43, 44. They deal with cases where the culling optimizations might be disabled/underperforming. Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
> You know that rendering a transparent object twice alter its > transparency. > Of course, you can avoid to render it in the color buffer using write > mask in one pass. What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to set the z-buffer and discard all transparent pixels in the first pass, then render the rest in detail with lequal comparison later. The first pass has just one texture lookup in the fragment shader, but what this saves is rendering the terrain pixels (and other trees) covered by the tree, and the terrain has a lot of complicated light and fog equations to solve, as well as up to four texture lookups and lots of noise generation. To trade that against an additional pass for trees which is essentially trivial turns out to be a really good deal. Of course, here's the part I don't know: All this makes perfect sense as long as the fragment shader is the bottleneck. But the first tree pass also needs the geometry computations in the vertex shader, and in an environment where the vertex shader is the bottleneck, it would make matters actually worse. So, the framerate gain for me personally left aside - what should I do with such things? Commit them and hope a majority will benefit? Not commit them? Make them optional and create a complicated rendering dialog? Test them and gather feedback? The idea with clouds is still to slip rectangles in which cover most of the opaque core of a cloud, render them into the z-buffer early on while passing through the normal clouds through vertex shading and discarding them in the fragment shader, and then render the rest of the clouds and the terrain with lequal comparison onto that depth buffer. I don't know if it actually works, but at least I'm pretty sure I understand now what is expensive about cloud rendering - funnily enough, it's fogging them. In a layer looking forward, we can have hundreds of cloud sheets overlapping all drawn from outside in, and so the fogging means we compute hundreds of exponential functions for every pixel... Depth buffering should definitely help here. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
> I wonder how we deal with this with the next release- I'm sure a whole > lot more users will complain about the "stuck" while launching FGFS. By printing a message like 'Building database during first startup' on the screen? By including the binary nav data with the release? Doesn't look like a show-stopper to me... Let me just say that I'm _extremely_ grateful for this feature - I so frequently just start Flightgear, have a look how a parameter change looks in practice and end it again, and reducing the startup time by half makes a lot of difference. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound problems with Lightning
On Mon, 01 Oct 2012 17:47:54 +0100 James Turner wrote: > The correct solution is to have multiple mono sources (which all sound are, > in reality) and appropriate source locations. That will accurately give the > positional cues, wherever the listener is located - inside or out, looking at > the acft from behind or the front. I'm not sure which sounds you are > referring to specifically, but assuming they relate to engine startup, then > one would expect each engine to be a separate positioned source, and generate > its own version of the start-up sounds. > This is exactly what OpenAL and the sound-manager are designed to accurately > model, btw. Yeah, I know the theory... but in practice, for this kind of all-enveloping sound even a semi-reasonable stereo recording (which, admittedly, none of the current Lightning recordings are) is far more convincing/realistic than trying to model the exact positioning of the sound of each engine and its path to each of our ears. In reality, sound doesn't come straight from the source to our ears, it's reflected and re-reflected and absorbed by all sorts of surfaces round about us. The place I miss stereo sounds most is in glider cockpits - where are you going to position the sound of the wind rushing past the canopy, fuselage etc? It's bound to just sound mono and dead (I'd be happy to be proved wrong of course!) Yet a stereo sound clip "feels" right, automatically (better still if L/R channel volumes can be adjusted individually). Anyway, by the looks of it we can't have that for the reasons Erik mentioned so I'll just have to forget about it. Having tried the Lightning though, I also hear what Alan reports and it's not what I had thought - the looped engine sound is indeed quite frequently broken up or interrupted and I have no idea why. It's not a problem with the sound clip, and even within FG it used to work perfectly - something has changed. Does anyone else hear that, in the Lightning or in any other model? AJ -- -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Hi Fred, > I know some people erase the content of the folder having autosave.xml. > This folder is now used to host a navigation data cache. The first time, > a SQL database is built to speedup future start. If this cache is erased > every time, it defeats the purpose of the cache and make the start > much longer every time. > Just guessing... > Regards, >-Fred Yes, that might be the case. In the meanwhile I found out myself that it hosts the navigation cache in the autosave-folder. The reason why it had to built it up again was simply, that I didn't quit FGFS on the usual normal way but just hitting the Close-button of the FGFS-window. I wonder how we deal with this with the next release- I'm sure a whole lot more users will complain about the "stuck" while launching FGFS. Regards Heiko -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Better Patch: FOV automatic compensation for wider screens
Le 03/10/2012 22:05, Alexis Bory a écrit :
>
> Patch attached, Tests and comments welcome.
Self comment: this patch includes a change to the Hawkeye, grrr
use this one attached instead
Sorry for that
diff --git a/Nasal/view.nas b/Nasal/view.nas
index 6af58fa..09244dd 100644
--- a/Nasal/view.nas
+++ b/Nasal/view.nas
@@ -6,7 +6,7 @@
var index = nil;# current view index
var views = nil;# list of all view branches (/sim/view[n]) as props.Node
var current = nil; # current view branch (e.g. /sim/view[1]) as props.Node
-
+var fovProp = nil;
var hasmember = func(class, member) {
if (contains(class, member))
@@ -235,6 +235,7 @@ var manager = {
me.current.handler.start();
if (hasmember(me.current.handler, "update"))
me._loop_(me.loopid += 1);
+ resetFOV();
},
reset : func {
if (hasmember(me.current.handler, "reset"))
@@ -638,7 +639,61 @@ var point = {
-var fovProp = nil;
+##
+# view.ScreenWidthCompens: optional FOV compensation for wider screens.
+# It keeps an equivalent of 55° FOV on a 4:3 zone centered on the screen
+# whichever is the screen width/height ratio. Works only if width >= height.
+#
+# status: 0=Init, 1=toggle option, 2=waiting for the window size to change.
+
+var defaultFov = nil;
+var oldW = 0;
+var oldH = 0;
+var fovStore = {};
+
+var screenWidthCompens = func(status) {
+ var opt = getprop("/sim/current-view/field-of-view-compensation");
+ if (status == 0) {
+ defaultFov = getprop("/sim/current-view/config/default-field-of-view-deg");
+ forindex (var i; views) {
+ var defaultFovNode = views[i].getNode("config/default-field-of-view-deg", 1);
+ fovStore[i] = defaultFovNode.getValue();
+ }
+ } elsif (status == 1) {
+ opt = ! opt;
+ setprop("/sim/current-view/field-of-view-compensation", opt);
+ if (! opt) {
+ forindex (var i; views) {
+var defaultFovNode = views[i].getNode("config/default-field-of-view-deg", 1);
+defaultFovNode.setValue(fovStore[i]);
+ }
+ var vn = getprop("/sim/current-view/view-number");
+ setprop("/sim/current-view/field-of-view", fovStore[vn]);
+ }
+ } elsif (status == 2 and ! opt) {
+ return;
+ }
+ var w = getprop("/sim/rendering/camera-group/camera/viewport/width");
+ var h = getprop("/sim/rendering/camera-group/camera/viewport/height");
+ if (! opt) {
+ setprop("/sim/current-view/config/default-field-of-view-deg", defaultFov);
+ return;
+ }
+ if ( w != oldW or h != oldH or status == 1) {
+ oldW = w;
+ oldH = h;
+ d = 1.28066 * h; # 1.28066 = 4/3 (width/height ratio) / 2 / tan(55°)
+ newFov = 2 * math.atan2( w / h * h / 2, d) * R2D;
+ setprop("/sim/current-view/config/default-field-of-view-deg", newFov);
+ forindex (var i; views) {
+ var defaultFovNode = views[i].getNode("config/default-field-of-view-deg", 1);
+ defaultFovNode.setValue(newFov);
+ }
+ fovProp.setValue(newFov);
+ }
+ settimer(func { screenWidthCompens(2); }, 1);
+}
+
_setlistener("/sim/signals/nasal-dir-initialized", func {
@@ -654,6 +709,7 @@ _setlistener("/sim/signals/nasal-dir-initialized", func {
manager.init();
manager.register("Fly-By View", fly_by_view_handler);
manager.register("Model View", model_view_handler);
+ screenWidthCompens(0);
});
diff --git a/gui/dialogs/view.xml b/gui/dialogs/view.xml
index 1bd235b..7ef301c 100644
--- a/gui/dialogs/view.xml
+++ b/gui/dialogs/view.xml
@@ -88,6 +88,25 @@
+
+ hbox
+
+ sim/current-view/field-of-view-compensation
+ false
+
+ nasal
+ view.screenWidthCompens(1)
+
+
+
+ Compensate Field of View for wider screens
+
+
+
+
+
+
+
Close
diff --git a/preferences.xml b/preferences.xml
index 80b324d..ef7d593 100644
--- a/preferences.xml
+++ b/preferences.xml
@@ -346,6 +346,7 @@ Started September 2000 by David Megginson, da...@megginson.com
1.0
55.0
+ false
1.0
false
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch: FOV automatic compensation for wider screens
Hi all The default Field of View has been choosen a long time ago and discussed several times on the devel list. AFAIK this 55 deg FOV had been settled for two main reasons: 1) There is a need to have a standard FOV across different aircrafts so the user keeps its space and distance perception when being in different aircrafts cockpits. 2) We "determined [55 degree] as an acceptable compromise between seeing enough of the instrument panel and the outside world" quoting Curt's email in september 2008. Today we all are throwing our old 4:3 CRTs through the windows and most of us already enjoy the 16:9 or 16:10 ratio. This changes the rules. The idea is NOT to change anything to this standard. Instead, I've just added a tiny option in the Display Options dialog: [ ] Compensate Field of View for wider screens (Disabled by default) When you check this option, a new function in /Nasal/view.nas checks FG window size and changes the default FOV for each view so the vertical FOV keeps in line with what ought to be a 55 deg on a 4:3 screen. Actually it computes a 4:3 central part of the screen and change the overall FOV so the FOV on this central part keeps being 55 deg. The result is that when you resize and change the height/width of your window you still see the same instruments than in a standard 4:3 screen with 55 deg FOV. This should work out of the box for any aircraft. Unchecking the option resets the FOV for any view to the initial settings. Patch attached, Tests and comments welcome. Alexis diff --git a/Aircraft/E-2C/E-2C-set.xml b/Aircraft/E-2C/E-2C-set.xml index 9d6730a..3d16688 100644 --- a/Aircraft/E-2C/E-2C-set.xml +++ b/Aircraft/E-2C/E-2C-set.xml @@ -63,8 +63,8 @@ Grumman E-2C simulation config. -0.45 -0.072 --6.9 --16.5 +-6.85 +-17 55
Re: [Flightgear-devel] Depth buffers, render bins and passes
> De: "Renk Thorsten" > > > To summarize, all objects having a pass of render bin -1 are > > rendered before any object having a render bin 1. If an object have two > > passes, it is rendered twice, once with the objects of the same render bin > > than the first pass, once with the objects of the same render bin than > > the second pass. The second pass can be rendered before the first pass > > if the render bin numbers are inverted (the pass number has no > > rendering meaning). > > Thanks Fred, you just helped me squeezing a 30% higher framerate out > of trees. Going to try the trick on clouds next. You know that rendering a transparent object twice alter its transparency. Of course, you can avoid to render it in the color buffer using write mask in one pass. Regards, -Fred -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Hi Heiko, > De: "Heiko Schulz" > > any other comments on my problem? > > After a while it loaded now the nav datas, but whenever I start FGFS > again, it takes the same time again. > > Not sure if this behavior is intended... I know some people erase the content of the folder having autosave.xml. This folder is now used to host a navigation data cache. The first time, a SQL database is built to speedup future start. If this cache is erased every time, it defeats the purpose of the cache and make the start much longer every time. Just guessing... Regards, -Fred -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Depth buffers, render bins and passes
> To summarize, all objects having a pass of render bin -1 are rendered > before any object having a render bin 1. If an object have two passes, > it is rendered twice, once with the objects of the same render bin than > the first pass, once with the objects of the same render bin than the > second pass. The second pass can be rendered before the first pass if > the render bin numbers are inverted (the pass number has no rendering > meaning). Thanks Fred, you just helped me squeezing a 30% higher framerate out of trees. Going to try the trick on clouds next. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
> On 10/03/2012 07:30 PM, Heiko Schulz wrote: >> But already done: http://www.hoerbird.net/reisen.html >Gives me a 404 error. me too ;-) Changed the signature any other comments on my problem? After a while it loaded now the nav datas, but whenever I start FGFS again, it takes the same time again. Not sure if this behavior is intended... -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2012 07:30 PM, Heiko Schulz wrote: > But already done: http://www.hoerbird.net/reisen.html Gives me a 404 error. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBsfpkACgkQty+BhcbHvXioQwCfe9QrHjxs04IURsZeww6V/tDK e5oAn0XRapdpkWVC8YrdYoinT6PWgL88 =19st -END PGP SIGNATURE- -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Hello, I thought today it would be nice again to have a flight in FGFS, since I found some spare time. Updated FGData, download the latest Jenkins build #726 for win32 and launched it. Since a whole while now, a bit more than 30min, it is stuck at "Loading navigation datas". And I'm still waiting, and waiting... I guess it has something to do with the changes announced here, but it is just a guess. No relevant console output (just: "Warning: GraphicsWindowWin32::grabFocus() - Failed grabbing the focus") win32 Jenkins Build #726, updated FGData Dualcore 2,6 Ghz, 4GB Ram, Nvidia GeForce GTX460 1GB VRAM Bug Report: https://code.google.com/p/flightgear-bugs/issues/detail?id=894 Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FW:Using FlightGear to visualize JSBSim state
I've been trying to drive FlightGear from an external instance of JSBSim running, over a socket. Not having much luck at the moment. Looks like I have the correct net_fdm header (version 24). I start FlightGear like this: $ FlightGear/projects/VC90/Win32/Release/fgfs.exe --fg-root="c:/cygwin/home/jon/flightgear/fgdata" --aircraft=c172p --native-fdm=socket,in,60,,5500,tcp --fdm=external After that is started up I crank up JSBSim with an output specified in the aircraft config file like this (per the email from HDWysong): In the JSBSim console I get this: Successfully connected to socket for output ... send: Software caused connection abort send: Software caused connection abort send: Software caused connection abort ... FlightGear immediately core dumps. Any suggestions? Jon > -Original Message- > From: Jon S. Berndt [mailto:jonsber...@comcast.net] > Sent: Wednesday, October 03, 2012 5:20 AM > To: 'Development issues' > Subject: Re: [Jsbsim-devel] Using FlightGear to visualize JSBSim state > > That was it. Thanks. > > Although I did get FlightGear to start up in this mode, it core dumped > when I tried to connect from JSBSim. I wonder if I need to update the > net fdm header. > > Jon > > > -Original Message- > > From: Anders Gidenstam [mailto:anders-...@gidenstam.org] > > Sent: Wednesday, October 03, 2012 2:03 AM > > To: 'Development issues' > > Subject: Re: [Jsbsim-devel] Using FlightGear to visualize JSBSim > state > > > > On Tue, 2 Oct 2012, Jon S. Berndt wrote: > > > > > Not sure it does work: > > > > > > FlightGear/projects/VC90/Win32/Release/fgfs.exe > > > --fg-root="c:/cygwin/home/jon/flightgear/fgdata" --aircraft=c172p > > > native-fdm=socket,in,60,,55p --fdm=external > > > > > > Processing command line arguments > > > Fatal error: Failed to open file > > > at native-fdm=socket,in,60,,5500,tcp (received from SimGear XML > > > Parser) > > > > Did you drop the '--' that should go before native-fdm when > > transcribing the command line to the message? Or are they missing > > there too? > > > > If it is the latter SG tried and failed to open the file "native- > > fdm=socket,in,60,,5500,tcp". > > > > Cheers, > > > > Anders > > -- > > > > - > - > > - > > > > Anders Gidenstam > > WWW: http://gitorious.org/anders-hangar > > http://www.gidenstam.org/FlightGear/ > > > > > > - > - > > - > > --- > > Don't let slow site performance ruin your business. Deploy New Relic > > APM Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try > New > > Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > Jsbsim-devel mailing list > > jsbsim-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > > ___ > > The JSBSim Flight Dynamics Model project http://www.JSBSim.org > > ___ > > > -- > - > --- > Don't let slow site performance ruin your business. Deploy New Relic > APM Deploy New Relic app performance management and know exactly what > is happening inside your Ruby, Python, PHP, Java, and .NET app Try New > Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > Jsbsim-devel mailing list > jsbsim-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > ___ > The JSBSim Flight Dynamics Model project http://www.JSBSim.org > ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no
Re: [Flightgear-devel] another git question
On 3 Oct 2012, at 09:41, Tim Moore wrote: > A better alternative in your case might be to use git bundles, which > pack into a file the data that would be on the wire in a git push. > http://git-scm.com/2010/03/10/bundles.html seems well suited to your scenario. Oooh, I didn't know about these - they sound like a good solution to Curt's issue. (Well, I'm a little surprised he/Curt can't rig some kind of serial/ usb-ethernet connection sufficient to push/pull directly from the device, but that's 'solving the wrong problem' :) James -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another git question
On Tuesday 02 October 2012 21:07:58 Curtis Olson wrote: > I have a clone of the repository on my embedded system too, and it's remote > is setup to point to the clone on the thumb drive when that is plugged in. > So I can plug the thumb drive into my main linux computer and run > pull/push against the master repository, or I can plug the thumb drive into > the embedded system and do pulls/pushes from the local embedded system with > the repository on the thumb drive acting as the remote master. > > If I "cd" to the thumb drive repository and run git push (which I thought > would push my changes to the master repository) I get the following error: > > $ git push > To /path/myrepo.git/ > ! [rejected]master -> master (non-fast-forward) > Any suggestions? Having more than one bare repo probably won't work well. I would put a repository with working directory on the thumb drive. Now you can't push to this repo anymore, but you don't have to. Simply pull the changes from your embedded device to the thumb drive. Then you can push them to the master on your PC. Similarily you can pull changes from your master to the thumb drive and then pull the changes from the thumb to your embedded device. In other words, simply replace the embedded -> thumb push by a thumb <- embedded pull. Also remember that a git pull is just a git fetch followed by a git merge. Might help with the bare repo. Stefan signature.asc Description: This is a digitally signed message part. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another git question
The short answer is to not have a bare repo on the thumb drive, so it is more practical to push from it, especially to your master repo. If you do that, you need to realize that the branch you have checked out into the working tree could be made out of date in odd ways by pushing into the repo. I usually get around that by pushing around branches that won't be checked out in the repo (i.e., other than master). A better alternative in your case might be to use git bundles, which pack into a file the data that would be on the wire in a git push. http://git-scm.com/2010/03/10/bundles.html seems well suited to your scenario. Tim On Wed, Oct 3, 2012 at 4:07 AM, Curtis Olson wrote: > I know how everyone loves git questions here, so this is a bit off topic, > but I have another crazy git question. The situation is probably weird > enough that I might not be able to explain it well enough to get an answer, > but let me try. > > The situation is that I have a master git repository on my linux pc > (--bare). I then cloned it from multiple places and I can push and pull and > commit from any of the remote clones (the clones that have a working tree) > and everything works as expected. > > Now I'd like to also be able to pull and push and make changes (and keep in > sync) on a computer that is impossible to have on the network (it's an > embedded linux computer that has no network hardware and no way to add any.) > The embedded linux computer has a full copy of git and a full native > development system right on board. > > I am able to plug in a USB thumb drive, so my "brilliant" idea was to create > a clone of the master repository on the thumb drive. The clone on the thumb > drive is setup so it's remote path is valid when it is plugged into my main > linux desktop PC and can see the master repository from there. > > I have a clone of the repository on my embedded system too, and it's remote > is setup to point to the clone on the thumb drive when that is plugged in. > So I can plug the thumb drive into my main linux computer and run pull/push > against the master repository, or I can plug the thumb drive into the > embedded system and do pulls/pushes from the local embedded system with the > repository on the thumb drive acting as the remote master. Then if there > are changes from the embedded system, I can move the thumb drive over to the > linux desktop PC, go to the thumb drive repository and run a push from there > to get the changes back into the master central repository ... that was my > theory at least and I though I had it working until I started pushing > changes around from a few different directions. > > The clone on the thumb drive was originally just a simple clone with a > working tree, but I ran into problems making that the remote for my embedded > clone, so I went back and remade the thumb drive clone using the --bare > option. But now I'm in a situation where I have changes from the embedded > system that I've pushed into the thumb drive repository. And I have changes > from elsewhere that I've pushed into the master repository. > > If I "cd" to the thumb drive repository and run git push (which I thought > would push my changes to the master repository) I get the following error: > > $ git push > To /path/myrepo.git/ > ! [rejected]master -> master (non-fast-forward) > error: failed to push some refs to '/path/myrepo.git/' > hint: Updates were rejected because the tip of your current branch is behind > hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') > hint: before pushing again. > hint: See the 'Note about fast-forwards' in 'git push --help' for details. > > However, my thumb drive repository is created with the --bare option so I > don't have a working tree, thus when I run "git pull" as per the suggestion > in the error message I get: > > $ git pull > fatal: /usr/libexec/git-core/git-pull cannot be used without a working tree. > > This may not make any sense the way I'm explaining it, or maybe I'm missing > something completely obvious? But essentially I'm trying to work around not > having a network connection by creating a go-between repository clone on a > thumb drive. Is this possible? > > BTW, I looked at git clone --mirror, but I need to pass changes in both > directions to/from the embedded system through the thumb drive repository so > I don't think a pure mirror of the master repository will do what I want. > > Any suggestions? > > Thanks, > > Curt. > -- > Curtis Olson: > http://www.atiak.com - http://aem.umn.edu/~uav/ > http://www.flightgear.org - http://gallinazo.flightgear.org > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
Re: [Flightgear-devel] another git question
Hi, Curt, from my limited understanding of Git - you have painted yourself into a corner by having bare repo at one hand and creating situation where you need to merge on the other. Possible immediate solutions I see - either clone the thumb repo to a new non-bare repo, add your master repo as a remote, do a merge and push from there - or add the thumb repo as a remote to an already existing non-bare repo, merge it and push to master In the future, you should make sure that you freeze the master repo, then pull to the thumb, pull to embedded, rebase embedded, commit, push from embedded to thumb, push from thumb to master, unfreeze master Oh, and make backups before you experiment, in case something b0rks :) Cheers, Edheldil -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
