Jump to content
The Dark Mod Forums

Translucent editor textures (WIP)


Recommended Posts

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.

editor textures.txt (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 them at your own risk, but don't ever use them when you're releasing a map or FM. The added geometry may will affect performance. @Zen3001 suggested a batch file to automate deactivating my custom materials before dmap'ing.

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

 

(It looks more confusing when it's not your own maps.)
i3JVm4Y.png



If you don't know how to use this:

 

Just copy all the folders into your darkmod folder. You should end up with:

tdm_folder\materials
tdm_folder\textures    <-- If you don't want my textures, ignore this folder
tdm_folder\maps        <-- if you don't want my test map, ignore this folder

If you've previously unpacked "tdm_textures_base.pk4", you may want to check what files are in the archive and decide if you want to back up yours, replace them, etc.

If you already have DR running, you need to restart it.



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
  • Like 3

My FMs: By The Cookbook

Link to comment
Share on other sites

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".

  • Like 2
Link to comment
Share on other sites

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.thedarkmod.com/view.php?id=4182#c7801

  • Like 1

Some things I'm repeatedly thinking about...

 

- louder scream when you're dying

Link to comment
Share on other sites

@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

My FMs: By The Cookbook

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

 

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.thedarkmod.com/view.php?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/codereader/DarkRadiant/commit/6796c7c27208e79fd073caad25a7b1fb39ee87b1

 

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.

  • Like 1
Link to comment
Share on other sites

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

My FMs: By The Cookbook

Link to comment
Share on other sites

@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
  • Like 1

My FMs: By The Cookbook

Link to comment
Share on other sites

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

My FMs: By The Cookbook

Link to comment
Share on other sites

I already did that 4 years ago for every common and editor textures http://forums.thedarkmod.com/topic/16809-translucent-textures-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.com/file/207qnekcziucuzb/Translucent_textures_by_IZaRTaX.rar/file

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

Edited by IZaRTaX
  • Like 2
Link to comment
Share on other sites

 

     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

My FMs: By The Cookbook

Link to comment
Share on other sites

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.com/file/207qnekcziucuzb/Translucent_textures_by_IZaRTaX.rar/file

  • Like 1
Link to comment
Share on other sites

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
  • Like 1

My FMs: By The Cookbook

Link to comment
Share on other sites

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
  • Like 1

My FMs: By The Cookbook

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

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

My FMs: By The Cookbook

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 weeks later...

Blank face (nodraw) with a pre-made, opaque decal placed over it.

Bearing in mind that decals won't have shadows and are no clip. Playerclip/Level design a way around that.

Add collision arg: http://wiki.thedarkmod.com/index.php?title=Clipmodel (or arg on decal, "solid 1", so can be set to "solid 0" if required, called by trigger script or to destroy / rem. monster clip / player clip as required.)

Translucent texture complete.

----

Decal texture tutorial goes to LOD tutorial instead of decals tutorial: http://wiki.thedarkmod.com/index.php?title=Decals

Perhaps needs a re-route to here instead:

http://wiki.thedarkmod.com/index.php?title=Text_Decals_for_Signs_etc.#Customising_and_Making_your_own

Edited by teh_saccade
Link to comment
Share on other sites

  • 2 weeks later...

@OrbWeaveris there anything about the materials that gets saved into the map file itself by DR? Because I'm having issues with nodraw_solids that make me think that's the case. (Sorry for revamping this after so long, but I've been away from TDM all this time (again), and just starting noticing this now.)

Just one thing first: when I'm using my materials for mapping, I'm not using them for dmapping. I use a batch file similar to the one suggested by @Zen3001in a post above, which temporarily renames them. So as far as the game itself is concerned, it's using all the defaults.

Now, the issue is that nodraw_solids aren't properly working in-game. Collisions are fine, but the sounds are not. A nodraw_solid_metal will not sound like metal (will do some generic sound I think, similar to jumping on a mattress).

Given that nodraw_solids should work just by being there, as far as I know, I thought this might be caused by my materials. So I removed all custom stuff from the TDM folder, and tried dmapping the map again, but still didn't fix it.

I went back in DR, resized the brush a bit and re-saved the map, and only then dmapping fixed the issue. Suddenly nodraw_solids were making respective sounds.

 

So that makes me think DR probably writes some crucial material information to the map file that makes my custom materials problematic.

And if that's the case, then we shouldn't be using these custom materials at all... :(

Edited by Skaruts
  • Like 1

My FMs: By The Cookbook

Link to comment
Share on other sites

Actually I'm confused. Something isn't right, but I can't quite pin it. I just tested this in a test map and nodraw_solids are working fine with my materials. 

I may have found a what seems to be a bug in DR, which may have been what confused me before. May be a known bug (if it's a bug), but I didn't know about it until today: if you only change the material on a brush from one nodraw_solid to another and then dmap it, nothing will change in the game. That surface will keep making the sound from the previous material that was there. You have to also edit the brush itself (e.g. shrink or enlarge it a bit) in order to make it work.

At least that happens on my end, regardless of my custom materials.

Edited by Skaruts

My FMs: By The Cookbook

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

    • 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
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...