I think this is happening because of the bit depth of the image.
When creating a new image for displacement map on blender, mark the 32 bit option.
I think this is happening because of the bit depth of the image.
Compression can be a big problem with maps. The things which help to make a picture look good to the human eye while remaining “a small file,” can play pure-hell when that “picture” is actually being used as a source of data. That’s what the “OpenEXR” file-formats are all about. You want to do all of your data preparation and manipulation with as much numeric resolution as you can muster (e.g. “float”), and keep that data pristine while you manipulate it. Only when these manipulations are completely finished do you reduce it, “all at once and in one step,” to the necessary resolution for use. (Keeping the original source-data untouched.)
You really never want to use (lossy …) compression at all. Compression introduces noise, and in these contexts you can plainly see it.
Ive you use Node Wrangler you can already see it happening in the material preview. There is banding happening, this affects the displacement. Im not really into nodes so i hardly know enough to fix this. My gues the values are wrong. Displacement works with black and white and values in between. But your adding green into it, im not sure if the green is seen as color or as black/white channel by itself. Perhaps convert it to black/white than input it in the multiply value?
PS i check the github page, he notes him self “This addon doesnt support shape keys”. Hmm is it reallu usefull than?
Ps have you tried using a displacement modifier and than using those vertex groups as input. I think it looks a bit better than. What i dont get is when you devide the channels. why it shows also red in the green?!
Another thing i see, what i dont understand. Is how Blender separate the channels RGB. If i look at photoshop it does this complete differenrt.
Than i noticed why, you input the color vector and seperated those… duhhhh
Why not test making black and white maps yourself than? Im not sure what this addon really does in your workflow. You dont seem to be using the vertex output this addin makes???
PS what a weird repo that is, he doesnt really explain how to use it. He should give a bit more info. Perhaps its because im not English speaking, i had to figure out the color vertex output myself, reading it twice my lightbulb went on
It looks like there was an update to the Tension Map Script a couple days ago, but upon trying it, i can’t get it to work. It creates the vertex groups and vertex colors, but there’s nothing in them. Am I missing something, or is it just broken?
EDIT: It looks like it DOES work, but it doesn’t work on objects rigged with Mesh Deform.
@rombout It’s been a while since I tried this addon, but yeah I think running it through the Separate RGB node essentially turns the green and red channels each into black and white values. Interesting to note that shape keys aren’t supported yet, I suppose that might have something to do with it, even though it does (or did) work with them, despite the creasing.
@Ascalon Good to know it’s still being developed! I just tried the update and it’s clearly not working properly with shape keys, so I suppose there’s nothing for it but to continue waiting patiently.
I wish there was a faster and easier way to use this !
Yeah it confirmed does not support Shape Keys (but may in the next version), but it does actually support Mesh Deform, it just didn’t work for me because I had a mirror modifier on my clothing. See here:
Maybe you guys might want to look at this and see if it can be salvaged? It was built for this guy’s thesis as a muscle system he was building from scratch, but, he uses a tension map as part of it.
It’s from an older version of blender (2.6, I think?) so, if it works at all, it will require a little porting. But, for his purposes, it works. I wasn’t able to check if it was relying on the in-built stress map, but I didn’t get the impression that it did when I was skimming his actual written paper?
Also, I’m not seeing it on blendswap right now, but I swear there was a working demonstration there, or somewhere.
I have a whole massive folder of old experimental .blends I downloaded a while back, and I’m pretty sure there is one in there that is a post-2.49 tension mapper. I will see if I can find if that’s real or not…
Is this it? https://www.blendswap.com/blend/4902
I believe it is, thanks. I must have just not been paying very close attention. I’m going to get a copy of Blender 2.6 and take a peek at how he accomplished this and see if there is anything salvageable, of if maybe it’s just useless to the question at hand.
Welp, I had another crack at this with the latest version and the creases are still there. Bones are not immune either.
It seems like it’s lacking some sensitivity to deformation as well. I saw that the dev can’t afford much time to work on it, so perhaps it’s time for me to put together a case for it to be built into Blender proper, after all it already was once upon a time.
It’s not an ideal solution, but have you tried using the displacement modifier instead of material nodes? I did a simple test and it seems to work for shape keys and for bones without the creasing artifacts. Your scenes end up heavier because you need to subdivide the mesh with a subdivision modifier, but until the displacement material nodes behave, it might be an option.
Funny you should mention that, because I found out about it a couple of days ago and was nearly ready to report my findings. Thanks for mentioning it though.
For displacement this gets rid of the creases, but there’s another problem: it usually crashes after rendering each frame in an animation, and if it makes it past one frame the add-on doesn’t update. So essentially you have to render an animation manually, one frame at a time, pressing the “Update tension map” button as you go.
I’m not sure if it’s handling shape keys properly either, I have to do some more tests with that. Bump maps still cause creases of course, but they’re not as evident in cylinders for some reason.
The only way i’ve found to mitigate this is to add a highlight roll off to the color channels and apply some mid levels dither with a noise, it’s far from perfect and pretty heavy (and a bit noisy), but from afar and on some more lesser distorted geometry it could work.
All of this is a sign that it’s just the node color itself has a weird interpolation and creates hard transitions where there should be a smooth gradient and it’s clipped in a very narrow range. The highligh roll off works well only because it’s smooths out the hard creases (clipping values) but some abrupt changes can be seen in the the medium lights as well and there’s no way to get rid of them without affecting the others (you can see what i’m talking about in my example because some creases are still there even with the noise dither)
It’s either a blender problem (I’ve always found the weight painting to have some pretty nastry looking gradients on the ends, always ended up smoothing them like crazy), or it’s the addons problem that needs to smooth the interpolation a bit (or maybe even both).
You can easily see it on this weight map of the squeeze vertex group, you already know where the creases are gonna be.
Everything lacks resolution and it looks like everything is clipped in a very narrow range. Nothing should be hard blue or red, especially this fast, if you push the displacement a little bit you’ll very quickly start to see the limits.
Yeah it’s definitely not giving quality results - and why doesn’t it have an effect on the squash that’s happening on the X axis?
That’s been bothering me for a while.
You’ve managed to get it looking better that I have at least, so done well done on that front.
That’s true, x axis is completely ignored but it could be something with the project idk
Anyway I see that your RCS suggestion is getting traction, some dudes are already on it, I’m hyped
@shteeve made an updated version of the add on, not home rn but maybe the creases are gone ?