Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto Execution "Always" gives flickering on Subdivide modifier #576

Closed
enzyme69 opened this issue Jul 20, 2016 · 7 comments
Closed

Auto Execution "Always" gives flickering on Subdivide modifier #576

enzyme69 opened this issue Jul 20, 2016 · 7 comments

Comments

@enzyme69
Copy link

flicker_update

I am using "Auto Execution" as Always. All I have in the scene is a Box with

  • Skin Modifier
  • Subdiv Modifier
  • Using Object Attribute Output, I am changing >> modifiers["Subsurf"].levels

I am getting Flickering mesh with Auto Execution.
When I use Property Changed tick box, the flicker disappear.

Now, I am curious on New Trigger. I will have to check that.

But I think even with "Always", it should not flickering.

@JacquesLucke
Copy link
Owner

Hm, I guess you don't change the vertices all the time? This looks a bit like a bug in the Skin Modifier. Will check in more detail when I'm at home.

@JacquesLucke
Copy link
Owner

@og76
Copy link
Contributor

og76 commented Jul 23, 2016

fwiw
this is not the only place you'll encounter "different outputs for same input" behavior, more like a random choice between equivalent solutions, eventually leading to flicker in Animation Nodes or other repeated execution case.

However, do notice that auto execution just repeats the exec every x seconds.
Evwn if without it things seam ok, well, they are not if u are animating. On each frame the solution will be random, so it will flicker ...

Another example that comes to mind is bvh closest where if the closest point is on an edge, the returned polygon index will.. flicker, being sort of a random choice between those 2 poly.
(one of the reasons for the extra normal check I was doin on the "is inside volume - normal based" version. extra checks that eventually made it sloow.. )

There are other cases for this, (marginal or weird or not), but do not remember now
and, sorry, time is not on my side these days. :(

ps.
solutions? hm, it so depends on the specific case. in some cases a certain tolerance (or on the contrary, precision) may help "fix" the result ... or more "fixed"

@enzyme69
Copy link
Author

enzyme69 commented Jul 23, 2016 via email

@og76
Copy link
Contributor

og76 commented Jul 24, 2016

w do you mean "goes back"?

also..
smooth

@enzyme69
Copy link
Author

Ok, I think that might have been fixed at some point I probably was using
older version. I recalled having this "issue":

  1. Original Suzanne
  2. Instance Copy Suzanne, Shade Smooth, and it goes to smooth and playback,
    it goes back to Shade Flat.

I tried it just now, the copy when smoothed, it affects the original
Suzanne. Which is weird too. But I tested again and it is not affecting
original Suzanne. I tested with this switches on and off: Deep Copy, Copy
Full Objects, Copy from Source.

But, probably has been fixed. And thanks for pointing that "Shade Object
Smooth" node. I didn't know.

Anyhow, the flickering thing happens sometimes when I subdivide mesh
outputted from AN. It is unexpected behaviour, I reckoned.


On 24 July 2016 at 11:11, og76 notifications@github.com wrote:

w do you mean "goes back"?

also..
[image: smooth]
https://cloud.githubusercontent.com/assets/11709974/17081121/99e0e198-5154-11e6-985b-1fe50429a525.PNG


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#576 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADxQL8eTtS2eG14ABNbuDNPmiqgPiU11ks5qYrvYgaJpZM4JQYFF
.

@JacquesLucke
Copy link
Owner

Close it because it is a bug in Blender.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants