Jump to content
The Dark Mod Forums

"r_materialOverride" For Single Surfaces


Spooks

Recommended Posts

I have a suggestion for a new TDM console command that, I think, would be a boon to mappers. I think one of the most time-consuming parts of mapping is compiling the entire map in order to check out how a single change you've made looks in-game. The bigger the map is the longer it takes to compile, and the further away you get from efficient WYSIWYG editing (save for running TDM inside DR, of course, which isn't happening). There's two main things you really need to be checking in-game rather than in-editor: one is shadows and the other one is textures. I'm glad to say that shadows are no longer a problem with Shadow Map implementation. Before you had to recompile the entire map for the stencils to update, but now a simple map reload will give you updated shadows, it's fantastic. Texture changes, however, are still a problem. Even a single texture replacement requires a full recompile.

r_materialOverride is a good, if limited, command that replaces all the materials in-game to a set value that you can get by copying a shader name in DR. I use it early on in the mapping process to save time laboriously trying one texture after another and recompiling. I need to know how a texture looks like, scaled and repeated, on a facade or whatever else have you, its density, its normalmap under lighting, if it's too bright or dark versus the ambient, if the color flows well into the other textures. ...Except not really, because r_materialOverride replaces all textures in-game, of course. As such I sort of have to remember how the level looked and try to focus only on the material I am trying to change.

I propose a new console command that would be something like r_surfaceOverride. It would combine the usage and syntax of r_materialOverride (eg "r_surfaceOverride "textures/common/example") with the ability of another console command, reloadSurface, to target a single surface under the player's crosshairs. The way it'd work is it would only replace a single material, the one you're looking at currently, with your DR-copy-pasted shader name, and if you looked at another surface and ran the command again, the former surface will go back to normal and the current one will get overridden.

If any developers want to chime in and opine on the technical feasibility of this proposal that would be great. If you, as a mapper, agree with me that a command like this would be useful, feel free do discuss it here. If permitted, I'll elevate it to a feature proposal on Mantis. And, of course, if something like this already exists, do let me know. 😛

  • Like 3

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

A skin is just a material overriding another material and that as you know doesn't not require the map to be recompiled, So what you want is a cmd that overrides a material for another like a skin does.  

Quote

 and if you looked at another surface and ran the command again, the former surface will go back to normal and the current one will get overridden

That is more involved but is possible, afaik you would need to save the original material name into a global var and make a global pointer to the surface, then when you call the cmd into another surface, the cmd gets the info from the global var and pointer, so it can change two surfaces at the same time, the old one into the original material and the new one into the test material, and do that everytime is called.  

IMO to make things less complicated code wise, it would be best if the user add to run the cmd on the surface again to change it back, no need to mess with global variables or pointers, would need the user to remember/save the original material name before doing the changes, but imo that is not hard. 

Link to comment
Share on other sites

I mean... sure, the skinning comparison is legitimate but a bit misleading since in DR editing parlance "skinning" only applies to models and not world geometry. As to the possible implementation I've also now thought of a find-and-replace type string (that is like the dialogue in DR or, aptly, like .skin definition files themselves) in the form of r_surfaceOverride "textures/fromthis" "textures/tothis". That might be a bit too much typing/copy-pasting though, I think a "look at what you want to change" approach would be faster and more user friendly.

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

Changing materials on brushes/patches and on models are two very different things.

For models, it should already work by saving new model and doing reloadModels. If you edit material, then you do reloadDecls, and I guess you should see updated material after that. Correct me if I am wrong here.

For brushes and patches it is harder, because 1) dmap reads them from .map-file, compiles them into surfaces, and writes them into .proc file, and 2) idRenderWorld loads the whole .proc file and saves these surfaces into "local models", after which it immediately creates idRenderEntity for every _areaN model (i.e. every area of the worldspawn). I'm not sure any reload mechanism is present here. So doing a honest reload is hard.

But if you are willing to point to the surface, then indeed it is easy to find it and change its material. There is already a command r_showSurfaceInfo, which finds surface under cursor and displays its name. I guess I can add surface index in this command. After that adding a command to override material of this surface should be easy. I would suggest name like r_surfaceMaterialOverride or r_materialOverrideSurface, since you only change material, but not the surface itself. By the way, do you want material changes to persist in the current game? If yes, then this must console command instead of cvar. I'm afraid I don't understand your idea about reloadSurface command: in my opinion one added command should be enough.

UPDATE: Ok, now I have found that reloadSurface is an already present command 😀

UPDATE: Committed changes to idRenderWorld::Trace. Most importantly, now it returns surface index, so replacing material should be easy.

Note that reloading texture coordinates is a big problem, since texture coordinates are stored in the geometry itself. Aside from some functional changes like "multiply all by (Cu,Cv)" or "add (Du,Dv)", nothing else can be done easily.

 

Generally speaking, I was thinking about this problem. We have reduced reloading problem on programming side by enabling "Edit and Continue" in Visual C++. It does not always work, but is still a big help and time saver. I was thinking of incremental dmap compilation: not clear yet how to do it. Sounds like a challenging task. Everything which changes worldspawn makes things complicated. Simple things like respawning changed entities are indeed possible (in fact, there is even some code for it, since builtin Radiant did it). Saving locations of movables during respawn is possible. Changing AI patrol paths is much harder, but probably possible too. It is even possible to make such changes in DR to immediately propagate to the game: the recently added automation protocol can be used to send commands from DR to the game.

  • Like 1
Link to comment
Share on other sites

Speaking of stencil shadows. Shadow volumes of worldspawn are loaded from .proc file ("prelight" models), that's why they don't update without dmap.

This is an optimization that you can turn off by setting cvar r_useOptimizedShadows 0. Better do reloadModels after you change this cvar. With this, stencil shadows should recompute without dmap.

Link to comment
Share on other sites

  • 2 weeks later...

@Spooks, do you still want this feature?

If yes, then do you think it would be more useful with temporary material change or persistent change (i.e. changed material persists until the end of current game session) ? I'm afraid the implementation would be different in these two cases.

Also, I wonder what other mappers think of it. Right now it seems that Spooks is the only one who tweaks the visual look in-game.

Link to comment
Share on other sites

  • 2 months later...

Hello! That @ apparently did not catch me at all, so here I am almost 3 months later checking the thread manually. Yes. I still think it's useful. Can you elucidate how temporary "temporary" is? Does it disappear on map change/reload?

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

A temporary solution would store information about replaced surface and material in some separate place, e.g. in cvar. You can only replace one surface at a time: if you decide to replace another one, the first surface will be reset to normal. In your proposal, the surface under cursor is always replaced, and if you move cursor, then it will be reset to normal, while another surface under cursor will get replaced, etc.

A persistent solution is possible with a command. You say "replace the material of this surface", and we change the material pointer in the memory of the model. So the old material would be lost, and the new material would take effect. Until you do something to reload the model (I guess needs TDM reboot or reloadModels command). Saving/loading game does not reload models, so the change will persist, I guess. Of course, you can apply the command as many times as you want, and replace as many surfaces as you need, using different materials if needed.

Link to comment
Share on other sites

I had the temporary solution more in mind, in that case, but I don't mean to imply that there'd be a constant cursor update - that is to say that the texture on surfaces would change as you look around. I meant more like how r_materialoverride does it, if you want another surface under the cursor to get replaced you have to look at it and input the new command again. Just clearing that up in case there was misunderstanding.

I do agree that another opinion would be valuable, how I would use it is not general enough to be extrapolated, I can see the use-case of this command being comfortably exhausted without the mapper having to reload their map again but I might be unduly generalizing. How I see its use is the ability to test one surface (a building facade, road, wallpaper) change against the context of others you already have put down in DR. Replacing multiple brush surfaces in-game might be extra flexible but like you said it would be harder to do and I think it overlaps into regular DR functionality at that point.

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

Please download this binary and test it.

The command is called overrideSurfaceMaterial, and it changes the material of the surface directly in the model. So all entities with same model are affected. Moreover, the change is persistent: I guess something like reloadModels all is needed to reset materials back to normal. TDM restart of course works too: the command never changes anything on HDD 😀

 

  • Like 2
Link to comment
Share on other sites

Things are pretty hectic over here, I wasn't on the forums for a week so even that ping might've not been a saving grace if I didn't log in to divert responsibilities from other things I gotta do... 😅

Anyway, yeah! The command seems to work alright, reloading the game properly resets the materials, but reloadModels all doesn't reset material changes on brushes, aptly enough. I'm not sure that's that important, though.

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

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

    • 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
    • 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
×
×
  • Create New...