It's that time of year, again. I'm not referring to the 1 year anniversary of BNov. I'm referring to that fact that we've hit the point where I'm fairly comfortable with writing a manual, then releasing.
There is, come to think of it, one tiny little thing that should be done before release, and that is to make a passable UI for selecting the starting position in network games.
So then we've hit the point where we just need to do that one thing, create a skybox (if we really want it; is it necessarily needed?), test it, lower the network bandwidth (turn down the SONAR broadcast rate), write the manual, and we're freakin' done.
We've almost made it. Let's hit the ground running. I have a couple of small projects, so we can get this done by the BEST Kickoff on September 10th.
Let's go. We got this.
Sunday, August 28, 2011
Sunday, July 31, 2011
Long delay, but I'm still here.
Okay, team. After an extended period of time slacking off at an internship down at WPEngine, I'm back and (almost) ready to slack off here.
My hope is that I'll mirror last summer, when I wrote four thousand lines of code and put in most of the ground level framework, a running simulation, in the last two weeks of summer. This summer, when school starts, the line count is going to pass 30k, and BNov will be a decent game (okay, so maybe I'm a little hopeful).
Here's what needs to be done:
My hope is that I'll mirror last summer, when I wrote four thousand lines of code and put in most of the ground level framework, a running simulation, in the last two weeks of summer. This summer, when school starts, the line count is going to pass 30k, and BNov will be a decent game (okay, so maybe I'm a little hopeful).
Here's what needs to be done:
- The network needs to be finalized and written. This is pretty big, but we have a lot of the lower level stuff. One of the big issues is that the most recent version has issues running locally.
- Models need to be made. This is also big, because it involves both graphics modelling and Python scripting - and frankly, I suck at graphics modelling.
- A closely linked objective is better AI. At the moment, things (torpedoes) might sort of hit something if you're really lucky, and you shoot a lot of them. This is also tied into number four.
- This last one is big only emotionally. The SONAR model must be set in stone, at least for some period of time. I don't think we can't decently meet any time goals if I keep on rewriting it from scratch (anyone who looks at the code will realize that there is actually 2 complete rewrites of the SONAR module, both of which are enabled and running at all stages of the game.)
- The user interface. Need I say more? We need to clarify what we expect. Speech isn't what we thought it'd be, sadly. I'm impressed, but the possibility of failure is too high for, well, controlling navies. Perhaps some sort of confirmation method would be preferable? (Some sort of Windows style "Are you sure you want to dodge the incoming torpedo?")
Tuesday, May 31, 2011
Holy Moly, Batman!
So somewhere, far back into the dark ages (I.E. a year and a half ago), I wrote a tiny little function. This wee little function was made for a small, developing program barely scratching a hundred lines of code. It's sole purpose in life was to pull together all of the little loose ends of logging and present them as a single API capable of getting a direct hit from even the most critical hacker. It would go on in life to form a bullet proof backbone to a full thirty-five thousand lines of code spread across two projects.
It's name was logAddEntry().
I found a bug in it. This piece of code has literally gone untouched for over a year and a half, and has supported my two biggest projects since almost two years ago. It fell prey to a simple fixed-length buffer error... If the sum total of all of the arguments to the function is over 1000 bytes, then it will write over the end of the buffer. It's amazing how long some pieces of code last...
Along a different note, I've recently become frustrated with the whole speech to text system. It never seems to recognize my voice correctly - I'll be following the dummy ship, and I'll give a command to shift a couple of degrees because, well, the torpedoes are very touchy. Next thing I know, I turned ninety degrees off course and I have to redo the entire alignment. So to counteract this, I implemented a message box style system. Using this system, you can type the commands instead of having to speak them. It can be activated with the 'c' key. Then, just type what you would say, almost verbatim. It literally substitutes the text that you type for what you say, pretending that what you type came from PocketSphinx. It's useful, despite the requirement for attention to detail. There is one nice shortcut, which is that BNov will parse numbers. It comes in handy :)
Also, I implemented a simple skybox method. SVN r28 has a simple, standard SkyBox: I.E., I rendered a large textured box. In that particular rev, and every rev since, the textures are not done well. However, I had the epiphany that 'skybox' is not how the world is... And neither is 'skysphere.' See the illustration below. However, I decided that to best capture how clouds actually look would require a 'skyplane' along with the 'skybox.' The only thing that would be on the skybox would be the sun and blue sky - If we even want that. One thing that would be nice would be having the shaders generate the sky color automatically, along with lens flare. Then, the skyplane would have the clouds. We could even have multiple layers of clouds this way.
Oh - and by the way... I've changed what I think of the SONAR model (again!). I was looking at Dangerous Waters, which is another sub game, but I'm seeing a consensus... The dangerous waters system contains three systems: Broadband, narrowband, and DEMON. Broadband is a ring graph around the ship of total noise (possibly weighted by frequency - I'm not sure) versus bearing. Narrowband also takes the form of a circular graph - It records frequency versus bearing. DEMON is a true waterfall diagram - Time scrolls upward, while the horizontal axis records frequency profiles. The cool thing is that SONAR2 is able to support this new operating paradigm without modification, so that effort wasn't wasted.
On a more specific note, I found what is perhaps the best resource in all of human history. And no, it's not Wikipedia. It's an illustrated guide to Submarine design history since WWII (Link), and I will admit that it is one of the few books that I'm seriously considering purchasing. Anyhow, it has many pages on the whole broadband/narrowband/DEMON concept. Okay, maybe just the DEMON stuff. It essentially lays out what the sound profiles of ships are (Oh - Another great resource is Here, but it's about Dangerous Waters). The thinking is that the water flowing over the ship is modulated by the spinning propellors, and so you end up with distinct lines whenever the propellor rotates one nth revolution. That means that, say, a seven bladed propellor spinning at 300RPM (5RPS) has a strong line at 35Hz. Insofar as I can tell, the whole thing in the Video Games about how you get a number of lines equal to the number of blades has shockingly little truth value. It's apparently just a useful feature if you want to play the game - In real life, it's not that easy.
The user interface was revamped, again. I decided that I had too little real estate, so I split the old window into it's constituent parts. Then, I put each part in it's own 'display.' You can switch between the different states by pressing the associated number on the top of the keyboard (numpad doesn't work anywhere, FYI). '1' is the periscope (full window!), '2' is the map view (ditto!), '3' is the assortment of dials and readouts (engine, heading, depth, etc.) and '4' is the new prototype broadband display (screenshot above). Quick note: The broadband display takes ~10s to warm up after starting BNov, and updates every 5s thereafter.
At some point in the near future, I'm going to start porting BNov to Windows. The public profile is growing, person by person, and I feel bad not having anything to show for those poor souls... Porting shouldn't be very hard, except for a few key libraries. Bullet should actually be easier than it is on Linux, as there are precompiled Bullet libraries. The two I'm worried about are OpenGL and GStreamer. I've had bad experiences with OpenGL and windows, I.E. I end up having to run as old as 1.1, which is a full major rev before what BNov requires. GStreamer, however, is more or less Linux-specific, as it is built on the GObject library. It'll compile under MinGW, according to the website, but it's still work. For this it might be worth porting to the Windows API. WAPI has a built in speech decoder, and Festival works on Windows, so that shouldn't be an issue. The built-in nature of this means that it's not only tuned, but somebody somewhere gets paid sums of money to make this work well, and it works off of trained data, so it'll be a lot more accurate.
Is it just me, or are these posts getting longer? It's starting to get to the point where stuff that I write is obsolete by the time the post is published. For instance, this particular post started eight or nine revisions ago... ;)
Along a different note, I've recently become frustrated with the whole speech to text system. It never seems to recognize my voice correctly - I'll be following the dummy ship, and I'll give a command to shift a couple of degrees because, well, the torpedoes are very touchy. Next thing I know, I turned ninety degrees off course and I have to redo the entire alignment. So to counteract this, I implemented a message box style system. Using this system, you can type the commands instead of having to speak them. It can be activated with the 'c' key. Then, just type what you would say, almost verbatim. It literally substitutes the text that you type for what you say, pretending that what you type came from PocketSphinx. It's useful, despite the requirement for attention to detail. There is one nice shortcut, which is that BNov will parse numbers. It comes in handy :)
 |
| Messaging System At Work |
Also, I implemented a simple skybox method. SVN r28 has a simple, standard SkyBox: I.E., I rendered a large textured box. In that particular rev, and every rev since, the textures are not done well. However, I had the epiphany that 'skybox' is not how the world is... And neither is 'skysphere.' See the illustration below. However, I decided that to best capture how clouds actually look would require a 'skyplane' along with the 'skybox.' The only thing that would be on the skybox would be the sun and blue sky - If we even want that. One thing that would be nice would be having the shaders generate the sky color automatically, along with lens flare. Then, the skyplane would have the clouds. We could even have multiple layers of clouds this way.
Oh - and by the way... I've changed what I think of the SONAR model (again!). I was looking at Dangerous Waters, which is another sub game, but I'm seeing a consensus... The dangerous waters system contains three systems: Broadband, narrowband, and DEMON. Broadband is a ring graph around the ship of total noise (possibly weighted by frequency - I'm not sure) versus bearing. Narrowband also takes the form of a circular graph - It records frequency versus bearing. DEMON is a true waterfall diagram - Time scrolls upward, while the horizontal axis records frequency profiles. The cool thing is that SONAR2 is able to support this new operating paradigm without modification, so that effort wasn't wasted.
 |
| Prototype SONAR Broadband Display |
On a more specific note, I found what is perhaps the best resource in all of human history. And no, it's not Wikipedia. It's an illustrated guide to Submarine design history since WWII (Link), and I will admit that it is one of the few books that I'm seriously considering purchasing. Anyhow, it has many pages on the whole broadband/narrowband/DEMON concept. Okay, maybe just the DEMON stuff. It essentially lays out what the sound profiles of ships are (Oh - Another great resource is Here, but it's about Dangerous Waters). The thinking is that the water flowing over the ship is modulated by the spinning propellors, and so you end up with distinct lines whenever the propellor rotates one nth revolution. That means that, say, a seven bladed propellor spinning at 300RPM (5RPS) has a strong line at 35Hz. Insofar as I can tell, the whole thing in the Video Games about how you get a number of lines equal to the number of blades has shockingly little truth value. It's apparently just a useful feature if you want to play the game - In real life, it's not that easy.
The user interface was revamped, again. I decided that I had too little real estate, so I split the old window into it's constituent parts. Then, I put each part in it's own 'display.' You can switch between the different states by pressing the associated number on the top of the keyboard (numpad doesn't work anywhere, FYI). '1' is the periscope (full window!), '2' is the map view (ditto!), '3' is the assortment of dials and readouts (engine, heading, depth, etc.) and '4' is the new prototype broadband display (screenshot above). Quick note: The broadband display takes ~10s to warm up after starting BNov, and updates every 5s thereafter.
At some point in the near future, I'm going to start porting BNov to Windows. The public profile is growing, person by person, and I feel bad not having anything to show for those poor souls... Porting shouldn't be very hard, except for a few key libraries. Bullet should actually be easier than it is on Linux, as there are precompiled Bullet libraries. The two I'm worried about are OpenGL and GStreamer. I've had bad experiences with OpenGL and windows, I.E. I end up having to run as old as 1.1, which is a full major rev before what BNov requires. GStreamer, however, is more or less Linux-specific, as it is built on the GObject library. It'll compile under MinGW, according to the website, but it's still work. For this it might be worth porting to the Windows API. WAPI has a built in speech decoder, and Festival works on Windows, so that shouldn't be an issue. The built-in nature of this means that it's not only tuned, but somebody somewhere gets paid sums of money to make this work well, and it works off of trained data, so it'll be a lot more accurate.
Is it just me, or are these posts getting longer? It's starting to get to the point where stuff that I write is obsolete by the time the post is published. For instance, this particular post started eight or nine revisions ago... ;)
Wednesday, May 4, 2011
Fourier
Time has been progressing.
Slowly.
Anyone who watches the BN SourceForge page (Now known as 'BNSF') will have noticed that Sunday night I posted four different feature requests. I realized that the school year is running out... So I decided that I need to dedicate more time to this project, since school is... school :) I'll start implementing these features after I finish the Fourier transform stuff (see below). Then, in two or three weeks time the Game Testing Team (you know who you are) will host a LAN party, and we'll nail down as many bugs and interface problems as possible. Then, we'll fix all of the bugs. Repeat.
I have new found knowledge of the Fourier transform system. One fact is that you should never, ever try to make your own library: mine still doesn't work. Now I'm using the FFTW library, which works well... but has some idiosyncrasies of its own. My new knowledge of the DFT is that of the windowing function and bin leakage. But, I have decided that I DON'T CARE. On board an actual ship, there will still be bin leakage in the SONAR detection, so I can just include the bin leakage as part of the acoustic profile of each component. This has the drawback that propagation loss will be messed up, as higher frequency leakage will propagate as if it were actually traversing the ocean. Oh, well, I guess it'll be fixed at some point :)
When I last posted, I had setup a eureqa system to hunt down the component frequencies of a particular audio file. Turns out that this has some downsides... Eureqa is a great program, but it was not intended for acoustical analysis. I killed the job after eight days and 1,500 core hours. We found two waveforms. I know that there's more.
But this leads me to a new conclusion. What if we had a program that would perform an optimized GA for acoustical analysis? We could implement it by taking the DFT of a waveform, and marking the peaks. Then, we just start adding the tallest peaks as single sinusoids, and recalculate the DFT each time we add a new wave. Then, we get the effect of the bin leakage in terms of the waves, so that when the final sum of sines is read by a computer and spectroanalyzed, it shows the proper spectrograph. I'll implement this when I get some time on my hands, but for now I'll just hand-generate a waveform for the propeller. I might also switch the bin system to be logarithmic, because at the moment the system is linear: there's a 10-110Hz bin, and a 19000-19100Hz bin. Doesn't quite work as well as I had hoped...
On the subject of acoustics, I had an epiphany with how to take into account thermoclines. What we will do is assume that all thermoclines occur in transitions between solid blocks of water-temperature-areas. We'll just say that at, say, 100m, the water changes suddenly to some different temperature. We can calculate how to measure the speed of sound in water for the two areas. Then, we can just use Snell's law to figure out the amount that it refracts. We can just setup a triangle... and we have the new distance in each medium, which can be passed to the propagation function to calculate the overall propagation.
Oh, and speaking of the Game Testing Team: the default BN scenario, the one that loads by default (you can change it with the '--scenario=' flag), now includes a really dumb target. It should be visible on SONAR, as well as visually, from load time.
Slowly.
Anyone who watches the BN SourceForge page (Now known as 'BNSF') will have noticed that Sunday night I posted four different feature requests. I realized that the school year is running out... So I decided that I need to dedicate more time to this project, since school is... school :) I'll start implementing these features after I finish the Fourier transform stuff (see below). Then, in two or three weeks time the Game Testing Team (you know who you are) will host a LAN party, and we'll nail down as many bugs and interface problems as possible. Then, we'll fix all of the bugs. Repeat.
I have new found knowledge of the Fourier transform system. One fact is that you should never, ever try to make your own library: mine still doesn't work. Now I'm using the FFTW library, which works well... but has some idiosyncrasies of its own. My new knowledge of the DFT is that of the windowing function and bin leakage. But, I have decided that I DON'T CARE. On board an actual ship, there will still be bin leakage in the SONAR detection, so I can just include the bin leakage as part of the acoustic profile of each component. This has the drawback that propagation loss will be messed up, as higher frequency leakage will propagate as if it were actually traversing the ocean. Oh, well, I guess it'll be fixed at some point :)
 |
| Acoustic Leakage Pipeline |
When I last posted, I had setup a eureqa system to hunt down the component frequencies of a particular audio file. Turns out that this has some downsides... Eureqa is a great program, but it was not intended for acoustical analysis. I killed the job after eight days and 1,500 core hours. We found two waveforms. I know that there's more.
But this leads me to a new conclusion. What if we had a program that would perform an optimized GA for acoustical analysis? We could implement it by taking the DFT of a waveform, and marking the peaks. Then, we just start adding the tallest peaks as single sinusoids, and recalculate the DFT each time we add a new wave. Then, we get the effect of the bin leakage in terms of the waves, so that when the final sum of sines is read by a computer and spectroanalyzed, it shows the proper spectrograph. I'll implement this when I get some time on my hands, but for now I'll just hand-generate a waveform for the propeller. I might also switch the bin system to be logarithmic, because at the moment the system is linear: there's a 10-110Hz bin, and a 19000-19100Hz bin. Doesn't quite work as well as I had hoped...
On the subject of acoustics, I had an epiphany with how to take into account thermoclines. What we will do is assume that all thermoclines occur in transitions between solid blocks of water-temperature-areas. We'll just say that at, say, 100m, the water changes suddenly to some different temperature. We can calculate how to measure the speed of sound in water for the two areas. Then, we can just use Snell's law to figure out the amount that it refracts. We can just setup a triangle... and we have the new distance in each medium, which can be passed to the propagation function to calculate the overall propagation.
 |
| Path of Acoustical waves through the thermocline |
Oh, and speaking of the Game Testing Team: the default BN scenario, the one that loads by default (you can change it with the '--scenario=' flag), now includes a really dumb target. It should be visible on SONAR, as well as visually, from load time.
Friday, April 22, 2011
Long Time, But I Hear You... Differently
It's been a depressingly long time since I got anywhere on anything. However, as of late I redid the SONAR module. The new SONAR module (dubbed SONAR2) splits the frequency band into a hundred different bands. It also uses a more realistic propagation model, pulled from some university web site.
But, one step at a time as it may be, I still need to finish the first step. The first sound file is composed of four sines: 60Hz at 5dB, 160Hz at 8dB, 5Hz at 20dB, and 600Hz at -20dB. I pulled these waves from a spectrogram of a helicopter, and I just picked the first four strongest waves that seemed relevant to me at the time, and made up some other ones. In the original, there was a quiet spot at 5Hz. The levels of each of these waves was tweaked later, in Audacity.
One idea (on another note) I had was to run the audio data through Eureqa. Then Eureqa would figure out a set of sums of sines, which can easily converted to a series of frequencies and amplitudes. The problem with this is that it involves crunching millions of numbers in a genetic algorithm evolver - in other words, time and memory. I'm crunching away with the first sound file, my approximation, and it still hasn't gotten anywhere important. I'm using eight cores on this search, so hopefully it finds something. I'll let it run overnight, then check it again.
Another idea I had was to use a computational fluid dynamics program to calculate the fluctuations in water. I downloaded OpenFOAM and played around with it a little, but it seems a little bit low-res. I'm going to play around with it on a more powerful machine later today...
Another idea I had, crazy though it sounds, is that my estimated propeller sounds accurate. If that's true, then I'll just use that, but I don't want to sacrifice accuracy... How does it sound? It doesn't take into account things like the engine, so it should be somewhat heavy on the beat. My theory is that there is a powerful beat every time a blade passes the viewer. As such, in this example, the first audio clip would represent a 2-blade helicopter rotating at 150RPM, or a 5-blade ship rotating at 60RPM. I don't know how I would take into account things like cavitation... But one step at a time.
It includes a new waterfall diagram, which is fairly neat. According to the manual for a commercial submarine simulator, targets can be located by watching it's bearing change over time, figuring out the speed from the acoustical profile, combining the two gives distance, which can be a position and direction at a speed. Is there a cooler way to target torpedoes? Here's a screenshot of the new waterfall diagram, showing a ship as a dim thin vertical white band (the background noise is black):
Notice that the frequency profile for the ship is flat, from bottom to top. While the structure is in place for having a finite element analysis for calculating the ship noise profile, I don't actually know how to calculate the noise a propeller makes. It's harder than it sounds. I downloaded a neat little sound analyzer called Praat, which has support for all sorts of spectrograms. It hasn't led me to a solution yet, though. Below is my best attempt to imitate a two bladed helicopter in air using only sums of sines:
I know, it's not the best, but it's not all that bad. It has a mere four sine waves. Below is another audio clip that's a simple linear combination between 60Hz and 120Hz over the course of 30 seconds. To me it sounds like a propeller spinning up... Hopefully it's not just me.:
The second one demonstrates how you can (hopefully) determine speed from the spectrogram. This work is only for the propeller noise, so work will have to be done for the engines, the motors, the generators, arbitrary skin friction noise, and so on. One step at a time, I guess.
But, one step at a time as it may be, I still need to finish the first step. The first sound file is composed of four sines: 60Hz at 5dB, 160Hz at 8dB, 5Hz at 20dB, and 600Hz at -20dB. I pulled these waves from a spectrogram of a helicopter, and I just picked the first four strongest waves that seemed relevant to me at the time, and made up some other ones. In the original, there was a quiet spot at 5Hz. The levels of each of these waves was tweaked later, in Audacity.
One idea (on another note) I had was to run the audio data through Eureqa. Then Eureqa would figure out a set of sums of sines, which can easily converted to a series of frequencies and amplitudes. The problem with this is that it involves crunching millions of numbers in a genetic algorithm evolver - in other words, time and memory. I'm crunching away with the first sound file, my approximation, and it still hasn't gotten anywhere important. I'm using eight cores on this search, so hopefully it finds something. I'll let it run overnight, then check it again.
Another idea I had was to use a computational fluid dynamics program to calculate the fluctuations in water. I downloaded OpenFOAM and played around with it a little, but it seems a little bit low-res. I'm going to play around with it on a more powerful machine later today...
Another idea I had, crazy though it sounds, is that my estimated propeller sounds accurate. If that's true, then I'll just use that, but I don't want to sacrifice accuracy... How does it sound? It doesn't take into account things like the engine, so it should be somewhat heavy on the beat. My theory is that there is a powerful beat every time a blade passes the viewer. As such, in this example, the first audio clip would represent a 2-blade helicopter rotating at 150RPM, or a 5-blade ship rotating at 60RPM. I don't know how I would take into account things like cavitation... But one step at a time.
Sunday, April 3, 2011
We have a Website!
I finally put a website up! At the moment, it's still fairly hacked together. But, regardless, it's still there. Most of it I ripped from the SpeedSim website, so many thanks to them. Rest assured that the website isn't a replacement for this blog, but anything relevant to the end user will be down on the site. I need to figure out a good way to run the news... How is this normally done?
Here's a link to the website.
On a different note, I thought about licenses over the weekend, and I'm thinking that a MIT license would be good.
The sad thing is that this is really all I'm going to get done this week... *snif*
Here's a link to the website.
On a different note, I thought about licenses over the weekend, and I'm thinking that a MIT license would be good.
The sad thing is that this is really all I'm going to get done this week... *snif*
Thursday, March 31, 2011
It's Airtight Now
Alright, maybe it isn't quite airtight.
On my other computer, I started developing a moving map display. It's present in r13&14. r13 lacks some required images, but r14 includes these images. It's a little bit simplistic at the moment, as shown in the screenshot below, but you can switch back and forth to periscope view by pressing the 'L' key.
Man, I'm loving this screenshot feature! Why didn't I do it sooner?
On a related note, I'm working on a contour map generator. It's not in the repository yet, but it will be soon. I'm considering moving it into the Blue November core engine so that it'll be generated automagically at runtime, but that's a ways down the road.
As predicted, it's been a slow week, just like last week. Next week will also be slow, since I'll be at a robotics competition for half of the week. The week after will be much faster.
Stay tuned :)
SVN r15 fixed bug 3220471. That bug is the one which reported major memory leaks. These leaks have been tracked down to the Python modules, and dealt with. These memory leaks are no longer detectable.
On my other computer, I started developing a moving map display. It's present in r13&14. r13 lacks some required images, but r14 includes these images. It's a little bit simplistic at the moment, as shown in the screenshot below, but you can switch back and forth to periscope view by pressing the 'L' key.
On a related note, I'm working on a contour map generator. It's not in the repository yet, but it will be soon. I'm considering moving it into the Blue November core engine so that it'll be generated automagically at runtime, but that's a ways down the road.
As predicted, it's been a slow week, just like last week. Next week will also be slow, since I'll be at a robotics competition for half of the week. The week after will be much faster.
Stay tuned :)
Subscribe to:
Comments (Atom)