Spring RTS Engine

SinbadEV wrote:

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.

Acguy. Hygogg etc sinbad..


Ah well shit I though I finally understood it. I see it throw around a lot and still don't get mr strawman.

I guess my thoughts on you r. Extereme case are tbat they only obscure the key issue. How will I know my unit depth? How will tgeir bodies Lugn

You have a significantly larger check esp I n your jelly mountain

that is unreadable to me.
i have no idea what you are trying to say.

I meant to post you some kind of response knroke, sorry, I do not feel well right now and the the whole shaking hands thing makes posting from my phone difficult. Sorry, I thought I had posted my reply earlier. I will try and reply better in time. Thanks for not taking my earlier question about the strawman thing to offense, I still don't follow how it works. I have no idea why I didn't post that last post but from my phone towards the end of it my hads were pretty bad.

anyway. I have to. I think your heavier examlple of your jello water mountain workds too strongly in my earlier arguement that the thing is too complex as far as equations. I don't thin that resolving angle(important for that ship sliding down him) and depth for my guy with the transformation are in any way simpler.

sinbad 45? really? come on.

honestly I don't see how it is any different to how land units work already.
* land units already angle themselves to the terrain. so why wouldn't water units angle themselves to the water mesh.
* land units already find it difficult to travel up hill, so why wouldnt water units have more difficulty traveling uphill on the water terrain simulating current
* terraforming land works, so why cant we use the same tools to alter water so that we can resolve flow when the land is changed.(the only processor intensive task)
* with a good shader using the surface normal to animate in a direction we can get visual current.

with this we could create volcanoes that spew lava, rivers, waterfalls, dynamic flooding of maps.

like I've said the dynamic water height could be profiled without any changes to the engine with a lua gadget that deforms existing terrain. in that way we can see if its feasible.

If i were to do it it would be the most naive method starting with:
* looping through all the points of the terrain performing something like gaussian blur
but that would hardly look any good, would not preserve volume, and is not a good test. I'm sure there would be more optimal ways to selectively modify the terrain mesh

Then there's the re-calculation of pathing.

check the depth below him by drawing a perpendicular line down from his body

perpendicular means this
yes?

So perpendicular from body would be like the err penis of swimmer who is swimming in water with belly down.
But I could not draw that so I sticked a stick to the bottom of a boat.
yellow = measured along perpendicular line from body (your idea)
green = measured directly downwards (mine)

What would you consider correct depth?
Note how picture 1+3 are the same, excpet boat has rotated (either from sinking or the watermesh got steeper)
The yellow line would measure a much deeper depth even if boat is still in same position: How does it make sense that the water suddendly is suddendly deeper because boat rotated?

smoth wrote:the thing is too complex as far as equations

No. If you need angle of watermesh (which for getting depth, you do not need) it is the same equation as for angle of terrain mesh.
Functions to get terrain normals already exist and are basic.

enetheru wrote: * land units already angle themselves to the terrain. so why wouldn't water units angle themselves to the water mesh.

The same is also true for the air units/mesh as well.

Although it would be neat to have water tables, I would prefer a simpler solution. Maybe water could just be tied to the type map. The water plain could just be drawn at whatever height the type map describes. This would allow simple height changes for maps such as folsom dam. The only difference being the edge of the water plains would need to be seperated by a hard surface so one could never see the 'edge' of the water. If a mapper wanted things such as waterfalls those could be handled by a separate shader.

Maybe water could just be tied to the type map. The water plain could just be drawn at whatever height the type map describes.

How is that "simpler"? In the end you always need some way to store y-level of water at x,z coordinate. If you name it typemap or a new map/mesh is same thing.

knorke wrote:How is that "simpler"? In the end you always need some way to store y-level of water at x,z coordinate. If you name it typemap or a new map/mesh is same thing.

If a map has variable water it should also have variable map hardness, why not use the same mechanism for both (type map in this case). Adding new seperate maps, in my mind is the definition of complex.

Also with a type map you could easily define the exact level for two or more different water levels, without caring how they relate to each other.

knorke wrote:

Maybe water could just be tied to the type map. The water plain could just be drawn at whatever height the type map describes.

How is that "simpler"? In the end you always need some way to store y-level of water at x,z coordinate. If you name it typemap or a new map/mesh is same thing.

Thanks for having my back on this one knorke, we KNOW it will work. and its such an incredibly simple solution compared to creating a new type of system.

How can i get engine devs to weigh in on feasibility?
I would like to make it happen, but i wouldn?t know where to start.

what with the variety of systems that would need to be touched.. its too complex for me at the moment.

when I say complex, I mean general complexity that arises from any solution. I think that my solution is the simplest possible with the most flexibility.

Okay I'm having a tough time explaining whats in my mind but for now forget type maps. What I imagine is multiple simple quads intersecting the 'land' heightmap at different z in different areas.
It would basically be the way it is now but the water level would not always be 0. No angles, no difference in how units act when under the water level, just simple quads parallel to the x and y axis (I'm assuming z is up and down?). When units are under these quads they are under water.
not a

enetheru wrote:variety of systems that would need to be touched..

I'm not trying to say you're way wouldn't be awesome and allow for more diversity, I'm simply adding my idea to the pool.

Edit: I think I'm swimming towards off-topic so I'll just quit posting for now

Funkencool wrote:What I imagine is multiple simple quads intersecting the 'land' heightmap at different z in different areas.

yes I understood, but it means specifically coding that particular way of drawing the quads, you would have to make something new.

why not use an existing system such as ROAM. that we already use.. no need to code up something new when you have a solution already.

People keep thinking of development from scratch, but that's not what this is. this is code re-use.

I just imagine more work getting all the different types of water that already exist(dynamic, bump,...) working correctly with the mesh. but then again maybe that's not hard either, i have no idea really...

knorke wrote: So perpendicular from body would be like the err penis of swimmer who is swimming in water with belly down.

inb4rudderpenis and dutch rudder.

Assuming someone with coding skills could be arsed to bother with it I'd say the easiest solution would be to just add and render a water plane heightmap... use water's y - terrain's y to determine the depth at a given XZ and then provide Lua hooks to do anything more complicated like current or flow or water heightmap deformation.

for a map with multiple flat static water-planes this would be entirely sufficient and if mappers or game-designers want to do anything fancier they can Lua it.

(edit: because ywysg corrected my error)

In Spring, the vertical axis is Y, and the horizontal plane is XZ.

I dont want to annoy- but- isnt this just another case of advanced Unit Physics? A lake shaped forcefield that puts the drag on all non ship units, while those get a force of there own to stay on top of it?

The Rest is just graphics and forcefield geometry..

I don't know if this is possible by already written lua or in the new engine...

But if it works, warp fields as a second smooth mesh for space units would also work, right?

Or Gravity-clouds which makes your planes faster over your own terrain.

I am interested what happens/happened about this.