0
$\begingroup$

I expect to be able to "texture paint" in the bump-map slot on 2.8 and have my changes visually reflected -- i.e. if I paint a bump on the cube in the right-hand view, it should look like a bump immediately without changing modes. That expectation comes from this online tutorial, although it seems to be using an earlier version of 2.8 with different interface widgets.

But that's not what happens: when I paint a bump in "Single Image" mode: 1st picture ... then I always get the error message shown in the top picture: "Missing Textures, detected!" However, if I switch the mode to 'Material': 2nd picture ... then the brush color is reflected on the cube, but it's shown as a color change, not a change to the normal height. I can switch modes to see the change as a bump, but that's tedious and makes it difficult to paint any complexity for all the mode-switching.

I've ensured that there are image files for the diffuse and bump map, and they've been saved before the experiment is attempted.

This problem means that it really isn't possible to interactively 'paint' bumps in a visual way, because I cannot see the effects of my brush without changing modes. It seems clear that this is not the design intent of the software.

Am I doing something wrong, or am I seeing a bug of an unfinished product?

$\endgroup$
  • 1
    $\begingroup$ Are you sure your images are connected correctly in the shader editor? How is your bump image connected to your shader? It shouldn't be connected to the color input but be connected to a bump node height input and fed to the shader normal input. Also, if you see the tutorial example he is using the LookDev preview with Eevee and I have no issues painting there on my end. If you are using the flat shading, you won't see the effect of the material, ony a single image at a time. $\endgroup$ – Craig D Jones Feb 13 at 13:48
  • $\begingroup$ @CraigDJones: thanks for the response -- yes, it's connected to a bump node height input, and the evidence is that it renders bumpy when I choose the 'single image' mode. I'm using the node configuration that was created automatically with the 'slot', I didn't change that setup. I'll double-check my preview settings, although I'm sure that I've tried all possibilities at least a dozen times :) I'll upload the .blend file and beg for additional inspection after that... $\endgroup$ – Stabledog Feb 14 at 22:03
  • 1
    $\begingroup$ Ok, I found a clue: if I turn off the 3d View overlays, and use LookDev preview, it works! It's not clear why overlays matter, but I'm less concerned with that... as long as I can function, it's all good. I'll post an answer to my own question, thanks for pointing me partway there. $\endgroup$ – Stabledog Feb 15 at 0:51
1
$\begingroup$

I found the answer to my problem, with some prodding from @CraigDJones: there's two things that enable texture bump painting to work as I expect:

  1. Use LookDev preview mode in the 3D View texture painter
  2. Turn off the Overlays.

It's not clear why either of these steps are required, but for this beta at least (2019-02-10 Windows version) I've got a functioning solution.

==== EDIT ====

Sadly, that solution only works for very simple .blend files, it seems. I have a more complex model and I still cannot get texture painting to work on the bigger model. It seems like there are so many weaknesses from a UX perspective in this feature that it just can't be called a 'feature' yet. :(

I've had to un-accept my own answer: there's a novelty!

$\endgroup$
1
$\begingroup$

I played with the settings a bit and found the one that was causing the issue.

If you go into the options for the gizmos, at the very bottom under a heading of "Texture Paint" there is a single setting called "Opacity". If you set this value to zero you will see the fully rendered object with all of your material data including the texture feeds.

At a value of one it shows the texture you are currently editing in a bitmap form overlayed on the 3D model. Values in between mix the two views. This also works in the "Rendered" type of view. I think this bug is actually a feature, just somewhat hidden.

$\endgroup$
  • $\begingroup$ I'll see if I can reproduce that, thanks. $\endgroup$ – Stabledog Jun 21 at 1:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.