Jump to content
The Dark Mod Forums

Water effects not rendered through warp glass


Recommended Posts

1 hour ago, duzenko said:

@Frost_Salamander Are you using the exe from my link? It's supposed to be 32-bit, unlike what you reported above

 

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

You also suggested trying the 'latest development build'.  I asked if that can be obtained using tdm_installer, and you said 'yes'.  That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856

So - I am probably doing something wrong but not sure what 😂

Link to comment
Share on other sites

In order to depth sort, it is desirable to take bounding box of surface into account.
That would allow to support world surfaces, and entities not centered at origin.

Depth sorting has one major problem: as player moves, objects order sometimes changes, which results in a hugely visible "toggling". In a sense, it is more pleasant to render surfaces in fixed order than to sort them dynamically.

Wouldn't it make sense if we apply proper sorting only for static surfaces whose bounding boxes don't intersect?
I believe it is possible to reliably decide which box should be more distance in this case.
Not sure yet what to do if boxes intersect, or how to mix it with dynamic objects: comparison must be transitive...

 

Link to comment
Share on other sites

After some more consideration, it won't work, even in limited case.

Actually, nothing will help. You'll just replace one problem with another, no matter what you do.
Translucency is common problem which remains unsolved. If you have ordinary translucent objects with common material, then you can at least do some OIT (like per-pixel lists, depth peeling, or weighted approximation), but if you need to copy background, nothing of it works.

Just remember that you should not have more than one heatHaze material per view, and that if you have many translucent objects, they'll probably render in wrong order.

Link to comment
Share on other sites

I think the best solution would be to save the current way of rendering objects, but allow mappers to specify tie-breakers in scripts. Don't try to make clever automatic solution, it won't work and won't be easily configurable.

If mapper really wants to get complicated translucency work, he can often get away with some simple conditions like:

  • if in area Q, then render A then B, otherwise render B then A
  • if coord X < 1540, then render A then B, otherwise render B then A

But for this to make sense, we need to guarantee that we won't try to tweak anything above this tie-breaker ourselves. We won't change "sort" variable in core materials, won't split its values into more classes, etc. All that tweaking that you did in the core game must be stopped, because if you continue, you'll break mapper's translucency tweaks.

Link to comment
Share on other sites

I got quite good results manually reordering render order inside my lighthouse. Lamp beam > transparent windows > foggy skybox. Of course it helps that you can't really look into the lighthouse top from outside up close.

Link to comment
Share on other sites

BTW, there is another solution straight from the days of the first Doom: we can use BSP to establish rendering order.

But:

  1. Our BSP is too large to traverse in realtime, so we should build a separate BSP only for translucent geometry.
  2. If some surface is split into chunks by BSP planes, we must not merge it back: we must retain each chunk as separate surface and order + render each chunk separately.
  3. Obviously, this only works for world brushes: no entities, no patches, no models.
  4. It is not obvious how to merge unsupported translucent geometry into BSP order... maybe by some origin point.
  5. This requires quite serious effort on dmap + rendered frontend + integration with backend.

 

Link to comment
Share on other sites

We don't really need universal or fully automatic solution

If there is a workflow that allows to achieve a particular result with minimum effort from mapper it should be good enough

Some problems can even be solved on the material level

E.g. glass is safe to render after water, etc.

Link to comment
Share on other sites

13 hours ago, Frost_Salamander said:

When I tried your .exe, I got this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

You also suggested trying the 'latest development build'.  I asked if that can be obtained using tdm_installer, and you said 'yes'.  That's what I reported here: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475856

So - I am probably doing something wrong but not sure what 😂

Put the downloaded exe into the folder with the dev build and run it from there

Link to comment
Share on other sites

Have you tested it performance-wise? Last time I checked, heat haze was getting more resource hungry the more pixels in player viewport it used. So sticking your nose to the glass and looking at another big heat haze surface, like a body of water or something, could be really expensive.

Link to comment
Share on other sites

On 7/3/2022 at 11:18 AM, duzenko said:

Put the downloaded exe into the folder with the dev build and run it from there

Sorry finally got around to trying this - it still looks like this: https://forums.thedarkmod.com/index.php?/topic/21477-water-effects-not-rendered-through-warp-glass/&do=findComment&comment=475732

 

Link to comment
Share on other sites

@duzenko, how can mappers control render order now, including dynamically from script?

Can they set "sort" parameter directly as spawnarg?
Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value?
Can it be done in script during runtime?

Link to comment
Share on other sites

8 minutes ago, stgatilov said:

@duzenko, how can mappers control render order now, including dynamically from script?

Can they set "sort" parameter directly as spawnarg?
Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value?
Can it be done in script during runtime?

Sort is per material

There is additional drawSortOffset entity spawnarg that allows mapper to mark some entities to draw "a little later" but it's very rigid. I think it covers like 90% of all situations though. It's main problem is that it has to be set manually for each 'fixed' entity by mapper who must understand the technical 3D scene breakdown.

I don't know about script support and I don't think it's a good direction to take. Scripts are for game events IMHO.

Now one new thing I just noticed is we already have sort by distance for SEED objects. I wish I knew how to use it for translucents.

Link to comment
Share on other sites

9 hours ago, Frost_Salamander said:

Can I have a screenshot with a console version on it? Use shift+tilde for partial console view

Link to comment
Share on other sites

10 hours ago, duzenko said:

Sort is per material

There is additional drawSortOffset entity spawnarg that allows mapper to mark some entities to draw "a little later" but it's very rigid. I think it covers like 90% of all situations though. It's main problem is that it has to be set manually for each 'fixed' entity by mapper who must understand the technical 3D scene breakdown.

Well, mapper can at least establish relative order between translucent entities of same-kind material.
But I think it is not possible to do this in script right now.

Quote

I don't know about script support and I don't think it's a good direction to take. Scripts are for game events IMHO.

Yes, it is not perfect, but it should work.
It would allow "user-assisted translucency" 😁 for those who dare.

Quote

Now one new thing I just noticed is we already have sort by distance for SEED objects. I wish I knew how to use it for translucents.

I don't think there is anything like that.
Moreover, SEED is hardly a good piece of code to look for admiration...

  • Haha 1
Link to comment
Share on other sites

3 hours ago, nbohr1more said:

You will need the latest glprog data from the SVN tree:

https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/glprogs/

Isn't that in the latest dev build though (which is what I'm using for the TDM install that I'm running @duzenko's exe from)?  Also his download included a 'glprogs' folder that I also copied into my TDM installation...

Link to comment
Share on other sites

I removed DSF_SORT_DEPTH flag and new sorting code.

I committed test map to assets SVN as test/5990_render.map.

I did a few adjustments to the map, most importantly set "drawSortOffset" "1" on the window: now it renders properly always.
However, this assumes that player cannot get into water: it player is inside water, then he won't see glass windows behind water obviously.


Speaking of "drawSortOffset", I think it has some issues right now:

1) I have a pool of water, and I know player cannot get into this pool since the level is too low. I'd like to make sure this piece of water renders before all the surfaces with similar material. I set "drawSortOffset" "-1" on the water, and its rendering is totally broken because it is no longer considered "postprocessing", thus framebuffer is not saved.
Setting "drawSortOffset" on the window is possible but hardly a good idea: I don't have any guarantees about window, so I should not have to tweak it.

2) drawSortOffset is an integer, so it is not very applicable to ordinary translucents. In fact, the original D3 way of tweaking translucents is by classifying them into "close", "medium", "far", but that's only possible in material. softOffset works well only for afterFog, postProcess, last classes, since their "sort" values are far from each other. But: mapper must know that he cannot set large values, or he'll break everything.


Wouldn't it be better if we:

  1. Sort by "sort" class first, then by mapper's "drawSortOffset", lastly by surface index. In other words, let softOffset be tie-breaker, instead of a way to break classes in implementation-defined way.
  2. Allow mappers to override "sort" class of entity by spawnarg. So if mapper decides that some object is not really "close" but should be "medium", he sets "drawSort" "medium" spawnarg on entity and this is used instead of the value from material.

I'm not even sure it p.2 is necessary. Ideally, these close/medium/far classes either should not exist, or should be totally certain so that mappers don't need to override then on per-entity basis.

Link to comment
Share on other sites

On 6/24/2022 at 1:48 PM, Frost_Salamander said:

Sure, but I'll need you to specify exactly what you need because I don't really understand what's happening on the same level as you do. Name it and I'll add it to the map.

If it's not two-sided how do we replicate the issue?  Do you want a 'window' with only one face textured with the warp glass?

As far as I know you should only use twosided shaders on patches, as the back side of the patch is not rendered. Brushes should use onesided shaders.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

This a very cool development but I am still mystified by the strange inconsistencies:

461682688_lordsnlegacy(2022-07-0912-40-13)(-506.07-36_3265.41).thumb.jpg.f1b34dcae2557f73b650eb3ee5de936b.jpg

Lords and Legacy, the windows on the left side of this screen-shot render perfectly behind the heat haze particles of the guard's torch. While the window on the right has the old behavior of only rendering the heat-haze and erasing the window material. Both windows are using the same transparent window material ( textures/darkmod/glass/clear_warp ). I wonder what can account for these different behaviors ?

I wonder if is lighting info passing from lit stages and getting modified by non-lit stages? Maybe those types of interactions need to be passed to their own buffer too? ( increase to 5 ? )

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

47 minutes ago, nbohr1more said:

Lords and Legacy, the windows on the left side of this screen-shot render perfectly behind the heat haze particles of the guard's torch. While the window on the right has the old behavior of only rendering the heat-haze and erasing the window material. Both windows are using the same transparent window material ( textures/darkmod/glass/clear_warp ). I wonder what can account for these different behaviors ?

If they have same material and "sort" value, then they are eventually sorted by surface index. This order is constant in one playthrough, but can change even if you restart the game.

And if you have two postprocessing surfaces on the same place, then both of them will be visible if they render in correct order. If the closest surface renders first, then the farthest surface won't be visible.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...