Spring RTS Engine

I can imagine (someone doing) a map with two (round) pools and one with a different water height. But I also imagine terrain deformation would be turned off for that map.

I don't think that it would be done otherwise. Linking the pools with, for instance, a sloped trench, or a strait canal with a waterfall on the end, or maybe (I can imagine) an even more complex way, would cause very specific specific scenario's/terrains. All which would require different unit and water behaviour, it seems.

Another augment that speaks to my intuition:
Indonesia is a map, by Baracus, which was designed with the intention to let all available units in BA be able to join the battle. The water-levels are passable for most k-bots, yet still allowing the ships to sail there. Stuff like that.(There are some deeper areas where shipyards can be build.) I use to love that map, but no more . Because of the BAR Shiva (which I'll have to fix somehow I guess). Normally It starts swimming real nice when it hits the water. On Indonesia it doesn't know what's going on, water-depth wise.

I can imagine (someone doing) a map with two (round) pools and one with a different water height. But I also imagine terrain deformation would be turned off for that map.

I don't think that it would be done otherwise. Linking the pools with, for instance, a sloped trench, or a strait canal with a waterfall on the end, or maybe (I can imagine) an even more complex way, would cause very specific specific scenario's/terrains. All which would require different unit and water behaviour, it seems.

Another augment that speaks to my intuition:
Indonesia is a map, by Baracus, which was designed with the intention to let all available units in BA be able to join the battle. The water-levels are passable for most k-bots, yet still allowing the ships to sail there. Stuff like that.(There are some deeper areas where shipyards can be build.) I use to love that map, but no more . Because of the BAR Shiva (which I'll have to fix somehow I guess). Normally It starts swimming real nice when it hits the water. On Indonesia it doesn't know what's going on, water-depth wise.

ps.
Might be double post. first submit didn't seem to take.

I can imagine (someone doing) a map with two (round) pools and one with a different water height. But I also imagine terrain deformation would be turned off for that map.

I don't think that it would be done otherwise. Linking the pools with, for instance, a sloped trench, or a strait canal with a waterfall on the end, or maybe (I can imagine) an even more complex way, would cause very specific specific scenario's/terrains. All which would require different unit and water behaviour, it seems.

Another augment that speaks to my intuition:
Indonesia is a map, by Baracus, which was designed with the intention to let all available units in BA be able to join the battle. The water-levels are passable for most k-bots, yet still allowing the ships to sail there. Stuff like that.(There are some deeper areas where shipyards can be build.) I use to love that map, but no more . Because of the BAR Shiva (which I'll have to fix somehow I guess). Normally It starts swimming real nice when it hits the water. On Indonesia it doesn't know what's going on, water-depth wise.

ps.
Might be multiple post. submit doesn't seem to work.

if watermesh is like airmesh then "non-flat water" or "water on different levels" is the same.

smoth wrote:he has to check the depth below him by drawing a perpendicular line down from his body

no, that does not make sense.

The other thing is same as upright=true/false tag that already exists for ground units.

knorke wrote:

smoth wrote:he has to check the depth below him by drawing a perpendicular line down from his body

no, that does not make sense.

do tell a sensible version.

i did...
perpendicular from body does not make sense because think what happens if the swimmer is swimming up a 90° watermountain:
the line might never intersect with terrain, water depth=infinite?

where would that scenario make sense?

it is extreme case to show that your formula is wrong.
in less extreme cases it is also wrong but like this it is easyier to show why.

knorke wrote:Still do not understand why "Getting water depth becomes more complex esp at angles."

he may be thinking because you have two faces at different angles their distance at different locations has to be calculated. you cant simply use the nearest vertex locations..

but, how is it being done already? i doubt we are calculating between vertices of a face at the moment anyway, it would probably be nearest vertex height for speed reasons.. so I believe knorke would be correct.

Google_Frog wrote:One solution would be to create a general system as described by enetheru but then create maps, animations and gadgets which all assume the water map is flat whenever it is above ground. Anyway, angled water is not going to automatically look good.

It would take a ridiculous amount of work to make generalised water graphics which are as good as the graphics we currently have for flat water. It is unreasonable for the engine to detect the shape of your water map and deduce exactly how it should look like it is flowing.

It would be trivial to alter the existing water shader to make the wind direction effected by the surface normal. that way it appears that the water flows in a direction. and that's just to get started. i'm more worried about the shoreline part of the shader.

Silentwings wrote:I also can't see how non-flat water would be possible without massive changes and perf usage. But I've certainly made maps before where I wished I could have (flat) water in pools at different levels across the terrain.

I don't honestly see the difference between flat and non flat of different heights, you still have to detect that particular height.

FireStorm_ wrote:I can imagine (someone doing) a map with two (round) pools and one with a different water height. But I also imagine terrain deformation would be turned off for that map.

Probably the best think about this proposal is that its general enough to allow terrain deformation and water flow if someone does eventually wants to code it, of course performance cost is associated, but that's the same for any feature.

I think that the performance cost for using a ROAM mesh for water unit movement would be minimal, its already done in all cases, and planes already have to check the distance between the ground and the sky mesh.. so there really isn't a case for massive performance loss there.

I'm more interested in the performance cost to do water deformation, and that can be profiled with out any engine code changes.. ala play with the existing terrain to make it like water with lua scripts. even then i dont think it would be that expensive if done correctly.

if i get my ass back to uni next year i will attempt to make it myself(in a few years)..

knorke wrote:it is extreme case to show that your formula is wrong.
in less extreme cases it is also wrong but like this it is easyier to show why.

isn't that called a strawman?

No. A strawman is when you refute something else than the opponent argument.

Would that not be ignoratio elenchi?

I'm not sure an argument from extremes is really a straw man either; depends if knorke is misrepresenting Smoth's argument, or simply pointing out some problematic edge cases.

who cares what it is called?
It is neither a "strawman", "ignoratio elenchi" or a "problematic edge case."
The "formula" is always wrong, not just in extreme cases, I just choose an example where it is most obvious why and how.

I agree with smoth (rephrasing it a bit) that when I stand on the deck of a ship, and the ship sails out of a pool, onto a waterside (without touching the bottom), and down into another pool, that the deck of the ship will not stay parallel with (in theory) flat earth/land surface. Simulating this would require to have the ship tilted, and requires to know at which angle.

I agree with Knorke that if the ship deck would stay horizontal, checking depth would be the way to keep it on/above the water-surface at all times.

Also wondering: 'Can' the plane mesh be used in a more dynamic way? for instance, have a smoke column arise, which would be need avoided by planes. Adding a no fly zone mid-game, basicly. I wonder how the planes would behave. (I'd test that first, I think)

when I stand on the deck of a ship, and the ship sails out of a pool, onto a waterside (without touching the bottom), and down into another pool, that the deck of the ship will not stay parallel with (in theory) flat earth/land surface.

noone doubted that.
getting the angle of watermesh for this would work just the same as for getting angle of terrain.

I agree with Knorke that if the ship deck would stay horizontal, checking depth would be the way to keep it on/above the water-surface at all times.

that is not what i said.

knorke wrote:

I agree with Knorke that if the ship deck would stay horizontal, checking depth would be the way to keep it on/above the water-surface at all times.

that is not what i said.

I was referring to:

The ships would still use terrainmap for navigation/collision just their y-coordinate is not set to constant zero, instead is based on watermesh.

and:

no, you just stick a stick into the water and see how far it goes.
why would it matter if the ground is at an angle?

And that all refers back to:

Now it would become "how far from waterplane downwards to terrain", which is
waterDepth=waterPlane (x,z) - terrainHeight (x,z)

No?

Also: I'm trying to imagine the 90 degree mountain scenario. Wouldn't it compare with how current (all-terrain)land units scale cliffs? Suddenly I'm thinking: Why would it (need to) be different for boats on hills/cliffs of water? (I'll have to give it more thought still, I think )

FireStorm_ wrote:Also: I'm trying to imagine the 90 degree mountain scenario. Wouldn't it compare with how current (all-terrain)land units scale cliffs? Suddenly I'm thinking: Why would it (need to) be different for boats on hills/cliffs of water? (I'll have to give it more thought still, I think )

anything above about 45 degrees is surely too rough to navigate reliably... water tends to be either flat or moving really fast... adding a "slope tolerance" to floating things and then having them avoid anything steeper in the same way a vehicle avoids ledges would suffice but this is all ignoring the fact that flow is going to result in having to account for current.

My mistake perhaps but I was no longer referring to actual real life vehicles or vessels, but I was thinking about Spring-units. (How would an all-terrain k-bot compare to a boat on a water-mesh? (And what problem/difference haven't I thought about? )

No?

No. \o/
One thing is about what angle unit is at. Other thing is how one would measure waterdepth for an unit that is at angle.

(ah, I think I get it.)
...and one would need both for proper behaviour of a unit (i.e. ship) sailing down a water slide. The first to position it at the water surface (and the bow just below) And the second one to tilt it so the the deck of the vessel becomes parallel to the water surface.