Page MenuHome

Incorrect Auto Texture Space in both viewport and render, and with and w/o modifiers
Closed, ResolvedPublicBUG


System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 425.31

Blender Version
Broken: version: 2.80 (sub 68), branch: master, commit date: 2019-05-16 17:17, hash: rB3076544c8c52

Let me know if it's better to split these into multiple bugs. They're just very related, like different expressions of the same problem, and I wanted to show them all at once

Short description of error(s)

A) During render and with a modifier on a mesh, even with Auto Texture Space (ATS) OFF, it will behave as if ATS is ON, and not even in the shape of the original mesh, but one that stretches and bounds the entire modified mesh (eg if a mesh has a mirror modifier, the bounds of the Texture Space is a wide as the final mesh, something that doesn't happen in 2.79) (I haven't tested every modifier)

B) If you were using ATS OFF with custom bound values, and then turn it ON back again, the values of the bound won't update to reflect it until you reload the file or undo. (In 2.79 you could simply enter into edit mode and the values would update) But this has weird consequences for that period in which ATS is ON but the values don't reflect it:

C) During render, and without a modifier, even with ATS ON, it will render with ATS OFF and the old bound values. But if it has a modifier, bug A) happens

D) On the Lookdev viewport however, you can see the correct ATS on the material as soon as you turn it ON, even on meshes with modifers and even though the values of the bound still won't updated. But you realize that it's not truly working when you render and bugs C) and A) happen, or when you enter and exit edit mode and see the old custom Texture Space still working instead of the ATS that we want

All in all, bug C) and bug D) would disappear if bug B) got fixed to update the values more instantly. But that still leaves bug A) Meshes with modifiers during render won't use either the custom texture space nor the ATS of the original unmodified mesh (render engine doesn't seem to matter)

Exact steps for others to reproduce the error
[Based on the default startup or an attached .blend file (as simple as possible)]

Use lookdev or rendered shading mode
To observe bug A) open the file and just render F12. The entire column of objects with modifers will have the wrong texture space
To observe bugs B) C) and D), since these get cured as soon as a file is reloaded, you have to turn off Auto Texture Space on the last two rows of objects, input custom texture space bound values (like Loc0,0,0 Scale 1,0.2,0.2 to use the same I used) and then turn ATS on again. You have to enter and exit edit mode on the last row too and this should replicate the images attached. Observe how the bound values remain the same still.
To observe the ATS updating the bounding values, Save and Reload.

I hope the checkmarks gives you an idea on how things should look properly. With and without modifier, with and without ATS, and the same across viewport and render with no differences

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to 50.

I can confirm that the result differs between viewport and render for both eevee and cycles.

@Brecht Van Lommel (brecht), @Clément Foucault (fclem) any ideas?

Vilem Duha (pildanovak) changed the task status from Resolved to Unknown Status.Jul 14 2019, 7:14 PM

this isn't still fixed, see the file below, where still about half of the generating (mesh changing) modifiers switches back to auto:

@Brecht Van Lommel (brecht), even with your fix, some modifiers continue to affect the Texture Space.
For example the boolean in the file attached in the comment above.

Philipp Oeser (lichtwerk) raised the priority of this task from 50 to High.Aug 29 2019, 12:19 PM

It is reported often, and since it is a regression, I dare setting this to High prio.

@Brecht Van Lommel (brecht) : I have added this to 2.81 milestone (since it was set to "High"), mind checking again?

Brecht Van Lommel (brecht) changed the task status from Resolved to Unknown Status.Sep 21 2019, 12:37 AM

The fix caused another bug, reverted for now, will look at it again next week.

Thank you guys!
PS: I am new to the developers commit system, so if this kind of comments are not welcome due to unnecessary notification and crowding, please let me know. I just felt like expressing my gratitude for looking into this)