Corvus262

Yeah, I see how the repo structure could resemble a Blender addon. The blend file has everything set up for generating color ranges from a provided palette, the python script is completely separate and doesn't interact with Blender at all. Hopefully that clears the confusion :)

The program which you're using to install mods most likely can not recognize the directory structure of the provided repository (if it even got that far). To check out this mod, load the corvuspal.wad from the wads directory in the repository using your sourceport of choice. To download the whole repository you can use this link: https://github.com/theraven262/doom-palette_tools/archive/refs/heads/main.zip Unzip the downloaded file and navigate to the wads folder inside, there you'll find the palette wad.

The effect of the color changes is immediately noticeable and I really like it, I was trying to make something like this for a while and I never managed to get it to look this good.

Yeah the ranges which I've constructed were made for my edited palette, thats why the yellow fades suddenly trough red/orange now. But the rest is fine I think. I'm afraid that I can't properly explain the basics of how to run python scripts, google should know best. Especially considering that the process differs based on the operating system, and I don't have a windows machine at hand to be able to test for the most common case. I think that I can safely assume that linux users will know how to run scripts.

Yeah and the compositor is better equipped to deal with colors in general, I don't know why I didn't use it originally. I'm not too worried about mipmapping issues, as I've lowered the filter size as much as possible, but will still switch to the compositor just in case. What part of running the script do you find to be confusing, or think would be confusing for other people? I know that the naming scheme of the input files is weird, because of Blender, but not much else. Also your results look better than I imagined the default palette would render to, there is still some weirdness with the browns in the low red range but that can be fixed by removing the brown from the available colors in the compositor. That yellow is weird though, and I have no idea whats causing it. [EDIT] The example is actually your custom palette I assume?

Yeah openCV, colorsys and numpy are used. For the color management, I just assumed that if I don't do any changes to the input image and then render, I'll get the same thing as the output. This might not be the case though, but I need to do some testing to confirm. [EDIT] You were right, there is filmic view transform applied to the scene. Without it, it works as initially expected. I need to adjust the tinting of the colormap now, as this makes my current node setup behave completely differently. [EDIT2] The files have been updated.

(okay, there is a bit of python holding everything together as well) The mission objectives are simple: 1. tint playpal ranges to look exotic 2. make palette ranges fade to blue when low and orange when high 3. generate a colormap that uses hand-picked ranges 4. and most importantly: make it automated so we can iterate fast. (objective one is skippable if you’re boring) (also I won’t be describing how to do objective one) Repository Link If there was anything else to the introduction, I’ve forgotten it, SCREENSHOTS! Hello Doomworld! The ability to modify the colormap and the palette allows for so much control over the general look and feel of a wad that I’m surprised more projects don’t do it. Granted, it can be hard to modify certain palette ranges in such a way that some textures don’t get weird, but even just hue shifting the blue, as at least a couple of wads do (at least that I know of), can go a long way. Going deeper So, raven colormaps (and strife) use hand-picked ranges for colormap fades. That means that the color red, for example, can only fade to black trough the shades of red, hand-picked, NOT brown. Usually, when you generate your colormap in Slade, all of the colors in the playpal are available for generating this red range. This allows for those weird brown areas in the red part of the default doom colormap for example. And I don’t like those brown areas in the red colormap. Because of that, I wrote a script that assembles the whole colormap from the provided color sets for every range on the playpal. That is the python script you can see in the repo. Cutting up the playpal and selecting ranges takes some painstaking effort, and I’m pretty lazy so I made Blender do it for me. It took quite a while but now we can all experiment with this stuff and fast. Here’s the comparison between the default PLAYPAL and COLORMAP (left), and my edits. Going even deeper This cuts up the palette. Don’t worry, the messiness is normal. Let me introduce you to the intricacies of operating my constructs. First open up the .blend and just render (this should just work), it will create a directory where the outputs are stored and that should be in the directory of the .blend. Then, move the python script into this new directory and run it with the number of ranges as the only argument. The number of ranges in the default doom case (according to myself) is 22. This depends on how you cut up the palette. You should then end up with a PLAYPAL and the top part of the COLORMAP (to which you should append the additional rows for invuln and whatever else). Put the stuff into a wad, name it accordingly and convert the COLORMAP into a flat so it becomes an actual colormap and then you’re set. Going to the very bottom of things Unfortunately, in order to edit this stuff (apart from the python script) you need to have some knowledge of Blender’s node systems. Though depending on your background some of this might be intuitive for you. The material for the plane handles palette colorization, didn’t get to organize the stuff terribly well, so tweak it and see what happens. The compositor handles cutting up the palette, you’ll figure out the naming scheme from there and the method of assembling the color sets, I’ve provided the BTSX example as well so that you can see how the approach works in general. The doom (my edited version) and btsx palettes come packed with the file, you can select which one you want to render by connecting it to the node tree. The python script also takes up the second argument which describes the lightness falloff curve’s curvature (not a mathematician, don’t know what its called) and the default is 1.4, here's a graph. So you can see that 1 represents a linear falloff and everything below 1 represents a bad fallofff. You can go up to 2. Keep in mind that color choices are about as subjective as one can get, and therefore you yourself can probably achieve more pleasing results by tweaking these parameters. Thats all for the first post, I’m interested in your results and am here to help if I’ve made a mistake somewhere. Good luck!