Jump to content
The Dark Mod Forums
Sign in to follow this  
Spooks

"r_materialOverride" For Single Surfaces

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 2

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

 

 

Share this post


Link to post
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. 

Share this post


Link to post
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!

 

 

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Sign in to follow this  

×
×
  • Create New...