One of my projects involves a motorized boat on a river. I want it to respond to the current speed and direction. Currently, my idea is to break the river surface up into pieces that allow me to give each piece a different texture name, then I check which texture the boat is on, and it sees the current data that way.

But, I downloaded and messed around with the Crane demo and just wonder if I'm trying things the hard way. Do you think A6 physics would make a realistic boat in a river current?

I've only got the commercial version, right now.

Thanks, Ron

While it can be done, I don't think it is hardly the easiest way to do it. I don't think it would be possible with commercial though either. Simulating fluid dynamits is hard. It is even hard for software which is set up to calculate a short segment of time over a long period of time (determine what will happen when a landing craft hits the water at 50 mph...that 30 second or so time period takes well over a days worth of CPU time, and is still inaccurate).

You should be able to "fake it" some and get satisfactory results using the method you are persuing right now. This post touches on some ways to use the physics engine with water though.

http://www.conitecserver.com/ubbthreads/showflat.php?Cat=&Number=288647&page=1&view=collapsed&sb=5&o=&fpart=1

actually this isn't a bad way to fake it. You would program a diffrent texture name for each segment, say n1000. the first part of the name gives you direction, teh second the magnitude and then you add a force in response in response to the texture name.

Sounds ez to me. Just make sure to make the segments large with respect to the boat model and it should work pretty well. You could do smaller segments, but you'll likely experience very jerky accelerations.

Neat idea!

If I understand you right, this seems like the eziest way to do a river using the 3DGS A6 PE.

If you do not have breaking waves or other mesh deformation then this should be easy to do. I don't think using different textures is very efficient. How about using a default direction for your river and then place some invisible marker objects that player collides with to change directions and such. But that will depend on what you want to achieve in the first place.

Thanks for the ideas.

It's not a white-water river I'm trying to simulate, but something smoother, like the Ohio River. We regularly put boats on the river in my town and there are many things you must watch for when on moving water. There's laminar flow, eddies behind bridge columns and shore coves, dam boils, strainers, standing waves (just above rocks) etc. I would like to simulate the way a boat responds to river current. It is very interesting to operate under such conditions.

The direction of the current could change drastically - 180 degrees with eddies and boils, but I do like the method mentioned of using markers rather than textures. It even seems that there might be some use here for a State machine AI. There really wouldn't be much mesh deformation, as all movement would probably be accomplished with animated textures and u,v, animation.


Regards,
Ron

The quickest solution (from the scripting side) would be to use "trigger volumes" to mark the eddies and things. But, from a level building and game play side, I like the idea of using textures since I imagine these water features would have different textures/animations so the player could identify what sort of behavior to expect (i.e. white-water, reverse animation, etc.).

Going from the top of my head, I would have the boat scan for the texture, look up that texture in a list (maybe just use the first letter in the texture name to make things quicker), and then use the physics values stored in the list for that frame.

Thanks, Doug. You're exactly right that different parts of the river would have different texture animations. I also plan on offering the player a top-down view along with a 3D view to navigate the river. I didn't even think about just checking the first letter of the texture name to speed things up.

fastlane, I forgot to reply about something you mentioned earlier. You mentioned how the changes might appear jerky as they change. I'll offer something I learned in another project where I had a character walking through rooms full of smoke. As they got closer to the fire the smoke would become denser, and less so as the walked away. I used the floor texture of each room to determine it's smoke density, and the room's smoke density affected a global smoke density. But, I just smoothly ramped between different values like this, and it was virtually unnoticeable:

Code:

---

 
if(room_smoke_density > current_smoke_density)
{
     current_smoke_density += .01;
}
if(room_smoke_density < current_smoke_density)
{
     current_smoke_density -= .01;
}
 

---

I put this inside a while() loop.

Thanks, Ron

Ramping is nice.

Essentially it's an outside interpolation routine controling the smoke. You can definitly smooth the motion out, but my original warning was just the genral idea that if you nodes are too small (whether node is a certain smoke density or a river segment) then you won't be able to interpolate and jerkiness ensues.

All teh same, marcos ideas seems the best! It avoids having to make constant Trace_Texture calls. Much nicer!