Re: [Flightgear-devel] FlightGear at TU Delft
On Fri, 9 Nov 2012 20:37:10 +, Stuart wrote in message CAP3ntysv=1xcks8nk_ssk3+e8-wwrbmwulwomaquy3vy0gd...@mail.gmail.com: On Mon, Sep 10, 2012 at 12:26 PM, Jan Comans wrote: We should have a random number generator in simgear that returns the same random number within the same period of time (I believe it was set to 1 second) to prevent short time quirks between different machines. This was specially added for (random) clouds. I have looked at this, but as far as I can see FG calls the regular time seed intialization instead of the 'time period' one. I think the period is even 10min. But I recall having some issues with giving the whole simulation a fixed seed (either through the srand10 method or providing a custom seed). Next to that, the time period seed relies on the fact that system clocks are more or less in sync. Normally NTP should take care of that, but with our sim being tweaked constantly this is difficult to guarantee. This for me is also a reason for providing a separate rng to handle the part that I'm interested in. As I said before, form me this was just a quick and dirty hack to get the results we needed. Personally, I think it would be beneficial to put the randomness somewhere in the property tree so that the cloud code can build 'deterministic' clouds from these values. In this way, other FG instances could be coupled in way similar to using --fdm=external, and just receive the basic random seeds that would result in the same cloud fields on every instance. But that's just my idea without having looked at the code too much. I've committed a change to keep the clouds in sync across multi-process systems. It relies on the clocks of the systems being roughly in sync as the seed changes every 10 minutes. ..are we now close to be able to run a FlightGear clock service, e.g. over a multiplayer network, independently from real time or hardware clocks, to e.g. render a 4K cinematic quality movie at say 4% of real time speeds 'n framerates? -- ..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. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
On Sat, Nov 10, 2012 at 9:10 AM, Arnt Karlsen wrote: ..are we now close to be able to run a FlightGear clock service, e.g. over a multiplayer network, independently from real time or hardware clocks, to e.g. render a 4K cinematic quality movie at say 4% of real time speeds 'n framerates? Short answer: No. The changes just affect random number seed generation. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
On Mon, Sep 10, 2012 at 12:26 PM, Jan Comans wrote: We should have a random number generator in simgear that returns the same random number within the same period of time (I believe it was set to 1 second) to prevent short time quirks between different machines. This was specially added for (random) clouds. I have looked at this, but as far as I can see FG calls the regular time seed intialization instead of the 'time period' one. I think the period is even 10min. But I recall having some issues with giving the whole simulation a fixed seed (either through the srand10 method or providing a custom seed). Next to that, the time period seed relies on the fact that system clocks are more or less in sync. Normally NTP should take care of that, but with our sim being tweaked constantly this is difficult to guarantee. This for me is also a reason for providing a separate rng to handle the part that I'm interested in. As I said before, form me this was just a quick and dirty hack to get the results we needed. Personally, I think it would be beneficial to put the randomness somewhere in the property tree so that the cloud code can build 'deterministic' clouds from these values. In this way, other FG instances could be coupled in way similar to using --fdm=external, and just receive the basic random seeds that would result in the same cloud fields on every instance. But that's just my idea without having looked at the code too much. I've committed a change to keep the clouds in sync across multi-process systems. It relies on the clocks of the systems being roughly in sync as the seed changes every 10 minutes. Thanks for pointing out the problem Jan and for your patch which gave me a simple recipe to follow of where needed change :). I've limited ability to test this myself, but certainly re-starting FG a couple of times created the same cloud-field. Note that a reset does not as the RNG seed is not re-generated. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
I haven't had the chance to look at your fix beyond viewing the diffs, but at first glance I'm slightly surprised it works across multiple machines/instances. I would expect that differences in initialization time would mean that at any given moment in time some instances would have made more calls to mt_rand than others, resulting in different generated numbers, even if they all started with the same seed. Is this something you've had to resolve, or is it simply not an issue because the only calls that truly matter are the initial calls to determine cloud placement? My first try was to just switch to a fixed seed with the default random number generator during initialization. But for some reason, this didn't really work out so well. I can't exactly remember, but I think it seemed to work on my home machine, but failed in our simulator. Then I decided to create a second rng which always initializes with a fixed seed ( either 1 or the value of FGRANDOMSEED). Then I just replaced all request for a random number with a call to this new rng. I just hoped that the clouds didn't depend on any variables that rely on the other rng somewhere along the way. But apparently this doesn't happen and the clouds come out the same on each machine/instance. We do have to be careful with initializing FlightGear of course. Slight differences in command line parameters result in wrong cloud fields. This is basically the reason why I referred to my patch as a hack. Changing the weather on the fly doesn't work at the moment because there is no way we can do exactly the same in each weather dialog on every machine. This would require a more fundamental change in the cloud generation code. I'm currently up to my elbows in the random buildings code, but once I've completed that job I will look at your fix in more detail and work out how best to integrate it. I know the feeling :) At the moment I don't have a lot of time to spend since I'm finalizing my experiment which should run in a couple of weeks. But once I get some time I'll try to look at the code a bit more and see if I have some ideas. I'll get in touch when I get to it. Cheers, Jan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
Really nice to read about that. I got the chance to look at a similar install of flightgear in Tübingen very close to where I live. And You may remember me - I believe we have talked about the problems you have at the fsweekend. I definitely remember. Apologies for waiting so long to get in touch again :) As explained every now and then, I am working on a viewer instance that is designed from ground up for this kind of scenario, so in the long term this should work, but for the short time it is really good to know that this is at least somehow solved. For our kind of work this kind of modular setup would make life a lot easier, so I would be very interested in your progress. No pressure tough. Cheers, Jan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
On 09/10/2012 10:33 AM, Jan Comans wrote: My first try was to just switch to a fixed seed with the default random number generator during initialization. But for some reason, this didn't really work out so well. I can't exactly remember, but I think it seemed to work on my home machine, but failed in our simulator. We should have a random number generator in simgear that returns the same random number within the same period of time (I believe it was set to 1 second) to prevent short time quirks between different machines. This was specially added for (random) clouds. Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
On Mon, Sep 10, 2012 at 11:03 AM, Erik Hofman wrote: We should have a random number generator in simgear that returns the same random number within the same period of time (I believe it was set to 1 second) to prevent short time quirks between different machines. This was specially added for (random) clouds. My memory may be failing me, but I don't recall using this when implementing the current 3D clouds, so I suspect it isn't currently in use. Thanks for the pointer. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
We should have a random number generator in simgear that returns the same random number within the same period of time (I believe it was set to 1 second) to prevent short time quirks between different machines. This was specially added for (random) clouds. I have looked at this, but as far as I can see FG calls the regular time seed intialization instead of the 'time period' one. I think the period is even 10min. But I recall having some issues with giving the whole simulation a fixed seed (either through the srand10 method or providing a custom seed). Next to that, the time period seed relies on the fact that system clocks are more or less in sync. Normally NTP should take care of that, but with our sim being tweaked constantly this is difficult to guarantee. This for me is also a reason for providing a separate rng to handle the part that I'm interested in. As I said before, form me this was just a quick and dirty hack to get the results we needed. Personally, I think it would be beneficial to put the randomness somewhere in the property tree so that the cloud code can build 'deterministic' clouds from these values. In this way, other FG instances could be coupled in way similar to using --fdm=external, and just receive the basic random seeds that would result in the same cloud fields on every instance. But that's just my idea without having looked at the code too much. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
Hi, Really nice to read about that. I got the chance to look at a similar install of flightgear in Tübingen very close to where I live. And You may remember me - I believe we have talked about the problems you have at the fsweekend. So to say: I am glad to see this piece of software installed in this kind of environments. Thank you! We did have one issue tough with our setup. Since we run three different instances on three different machines, we got clouds which weren't consistent across the screen. We fixed this with a small hack in the random number generator and the cloud rendering code. It's not pretty, but does the job for now. If you're interested, it is in my gitorious repository: https://gitorious.org/csflightgear. In the next few weeks, we will be fiddling a bit more with the setup and might do some further tweaking. If I have more problems, workarounds, tweaks, ... I'll let you know about it. And we are of course interested in feedback from you all should you should you see something you like or don't like. I am somehow short on time. But I want to have the problem with the clouds solved. As explained every now and then, I am working on a viewer instance that is designed from ground up for this kind of scenario, so in the long term this should work, but for the short time it is really good to know that this is at least somehow solved. If I forget about that, feel free to remind me ... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
On Wed, Sep 5, 2012 at 5:34 PM, Jan Comans wrote: We did have one issue tough with our setup. Since we run three different instances on three different machines, we got clouds which weren't consistent across the screen. We fixed this with a small hack in the random number generator and the cloud rendering code. Hi Jan, I'm the author of the 3D clouds code. Thanks very much for highlighting the random number generator problem, and for your fix. I haven't had the chance to look at your fix beyond viewing the diffs, but at first glance I'm slightly surprised it works across multiple machines/instances. I would expect that differences in initialization time would mean that at any given moment in time some instances would have made more calls to mt_rand than others, resulting in different generated numbers, even if they all started with the same seed. Is this something you've had to resolve, or is it simply not an issue because the only calls that truly matter are the initial calls to determine cloud placement? I'm currently up to my elbows in the random buildings code, but once I've completed that job I will look at your fix in more detail and work out how best to integrate it. Thanks, -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
However, in the past couple of weeks ( after a graphics card update for our simulator) we started working with FlightGear 2.8. Thanks a lot for your report! It's really nice and motivating to see FlightGear being used for serious (research) projects and not just for fun/gaming. And a full motion sim certainly is a serious thing ;-). Also shows that FSWeekend is a worthwhile event (btw for everyone: this year's FSWeekend takes place on November 3rd/4th). cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
