Forums are up and working at the new site now:

http://speedboatsim.com

Anyone interested in this project can register and sign up for the forum. I'll try to figure out a way to send everybody there an email when it's released so you're among the first to know.

Ok, how about this one?

Can I ask you guys which engine sound you prefer? The red boat or the blue boat? Neither one is really a set of recordings from a 2-stroke outboard, but these are my only options right now so it'll have to be one or the other.

Not for the first release. If sales are good enough I would like to do that, but would want to do it properly with a good fluid dynamic simulation. I wouldn't want to fake it with some cheesy wake effect. Doing it the way I'd like is a tricky issue though because you need an enormous computational mesh (major CPU or GPU hog, and the frame rate is already pushing the limits on the Oculus Rift with a 680X card). I have some ideas for this but won't know what's really feasible until I try them.

Thanks, guys. I'm having fun with it.

Features: I'm trying not to get too carried away there. It's easy to fall into a never ending trap of adding new stuff and never releasing anything. Got to pick and choose carefully.

Forces view showing aerodynamic and hydrodynamic force vectors. This also shows a blue outline where the boat touches the water to visualize the wetted surface area of the hull. This is handy for tuning the hull shape to get it really flying.


http://www.performancesimulati ... /boat-sim-forces-view.png

Showing off the new instrument panel and some of the dynamics resulting from extreme engine trim and jack plate adjustments.

There's no way I could ever make physics that good.

VRC- I quit the project almost a year ago so can't say (hence the boat simulator now). My guess is that it would be a major undertaking mostly because of how the GUI works. They'd either need it to operate on your monitor while you're in the car setup and menus and so forth, then change to Rift mode when you get on the track, or the whole GUI system would have to be completely rewritten from scratch, something that probably took a year or longer to do the first time around with all the redesigns and so forth. That would be a major undertaking at VRC, and with the internal dynamics of the company itself it would just drag on and on forever. I'll be surprised if VRC ever has Rift support. They want it, but wanting it and getting around to doing it are two different things.

Another issue you pointed out too is the pixelation and the size of the cars. I have a Z800 headset (an older VR head set with two physical screens) that didn't seem to have as much pixelation as the Rift which could run VRC. It was cool, especially seeing the car rotate in front of you on the pit table a foot or two from your face, but as you suggested, the typical view is "big track, tiny cars" which needs that to be a lot better than it currently is. I think with the Rift in the current state you would barely be able to make out the cars. They'd be little colored blobs of a few pixels most of the time probably.

I could be wrong, but even if the Rift was perfect in that regard I don't think you'd see Rift support in VRC for years to come. Without airing any laundry, there are reasons I finally left the company.

Sinbad: A guy I'm talking with is doing a nice looking fishing game:

http://forum.unity3d.com/threads/wip-the-angler-game-first-person-online-fishing-simulator.282584/

Ah, I suppose you'd need a motion platform for that. A couple people have asked for it. I don't know yet, we'll see. It'd sure be cool.

Here's a new vid: https://www.youtube.com/watch?v=Os07IiyGYnA

Yep, it does it.

https://www.youtube.com/watch?v=qKTXxzPPMo0

Yes, that's been my thought exactly. One version that runs live like the videos, but then another one that spits out samples. I've had a couple indie developers express interest in that.

This actually runs on the graphics card if you can believe that. It's all done with a compute shader, otherwise there's just no way to run that in real time with somewhere in the neighborhood of 40 billion computations per second. A single core on a CPU last time I checked did maybe 1.3 billiion, so it's on another level computationally speaking. I was amazed that it actually ran with the boat simulator on top of it:

https://www.youtube.com/watch?v=hAO7SMqUfI0

It's a cool concept, something I thought of almost 20 years ago but didn't have the programming knowledge to pull off back then. I've done several CPU experiments over the years trying different ideas. The ultimate was to try bunging it onto a compute shader so it'd run on the graphics card like this one. Last summer I succeeded, but unfortunately it's still a bit too resource heavy. It's doing almost nothing on the CPU itself other than copying a small amount of data to the sound buffer now and then. Depending on how much you're doing, using the graphics card can mean cutting into the frame rate pretty badly.

So it was pretty close, my best attempt yet probably, but fell just a bit short on the audio quality and computational resource side unfortunately. As graphics cards continue to get faster, one of those problems will fix itself, but the other will take some more thinking and work. In the meantime I've decided to just use samples for the boat sim. Maybe some day I can improve the other thing to the point where it could be used for professional audio like you said. Given the cost of audio production (especially recording samples), there's got to be some money there. Someone suggested I just keep the tool to myself and produce sound files to put on the Unity Asset Store and so on.

Anyway, I'm not happy enough with the quality to go there just yet. Maybe some day.

FMOD: What I liked about this, at least in regards to Unity, is that once I learned more or less how the system worked I was able to drop in Greg's audio just as he'd produced it. This is really nice from a workflow standpoint because if a guy sends me something new, it just takes a few minutes to get it in and running exactly as he designed it complete with the cross fading and everything. I have no idea what it's like to actually do that side of it though, I've not used the designer for anything myself other than to tweak a volume blend or something.

Keep in touch on the audio. If you come up with something, even months from now, it'd be nice to hear about it. You never know...

Interesting. I don't do a whole lot with samples myself. I helped out with the ones for VRC/VRC Pro years ago which weren't exactly award winning, but did the job well enough.

Did you ever see my procedural audio stuff?

https://www.youtube.com/watch?v=vKnfO3LFPls

This is all running in a compute shader and is a real time engine simulation. The gas dynamics in the exhaust system produce the sound directly. Unfortunately I can't really get away with doing the 40 or so billion computations per second on top of a video game. It works, but it hits the frame rate and unfortunately at this point, I still think good professionally done samples still sound better. Maybe some day, but it's not ready for prime time yet, sadly. Shame really, good audio is expensive and this would have really cut down on costs.


Do you play with FMod's engine sound designer by chance? If you can produce some good audio mixed up with FMod that isn't ripped from another game, I might be interested in buying it. Right now I've got Greg Hill (iRacing and others) doing the audio, but more samples might be welcome if the price and quality is there. It's a thought anyway, if not now, you could shoot me an email a few months from now if you get the bug to give it a shot. Good audio to me is extremely important and ranks right up there with physics.

I'd be interested in hearing what you did with the GPL samples either way if you feel like sharing. Of course I won't use anything you send me without your permission, even for a video.

Thanks, guys. For sound, my ideal would be this:


https://www.youtube.com/watch?v=0rebIoTEJDI

https://www.youtube.com/watch?v=iDtb-QNeekw

https://www.youtube.com/watch?v=57CXKOCWvVI

https://www.youtube.com/watch?v=nHSQj-F-fpw

F1 outboard engine on a dyno:

https://www.youtube.com/watch?v=XZkxJJrB9ZM&index=7&list=LLJPkUELk8PSyAIioegAVS7g


I just love the 2 stroke V6 outboard sounds because they sound like they rev to the moon since there's twice as many exhaust pulses per second as there are with a 4 stroke. As a kid, my family had a Merc 175 HP that snapped and snarled a lot like the ones in a couple of the videos above. This was on an 18' custom Switzercraft that did a little better than 60 mph. Back then they didn't have 4 strokes. Those just sound boring in comparison. Ideally we'd get a Mercury 300 XS (2 stroke) recorded.

This is an exciting one too even though they've got music going on top of it:

https://www.youtube.com/watch?v=gUWJGQp062M


Bose: What are (is?) Fanaleds? Are those for the F1 style rev LEDs people make that go above the steering wheel? If so, that's an interesting idea indeed.

Sinbad: Ha! I hadn't seen that one. My friend had an Amiga for awhile when we were kids, they were really amazing at the time. Our favorite game back then to play on it was probably Jet.

Not just yet, it's too soon!

Quote from BigPeBe :

As a sound guy I must pick on this one, looking from the video you posted the pitch of the engine sounds are wrong. It sounds like the engine is doing 2x the rpm the tachometer shows.

Still interesting project, I'm not into boats really, but gotta admit when the Oculus consumer version will be out I might be tempted to try this out.

Good ear. It's actually sped up 50%.

What I've got here is a V8 4 stroke sample when I really need a V6 2 stroke. The main frequency of a V6 2 stroke is 50% higher than a V8 4 stroke, so it's sped up to fit. 2 strokes really scream.

I'm awaiting a proper 2 stroke V6. If it comes through it'll be replaced with a totally different sound.

Haha, right? Yeah, it doesn't feel connected to the track at all either.

Hi, guys. I thought there might be a few people around here that might find my latest development project interesting. Something a little different, anyway. It supports Oculus Rift and triple monitors as well.

http://speedboatsim.com

There are a couple Rift videos there for anyone that's got one, starting with this:
https://www.youtube.com/watch?v=rOxXjc8D3RM

If this might be up your alley at all, let me know what you think.

Last edited by jtw62074, Wed, 17 Jun 2015 09:02.

I'm a bit late for the thread, but that's good stuff, Scawen. My only time in a race car was a few laps at the Indianapolis Motor Speedway in an old Indycar with a weaker engine for public use.

http://www.youtube.com/watch?v=4V8Sz3PKLI4

Believe it or not, that's about 130 mph right there. After this was a ride in a 180 mph two seater with Arie Luyendyk Jr. driving. Great fun.

Ahha, I understand totalFitness as you're using it now. Thanks.

Getting rid of the population or stopping the mating isn't really necessary. That will happen just by chance anyway the way you're doing it. Nevermind what I said, carry on.

I'm still not following you on totalFitness of the group as a whole. Generally what you do is have a fresh population within a generation derived from the previous one. A "total fitness" of the whole population in a generation is kind of meaningless because what you're really interested in is the fitness of each individual member of that generation. If Bob, Tom, and Bill are competing for the #1 spot in a mating game and score like this:

Bob = 10
Tom = 5
Bill = 1

Those are the fitness scores, one for each member. Who cares that the total score is 16? What you want to know is that Bob is the best, Tom is next best, followed by Bill. Maybe Bob gets to have 2 kids, Tom has 1, and Bill goes home alone. On the next generation, Bob, Tom and Bill are all gone and removed. Only their children survive and reproduce again. What does it matter that their children all added together score 12 or 1049? The best ones of that group are the ones that get the mating chances regardless of the group total score. So yeah, I don't really understand why the totalFitness of the group is even there.

Anyway, good to hear the k1/k2 thing worked a little better at least and got you through turn 1.

And following that thought, this is where particle swarm helps. The offspring will almost certainly not be what they were shown there. Instead all the k1 and k2 values will just deviate a little bit from what they were before. For instance, there's really no mating or crossover. Instead the amount that each agent's k1 or k2 value changes is controlled by the fitness score and a simple computation, basically. (Think of k1 and k2 as having "velocities" which are just the amount that those values will change. Each agent has its own velocities that are adjusting in a way to chase the best agent that has existed so far throughout history, basically).

So while you started with these two:

k1[0] = 1
k2[0] = 10

k1[1] = 2
k2[2] = 20

Let's just pretend for a second that the best k1 value was actually 1.5, and the best k2 value was 15, but the population hasn't figured that out yet. You could end up with these two as the values swarm around on their hunt for those optimums:

child.k1[0] = 1.1
child.k2[0] = 12

child.k1[1] = 1.8
child.k2[1] = 18

They don't get stuck waiting for a mutation, instead they have a good probability of progressing in the right direction immediately.

Here's another issue with using the DNAStrand type of approach. Here's my example again but this time using k1 and k2 values:


So here we're doing it your way instead of at the bit level to show a potential problem. Suppose we mate these two guys together:

k1[0] = 1
k2[0] = 10

k1[1] = 2
k2[2] = 20

I can't tell for sure from your code, but you might want to check to see if all that is really happening here is that you're just swapping the k1 and k2 values back and forth. I.e., you could end up with these possible children:

child.k1[0] = 1
child.k2[0] = 10

child.k1[1] = 1
child.k2[1] = 20

child.k1[2] = 2
child.k2[2] = 10

child.k1[3] = 2
child.k2[3] = 20


And that's it. Do you see a problem here? The only possible values for k1 are 1 and 2 for the children. Same goes for k2 where the only possibilities are 10 and 20. Sure, you get a unique child, but the gene is at such a high level that the steering response to cross track distance is not changed by breeding. The only way k1 could become anything other than a value that already exists in the gene pool is for a mutation to happen and that can take a really long time. That's probably not really what you want. You want k1 to be determined at a deeper level than that so the children might have a value of 1.5 or 4 or something.

In other words, k1 might be determined by more than 1 gene. It's a combination of genes that determines the steering response to cross track distance rather than just one gene. That's where the bit level stuff comes in. In my neural network approach to this, that's indeed what would have happened had I used a genetic algo instead of particle swarm. The genes were the links themselves (lots of them) to determine the final k1 value. So two parents with a k1 value of 1 and 2 would not be very likely to actually produce an offspring with k1 of 1 or 2.

Granted, your way might still work, it just might take a lot longer. I'm not entirely sure. I wrote a few little virtual creature simulations in a manner similar to yours where the genes were things like attack speed, metabolism, eye sight distance, and so on. When I mated them I split the whole structure up, like taking the first 5 numbers (bytes in my case) from one parent and inserting them into the beginning of the other parent. This way the child was really half one parent and half the other while the basic sequence was preserved. There wasn't a hop skotch game going on with the gene swapping where one parent gives genes 2,5, and 7 on one turn while on another it gives genes 1,2, and 3. I'm not sure if this really matters, it might just be in my head. Your way might be doing the same thing or it may be equivalent in the end anyway, I'm not sure. Just wanted to throw that out there to spur some more thinking.

Last edited by jtw62074, Mon, 23 Jun 2014 15:00.

Quote from blackbird04217 :

The input was essentially the t, interpolating between the outputs for reference point X and X + 1, and the out puts was -1 to 1 steering and -1 to 1 throttle/brake.

So you're determining throttle/brake and steering only from the t value and nothing else? Correct me if I'm misunderstanding, but I'm getting the impression that the t value is just how far along you are along the curve. The point behind you is 0, the point ahead is 1, if you're half way between then t = 0.5. Is that correct?

If yes, how is "I am 50% of the way to the next point" used to determine whether to turn left or right, let alone tell it how much to steer or brake or whatever? I can't imagine how that would be enough information. This is what I mean by it wouldn't really matter if the real value was 51% and you came up with 50%. An AI can't drive a car by only asking if the gas cap is open or not.

Quote from blackbird04217 :

Maybe I'm being pessimistic, or silly, or thinking wrongly about something but I feel that steeringOutput computed this way is somewhat using logic to do so. Although there are no if (leftRightDistance > k1) like I was writing before, the if statement is slightly hidden when leftRightDistance has negative/positive values.

Call it what you want, but this is how all controllers work, more or less. You have input variables and a function that produces output variables. I would not call it "logic" until you have an "if" or other logical statement in there (and/or/xor/etc). Using an equation like this is different because the value starts at 0 when you're at 0 distance and velocity and increases (rather than jumping suddenly) as those values increase.

There is such a thing as "fuzzy logic" which might be more intuitive for you and worth a look, but those are more suited to "expert systems" and aren't particularly well suited to problems like AI car controllers (maybe good for parallel parking, but that's probably about it). You'll end up back in the same boat where you're hand tuning numbers, only a lot more of them this time. Walk before you run. These aren't systems that learn on their own normally anyway, but there's no reason they can't be trained by neural networks using genetic and particle swarm algo (or whatever else). Anyway, this would be getting ahead of where you are right now I think.

Quote from blackbird04217 :

The population runs for a generation, and before spawning the next generation compute the totalBestFit by adding all the fitnesses up. This allows me to choose chromosomes randomly, while giving the 'better' genes a better chance to spawn again. I do not remove chromosomes once selected, so ultimately it could be selected several times, I was unsure on this detail, but it makes sense to me that it would remain in the pool.

If we had a population of 4 chromosomes, with the following fitness:

A: 60
B: 32
C: 5
D: 3

Then total fitness is 100, for simplicity. A then has a 60% chance of being selected each time the GetRandomChromosome() is called, which it will be called 4 times. B has a 32% chance, and C and D are fairly small. This means A and B are more likely to spawn again, and then possibly crossover, and possibly mutate....

This is how I understood the genetic algorithm / process to work. Let me try real quick the way you mentioned above using only 2 genes, to modify k values

Total fitness of the population? You're trying to evolve one good car, not a whole population of them. Survival of the fittest. Let the bad ones die with no chance of reproducing. That's how real evolution works.

Imagine if you had a generation of 10 cars, 1 by shear luck drives really well on the first generation and the other 9 are crap. What you want is that really good car to survive and mate (even better if it mates with another really good car probably, possibly several times with different mates). You don't want that really good car to get lost just because the total fitness of some other generation was better, which really just means the average car in that group was better than the average car in the group before it. You don't want a good average car in a good average group, you want the best car that has ever lived, period. I think you might actually be breeding between generations and that might be part of why they're getting stuck. That stops evolution.

Following that, normally what you'd do is score each individual car. I wouldn't add up the fitness scores to get a total like you're doing. Instead in your example where:

A: 60
B: 32
C: 5
D: 3

This just means A and B have the highest chance of reproducing, or they mate more than the others or something similar. You could just take the best 50% of them (or whatever fills your population), mate them with each other, then throw the rest away. That's what this is modelling about evolution: A group of animals where only the fittest get to reproduce and the rest die off along with their particular gene combinations. The dead ones that didn't get a chance to reproduce don't get any further contribution to the gene pool. You just do it in a way where the population stays the same every generation, but it's important to let the old ones die. You don't want the bad creatures to reproduce.

With the 4 car example there, you want to produce 4 new cars. You could do that several ways, up to you. One way would be to mate the best 2 together to produce 1 or 2 or even 3 cars (high birthrate, these are horny cars). Maybe your percentage chance stuff is actually working that way, I'm not sure, but the idea is to lose C and D entirely and replace them with something better. Hopefully A and B or B and C make something even better than A.

Anyway, just sit and think about fixed sized animal populations for awhile. That's how this idea of genetic algorithms came about.

I'm getting the impression you might not quite be understanding what a genetic algorithm is. Forgive me if I'm wrong about that.

The idea generally is to change a value at the bit level. For instance if you had two parent values of 500 and 480, they are as follows in binary:

500 -> 0000 0001 1111 0100
480 -> 0000 0001 1110 0000

You then mate them by picking a point to splice them together which is essentially how DNA splicing works. If we picked the center in this case the child would become:

0000 0001 1110 0000

In this case the result is also 480 just like one of the parents, so whether the value becomes unique or not and different from either of the parents really depends. If instead the splice was done on the last 4 bytes you'd get this:

0000 0001 1111 <splice point> 0000

Here you get 496 which is between both parents and unique to both. This works well if you're homing in on a number between the parents, but if the number you really need is 29000 or something, you're going to be stuck waiting for a random mutation to just happen to land you in a better spot. That could take awhile. If the splice point is itself random, you've got 32 bits here to play with so in order to flip the first bit and get this:

1000 0001 1111 0000 -> decimal = 33264

...you might have to wait 32 * chancesOfAMutation generations to even see a number anywhere near that 29000 number that you really want.

Might you instead be doing it at the 32 byte boundaries, something like the following?

struct DNAStrand
{
float floatValue1
float floatValue2
.
.
.
}

And then create a child DNAStrand by mixing floatValue1 of parent 1 with floatValue2 of parent 2? If so, even though you may get a unique child now and then, floatValue1 and floatValue2 don't ever change except by mutation. In that case you aren't getting as much variation as you could be perhaps?

Anyway, there's a lot of things like this that could be going on in your simulation. Without more specific information or code, there's not much more I can say.