simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 

Author Topic: Volume/underwater effects in next release (2019)  (Read 27 times)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« on: April 06, 2019, 06:07:26 PM »

I thought I already logged a post about this :confused: but it seems not.

Long story short is I arose with an idea earlier this week that I'm pretty excited about: that is to add depth to transparent textures to simulate bodies of water mainly, since the effect is going to need the geometry in question to behave like a liquid filled basin.

This is going to give way to swimming features I'm sure. In due course.

The idea is pretty simple, and it builds on the depth-buffer that's used to blend the sky and shadows naturally/beautifully into the level geometry.

I think I may have had the idea before, but it was not practical until I very recently added the ability to put transparent materials inside of the MSM tile models. Before this, the only way to make bodies of water was to use "objects" and that is not enough to work with to build water effects around.


This will be a natural extension of the depth-buffer effect, which is something I appreciate, because I feel like software that is effortless is intrinsically more elegant and beautiful.


I'm pressed for time today, I have to go out, so I must be brief. Below is some new supporting extensions I've staked out to begin.

Code: [Select]
[Volume]

;testing new feature
0_meerawater = Meera water
volume_depth = 1
volume_power = 2

I'm using the opening zone of Moratheia as a test-bed for the basic effect. I'm not sure what is appropriate to modeling water. So I've kept it basic. I think basic suits SOM.

In this configuration file code, "Meera water" is human readable text for the event editor. The other two are functions that receive parameters. "0_meerawater" assigns the texture to slot 0 in the event editor. And 0 is a parameter to the formula. It's possible to assign more textures to 0, to make a group. But I haven't made it possible to use a different parameter within the same group.


Depth means that more distance between the pixel on the transparent surface and the opaque pixel that is behind it makes the volume-texture appear more opaque, as if there is more of it in that space, as if it's a column from one pixel to the next.


The "depth" formula just says how far can you see into the material. And "power" is if there needs to be a curve in terms of the amount of transparency at shallower depths being nonlinear.


I don't know if this models light. I would rather keep it simple, and I don't try to model physical reality with graphics anyway. Generally I like graphics that appear static. Optical effects like specular reflection can be distracting, and hard to do correct in real-time. If they don't look precisely correct there is an "uncanny valley" effect that can be hideous. I think that's why contemporary video games are ugly in my estimation.


Things get more complicated when you go underwater. The problem turns inside out, and that's where the event editor comes into play, since events need to respond to the change in the world's dynamics. It's also necessary to orchestrate a full-screen effect since the polygons that form the surface of the water won't cover everything as seen from the inside out.


Transparent elements embedded in the volume texture's "imaginary basin" also compound the situation. I think they can be managed by blending their depths into the depth-buffer. But there's another problem, in that the transparent elements are typically z-sorted, and this is by model section, and not pixels, and I haven't gamed out what the impact of that might be. But I expect if it is subtly glitchy it's just going to be a fact of life. Transparency is already like that. It's more evident when things like particle effects fly through a field of z-sorted transparent elements. When elements are static maybe artists can work out ideal placements. But z-sorting effects can be different depending on vantage.


I'm planning to use this on KF2's Melanat zone to tail off the underwater causeway like geometry. I got the idea thinking about Moratheia. I recently heard from its author. I don't know if I should be sharing that here, but there you are.
« Last Edit: April 06, 2019, 09:12:03 PM by Holy Diver »

Holy Diver has 2200 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #1 on: April 12, 2019, 10:59:23 AM »


Update: I've completed work on this, up to the coming release, in the next few days, however, I never intended for this release to include everything described in the opening post...

Mainly, there won't be an event tie in feature, and no full-screen effect. On the upside, it turns out the effect generalizes to any kind of geometry, and so I've enabled it for pretty much everything, with some limitations:

1) The transparent polygons have to have either an opaque polygon behind them, or they require a volume-texture polygon behind them, ideally their own.

2) When the volume-texture is serving as its own backing polygon it likely needs to be self-contained, because they are currently drawing their inside-out faces first, and then their front facing faces after. To be able to build a multi-tile or multi-object version of this it would be necessary to (somehow) draw all of the participant's inside-out faces before swicthing to their front facing faces. That would be less efficient for SOM because it streams its polygons. Currently I have it so it can do multi-pass with one stream. If the problem was just batching the rendering it would not be difficult to do, but there is also a z-sorting problem, meaning clusters would have to be batched separately/intelligently to make it work.

3) Regular (transparency) z-sorting limits apply. Namely: overlapping and concave objects can sometimes have blending glitches or incorrect z-order. This problem will not go away without more fine-grain z-sorting. That's not inconceivable. But it's not a big priority either.

I don't actually know how to approach the event problem. The obvious way is to add a new clipping code to the MHM format. The only hurdle there is x2mhm cannot be used. I have at least one other MHM tools, but it doesn't subdivide like x2mhm. I've long wanted to develop a replacement for it.



Currently the extensions are as described. A volume_sides extension is used to request to not do the inside-out pass, but it has no effect other than to reduce the workload.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #2 on: April 13, 2019, 10:45:02 PM »

You can now see this for yourself with the latest release. Below is code taken from my KFII project. ii1161280 is the water TXR file name. If volume_sides is 2 then the reverse side of the water sheet is rendered to the depth-buffer, invisibly. (This probably isn't required, since the performance overhead for rendering the backward facing polygons is negligible, because you can never see both sides at the same time. In other cases it might be more useful. But it illustrates that it's not in use I suppose.)

Code: [Select]
[Volume]

;testing new feature
0_ii1161280 = Veld seawater
volume_depth = 8
volume_power = 1/3
volume_sides = 1

BTW: Something I think I neglected to explain before is the "0_ii1161280" part can have wildcard characters where underscores (_) appear. It's not possible to write a space ( ) in a file name, and so, spaces must use the wildcard. Wildcards can match more than one texture's file name.