Need to check again on this, was introduced in rBe82b7f15270e.

Thx for getting back, closing then...

Confirmed, checking...

This is actually working in wireframe. It is X-Ray, where this starts behaving differently [X-Ray with alpha < 1 will not paint the overlays in the occluded areas]

Can reproduce in 2.80, but this seems to be resolved in 2.81.

It is not really related to that commit.
Underline was there before [2d only] and was behaving just like that for 2d as well [unconnected undeformed single character underline]

Can confirm a performance difference.
@Clément Foucault (fclem): this expected? (I know there's changes to bump and tree traversal, but this also seems to affect trees not even connected to normal slot... but I guess the traversal runs regardless...)

At the current state, this report is empty and we cannot do anything about it,,,

Oki, closing then...

The original issue is solved, practically they dont interfere with editing either imo.
But there is the difference in hidden path drawing (where 2.79 draws with alpha, 2.8 draws solid), checking...

Not in front of blender atm. need to check this again then (was working when I tried...)

thx for getting back, closing then...

The other settings you mention dont neccessarily depend on the type of new image you are loading, whereas the colorspace can be guessed/determined automatically, thats why blender does that for you.

Not sure if this is about the RTX 2070, but no crash here (bot with manual steps, or opening the file, linux, 970m, 435.21)

There were T66362 and T66004 and if I understand correctly, this is a known limitation atm.

Are you sure this is not added by an [external] Addon in 2.80 (that hasnt been enabled/installed in 2.81)?

Thx @Garry R. Osgood (grosgood) for finding the related tickets, will merge into T70114 first (then check again if T70114 and T62254 are the same...)

Caused by rB5f51e7817206 / rBbe2cd4bb532

Confirmed, checking...

Confirmed, checking...

Will confirm for now

This is really tied to T63356 very much.
It is really the same issue to be honest (though a special case - perpendicular planes would make it even harder to show up in any drawing method).

In T70642#793120, @Benoit Alexis (alexisb38) wrote:

Thank you very much for your time ! here is the new report for the "vanishing cache" : T70696
Maybe the Bake All Dynamics issue is not really a bug since it was coded that way, but its behavior is really confusing for the user, and quite honestly it represents a lot of wasted time, I can't imagine how so few people have reported this so far. So should it be a feature request then ?

I propose to split this report up:

FYI, the skipping of hair particles with Bake All Dynamics was introduced in rB66918b3add4d.
On first sight, I dont see a particular reason to skip [tested non-skipping which seems to work], but this is ancient, so I guess this has never been considered a bug...

FYI, the skipping of hair particles with Bake All Dynamics was introduced in rB66918b3add4d.
On first sight, I dont see a particular reason to skip [tested non-skipping which seems to work], but this is ancient, so I guess this has never been considered a bug...

Also having no issues here.
We would need the information @Brendon Murphy (meta-androcto) asked for to proceed.
Please also check a fresh build from https://builder.blender.org/download/
Please also try with File → Defaults → Load Factory Settings and only enable ANT (nothing else) to see if you still can reproduce this issue.

Looks like this is not relevant for 2.8 anymore?

It is not really clear to me which GPU this E5430 is using? (some sort of Intel® HD graphics).
Please make sure all drivers are up to date
https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html

I think this is not a bug.

This is tied to the simulation having a negative start frame.

Sorry to say that PointCaches are pretty new to me (just wrapping my head around this now)

Thx for getting back, closing then...

Some first notes (without diving deeper)

note: nodeCountSocketLinks could be used in P1133 [still not sure if that defeats the purpose / kills performance]

Hm, just noticed there was T43940... still think this is a bug though...

Can confirm, there are a couple of related popover issues : T63890, T63999

While this might sound inconvenient, you need an active ImageTexture in every material, otherwise you end up with this "undefined" behavior.

Good news: resolved, since rB95199dca1f12.

Tbh, I can edit the hair from FurBall.blend with much better performance than the video [linux, i7-6700, 970m, 435.21 drivers], simple children have no lag at all, interpolated just a tiny bit...
Will run some test against 2.79 tomorrow...

@Clément Foucault (fclem): havent done performance checks, not sure if this defeats the purpose of backwards iter [could even be worse!], but if we check if the links are actually the same, we can fix by P1133
(couldnt find a quick check on a socket to see if it has more than one link...)

Actually caused by rB5c79f2d0fba7...

Can confirm, checking... (assume this is caused by ffd5e1e6acd2)

OKi, will close, thx for getting back...

Cannot reproduce here (file works the same here in 2.8 official release and rB7a1847f0e9fd)

@Jeroen Bakker (jbakker): not sure who is working on "We will do the same like we do in texture painting. There is already a task for that" or where this could be merged into?

Cannot reproduce here.

This report does not contain all the requested information, which is required for us to investigate the issue.

In D6018#138447, @Dalai Felinto (dfelinto) wrote:

Tested here. Nitpicking aside the patch is good and working well.
That aside (as a separate patch in the far future?) I think it should keyframe ALL channels if anything changed. This is how Blender does by default.
If you open:

camera bug.blend740 KBDownload

And just translate the camera around it will keyframe location, rotation AND scale. But 2.80 is working like this patch, and not how I suggest, so we can treat as a separate issue.

clang format

Turns out this was made on purpose, see rB4005b88b30cf: minor edits to node view - when single (non frame) node selected, dont zoom in…, not sure what the reasoning there is @Campbell Barton (campbellbarton) ?
Maybe we should do something like D6019 (which will take the biggest node in the tree into account), so you get panning once close, but still gets you closer if you start far out?

Confirmed, checking...

Tbh, I see the particle system being replaced, but this will not really include hair [at least not in a first step, I might be mistaken, but I'm not aware of anything related to hair really in the works...], so if time permits, this should still be looked at... [that is my opinion at least...]

Because for walk, the cursor is constantly warped (WM_cursor_warp in walkEvent), we cant do something reasonable with comparing mouse positions (to detect rotation) once the mouse comes to rest [this was only working prior to rB22bdd08dfd08 because keyframes were inserted constantly]

Fly is actually fine, I think rB22bdd08dfd08 just exposed some quirk in the logic of walk moffset (or just doesnt play nicely with it anymore -- in that once your mouse comes to rest, moffset will be zero, so it is not suitable anymore for a check if rotation has happened at some point...), will check...