water as a secondary terrain

[enetheru]

ok, so i'm just posting this because it popped into my head and i searched for a similar thread but they talk about other things closely related but different and i wanted to not pollute.

I'm sure someone has already thought it and i'm pretty sure that this will be shot down for all the same reasons as other ideas, but here goes.

Make the water a second terrain.

the code re-use would be pretty high.
effects like overflow when walls are broken due to terrain deformation could be coded in lua like other terrain deformation scripts
even dynamic textures based on flow "angle of water terrain" would be possible. to make rivers waterfalls etc.

anyway.. it was just a thought.

[smoth]

Make the water a second terrain.

the code re-use would be pretty high.
effects like overflow when walls are broken due to terrain deformation could be coded in lua like other terrain deformation scripts
even dynamic textures based on flow "angle of water terrain" would be possible. to make rivers waterfalls etc.

anyway.. it was just a thought.

I don't follow you at all. Are you saying make the water a 3d mesh?

[enetheru]

Make the water a second terrain.

the code re-use would be pretty high.
effects like overflow when walls are broken due to terrain deformation could be coded in lua like other terrain deformation scripts
even dynamic textures based on flow "angle of water terrain" would be possible. to make rivers waterfalls etc.

anyway.. it was just a thought.

I don't follow you at all. Are you saying make the water a 3d mesh?

yes, basically exactly the same as the terrain 3d mesh.

[smoth]

would probably be very expensive.

[Google_Frog]

is 3d mesh the right name for the current terrain? I'd call it a heightmap.

As far as I can tell this request is asking for water to be handled as a separate heightmap. If the water height at a point is higher than the terrain height then that point would be underwater.

A more reasonable request could be to let us create "water planes" which act as connected bodies of water. You could easily create lakes at different heights with this but any interaction between different heights or breaching of dams would need to be luaed.

I get the impression that any suggestions such as these are infeasible due to the state of engine development. You'd have to implement it yourself.

[knorke]

Ground units movement is based on terrain heightmap.
For planes there is airmesh. (basically is a second heightmap, editable independently from terrain)
For water/ship it is iirc in many places assumed that water level is at y=0
So replace this 0 with heightOfWaterHeightmap (x,z) and tada?

[enetheru]

Ground units movement is based on terrain heightmap.
For planes there is airmesh. (basically is a second heightmap, editable independently from terrain)
For water/ship it is iirc in many places assumed that water level is at y=0
So replace this 0 with heightOfWaterHeightmap (x,z) and tada?

as much as i would like it to be that simple i doubt it.

regular units would have to also check for water height, in case they are flooded.
along with changes to pathing.

air mesh would have to be deformed when water mesh deforms so that you don't end up with planes flying underwater.

boats and submarines would need to have something happen when they are beached.

the lua code already exists for dynamic terraforming of terrain, its not such a stretch to use similar code to resolve water flow problems.

The incline of the mesh polygons can be used in shaders to show direction of travel for rivers, waterfalls etc.

the hard part is how much engine code would need to be touched to make it work. and corner cases, like what happens when a boat goes over a waterfall. AFAIK ive never seen a boat in the air before.

I'm just glad the idea didn't get universal hate.

also @google frog, I have no idea what you are on about. using an existing paradigm(ROAM based mesh) with solid existing use cases such as knorke suggested(ground units, planes) I think would be much easier to implement, than a completely different system with some as yet unknown method of interaction.

this idea takes working existing things already implemented inside the engine and gives them a new twist.

[enetheru]

Ground units movement is based on terrain heightmap.
For planes there is airmesh. (basically is a second heightmap, editable independently from terrain)
For water/ship it is iirc in many places assumed that water level is at y=0
So replace this 0 with heightOfWaterHeightmap (x,z) and tada?

as much as i would like it to be that simple i doubt it.

regular units would have to also check for water height, in case they are flooded.
along with changes to pathing.

air mesh would have to be deformed when water mesh deforms so that you don't end up with planes flying underwater.

boats and submarines would need to have something happen when they are beached.

the lua code already exists for dynamic terraforming of terrain, its not such a stretch to use similar code to resolve water flow problems.

The incline of the mesh polygons can be used in shaders to show direction of travel for rivers, waterfalls etc.

the hard part is how much engine code would need to be touched to make it work. and corner cases, like what happens when a boat goes over a waterfall. AFAIK ive never seen a boat in the air before.

I'm just glad the idea didn't get universal hate.

also @google frog, I have no idea what you are on about. using an existing paradigm(ROAM based mesh) with solid existing use cases such as knorke suggested(ground units, planes) I think would be much easier to implement, than a completely different system with some as yet unknown method of interaction.

this idea takes working existing things already implemented inside the engine and gives them a new twist.

[enetheru]

Ground units movement is based on terrain heightmap.
For planes there is airmesh. (basically is a second heightmap, editable independently from terrain)
For water/ship it is iirc in many places assumed that water level is at y=0
So replace this 0 with heightOfWaterHeightmap (x,z) and tada?

as much as i would like it to be that simple i doubt it.

regular units would have to also check for water height, in case they are flooded.
along with changes to pathing.

air mesh would have to be deformed when water mesh deforms so that you don't end up with planes flying underwater.

boats and submarines would need to have something happen when they are beached.

the lua code already exists for dynamic terraforming of terrain, its not such a stretch to use similar code to resolve water flow problems.

The incline of the mesh polygons can be used in shaders to show direction of travel for rivers, waterfalls etc.

the hard part is how much engine code would need to be touched to make it work. and corner cases, like what happens when a boat goes over a waterfall. AFAIK ive never seen a boat in the air before.

I'm just glad the idea didn't get universal hate.

also @google frog, I have no idea what you are on about. using an existing paradigm(ROAM based mesh) with solid existing use cases such as knorke suggested(ground units, planes) I think would be much easier to implement, than a completely different system with some as yet unknown method of interaction.

this idea takes working existing things already implemented inside the engine and gives them a new twist.

[SpliFF]

We know it isn't impossible because games like From Dust do it. Of course that doesn't make it easy to program or easy on the system specs so I don't see it happening any time soon.

[smoth]

I don't know if this would be worth the performance cost and complexity it would add to things.

[knorke]

check for water height

Yes, but that is easy:
Atm water height is "how far from y=0 downwards to terrain", which is basically waterDepth = terrainHeight (x,z)

Now it would become "how far from waterplane downwards to terrain", which is
waterDepth=waterPlane (x,z) - terrainHeight (x,z)
Not more complex than before, math wise, but if needs such change in many places it is maybe bloated and bit ugly?

The ships would still use terrainmap for navigation/collision just their y-coordinate is not set to constant zero, instead is based on watermesh.
I imagine watermesh would be flat in all areas where it is visible to players (bumpy water doesnt really make sense)

That would basically allow to have water at different heights, like an ocean but then also a lake on top of a hill.
Or "Falsom Dam" map with different water level on north/south of the dam.
Though question is, is it worth much effort for such rather small gimmick?

[smoth]

it may be easy but the check per frame, per unit, per pixel, and the added math may cost something. As opposed to before where we can just check the unit for > 0? Getting water depth becomes more complex esp at angles.

[knorke]

Getting water depth becomes more complex esp at angles.

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?

[smoth]

some units may have animations in the water.

say I had a unit that does a transformation entering the water or swims like a person. The angle becomes relevant. Right now all water is flat so it is easy. Angle, depth are all things that are relevant when looking at the water.

Some cases I may use depth to determine when the unit auto transforms in the water as until it reaches a certain depth, it cannot have the room it needs to swim/submarine around.

[knorke]

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

Some cases I may use depth to determine when the unit auto transforms in the water as until it reaches a certain depth

Look at the formula I wrote to get waterdepth. It is just substracting two numbers. Complex? imo no.

Water would still be flat whereever units can move on it.
But even if you want rivers with steep slope or waterfalls and want units to tilt according to water-slope, that is still not complex or expensive.

[Google_Frog]

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.

[knorke]

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.

yes, hence just go with flat water imo.

[smoth]

if the unit is at an angle. going say down hill in the river. He has to at least swim parallel to the surface of said river. Instead of just making sure he is at the surface and checking how deep it is below him(which on an angle, you don't measure depth directly down, if so lol) he has to check the depth below him by drawing a perpendicular line down from his body. Which requires angle.

after that he has to measure that line, which requires a get height call. if it isn't deep enough he has to stand up in the water.

otherwise we would truck around near the surface

I am not explaining it very clearly. but just imagine someone swimming down hill. he doesn't stay perfectly horizontal. he will need to angle his body, gravity IRL ensures that we are parallel with the surface unlike the crazy boat that are like this:


For my planned implimentation, I had an idea of a morph into a form on the surface but because sprinng doesn't have on/off water like starcraft or CNC or Airmech or Warcraft etc it has to have some kind of depth detection to the script, like my old kampfer one.

[Silentwings]

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.