HumanShaders gives Godot projects a skin, eye and eye wetness shader to fork

Where to get it: the repository, the folder, and the demo page

There is no installation command to run, and there should not be. This is a Godot project with shader assets, so acquisition means copying files into your own project rather than installing a package.

The README points to two sources. The repository itself is the full project, including the example models and the model visualizer, and it tells you to download or clone only the content from the HumanShaders folder if the shaders are all you need. There is also a demo page on Itch.io that demonstrates the shader capabilities, which is the place to see the intended look before you copy anything.

A sensible first pass takes about ten minutes. Open the repository in a Godot editor that matches or exceeds the stated version, look at SkinShaderTest.tscn and EyeTest.tscn to see the shaders under known lighting, then copy the HumanShaders folder into your own project and re-create a minimal test scene for yourself, because the two test scenes live outside the folder you are meant to take.

Because the assets are copied rather than installed, the update path is manual. There are no GitHub releases to diff against and no version tag to compare, so if you want to pick up later changes from the author you will be comparing the HumanShaders folder by hand. That is another reason the folder boundary matters: it keeps the comparison small and mechanical.

The Scripts/ and Resources/ directories are worth opening too, since they sit outside the folder boundary and may hold the wiring that shows how the shaders are meant to be applied to a mesh.

Three shaders, and the scope that implies

HumanShaders is described plainly as a set of shaders for Godot to create realistic humanoid characters. The list of what actually exists right now is short.

The available shaders are a skin shader, an eye shader and an eye wetness shader. Three entries, which is a much clearer scope statement than the word realistic would be on its own. There is no claim of a complete character pipeline, no hair shader, no cloth, and no mention of subsurface scattering, translucency or any of the other techniques that a realistic skin implementation usually turns on.

That matters for evaluation. A shader library is easy to adopt optimistically and hard to adopt correctly, because the value is entirely in what the code gives you for free. Knowing that what is on offer is skin, eyes and wetness lets you judge the ratio of useful starting point to work remaining.

The primary language of the repository is listed as GDShader, Godot's shader language. That tells you the implementation lives in shader code rather than in a GDScript system that drives it, so the surface you fork is the shading model itself.

The intended audience is Godot developers making humanoid characters who want to look more lifelike than the default shading and who would rather start from an existing implementation than derive one. The author says to use these shaders as a base for your project, changing them to better suit your needs, which is a stronger statement about intent than any feature list: this is offered as code to be edited, not as a service.

Godot 4.5 and up, with a hedge about 4.4

The version support line is short and worth reading exactly. The README states Godot Version supported: 4.5+, and then adds probably works on 4.4.

That hedge is the kind of thing an author writes when they have not tested the older version and does not want to be blamed, which tells you something about how the project is tested. There is no compatibility matrix, no list of tested engine builds, and no changelog of engine versions the shaders have been ported to.

If your project is on Godot 4.4 or earlier, you are in the guessing category rather than the supported one. If you are on 4.5 or newer, you are on firm ground and the question becomes whether the shaders behave as you want in your own scene, your own light rig and your own shading setup.

The repository layout suggests a full Godot project rather than a loose asset drop. The top level includes project.godot, which is the Godot project file, along with Resources/, Scripts/, Shaders/, Models/ and the HumanShaders/ folder. There are also two test scenes, EyeTest.tscn and SkinShaderTest.tscn, and an icon.svg with its import file, plus splash_screen.png with its import file and a .gitattributes file.

Those two test scenes are the most useful thing in the repository for a newcomer, and they are worth opening before anything else. EyeTest.tscn is a scene for the eye shaders and SkinShaderTest.tscn is a scene for the skin shader. Each is a controlled environment where the shader is shown under known conditions, which is exactly what you want to compare against before changing anything.

The HumanShaders folder is the product boundary

The repository contains more than the shaders, and the author is explicit about which part to take. The README says this is the full project, including example models and a simple model visualizer, and that if you only care about the shaders you should only download or clone the content from the HumanShaders folder.

That single instruction resolves a question that otherwise causes friction. The rest of the tree, Models/, Scripts/, Resources/, the test scenes and the visualizer, is scaffolding for demonstration. The HumanShaders folder is the asset you fork into your own project.

The visualizer is worth mentioning because it explains how the author worked. A simple model visualizer alongside example models is a development tool, something that lets you inspect a mesh and how it responds to a shader without setting up a full scene. For a shader author, that is the difference between iterating on a look and iterating on a scene.

Two consequences follow for adoption. First, if you copy the whole repository into your project you inherit the demo models and their licence conditions along with the shaders, which is the reason the author drew the boundary in the first place. Second, if you take only the HumanShaders folder you get the shader assets without the test scenes, so you should recreate a minimal test scene of your own, using the two test scenes in the repository as a reference for what to look at.

The Scripts/ directory is separate from the HumanShaders folder, which suggests the shaders are delivered as resources with some supporting script layer around them. The exact split is something you can see by opening the two folders in a Godot project.

The licensing splits three ways, and one bucket has no clear terms

The licensing section is the most carefully written part of this README, and it is the part most likely to affect your decision.

The shaders themselves are clear. Human Shaders and its resources, meaning all the content inside the HumanShaders folder, are licensed under MIT and CC BY 4.0 Licenses. Two licences together, which normally means the code under MIT and the artistic resources under a Creative Commons attribution licence.

The example models are where it gets uneven. Digital Emily 2, a head scan by the USC Institute for Creative Technologies, has a license note saying the licensing terms for this model are not clearly stated on the source website. The README then gives the instruction directly: if you intend to use this model for anything beyond personal or non-commercial use, please contact the original creators at USC ICT for permission.

The third case is resolved. Infinite, a 3D head scan by Lee Perry-Smith, is licensed under a Creative Commons Attribution 3.0 Unported License.

So the repository carries three different positions at once. The code you are most likely to want, inside HumanShaders, is under permissive terms. One bundled model has terms nobody has clearly stated, with an explicit instruction to ask. The other is attribution only.

This is not unusual for a shader library that ships demo assets, and it is not the author's fault. It does mean the demo content and the shaders have to be treated as separate decisions, and that anyone planning a commercial title must resolve the Digital Emily 2 question with USC ICT before using that head scan, or leave it out.

Not actively maintained, and the author says so first

The README states the maintenance position without hedging: this is a work in progress and not actively maintained, don't expect frequent updates, or updates at all.

That is an unusual thing to put in the opening of a project README, and it changes how the repository should be evaluated. A maintained shader library is something you depend on and update when the engine moves. A non-maintained one is something you fork and own, and the README asks for exactly that behaviour, telling users to use the shaders as a base for their project and change them to suit their needs.

The repository facts are consistent with that statement. It is not archived, and the last push was on 2026-09-20, so there has been recent activity in the tree. There are no GitHub releases, so there is no version history to pin against and no changelog of shader changes to read.

That combination, recent commits without releases, matches a project where work happens when the author has a reason to do it rather than on a schedule. For a shader set, that is arguably the right shape. Shaders are visual code with many variables, and a sweeping refactor every few months helps nobody. A frozen set that you own, with a working starting point, has real value.

The catch is that you inherit the cost of engine upgrades. When Godot 4.5 and later change something in the rendering pipeline or in how built-in uniforms are provided, there is no upstream to fix the shader, and the person holding it is you.

When a shader set like this is the wrong starting point

Three cases make HumanShaders the wrong choice, and each one is a scope mismatch rather than a quality problem.

If your characters are stylised rather than realistic, the shaders solve a problem you do not have. The project targets realistic humanoids, and adopting a skin shader meant to approximate real skin on a deliberately non-photoreal character is a step backwards.

If you need hair, cloth, or any shading beyond the three on offer, you are assembling a character pipeline from parts, and this repository does not cover the rest. The missing shaders are not a small gap. A believable humanoid is mostly hair.

If you cannot fork and maintain the code, the third case applies. Since the project is explicitly not actively maintained and has no releases, a team that wants a shader library it can depend on and update from upstream has picked the wrong repository. Here, you would be copying a file into your project and becoming its maintainer.

There is also a demo to look at before committing. The README links a demo page on Itch.io showcasing the shader capabilities, which is the fastest way to see the intended result, and there is a model visualizer in the repository for inspecting the effect on a mesh without a full scene.

None of this makes the project bad. It makes it a starting point with a defined shape, and the honest question is whether three shaders cover enough of your character that forking them is cheaper than writing your own.

Editorial conclusion

Adopt HumanShaders if you are building a realistic humanoid character in Godot and want a working skin, eye and eye wetness shader to start from rather than write from scratch, and if you are comfortable owning the code and its updates yourself. Do not adopt it if you need a maintained shader library with a support path, because the README states the project is not actively maintained and that updates may not come at all. Before you commit, check which Godot version your project targets against the stated 4.5 or higher, and read the licensing note carefully, because only the content inside the HumanShaders folder is under MIT and CC BY 4.0 while the bundled Digital Emily 2 model has no clearly stated terms and requires permission from USC ICT for anything beyond non-commercial use.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. matmadness/HumanShaders on GitHub
4. README