Mon, Jun 18
Putting this on normal (so it doesnt appear untriaged...) because there is an issue [but only with old dependency graph...]
not an issue if you use the new dependency graph
(run blender from the commandline with the --enable-new-depsgraph option)
Sun, Jun 17
Wed, May 30
About the situation with subsurf and no 'use modfiier stack', not it is clearer to me. The reconnect in this case seems to work like this:
Tue, May 29
@Philipp Oeser (lichtwerk) Yes, of course. Sorry in case I failed to follow the preferred procedures. No secret that I'm rather new around here.
Hi @Brecht Van Lommel (brecht), @omgold (omgold), I've seen you discuss this on the mailinglist (and I understand reaching out here as for some reason this report seemed to slip under the radar)
But: why not continue here? This way others (including me) can follow and participate much better.
Sorry for the wall of text, but pasting from the mailinglist, so it doesnt get lost...
Mon, May 28
sorry for the duplicate and thanks for the answer :)
Unfortunately operations that alter topology are not supporting Custom Split Normals:
The problem here is that the "Use Modifier Stack" setting is not properly taken into account for these disconnect/reconnect operations.
Sun, May 27
Fri, May 25
Thank you for the report. Currently we are aware of many issues in 2.8 and actively working to fix them. But since replying to reports takes time, we have decided to limit bug reports to module team members.
May 16 2018
May 14 2018
May 9 2018
@Philipp Oeser (lichtwerk) : your work here is really aprecciated - thanks again for taking the time to fix this issue so soon!
@Lukas Ziechmann (bl_cat): note this isnt commited to master yet (want to check on an issue in 2.8 first so the merge would go smooth ...)
reg. T54397: surface deform is now ported as well, but changes can happen later as well [just need proper handling of 2.79 vs. 2.8], lets stick to that report and continue discussion there
May 8 2018
*wow* - getting back from work to find the bug I reported yesterday to be already fixed for 2.79. Thank you so much @Philipp Oeser (lichtwerk)! Regarding my other bug report: T54397 , do you think I should CC a 2.8-developers directly as the surface-deform modifier isn't ported over to 2.8 yet or would that be considered annoying/ unhelpful? I don't know the policy here and I don't want to clutter their chat with unimportant messages. Thanks again for your time and effort!
missing NULL check
lattice was already ported (see T54737), so this will need to go into 2.8 with minor tweaks separately
this probably wont merge into 2.8 cleanly [DerivedMesh → Mesh conversion], I guess I'll have to make another version for 2.8 as well [which should only be minimal massage].
CCing @Sybren A. Stüvel (sybren) , just so he knows...
D3239 should fix this
similar to rB9c95fd0a988fcd14f050098385e5461e2e51100d
Will have a look shortly
May 7 2018
May 4 2018
May 3 2018
possible fix: D3199
Just thought this could go in before this modifier gets ported in 2.8?
I'll leave porting the Particle Instance modifier to @Philipp Oeser (lichtwerk) then ;-)
Apr 30 2018
We are talking about the very first bone here, right (the one marked as 'root')?
Confirming on first sight.
Apr 28 2018
Apr 27 2018
Depsgraph indeed only takes layers into account. This way it's cheap to see if some object from hidden layer affects something currently visible. In Blender 2.8 we are switching to collections visibility instead of object visibility. This part is still being worked on, so need some work to make depsgraph aware of that once rest of design is locked down.
At a quick glance at the code, dependency graph is only aware of layers, not object visibilities at all.
This is not limited to the Armature modifier, seems all modifiers evaluated (e.g. on frame change)
(Above difference in fps between visible vs. hidden is probably drawing code etc, not modifier evaluation).
So in that case, I would think this is a (somewhat known) limitation to the depsgraph?
While it is very well possible that hidden objects need to be evaluated (think of something shrinkwrapped to a hidden deformed object - you would want the deformations to be evaluated), it doesnt have to be so (agree, it would make sense to skip evaluation in that case).
Apr 20 2018
@Philipp Oeser (lichtwerk), this is something what we should support indeed. Mind looking into this? Shouldn't be hard to add support :)
This is a limitation to the current Particle Instance modifier (not a bug though).