To Devs - A consideration for any future swimmable water
Cruor
Join Date: 2004-11-07 Member: 32677Members
Join Date: 2004-11-07 Member: 32677Members
<div class="IPBDescription">When it's on the table that is.</div>I know full well that swimmable water or water at all is not currently planned for implementation for launch. But when/if you occasionally get into it post-release I would like you to consider going for the approach of the Unreal/Rune editor, in that you place a water entity within a sealed of space, and when the game runs every area of that space is treated like swimmable water. And then having a flag for any surface (world geometry polygon) to declare if it's a fluid transition surface.
The neat thing about this system unlike that of the Hammer world editor is that you could create a big void room and place the water entity within it and then you could make an underwater station with surfaces or forcefields that would allow you to go from the dry interior of the station into the water and swim around the station. The same thing would be very difficult if at all possible to achieve with Hammer.
Now if my ramblings aren't quite clear I made up a quick conceptual image:
<img src="http://img196.imageshack.us/img196/9399/waterentity.jpg" border="0" class="linked-image" />
The neat thing about this system unlike that of the Hammer world editor is that you could create a big void room and place the water entity within it and then you could make an underwater station with surfaces or forcefields that would allow you to go from the dry interior of the station into the water and swim around the station. The same thing would be very difficult if at all possible to achieve with Hammer.
Now if my ramblings aren't quite clear I made up a quick conceptual image:
<img src="http://img196.imageshack.us/img196/9399/waterentity.jpg" border="0" class="linked-image" />
Comments
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->(the bounds moving above a certain level will be problematic)<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't quite know what you mean by this, but I'm guessing you're referring to their being water above the playable level thus impairing the commander's view. Perhaps the water entity could also have a flag to make that particular volume of water invisible to the commander.
You use a series of blocks to define the water volume as you do in hammer, then texture the exterior surfaces with the relevant texture for that transition.
The only thing source doesn't support is non-horizontal water textures, or looking into water from the side at all, but that's just because it isn't programmed to render them, not because you need some weirdly overcomplicated system to define the volume. It's a visual deficiency and nothing more, you can still step into the water volume from any direction.
You can also make flowing water in source, you just use one of several volumic force entities and stick it over the water volume, trigger_push or trigger_vphysics_motion would both work.
I also can't really think of any reason to have a wall of water you can walk into and out of, water in general is pretty useless in NS-style level design, if you must have it then it would be quite easy to just put moon pools or airlocks in.
Also Chris they aren't using source so I don't see how being able to do it with source has anything to do with this. Maybe the style, but it's not the same engine.
@Brownymaster: Now we don't know anything about what system for triggers and move entities UWE will implement so in the end it might very well be possible for a water level to raise, scale up and down in size etc. and then the water entity would merely have to make a new calculation on where the new surface is. And I doubt it would have to do this very often either. So as to not put strain on the server.
Granted level geometry in NS2 will be much much more complicated than that of the old maps of Unreal and Rune. And I don't have any idea about the manor of calculations that would be required to do this or if there is a brainfartingly easy way to do it that still escapes me. But I doubt it will require as much resources as dynamic lights and shadows does etc.
That's also how source and more or less any other game handles water, water is just a physics volume more or less identical to trigger_vphysics_motion, in fact you can mimic the behaviour of water about 90% using that entity, the only thing you can't do is the ability to propel yourself in any direction, but the slowed motion, limited fall speed, and sound effects can all be done by combining vphysics and a soundscape brush.
<!--quoteo(post=1777978:date=Jul 12 2010, 07:19 PM:name=brownymaster)--><div class='quotetop'>QUOTE (brownymaster @ Jul 12 2010, 07:19 PM) <a href="index.php?act=findpost&pid=1777978"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I meant increasing water height or weird movements (ie water fills up beyond a square and opens up into a cylinder. I could make a paint diagram but I'm too lazy).
Also Chris they aren't using source so I don't see how being able to do it with source has anything to do with this. Maybe the style, but it's not the same engine.<!--QuoteEnd--></div><!--QuoteEEnd-->
He's complaining about the source implementation, I'm pointing out that it works fine, and would be a suitable approach for NS.
That said I don't even know if it's possible given Sparks dynamic nature with little to no pre-compilation going on. However I do seem to remember there being singleplayer campaign maps in Rune with rising water suggesting it was not all done in pre-compilation so I remain hopeful.
Calculating precise volumes on the fly with complex geometry is difficult and processor intensive, no two ways about it. If it was being done in 2000 I would assume it wasn't calculating volumes, it's more likely to be using a solid block of water that moves up, or some sort of highly simplified geometry to perform the volume calculations on, either way it takes input from the level designer. No game yet has done accurately modelled water physics, they all use highly simplified volumes.