Shaders - HWRM/KarosGraveyard GitHub Wiki
consolidating all HWRM shader info
HWRM uses a psuedo PBR rendering system.
https://www.marmoset.co/toolbag/learn/pbr-theory
http://www.marmoset.co/toolbag/learn/pbr-practice
https://www.allegorithmic.com/pbr-guide
Useful shader threads on GBX forums
https://forums.gearboxsoftware.com/t/shaders-custom-shaders-awesome-shaders/127309
https://forums.gearboxsoftware.com/t/background-usage-of-cosmic-bg-and-cosmic-bg-a-shaders/1585904
https://forums.gearboxsoftware.com/t/textures-what-is-each-specific-shader-is-used-for-more-specifically-when-should-it-be-used/1776957
https://forums.gearboxsoftware.com/t/hwrm-shader-blender-cycles-v1-0/1317295
https://forums.gearboxsoftware.com/t/hwrm-2-0-per-ship-shader-controls-system/1521655
http://www.moddb.com/mods/resurgence/downloads/hwrm-shader-blender-cycles-v10
most common shaders
- ship: pretty much all regular ships
- badge: applied to polygons where the user selectable badge texture will show up
- thruster: allows engine on/engine off textures
- matte: used for many background/static map objects. does not interact with hyperspace effects
important shader related files
- SHADERS.MAP - used by HODOR during HOD creation. defines what shaders as declared in the DAE use what textures, and how they combine in the final HOD.
- HOD_ALIAS.MANIFEST - located in data > shaders, associates .surf files with shader names that are referenced in 3dsMax when creating the DAE (see above).
- MOD_ALIAS.MANIFEST - same function as HOD_ALIAS.MANIFEST, for use by mod authors. Place any custom shader names here.
Texture and Memory Considerations from Bitvenom (http://forums.gearboxsoftware.com/t/update-and-a-bit-of-a-tease/1203614/394)
Yes and Yes, I think. I mean, not all content is loaded, certainly. And if you can only have 2 players, well, you can only have 2 players :slightly_smiling: But make sure you take into account stuff like your backgrounds, and FX... Our backgrounds are typically 40MB without any planets or extra stuff, up to 120MB with all of the fun stuff - a 'plain' background over 50MB is probably just an example of poor material/texture use... For example a raw Cube instead of much, much more optimal Sphere. In addition, consider the sorts of detail your background has/needs... You can use stars or even cut-out overlays to provide details on top of a MUCH lower-res base background. It is very easy to add new stars for hero items like small nebula or constellations - as opposed to pushing your background res high enough to make those sorts of things sharp. For us, our most complicated backgrounds are in Campaign maps - we know exactly what will be in that level. For MP, often the most basic maps are best - leave the performance for other things. I've seen a fair amount of 'Cube' constructed maps - but those are insane: We use a single 4kx2k texture for our basic backgrounds - they often look amazing. As noted before, the stars and smaller details can be sharp as just extras not actually pixels in the background texture itself. A 'Cube' is going to be 2kx2k or more, per side - So that's 3x more RAM used, where often the top/bottom aren't seen. It's not only way slower to draw/render, it's wasteful - plus, the pixels for any given texture vary in screen-space size because they're smaller farther towards the edges of the cube. For FX, the balance is similar - use low-res textures when you can for things that aren't sharp, stick to only a size that you require - bigger is NOT better. And lastly, consider UI - here's another case where being conservative is king. That's because UI is ALWAYS loaded. Sure some of the ship-specific stuff only comes along with loaded ships (ShipIcons, etc) - but in general, super HQ UI art is burning your budget. Ship Icons are a great spot to screw up as well. Some authors insist on using big 'view' graphics - when often the on-screen size doesn't justify it. Or, they use non power-of-2 textures and choose shapes/aspects that waste RAM, often the same mistake over and over for each ship loaded - compounding the waste. A 512x256 preview icon is probably more than enough for most uses, and as a DDS ends up being tiny. You can scale it to 1024x512 easily - which is a substantial portion of even a 4k screen. Sorry to harp - but I get really cranky when I see artists burning budget without any regard for a balance of end-result vs performance. The budget in this case is just raw RAM - so if your LODs have unique textures, they're making the pressure for memory as a resource worse. Enough to matter? Probably not. As for LODs - the old advice was to not bother. However, the next patch doesn't support Goblins any longer - they're not an engine feature at all. We use our first LOD as the ship+goblins, and our 2nd LOD as the ship - then lower as required. So we're using LODs a bit. Not a ton, but some. I want to say we're at 1.7GB (last time I checked) - with 4 races in MP. There's not a ton of RAM left after that. If you double that (8 races) - and use races that are (aggregate) 50% bigger - that's like loading 12 races (8*1.5) - where in theory you had room for... 5? Nah, there's TONS of room - but games have budgets. We delivered a game in our resource budget at the highest level possible. If you double the content (pixels, polygons, etc) - and not the budget, bad things will happen. The budget is largely a limit of the type of engine/exe (32bit) that we are. So Mod authors can add more, but it can come at the cost of having to use lower-res textures, etc. You can't clone the races the game shipped with and then make them '50% bigger' just because you want more pixels without having to account for that somewhere.
Shader suggestions from Bitvenom
Shader values can be connected to navlights, allowing the ability to alter navlight visibility via LUA You can also use Material PARAM[] nodes in the DAE to change the shader values from outside - something I see almost nobody using... And that can be very, very powerful in this context. I think that is used in a few example assets?
Look at Asteroid_3 for an example. You need a HOLD_PARAMS node under your ROOT_LOD[0] node. It acts as the parent for the parameter tweaks.
MAT[Asteroid3]_PARAM[fadeWindow]_Type[RGBA]_Data[.25,0,.75,0] This sets the fadeWindow (it's linked to the asteroid resourcing progress effect) uniform of the material Asteroid3 to the new values. (I don't think it's actually a color like RGBA, it's just 4 float values (Vector4)).
Any property exposed in the .surf file for your material can be overloaded at the material level from within the DAE. You can make glows darker, affect the spec curve, etc. Anything the .surf has made 'public' - in effect. And if you find one you want public, but isn't - do it local to your mod, that's very easy too.
vert - vertex shader
frag - fragment shader, receives inputs from vertex shader
prog - links vert and frag
surf - texture hookup
imp - config/options (implementation) logic
New Start
H1 Shader Pipeline Documentation The HWR Shader Pipeline uses GLSL (instead of HLSL). There are mod_ counterparts for many of the .manifest files so that modders can isolate their information from the stock game files.
H2 Globals Globals exposed and used for the shaders are listed in data > shaders > named_globals.manifest - there is a mod_globals.manifest as well. Most of the global values are self-explanatory or suitably documented in named_globals.manifest, others requiring more detail can be listed below.
lightCore - used for the primary level lighting - float28 arranged like so, with .w values unused. [0] ambient light location [1] key light location [2] key light diffuse color [3] key light specular color [4] fill light location [5] fill light diffuse color [6] fill light specular color
H2 Config To add a new graphics option (this includes enabling the use of a new screen-space shader), you must alter several files.
- add the option to ot_video.lua in data > ui > newui > optionstabs using the formatting examples in that file
- add the new option to the hide/show lists in fegameoptions.lua and ingameoptions.lua in data > ui > newui
- add the new setting to dev_config.manifest (or mod_config) using the formatting examples in that file
- if setup correctly, the new setting will generate a save state entry in playercfg.lua (in bin > profile)
H2 Layout bindings 0 - vertex position 1 - mesh normals 2 - mesh normal tangent information 3 - mesh normal bitangent information 6 - uv map 1 information 7 - uv map 2 information
H2 Matrices Keylight Altlight Projection Modelview Camera Cameraproj Lastcamera Lastcameraproj
H2 SURF files depthFunc options: always less gequal lequal cull options: none front back fill options: poly polys points lines
H2 Textures These are the most common textures used for ship and thruster shaders. Other shaders use additional custom maps. Refer to SHADERS.MAP file for full listing. HODs automatically share textures with the same name to reduce memory load.
DIFF = standard diffuse map. No alpha channel.
DIFX = diffuse, thruster shader "off" status
REFL = RGB channels (grayscale) | black = non-reflective, white = fully reflective
SPEC = RGB channels (grayscale) | black = not shiny, white = very shiny
GLOW = RGB channels (grayscale) | black = no self-illumination, white = fully self-illuminated
PAIN = alpha channel (grayscale) | black = metal, white = paint (?)
STRP = alpha channel (grayscale) | black = no stripe color, white = stripe color
TEAM = alpha channel (grayscale) | black = no team color, white = team color
GLOX = self-illumination, thruster shader "off" status
STRX = stripe color, thruster shader "off" status
TEAX = team color, thruster shader "off" status
SPEX = specular, thruster shader "off" status
REFX = glossiness, thruster shader "off" status
NORM = Standard normal map. No alpha.