Jump to content


Photo

Translucent editor textures (WIP)


  • Please log in to reply
21 replies to this topic

#1 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 22 October 2018 - 09:11 PM

Some 4 years ago I tried making editor textures translucent, but I couldn't figure out how to work around some problems. Since I kinda returned to playing around with DR (yea that's a good description of all I ever do in it...), I tackled this again, and it seems I found a workable solution.

Some people seemed interested in this, so here you have it. Hopefully it's useful.

Attached File  editor textures.txt   178.7KB   9 downloads (rename extension to .rar to unpack)

WARNING: As OrbWeaver pointed out below, my materials add unnecessary geometry to your maps. While I can't find any other side effect, it's certainly possible that there is. Use it at your own risk, but don't use it if you're releasing a map or FM. The added geometry may affect performance.

Here's a preview of what it looks like with my textures. Took the screenshot when I was nosying around Melan's Fauchard map. 

Spoiler


If you don't know how to use this:
Spoiler


Some important things you might want to know:

  • I didn't make all editor textures translucent. Any solid textures (as in, can seal a map) are left opaque, as well as any textures I didn't know they weren't solid. I now know most nodraw types aren't, so I'll have to do them eventually.
  • Some of my textures were made from scratch and are a bit different. You can use the default textures if you want, though; I just decided to make my own because I found this had a few problems with the original ones (the blend mode brightens them a bit, and they seemed a bit too noisy for being see-through).
  • Some of my textures may be too transparent or not perceivable against bright textures behind them. I've been tweaking them for my own taste and to compensate for these problems, but I'm doing this as I go along with DR mapping, so the way they are now is a totally experimental WIP.
  • The blend mode I'm using allows for darkening/brightening the textures to add/remove transparency, respectively. So if you feel some of them are too transparent, or if you're using default textures and they're not transparent enough, you can easily tweak them in any image editor. Since the blend mode brightens the textures a bit on its own, you may find the need to darken them more than you'd expect (mine ended up really dark, but mostly for high translucency). Shadow materials use a different blend mode "filter" that doesn't make darkened textures more translucent, so they may look opaque if using default textures.
  • As you may have noticed in the preview, I added some lines around some textures (clips) to give them the effect of a cage, which helps distinguishing the shapes of brushes that have them all around. I may do the same thing on others, eventually, if needed.
  • In the zip file there's also a test texture-gallery map that I used to lay out the textures and test some stuff. I included it in case anyone wants to take a quick peek at how they look.

---------------

Now, the way I did this may not be ideal, and hopefully I didn't break anything. I changed the materials to add translucency, as well as a blend mode, which, after mixing and matching a bunch, was the only one I thought worked better. But then I also had to add a color value with 0 alpha or otherwise the brushes are visible in-game. That part gives me the confusings... I have no clue why that happens.

Example:

textures/editor/visportal
{
    // ... visportal stuff ...

    translucent
    {
        blend gl_one, gl_one_minus_src_color
        map _white
        color 0, 0, 0, 0 // this makes it invisible in-game (not in-editor)
    }
}

 
Originally I had tried adding an alpha channel to the textures, but couldn't find a blend mode that worked properly with it. The one that looked best also made the brushes behind other brushes show up as if they were in front. What I have now is the only alternative I could figure out that works.

So if anyone has any suggestions on how to improve this, I'm all ears.


Edited by Skaruts, 24 October 2018 - 02:24 AM.

  • nbohr1more, Amadeus and Aosys like this

#2 ERH+

ERH+

    Advanced Member

  • Member
  • PipPipPip
  • 740 posts

Posted 23 October 2018 - 06:48 AM

Doesn't atdm:seed have a same type of translucency? Couldn't you just copy material definition from that one?


Edited by ERH+, 23 October 2018 - 06:53 AM.

S2wtMNl.gif


#3 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7516 posts

Posted 23 October 2018 - 09:52 AM

It's an interesting hack you've found, but I should point out that if DR is allowing material stages to affect the rendering of the qer_editorimage texture, this is actually a bug. Depending on the render mode, DR should render either the qer_editorimage and absolutely nothing else, or the complete D3 material definition including multiple stages (if supported). It is certainly not intentional that keywords such as translucent or OpenGL blend modes will apply to the qer_editorimage, and there is no guarantee that the results will be correct or consistent across future versions.

 

If we actually want to support translucent editor textures (which I agree could be very helpful in circumstances like these), it would be preferable to add explicit support for it using qer_trans or some other editor-specific keyword.

 

But then I also had to add a color value with 0 alpha or otherwise the brushes are visible in-game. That part gives me the confusings... I have no clue why that happens.

 

That's bad. If the visportal texture renders at all in game, this means that the map compiler is not removing it during the compilation stage, as it should. This might also mean that it doesn't even function as a visportal at all (although I haven't tested — perhaps it is both a visportal and rendered geometry). Making it invisible with a blend mode doesn't actually remove the geometry: the triangles will still be there, and therefore affect performance.

 

I suggest you use the appropriate console commands (r_showTris and r_showPortals IIRC) while testing in game, to make sure that your proposed portal texture actually produces a portal, and does not result in (possibly invisible) geometry being rendered across the portal "surface".


  • AluminumHaste and Judith like this

#4 VanishedOne

VanishedOne

    Advanced Member

  • Member
  • PipPipPip
  • 860 posts

Posted 23 October 2018 - 11:34 AM

It's an interesting hack you've found, but I should point out that if DR is allowing material stages to affect the rendering of the qer_editorimage texture, this is actually a bug. Depending on the render mode, DR should render either the qer_editorimage and absolutely nothing else, or the complete D3 material definition including multiple stages (if supported). It is certainly not intentional that keywords such as translucent or OpenGL blend modes will apply to the qer_editorimage, and there is no guarantee that the results will be correct or consistent across future versions.

 

If we actually want to support translucent editor textures (which I agree could be very helpful in circumstances like these), it would be preferable to add explicit support for it using qer_trans or some other editor-specific keyword.

 

On a related note, we've had a past problem with a material becoming see-through in DR when it wasn't desired, and a material stage hack currently prevents it: http://bugs.thedarkm...p?id=4182#c7801


  • nbohr1more likes this

Some things I'm repeatedly thinking about...

- louder scream when you're dying


#5 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 23 October 2018 - 01:06 PM

@OrbWeaver, I've tested quite a few visportals after having this in my game and I didn't notice any problems (I used r_showtris, and r_showportals). Iirc I also tested for internal leaks.

 

Is the map parameter what makes them render in game? Visportal is set to _white (and it showed white in game before I added the color value), but in other materials it's set to their actual texture. I tried removing that parameter at some point, but iirc that made translucency stop working for the editor.

 

At it is though, I've noticed no problems at all. Though I'm not that experienced in this engine, so I could easily have missed something. 


Edited by Skaruts, 23 October 2018 - 01:09 PM.


#6 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7516 posts

Posted 23 October 2018 - 02:50 PM

@OrbWeaver, I've tested quite a few visportals after having this in my game and I didn't notice any problems (I used r_showtris, and r_showportals). Iirc I also tested for internal leaks.


I'm not saying there will be an immediately-noticeable performance drop. Adding a single quad (two triangles) per portal is not a huge burden on the engine, however visportals are not supposed to add any geometry across the portal surface, which yours clearly does. I have no idea if there will be other problems with mechanics that involve visportals, such as sound propagation, but even if there are none, I don't think it would be a good idea to make a general switch to a portal texture that introduces unnecessary invisible triangles across every portal.
 

Is the map parameter what makes them render in game? Visportal is set to _white (and it showed white in game before I added the color value), but in other materials it's set to their actual texture. I tried removing that parameter at some point, but iirc that made translucency stop working for the editor.


Yes. The actual visportal texture has no images at all, other than the editor image:
 

textures/editor/visportal
{
    description     "used to divide areas, areas between sealed portal faces are what gives the engine rendering, sound and AI information"

    qer_editorimage textures/editor/visportal.tga
    areaportal
    noshadows
}

As soon as you introduce an actual rendering stage, even if using the _white image map, you are telling the engine that this material needs to be rendered, which results in the map compiler not removing it, and the game engine rendering it (requiring extra triangles and draw calls) even if the rendered results contributes nothing to the final image.



#7 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7516 posts

Posted 23 October 2018 - 03:31 PM

 

On a related note, we've had a past problem with a material becoming see-through in DR when it wasn't desired, and a material stage hack currently prevents it: http://bugs.thedarkm...p?id=4182#c7801

 

Thanks for the pointer. I have actually identified the code which makes editor textures translucent; it was introduced in this commit:

 

https://github.com/c...5a7b1fb39ee87b1

 

The commit message says that it was intended to fix a bug with Z fighting in particle rendering, but since this function is used for all editor preview textures, it makes the translucent keyword operational for non-particle textures as well. This may in fact have been what Greebo intended (since translucent editor textures are clearly desired by some mappers, as this thread shows), rather than a bug in DR's material processing as I first assumed.


  • VanishedOne likes this

#8 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 23 October 2018 - 05:33 PM

I'm not saying there will be an immediately-noticeable performance drop. Adding a single quad (two triangles) per portal is not a huge burden on the engine, however visportals are not supposed to add any geometry across the portal surface, which yours clearly does. I have no idea if there will be other problems with mechanics that involve visportals, such as sound propagation, but even if there are none, I don't think it would be a good idea to make a general switch to a portal texture that introduces unnecessary invisible triangles across every portal.

I didn't mean performance, I didn't notice any behavior I wouldn't expect from visportals. I don't have maps of my own with a lot of stuff yet, so I've tested this with other already made maps. They seemed to behave as I would expect.

 

To be clear, using r_showportals does show the portals where they should be.

 

... however visportals are not supposed to add any geometry across the portal surface, which yours clearly does.

Not sure what you mean by that, though.

Forget that. I see what you mean. I'll do some more testing to see what it's doing.

 

I was gonna post a video of visportals working ingame, but it's taking ages to upload, so I'll post it later.


Edited by Skaruts, 23 October 2018 - 09:27 PM.


#9 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 23 October 2018 - 10:47 PM

@OrbWeaver, you're right. They do add geometry. :( Specifically, it adds both the functioning visportal and the geometry, like you said it might be the case. So the only difference the color value I added makes is that it makes their brush invisible.

You can sort of see it in the video, how the geometry is cut around them. The engine already seems to cut geometry at portals, but with default materials you notice less cuts, which tell you there's no brush there.
However, they seem to function properly, as far as I can tell.

(If by any chance the video has no sound, it's because I have no sound card at the moment.)

(On a related note, my materials don't seem to affect maps that were dmap'ed with default materials, unless you dmap them again with mine.)

I suppose this problem can also affect other things, like triggers, ladders, clips, etc.
 

If we actually want to support translucent editor textures (which I agree could be very helpful in circumstances like these), it would be preferable to add explicit support for it using qer_trans or some other editor-specific keyword.

Indeed that would be the ideal way to go about it (probably would be best as optional, as many people are probably used to it as it is). That way you could make it use some proper transparency too, unlike mine.


Edited by Skaruts, 24 October 2018 - 02:34 AM.

  • OrbWeaver likes this

#10 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 23 October 2018 - 11:08 PM

Doesn't atdm:seed have a same type of translucency? Couldn't you just copy material definition from that one?

Do you mean this, by any chance?
// Tels 2010-06-25
// Used to texture SEED blocks/regions
textures/darkmod/sfx/seed
{
    qer_editorimage textures/darkmod/sfx/seed
    noSelfShadow
    translucent
    noShadows
    nonsolid
    noimpact
    {
        blend add
        map textures/darkmod/sfx/seed
    }
}
It's basically the same thing, though.

Edited by Skaruts, 23 October 2018 - 11:08 PM.


#11 IZaRTaX

IZaRTaX

    Member

  • Member
  • PipPip
  • 12 posts

Posted 25 October 2018 - 05:01 AM

I already did that 4 years ago for every common and editor textures http://forums.thedar...es-darkradiant/

I redo all textures and add an alpha channel my function was:

textures/common/trigger
{
    qer_editorimage textures/common/trigger.tga
    qer_nocarve        // don't let an awry CSG operation cut it up
    noshadows
    trigger
{

     blend gl_src_alpha, gl_one
     map    textures/common/trigger.tga


}

     }

You can download the file here: http://www.mediafire...ZaRTaX.rar/file

Put the __translucent.pk4 in your darkmod folder and remove the __translucent.pk4 before your final compile


Edited by IZaRTaX, 25 October 2018 - 11:26 AM.

  • Amadeus and Skaruts like this

CoD4 / CoD5 Mapper Mp / Zombie Black ops 3 Mod Tools Alpha Tester.

 

Portfolio : https://www.zartax-level-design.com/

 


#12 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 25 October 2018 - 06:52 AM

     blend gl_src_alpha, gl_one

So that was the one... I figured there had to be a way to do it using alpha.

Seems like you had the same problem with extra geometry too. Putting it into a .pk4 is a good idea, though. Could've done that myself. Though they will be overridden if the user has unpacked these files to folders.

Thanks. I'll still be using my own textures, as I rather have those lines on some of them (and a bit more translucency), among a few other things, but this was nice to know.
 
EDIT: Noticed a problem, though: some textures are invisible behind some others.
toMU0m1.png
(Not just behind monster clip, most of the tall brushes have faces invisible behind the adjacent ones.)

(The bright strip below the monster clip is normal though, it's just a different wooden floor I have there.)

Edited by Skaruts, 25 October 2018 - 07:57 AM.


#13 IZaRTaX

IZaRTaX

    Member

  • Member
  • PipPip
  • 12 posts

Posted 25 October 2018 - 11:25 AM

So that was the one... I figured there had to be a way to do it using alpha.

Seems like you had the same problem with extra geometry too. Putting it into a .pk4 is a good idea, though. Could've done that myself. Though they will be overridden if the user has unpacked these files to folders.

Thanks. I'll still be using my own textures, as I rather have those lines on some of them (and a bit more translucency), among a few other things, but this was nice to know.
 
EDIT: Noticed a problem, though: some textures are invisible behind some others.
toMU0m1.png
(Not just behind monster clip, most of the tall brushes have faces invisible behind the adjacent ones.)

(The bright strip below the monster clip is normal though, it's just a different wooden floor I have there.)

 

My bad, I added a transclucent function that fix the issue now the textures are not invisible behind some others

 

http://www.mediafire...ZaRTaX.rar/file


  • Skaruts likes this

CoD4 / CoD5 Mapper Mp / Zombie Black ops 3 Mod Tools Alpha Tester.

 

Portfolio : https://www.zartax-level-design.com/

 


#14 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 25 October 2018 - 12:42 PM

Yea, it works now. 
 
To be honest I'm still not happy about it though. The transparency brightens the back ones a bit too much for my taste (this was one of the problems I had with other blend modes). I juxtaposed yours and mine for comparison:
iubZ98x.jpg

I'm not sure that that's a big problem in practice, but... personally I rather not have it.
 
My shadow material needs some fixing though.

Edited by Skaruts, 25 October 2018 - 12:43 PM.

  • IZaRTaX likes this

#15 IZaRTaX

IZaRTaX

    Member

  • Member
  • PipPip
  • 12 posts

Posted 25 October 2018 - 01:59 PM

I tried gl_one_minus_src_alpha seems working

 

(not my map)

3pkZEUI.jpg

 

 

You can test it here

 

http://www.mediafire...RTaX_2.rar/file


Edited by IZaRTaX, 25 October 2018 - 02:21 PM.

  • Skaruts likes this

CoD4 / CoD5 Mapper Mp / Zombie Black ops 3 Mod Tools Alpha Tester.

 

Portfolio : https://www.zartax-level-design.com/

 


#16 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 26 October 2018 - 02:16 AM

I'm currently adapting my textures to it. I found a little slight problem with the text of some of the back ones showing up in front of the text of some of the front ones, but that may be down to adjustments in the alpha channels. I'm gonna play around with it. It's probably not a big deal, though.


Edited by Skaruts, 26 October 2018 - 02:18 AM.

  • IZaRTaX likes this

#17 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7516 posts

Posted 29 October 2018 - 04:44 AM

It's never going to look good in the editor because it isn't "real" translucency, it's just an additive blend that doesn't write to the depth buffer (and therefore adds to whatever is behind it, making it brighter).

 

Do you really want every functional nodraw texture in the game to produce geometry in the map file (because of the new texture stage)? This doesn't seem like a good move, performance-wise. The whole point of those functional textures is that they influence important game behaviour without actually being rendered.


  • Judith likes this

#18 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1644 posts

Posted 29 October 2018 - 04:49 AM

Tbh, I don't understand the whole effort either. You have the whole section in Filter menu for that, and in keyboard settings, you can map every one of those filters to keys, if you need to work faster:

obraz.png



#19 OrbWeaver

OrbWeaver

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 7516 posts

Posted 29 October 2018 - 09:04 AM

Tbh, I don't understand the whole effort either. You have the whole section in Filter menu for that, and in keyboard settings, you can map every one of those filters to keys, if you need to work faster:

 

Well, I can see the value of having semi-transparent textures in some situations; being able to see visportals and the like without them obliterating whatever is behind them is a nice usability feature (if configurable by the user).

 

But turning every monsterclip or visportal into a fully-dmapped triangulated brush seems a very heavy price to pay for this convenience. Looking at last the screenshot from IZaRTaX, it seems that the triangle count could be almost doubled by this change.


  • Judith likes this

#20 Zen3001

Zen3001

    Member

  • Member
  • PipPip
  • 32 posts

Posted 31 October 2018 - 09:01 AM

WARNING: As OrbWeaver pointed out below, my materials add unnecessary geometry to your maps. While I can't find any other side effect, it's certainly possible that there is. Use it at your own risk, but don't use it if you're releasing a map or FM. The added geometry may affect performance.

I'm pretty sure it does effect performance, either way a good way arround it is by simply just removing the material files before compiling.

 

Here's a complete batch file I created to start the compiling:

@echo off
setlocal

set /P MAP="Map Name: "


cd materials

rename tdm_misc.mtr tdm_misc.don
rename tdm_internal_engine.mtr tdm_internal_engine.don

cd..

TheDarkModx64.exe +set com_allowConsole 1 +clear +dmap %MAP% +map %MAP% +condump dmaplog.txt +notarget

cd materials

rename tdm_misc.don tdm_misc.mtr
rename tdm_internal_engine.don tdm_internal_engine.mtr

cd ..

endlocal
echo on

Edited by Zen3001, 31 October 2018 - 09:07 AM.

  • Skaruts likes this

#21 Skaruts

Skaruts

    Member

  • Member
  • PipPip
  • 279 posts

Posted 31 October 2018 - 02:16 PM

Tbh, I don't understand the whole effort either. You have the whole section in Filter menu for that, and in keyboard settings, you can map every one of those filters to keys, if you need to work faster:


For example, when you're monster_cliping some part of your map there's no point having that filter on until you're finished. Meanwhile this helps navigating the 3D view and you can also see how things look more clearly in that view.

That's one example that stuck to my mind since recently, as I was watching Springheel's speed mapping videos, and at some point he expressed his annoyance at that. That was also when I thought I could try to tackle this again too.

Also the visportals, as OrbWeaver mentioned, among others.
 

It's never going to look good in the editor because it isn't "real" translucency, it's just an additive blend that doesn't write to the depth buffer (and therefore adds to whatever is behind it, making it brighter).
 
Do you really want every functional nodraw texture in the game to produce geometry in the map file (because of the new texture stage)? This doesn't seem like a good move, performance-wise. The whole point of those functional textures is that they influence important game behaviour without actually being rendered.

Yea, I figured the translucency would be hacky. I never intended this to be a definite solution, though, since the ideal one would always be if DR supported it. It's more like a next best thing, I guess.

That this creates extra geometry is indeed a bit of a set back. It's ok while building the maps, but then you only have have a sense of the real performance whenever you remove it... I don't know how annoying that may become. I never get to that point with my maps...

Edited by Skaruts, 31 October 2018 - 02:26 PM.


#22 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1644 posts

Posted 01 November 2018 - 04:36 AM

For example, when you're monster_cliping some part of your map there's no point having that filter on until you're finished. Meanwhile this helps navigating the 3D view and you can also see how things look more clearly in that view.

That's one example that stuck to my mind since recently, as I was watching Springheel's speed mapping videos, and at some point he expressed his annoyance at that. That was also when I thought I could try to tackle this again too.

Also the visportals, as OrbWeaver mentioned, among others.

 

Easiest remedy for that is working in passes. Basic gameplay geometry pass, AI patrols, lighting, detailing. This way you only work with 1-2 types of special materials at once, and you can easily toggle them with shortcuts. If you work on room by room basis, then yeah, you'll have a problem with those.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users