Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[PTTG]

I was thinking about how non-ocean bodies of water will be simulated. The current idea has been summed up as having "lakes" which consist of areas with a different "sea level" than normal, allowing for lakes to exist in mountains or for extremely low places like Death Valley be simulated.

There are a couple of ways to improve this simulation. Firstly, it needs a mechanism to simulate flowing rivers. Second, it should ideally have some ability to distinguish lakeshores from sea. Finally, it needs some way to respond to player action.

Rivers, naturally, would work well as lines, and in some ways may be very similar to roads, at least on a small scale. They could effectively consist of a lumpy road with a particle effect moving along it. Larger rivers, however, have to be aware of the underwater surface and act more like lakes and seawater, while retaining the flow awareness.

Lakes may need to be distinct from oceans as well. First of all, lake shores are virtually unaffected by tides, meaning they will have little sand or erosion. The fact that they are bodies of fresh water should ideally be simulated, if only because fresh water can look very different from brine.

Lastly, whatever system is developed needs to account for the potential actions of players. If terrain deformation is to become a major part of the game, it will be possible for players to make dams, or cut into reservoirs. Making ad-hoc additions to the river network will be needed- in fact, giving the procedural generator the power to add rivers may be a good idea.

Note also that waterfalls are going to be tough to do.

[cameni]

The polygons that will override the water level for some region can also override other properties: the height of the sandy or washed shore, water properties (color scattering and transmission coefficients ...), wave parameters and so on.

Rivers will be indeed done as roads, carving into the terrain. There will be also another type of vector data primitive that will be better suited for shapes of large rivers, and probably also for the smaller lakes.

Waterfalls ... yes, will be tough. Can't allow it to break the immersion

[Jagerbomber]

Yeah... You aren't immersed in as much water in a waterfall as you are in a lake. 

[monks]

 Just my 2 cents. I'm mainly talking from the perspective of importing user data into Outerra. Rivers and roads
 as shapefile import would be necessary for users who are importing their own data into Outerra since all
terrain data has to be georeffed. Shapefile would be ideal but it might be possible with either a raster to vector converter in Outerra importer or using something like .svg or .ai. Having said that you don't get per vertex z for svg or ai (they can't vary individually), so, unless Outerra will convert and then automatically generate the z values from the underlying terrain surface, they won't be usable. But, considering Outera's use as a simulator and all of the wealth of mapping data out there, and the potential commercial interest from GIS oriented developers, shp is really a no brainer. Once you have that, the world is your Oysterra.  Dxf might be useful too.
 I reckon support of shp, and then the addition of an auto creation of z values by Outerra from underlying
 terrain would be a great start. Not all river data has z values set. In Global Mapper for eg, you can transfer
 z values from the underlying terrain into the shp file. In World Machine terrain generator, there is a "drop to
 surface" feature, which drops the vector spline to the underlying terrain surface- essentially doing the same
 thing. You can then go on to edit the profile so that you can drop the river just below the terrain to create a
 valley or cutting. The profile editor though is difficult for lots of rivers, but the drop to surface is very handy. Another feature World Machine has is to auto interpolate z values between vertices set by the user, so that just by setting the end points, you can get a linear interpolation along the path. That's not always going to produce good results obviously but it's useful to have and trivial to implement.
 One thing which might improve World Machine is the ability to effect the surrounding terrain from the river z
 values. World Construction Set (which I have a license for) and VNS have things called terraffectors which are
 pretty cool. Basically you have total control over the profile of the "terra affector" (road, river, lake ,etc,
 I've even seen a glacier done with them) in 3D and depending on what the terraffector type is, the software
 procedurally creates the desired transitions around them, including texturing, That sounds very similar
 what you're saying Brano.
 If you could lower the surrounding terrain from the river z values so that the river was always below the
terrain (or rather never above it) that might be useful. But again, that creates potential problems- but it might solve more than it creates?, hard to say. World Machine does not have the feature to vary vector width
 over length though.
 I've recently looked into making rivers more realistic in the ME-DEM terrain, I can see how having different
 vector primitives for rivers and large rivers would be a good idea. You need to be able to vary the width of
the river over its length for the larger rivers. One you have that, you could procedurally affect the shores
 and hinterland from the primitive. I'm using Photoshop to manually alter river widths for the larger ones to
 create estuaries, valleys, etc. It's not an ideal way to do it simply because of the scales you're working at-
 getting a gradual transition from 1 pixel width to a couple fo hundred over say 30K pixels is  ...a bit of
 nightmare. Illustrator can vary width over length but I'm not sure that approach is significantly better- it
 involves control points. Fiddling with lots of those would probably be more accurate yes, but much less efficient than just painting them as rasters. I've not tried it in Illustrator though- only read about it. I'd be much more inclined to do that sort of thing in Global Mapper and just draw the river area as polygons. All our river estuary coverage goes back into Global Mapper as vectors via raster to vector conversion.
 Raster to vector is a very useful tool to have- I've got it in a couple of apps I use (Global Mapper and
 WinTopo, and it can be used for creating area polygons for the wider rivers. I don't know what coding something like that would involve though.
 I would prefer it if we could vary the river width by entering width values for the end vertices and then just
 procedurally interpolate (linear, power curve or whatever functions for variety) the width to create an area
 polygon.
 
monks

[cameni]

You are using some weird formatting there, a blob of text, hard to read

I plan to import the data for rivers in a format similar to what OSM uses. Small rivers as vectors with width information, larger ones as shapes. For the latter I need to find a good way to triangulate the shapes, but not just a simple triangulation of the defined area but also the transitional area where the river blends into the surrounding terrain, creating a shore profile.

Height of the river surface should be taken from the terrain elevation data, to fit it in there, though there may be some issues. Terrain processor should be able to pinpoint cases when the water would flow uphill and carve the river deeper into the terrain in that case, but who knows what else issues will be there.

[monks]

That's Notepad and me trying to type over two keyboards so I couldn't really reach the backspace to format :-D

 Cool, never used OSM but Global Mapper imports and exports in that format should we ever need it. I've just thought that I should really test the vector export into another prog that opens them, because we only ever export vectors as rasters and the river vector lines are not all necessarily connected if you see what I mean? Each river may exist as a number of disconnected lines that appear to be connected because the vertices at the joins share the same x,y value, but technically the rivers is not just a single line in the file. well I'm not sure of the technicalities of how shp stores info. I hope that doesn't cause problems because it's a nightmare to fix them in Global Mapper- so far with the method I've used anyway. //just checked the hydro 1K stream data I have and they are all stored a multiple lines so looks like that's standard formatting.//

 Heh, the z values might throw up some juicy problems. The river cutting would be very useful though. I guess in an enviroment on such a massive scale as Outerra you're always going to have a few glitches here and there, but with the Earth data at least you do have real actual rivers, lucky you! ..so Anteworld downflow should be "guaranteed"...By the time this feature comes around I'll have been through our rivers and removed any that fly.
To be honest it'll be great to see rivers of any kind!

monks

[Timmo]

My thoughts from experience with FSX:
The ability to properly cut a river polygon into the terrain using in-built tools is crucial- For FSX, river polygons have their height (of vertices) and slope set in the river data which is converted from shapefiles (XYZ vertex values from the ShapeField, a Guid relating to the water type and XSlope and YSlope pulled from the attribute table). They are independent of the underlying terrain and it is left to the scenery developer to create calculate all these values. Obviously the FSX development team had some way of doing this in GIS by combining a river polygon and DEM, but the tool/method wasn't part of the SDK.....I've struggled to come up with a similar solution myself (Obtaining vertex Z values from a DTM isn't hard, ensuring that the river polygon triangle is 'flat' across the river but has a slope downhill is difficult for anyone without fairly in-depth programming skills).

Placing the height values inside the river data may run into some issues for Outerra due to the terrains fractal displacement unless that is always a positive displacement? (i.e. a river polygon sitting above its surrounding terrain is wrong, a river polygon sitting below it after fractal tweaks is ok)

Anyway, the Outerra developers are far more intelligent than I so I'm sure they'll come up with something

[tom.luft]

I am really looking forward to having rivers in outerra. It would be a huge thing, however, if one could

• import laserscan data into outerra to refine an area's elevation data
• simulate rain (and calculate or import watersheds) in outerra and therefore
• simulate water flows of huge areas accurately within outerra

Yes, I'm a civil engineer

[John514]

• import laserscan data into outerra to refine an area's elevation data

Yes, I'm a civil engineer

Hm...LiDAR in Outerra..I think that would be too much for averege PCs to handle. Thus the Fractial refinment of the 90m resolution mesh. (Not to mention Lidar would take ages to stream and load)

[ZeosPantera]

Certain areas would definately benefit from the accuracy of lidar. The grand Canyon or around a race circuit. Small islands like Hawaii.

[Midviki]

*What about the collision from objects with liquid ?

- Swimming pools

- Water falls in shopping centers

- little rivers flowing in malls or other enclosures ( flowing along on 3D imported objects )

- Artesian fountains


*What about Evaporation of small ponds ?

*What about Rain ?

*What about water created by rain ?

*What about the water in contact with the terrain / soil creating a Muddy surface looking and with muddy physics as well?

*Will there be water created by rain ?

*Will the water created by the rain will be slowly evaporated with time passing ?

*Will there be possibilities to get water with a bucket from a river ?

*What about water vapor captured and transformed in to water droplets and the droplets creating bigger quantities ?

*What about water from vapors , droplets or just from other small source of water flowing / escaped along an made object, example: like a vertical wall, and very small amounts of water flowing down on it ?


And I realize that what I just said is the domain of outrageous for any game engine to have.But bare with me and maybe you can answer my question if any of this are in development already , finished but not launched , future development planed or "nay! not going to happen". [Q]:Can you give us a bit of insight of the plans you have and what is the current progress maybe on some of the mentioned things above ?

[cameni]

Rain & wet/mud effects certainly. Puddles ... there is some info about terrain curvature already, though it doesn't tell us enough info for water accumulation. Was thinking about running an analysis of the generated terrain, for some maximum puddle size it could be ok. When there's accumulation, evaporation will be there as well.

When lakes are supported, pools can be as well. However, simulating a flowing water is something else. Rivers won't be actually simulated, they will use predefined flow & water level data, perhaps seasonal. At least initially, until there are good simulation level of detail algorithms to make it viable for planetary scale.

[ZeosPantera]

When there's accumulation, evaporation will be there as well.

Don't forget absorption into the ground based on material and substrate..

Also having some variation of the surface in the road/runway editor to allow puddles to form would be ok. Perhaps only on old roads.

[Midviki]

Also having some variation of the surface in the road/runway editor to allow puddles to form would be ok. Perhaps only on old roads.

Yep, slippery terrain.

When lakes are supported, pools can be as well. However, simulating a flowing water is something else.

The "indoor rivers" interest me the most.
I was thinking about some indoor little river aqueducts flowing on some self made imported object or subterranean canals.

[GHAO]

Maybe river/water details could be hidden at distances of more than 150m? So in the air, you can't see the individual water particles interacting (it looks just like a flat plane), but up close you can see the water running, and if you dam then release a river it flows out naturally.

 - Light needs to be able to refract through the water, so we get the surface sparkle, and if the character is swimming, he can still see, but everything's off-kilter.
 - Waterfalls need to be detailed all the time, even in air.