Playing with Unity
Scott Przybylski last edited by Scott Przybylski
I was inspired by Design it, Drive it: Speedboats. I learned that he used Unity to create that game.
I had a long holiday weekend to play around with Unity myself.
I found an awesome tutorial on boat physics in Unity: http://www.habrador.com/tutorials/unity-boat-tutorial/2-basic-scene/
I started porting some of my code for driving the boat from Torque 3D into Unity. Spent some hours tweaking a collision mesh to be used for the buoyancy / other forces calculations.
So far I've found Unity to be much easier to use than Torque 3D was.
The blue around the bottom of the boat is the collision mesh that is currently in the water.
Unity is really great. I've played with that buoyancy setup before. I'm pretty sure that's what Todd Wasson used for the speedboat sim, or at least something very similar.
Nice, I remember you made something in Blender's game engine also. We gotta start collaborating. I'll probably push what I have made so far to a bitbucket repo soon.
Right on. Hit me up whenever. I'll get bitbucket setup again and check it out. I had started to make a really simplified game to see what I could come up with the last few weeks.
Hey, guys. I heard somebody click on my website somewhere around these parts. Hope you don't mind me popping in for a quick comment or two.
Looking good, Scott. Happy to be of some inspiration. I remember you in the WSC forums years ago with your rFactor Hydroplane mod. It looked well done and fun although I never tried it myself. I thought of you a couple times when I started on DIDI Boats two years ago though.
Regarding kallen's comment: No, I'm not using any scripts from the asset store or anywhere else for "Design it, Drive it : Speedboats" having anything to do with physics. The physics side is all custom code written by me. (I've been writing physics engines/models for at least 16 years now depending on when you want to start counting, mostly for cars).
The scripts/classes you're likely to find on the asset store are usually fairly simplistic in that they usually only compute buoyancy force and nothing else. From what I've seen they usually appear to be designed for objects that just float and bob in the water without moving very much. At best some of them seem to handle big, slow ships pretty well, but that's about it. The trouble with them is that buoyancy force with high speed boats is not a significant factor once the boat is moving much beyond a crawl, so any system designed with nothing but buoyancy in it isn't going to be any use for high speed boat sims. (My system doesn't even bother computing buoyancy forces anymore beyond a certain speed, it matters so little). Because of this, you'll probably find that you've got to write your own physics code to handle hydroplanes convincingly.
I've been writing a new mesh generation system for tunnel boats, the next thing I want to get into DIDI Boats. Players can design their own boats with this right inside the simulator by playing with the hull design parameters. Here's a procedurally generated mesh from the new system:
Just had a look through the tutorial you posted. That's a very good one that'll take you a long way. He gets the other stuff besides buoyancy in there, should be good for hydroplanes.
Thanks for stopping by, yeah I remember you from back in the WSC days, I think you showed me a video of a jet boat sim you were working on. Holy cow that's a lot of triangles on that tunnel hull! Is that the mesh you're calculating all of the forces for?
That tutorial is pretty good and it actually seems to work fairly well for a hydroplane. I just started adding some aerodynamics simulation for all the airfoil and the rudder/skidfin. These boats really are more of an airplane than a boat.
Would you mind if I asked you some physics questions? I've been a bit stuck with the engine/prop simulation, I think right now I've got some weird combination of car and plane stuff pulled from books and online sources. For some reason its extremely difficult to find any info on properly simulating boat propulsion.
Thanks for all your hard work making DIDI Boats, it's about time someone's made a speed boat sim (just wish it had multiplayer ).
Jet boats: Nope, I was doing RC cars at the time. Wasn't dealing with boats until about two years ago when I started DIDI.
Meshes: There aren't that many triangles in the physics part of it. There's no way to compute that many outside of a compute shader probably. The vee bottom boats currently in the sim are much lower poly, I think it's around 800-900 if you ignore the engine and seats, driver, etc.. To get it to do that many without hogging the whole CPU for physics on one boat required a lot of optimization.
The new system I wrote to do the tunnels (and whatever else down the road if I don't go broke first) is all generated from spline patches so I can just output the meshes at any resolution desired. The plan is to generate a low poly invisible one for the physics while the graphical version goes high poly on it. This way the physics model still matches the visual representation pretty closely and follows the players' design.
Fire away with the physics questions. I'm not sure if I'll get to doing hydroplanes ever (boat sims don't sell very well unfortunately). If I do it probably won't be any time soon. I just have a torque/rpm curve scaled with throttle position on one end and the prop torque feeding back into it on the other. The engine rpm just goes wherever it wants from there. My prop is modelled the same way the rest of the boat is: Triangles. The prop is solved at a much higher frequency though, would have to check but think it's 800Hz or so. Since they spin so quickly you have to be careful not to get strobing effects where the prop rotates exactly one time every frame and that kind of thing.
Oops, I guess I got you confused with someone else from the WSC forums. I do remember the RC car sim.
Are you actually spinning a joint and calculating the forces for the propeller blades?
One of the issues I was having was how you'd calculate the engine rpm from the load on the prop, when its submerged its going to spin a lot slower than when its out of the water.
ToddWasson last edited by ToddWasson
Yes, I'm spinning the propeller and calculating the forces on the individual propeller blades. The torque that fights back against the engine torque is computed from those forces. So I have two torques:
- Engine torque
- Prop torque
Angular_acceleration = (Engine_torque + prop_torque) / moment_of_inertia
(When accelerating, the engine torque is positive and the prop torque is negative, or vice versa depending on your coordinate system). Now that you know the acceleration, you can compute a new angular velocity (rpm). The rpm then increases or decreases due to the torques acting on it and nothing else, just like how it works in reality.
These two torques are analogous to a car tire where the engine is applying one torque while the slip ratio causes an opposite torque unless there's no friction at the tire. The engine then accelerates however it wants to. You don't really compute the rpm directly from other variables, instead you compute the acceleration and then change the rpm each step from that.
By doing the forces and torques at all the blades separately, I get all the nice effects from engine trim and so on because the angle of attack on the individual blades is changing as they rotate if the prop isn't lined up with the velocity vector (say it's trimmed up or down or steering). Trim the engine up and the bow lifts, etc.. This all feeds back into the force feedback too along with the aerodynamics and hydrodnamics on the engine itself so you get some interesting effects there.
Windmilling works too. If the prop is partly surfaced, the blades remaining in the water tend to pull the back of the boat in one direction which requires a steering correction.
Real boat racers are loving it. I've got at least two Formula One boat racers and a bunch of F2 and F3 guys, a smattering of others. Unfortunately there just aren't very many of them.
OK interesting, are you just calculating lift/drag for each propeller blade or are there other forces at play there?
I found this http://www-mdp.eng.cam.ac.uk/web/library/enginfo/aerothermal_dvd_only/aero/propeller/prop1.html it's got equations for lift, drag, thrust and torque for a propeller blade. I'm not sure what dr is, it looks like the area of a section of the prop.
Yeah, racing sims are a niche market and boat racing isn't really that popular, sadly combining the 2 isn't exactly gonna make you much money. I don't intend on selling anything, this is just a hobby for me. Pretty cool you've had some real boat racers play it. We've had some hydroplane drivers play with the HydroMod, it's not very realistic though, just a bunch of odd handling cars on a really bumpy track.
I'm using pretty much the same thing for the triangles in the propeller as I am for the triangles in the rest of the boat. There is a bit extra there to get the prop torque back out of it and that kind of thing, but it's the same physics.
What I'm computing is quite similar to the first tut you posted in the original post: A normal force from dynamic pressure that's perpendicular to the triangle, a buyoancy force which acts upwards, and a skin friction force which acts along the plane of the triangle which is quite similar to the one in the tut you posted. I use different lengths than the tut though, but it's fundamentally the same concept.
I have just one coefficient for each mesh that I can use for tuning the forces, otherwise the front of my outboard engine block creates too much drag. Think that's set to 0.5 but am not sure now. Everything else is just set to 1.
For the prop I skip the skin friction friction force which is an expensive computation because of the power factors and the buoyancy is skipped too. So there's just one normal force computed at each triangle in the prop. I just have two triangles per blade right now, one facing forward and one facing rearward, so only one or the other is computed depending on whether the prop is spinning faster than the water flow or slower than it.
Lift/Drag are just two components of the normal force. I don't compute them seperately from coefficients and add them together to get the normal force, instead I just compute the normal force directly which captures both. This probably wouldn't be the best for doing a flight simulator though because a wing at high angle of attack done with this approach wouldn't stall, for example, but for a boat it works just fine.
You could do the prop other ways instead of course including using something like the tut in your last post or just using an empirical curve fit (something like Pacejka's Magic Tire Model but for props). The trouble with the empirical approach is used have to find prop data, much like with a tire model you have to find tire data. I just figured I'd try the prop as a handful of triangles to see if it worked and it did pretty well. It's not as efficient as a real prop though since they're basically just single triangle blades cocked at some angle, but it works pretty well anyway. I have to angle the blades more than they should be to achieve a given pitch which has some consequences of its own, but all in all it's close enough to be pretty convincing anyway.
Hydroplanes: I've had a few requests for them so might add them at some point, but it won't be anytime soon. Because the boats are done procedurally so the players can design the hulls themselves, adding a new type of boat is a huge amount of work. I think I spent five or six weeks on that new mesh system including a good week or so just trying to get vertex welding to be as fast as it could be (ended up with a 50,000% speed improvement) and just yesterday started the work of trying to get the tunnel into DIDIBoats. I'll have to rethink some of how the rest of the game works to accomodate the new system, so this first one is taking awhile. After that I don't know how long it'll take to add a new boat type. Hopefully I can do this in a way that minimizes it so I can focus more on cranking out other types of boats before I go broke and have to move into a van down by the river.
One downside to doing the prop the way I'm doing it is that the inflow isn't handled like it is in the last link you posted. As a result of that, if the boat is sitting still and you jump on the throttle, the prop doesn't slip nearly as much as it should. It just lumbers forward from low rpm like a truck. Once you get planed out and up to speed the prop slip is in the right ballpark, but because the waterflow forward of the prop isn't being accelerated, it doesn't work well at low speed.
You don't get any ventilation or anything like that either which kind of sucks. I tried hacking something like that by trying to compute an inflow speed, but nothing I tried worked very well. Might give that another try someday.
Anyway, point being that there is a lot to be desired yet with my prop model. You can't go too crazy though on a per poly basis, it's expensive since it has to be computed far more often than the rest of the triangles. If I had only a few triangles per blade it would be as expensive as the entire rest of the boat even skipping the buoyancy and much more expensive skin friction drag computations. Doing something even more comprehensive like what's in your last link might require a supercomputer.
Ultimately what I'd have liked to do is compute all of this in a compute shader which is insanely fast. The trouble with that though is you have to read back the force data from the GPU, and the first time you do that each frame takes forever. Last time I tested it on my 680X GPU, reading a single float back took about 0.01 second which limits you immediately to 100 fps, and the CPU is just sitting there waiting the whole time. It doesn't matter a lot how much data you read back, but that first GetData() call in a given frame takes absolutely forever. After that you can do more GetData calls and they're super fast.
If it didn't lock up like that on the first call I'd have just done it in a compute shader. You could probably do tens (if not hundreds) of thousands of triangles this way and it wouldn't even be using the CPU. It might come for free.
I did this in a compute shader (there are more vids of other engines on my channel if you're curious):
This is a real time gas dynamic and engine simulation. I think most of these were running 256 cells per exhaust pipe and the time step was something like 1/480,000 second. So 480,000Hz, compare that to the typical Unity game running 50Hz. One of these was running 43 BILLION computations per second which would normally require about 40 CPU cores to do in real time.
Just over two years ago I turned it down a bit and got it running in the boat sim and it actually worked: https://www.youtube.com/watch?v=hAO7SMqUfI0
It didn't sound good enough for my liking though, that and it was a huge resource hog so I ended up going with samples like everybody else. But anyway, the point is that a compute shader can do stupidly massive computations in parallel, far far faster than a CPU on problems like this so I really wanted to do the fluid dynamics on the boat this way. Until that data readback can be made faster though, it's too much of a killer to do it. Maybe some day when graphics cards are faster on this end. We'll see.
OK, that's interesting, I didn't think of just using the same forces being applied to the rest of the hull. I'll have to give that a try, will probably take me a little while to get this sort of thing setup. I've been playing around with the aerodynamic forces a bit, I'll need to make another video soon, its fun trying to fly the boat with the front wing without flipping over.
That's interesting about the compute shaders. I know reading data back from the GPU has always been an issue.
The audio simulation is pretty cool, reminds me of the old racing sim Live For Speed, I'm pretty sure they did the same sort of thing.
Tunnels are released: http://www.youtube.com/watch?v=5c61WcnVwec
That looks sweet, hopefully I'll have some time this weekend to hook up my wheel and try it out.