better decals
Issue #792
resolved
I never used it so may be I miss something. But I followed the instructions on the blog and when I make a decal the null is generated but the material nodes are not.
http://diffeomorphic.blogspot.com/2020/12/decals.html
Comments (41)
-
repo owner
-
reporter
As for commit fd95740 I suppose it works as intended, but there are a number of issues we may want to address.
- The decal null could start with rotation (90,0,0) so to project the image along the figure front instead of the ground, that’s a better and more intuitive start.
- The combined node should be a mix instead of multiply.
- I don’t know how to address this but the decal is projected both to the front and the back of the figure, that’s not what a decal should do. If this is an intended limitation then should be explained in the docs.
-
The double sided issue can be resolved too, although tweaking it might require some manual input in some edge cases. Basically, you can use a spherical mask centered on the empty and then a color ramp to adjust the contrast. That way, by adjusting the radius of the mask, you can remove one side.
Alternatively, you could maybe do some vector math and ignore the surface whose normal points away from the empty. I think the first solution might be better in general.
-
reporter
Otherwise we can go with the usual uv mapping that will map one side correctly, but this way we need to drive the location and scale with the null and “translate“ the null coordinates to the uv map coordinates and have no idea how.
-
repo owner
The empty is now rotated.
The blend mode is now an option, either mix or multiply. I sort of like multiply; you can use white for transparent, and if the decal is a tattoo or a bruise, it is typically darker than the skin. If you want some other blend mode, it can easily be changed in the node editor.
I never noticed that the decal gets projected on the back too. Well, decals seem to be tricky in DS too, so if you want high quality maybe you should just go for layered images or geoshells. One coudl also solve the issue manually by assigning the faces with the decal to a separate material
-
reporter
Xin, may you make an example of the color ramp trick please ? Personally I didn’t get it.
-
reporter
Thomas, as for the issue with crossing materials we could use a shell. Same setup. We can also have as many decals as we want inside the same shell as shown below. Then it depends if we want different materials for every decal, apart the texture I mean. But this works fine to cross materials.
It remains the issue with backfaces, if Xin may explain better his tricks to deal with it.
-
reporter
- changed title to better decals
- marked as enhancement
changed the title since it’s becoming a discussion on how to improve decals
-
repo owner
Decals crossing boundaries are implemented in the last commit.
-
- attached decal_depth_mask.7z
Here are two possible solutions for the double side issue. See the modified node groups in the material. Also you need Blender 3.0 to open the file, although the methods work in older versions too.
The solution involving normals is not possible without adding unnecessary complexity I think, since you can’t get another object’s position in world space in the shaders, at least without using drivers, but that would be ugly for this.
-
reporter
As for commit 1b1ae93 there are a couple issues.
- We don’t want to instance a decal group for every material. We need to share a single decal group instance among materials. So instead of “decal”, “decal.001”, “decal.002” etc we only have “decal” in all the materials.
- The “skin” option selects the same materials as “skin-lips-nails“, also personally I’d let out the eyes materials from the skin selection.
As a side note using a shell instead of separate channels would allow to use one single “decal“ shell where we add decals, as shown in my example above. Instead of a number of groups. But I understand this is a different design and may require more planning.
-
repo owner
The button select different materials for G8F. Unless you have merged materials or changed the viewport color of the lips and nails. The same UI is used by the material editor and Make Udim Materials (where I introduced a bug yesterday).
-
repo owner
There is now only a single node group for each decal. Also, the influence can be controlled in the visibility panel, if the decal stretches out over several materials.
-
repo owner
Implemented Xin’s trick with the gradient texture. I don’t get how it works, but apparently it does.
-
Last commit seems fine, although the “depth mask” needs to be connected to the “mask” output of the group so the user can visualize the mask easier. Currently, that output is not connected.
Another thing which should be pointed out somewhere is that the user might need to tweak the scale of the input to the gradient texture, and that needs to be done from within the node group, otherwise you would need to tweak the scale on all instances which would be very annoying. Don’t know if adding those scale inputs to the visibility panel would be better.
-
reporter
I believe I get how the trick by Xin works, thank you Xin this is a great trick !
As for commit b7274b0 there are a couple issues.
1. MATERIAL SELECTION
The material selection doesn’t work fine here. I’m using a standard G8F straight from daz, no modifications. In blender 2.9 I get skin and skin-lips-nails to select the same things, that includes the eyes and inner mouth materials that are probably not needed but this is a minor issue. In blender 3.0 it doesn’t work at all.
edit. Blender 3.0 does the same as 2.9, I didn’t update the addon in the 3.0 folder that’s why it didn’t work.
2. DECAL DEPTH MASK AND GIZMO
For the trick by Xin to work it is important to set the scale for the gradient vector, so to get a sphere “squashed“ along the z axis. Otherwise the sphere mask will not be able to stay close to the surface. We can use (0.1,0.1,1.0) that works fine enough. The user will be able to adjust the depth by changing the distance of the gizmo from the surface.
Then as another neat trick, we can use a cube gizmo for the decal that will give us a visual feedback of what we’re doing. We need to set the cube size = 1 - threshold to match the depth mask, so in our case 0.5 does the trick. Then the user can adjust the scale parameters as needed to fit the decal, but I’d suggest to start as default with (0.5,0.5,0.2) that’s a decent start.
As final bug report the depth mask output is not connected.
-
repo owner
The issues have been addressed, apart from the problem with material selection which I don’t understand and don’t see myself. The selector uses viewport colors to determine if something is a skin material, so maybe that has been messed up. Will look into this later.
There is also a new option to add a mask, for the case that decal transparency is given by a separate texture. The mask file is set just below the Make Decal button, since you cannot launch a new file selector from within another file selector.
-
reporter
Commit a1bf271 seems to work fine here, that’s a nice improvement for decals. Just a couple notes.
As for the material selection I use the “original” viewport colors in the global settings, that’s why it doesn’t work for me. If using the “guess” colors is a requirement then it should be explained in the docs.
As for the file selector for the alpha map, a better design would be a decal panel with two file selectors, one for the decal and one for the alpha. That is, you press “make decal“ then the panel opens with the decal options and the two file selectors.
-
Also, keep in mind the other option in the .blend (the one that masks only along one direction of the empty and uses only one parameter) in case the gradient option is annoying to tweak. That option is also cheaper in terms of performance.
-
repo owner
Material selection should work with original colors now. However, you need to reimport the character, because the material type is stored in a custom property.
That it would be better to launch a new dialog with two file selectors is debatable. It means an additional step in the common case that transparency is included in the decal. The same UI is also used for favorite morphs in easy import, and in that case it would be difficult to change since multiple files can be selected. So I don’t think I will change the UI.
-
reporter
Commit 6335e32 works fine for me. Xin if you have nothing more to add I’ll mark as resolved.
-
repo owner
I did some additional tweaking. You can now have several copies of the same decal, controlled by different empties.
Xin, I made a trial implementation of your other mask, but I found it very difficult to control, so I think it is enough to limit ourselves to one method.
-
reporter
Commit d466016 works fine here.
Just for clarity, in my opinion we don’t need to expose the scale, because the cube gizmo approximates fine enough the central part of the squashed sphere that’s where the decal is mapped. So the front and back faces of the cube is where the decal is placed. The user can move and scale the gizmo and the sphere will be moved and scaled along.
It doesn’t harm to have the scale exposed but it’s not needed.
-
reporter
As for commit a407fd9, this is just to point out that the cube shape allows to know exactly where the decal is placed, because the front and back faces of the cube delimit the depth map. While the cone shape doesn’t, so this way we lose some control.
edit. Also a note about “parent to vertex”.
While it is possible to use decals this way, it is not what decals are designed for. That is, decals use uv projection instead of uv mapping, this means they don’t get distorted but also don’t follow the geometry deformations. So usually decals are used to add details to static objects such as vehicles and props. While to add details to figures we can use layered images and/or shells that are uv mapped.
At the end the only difference between layered images and decals is the uv transformation, that is, decals don’t need a uv map.
-
repo owner
Reverted to flattened cubes in the last commit and updated the documentation.
-
reporter
- changed status to resolved
Marking as resolved for now, will probably update to support the daz decals but I want to finish the metals first. Thank you Thomas and Xin for the nice improvements.
-
reporter
- changed status to open
-
reporter
UPDATE. A FIRST SUPPORT FOR IRAY DECALS
This is aimed as a first basic support since the decal options in iray are so many that it may be better to implement them in time as we need something or there's request from the daz users. Anyway once we got the latest improvements it is quite straightforward to get iray decals in blender. As a bonus the cube gizmo is already the same as the iray gizmo.
Below a simple test scene decals.duf and the equations. Please note that the 0.5 fixed size of the cube gizmo is needed to match the depth mask.
# a iray decal is implemented as a shell so all the surfaces are affected # for now we ignore most options and we always convert as: # face mode = "front and back" # two sided = "off" # clip mode = "position" # projection type = "planar" shell material = decal front surface shell priority = decal priority cube gizmo size = 0.5 cube gizmo (location, rotation, scale) = decal (location, rotation, scale)Please note that above we ignored the clipping size (depth, height, width). Because the daz user gets the scale to fit the decal so changing the clipping size is not needed, thus it's usually left at the default 50 cm that matches our 0.5 m cube gizmo. If we want to support the clipping size then the equation is below, where the 2.0 factor is 1.0/cube gizmo size = 1.0/0.5. But this should not be necessary for the common use of decals in daz studio.
# alt equation to support the clipping size cube gizmo scale x = 2.0 * decal clipping width/100 * global scale * scale x cube gizmo scale y = 2.0 * decal clipping depth/100 * global scale * scale z cube gizmo scale z = 2.0 * decal clipping height/100 * global scale * scale y
Of course Thomas let me know if something is not clear. Please note that in the test scene we will not support the decal reverse surface in the back face of the plane, because we ignore “two sided = on”, so in our implementation the back face of the plane gets the same material as the front face.
edit. As for the shell priority, daz decals always stay under daz shells, because shells in daz studio get a distance from the surface while decals don’t. So first come decals over the surface with their priority, then shells over the decals with their priority. Below an example where the shell covers the decal.
-
reporter
- attached decals.duf
- attached decal.jpg
- attached decal_2.jpg
test scene for iray decals
edit. beware that “decal_2.jpg“ was renamed by the uploader, the original name is “decal 2.jpg“
-
repo owner
Implemented in last commit. The back sides are ignored, so the decal on the plane is not inverted, which it isn’t in DS either if you look at it from the right side.
I am somewhat confused about the scale inputs, both for the mapping node and the depth mask, but the test scene seem to come in right.
-
repo owner
These decal materials are quite different from the ones created with the stand-alone tool. Those decals are essentially layered images, whereas the iray decals are full-fledged materials and therefore correspond to shell nodes.
-
reporter
As for the scale, the idea is that the gizmo approximates fine enough the central part of the sphere mask, that’s why we use a squashed sphere. The decal will be projected only on the central part anyway so we don’t care of the rest of the sphere.
Going to test the new commit ..
edit. As for the materials no, the daz decal materials are full iray materials, indeed we need a geometry opacity mask to create a transmapped decal. There’s no difference with other materials.
-
reporter
As for commit 97f4735 there are a couple issues.
1. GIZMO SCALE
It is not the scale in the decal node that we have to change, that is fixed and manages the depth mask. We only have to change the scale for the null. Also somewhat the plugin gets to double the scale for the null. I have a 1.0 scale in daz studio and a 2.0 scale in blender.
gradient scale = 0.1,0.1,1.0
output scale = 1.0,1.0,1.0
2. MATERIALS
The decal materials have to be full iray materials, the decal is a “normal“ shell as any other shell. I attached another test scene with a transmapped decal that now doesn’t work because there’s no geometry opacity.
-
reporter
- attached decals-2.duf
better decal test with transmapped decals
-
repo owner
The changes have been implemented in the last commit. However, something is still wrong, because the star decal is visible on the other side of the cylinder. That can be fixed by changing the scale of the depth mask node to (0.3, 0.3, 1).
-
reporter
Commit 86649b3 is not good. But I believe I got it now.
The reason why the scale is doubled from daz to blender is because the 0.5 m cube gizmo is not 0.5 but one meter. So it seems 0.5 is the "radius" of the cube, instead of the "diameter".
The reason why the star decal goes through the cylinder is because, for some reason, the decals imported from daz project along the Y axis, while the decals generated in blender project along the Z axis. So for a different projection we need a different "squash" of the sphere mask.
So to fix the issues above we need the setup below. There's a 0.25 cube size, with the relative 0.75 mask threshold and 2.0 map scale. And the modified (0.1,1.0,0.1) mask squash for the Y projection.
As a side note, if possible it would be nice for the decals to use the same conventions. So for example Y projection with 0.5 meters gizmo for all of them as the fix above. Instead of having Z projection with 1 meter gizmo for the blender decals.
-
repo owner
OK, I think I got it now. Both daz and blender decals work with the same mapping node group now.
-
reporter
Commit b292fda is great I believe this is a good start for decals, thank you Thomas for the fixes.
I get an error when I try to use decals together with shells though. Test scene included g8f-decals.duf, it’s G8F with a shell and a couple decals.
-
reporter
- attached g8f-decals.duf
decals with shells
-
repo owner
Fixed in last commit, and some other things too. The mapping and decal node groups are now reused by all materials. But not if you reimport the character, so the decals for the two meshes can be moved independently.
-
reporter
- changed status to resolved
Commit 764e7c3 does great. I believe we did it thank you Thomas for your patience and fast fixes and Xin for the great tips.
Marking as resolved for now and reopen if we need to add features or fix bugs.
- Log in to comment
It looks like I only tested this with a principled node. Fixed now.