What is this about? An improvement, a confirmation or a recovery of part of the 2.79 adaptive displacement?

Undo is bad in both, this is not a regression, any complex file makes undo nearly a torture to use. Just animating a camera for example, you are just transforming the camera, and making undo in a big scene takes A LOT instead of being instantaneous as it should be

This is a rather BIG bug from a rigger/character artist stand point!

In T60094#748133, @Alyssa Anderson (wackyvorlon) wrote:

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

The link doesn’t work :S

Thanks will take a look soon and I will try to start a conversation in devtalk :)

Does this means that your work for particles is taking shape for 2.81?

Another question, is this just for windows users?

I have a question regarding this implementation.

Hey @Sybren A. Stüvel (sybren) what do you think about this?

So I've investigated this a bit more and it's a different bug for sure.

I’ll report it later :)

I’ve been directed towards this bug by the Flip Fluids Addon developer, that is why I assumed that this is the same bug.
I’ll report a different bug if you think it’s a different one :)

This is not only flip fluid related, this could probably affect also elbeem or Mantaflow, since in the end they are generating meshes too

How is this going?

Lock Interface did not solve the issue, when I experienced the problem I tried it, without luck, I cannot test it right away, I'm on a hard and tight deadline, but I remember trying everything, even this, and it didn't work

In D3787#116642, @Oscar 'Nebe' Abad (OscarNebeAbad) wrote:

@Jacques Lucke (JacquesLucke) this is an amazing scatter tool! For total usefulness, how do you see any option to make some grid patterns, like hex, quad, radial, and some offsets? useful for hardsurfaces, city buildings and so.

Yes, I have not found the problem yet, still looking at particles code when I have some time, I would like to do some proper debug and profiling as Antonio did to find if I found the bottleneck, but I don't think it's a bug, it's just something to be improved.

No worries, I agree with you that better defaults would be good for the hair system :)

BTW not knowing a tool and trying to use it before doing a big presentation has never been a good idea, I’m sorry to hear that you are in that situation, try to apply the settings I described in the previous message and give a bit of collision thickness to the collider.

I have to disagree.

Here is the example with correct settings:

I'm afraid this is not an inestability problem, I mean... it is, but it's not a bug, it's due to defaults being wrong, and also the haird collision system not being the best in the world, it's not too precise.

I cannot reproduce it with the steps you said, an specific number and type of operations could be welcome to confirm this.

Looks great,

THANKS A LOT!!!!!

@Germano Cavalcante (mano-wii) well, right now this is a pretty important feature, I'm not sure what areas do you think that need more attention in snapping, could be great to know :) (really, no pun intented) but a common workflow in any software is to snap things to curves, since for example CAD data come in curve form and some parts of a CAD model may be constructed based on the CAD curve to allow an easy iteration.

It seems to be related to some kind of capping, with 100.000 particles * 100 interpolated children all CPU's are being used ina multithreaded task, while with 100.000 * 10 interpolated children it seems that is not running the multithreading, so it's doing a single threaded task

ok, so in 2.8 is also working, so this may be just the result of having faster particle creation and now having a much slower children creation, which in reality it's not slower, it's that now it's more obvious, I'm not sure, still doing some more tests though

It seems that the same thing worked fin in 2.79, the problem seems to be related to child particles

It seems the problem is related to children generation, when trying to generate 100.000 particles * 10 children on viewport it hangs

I tested today's master in windows, i7-5960x, without problem:

Why does this appears as buildable?

@Sam Van Hulle (sam_vh) probably what you want is a blue noise distribution pattern, this will give the impression of random and organic but at the same time will give the particles evenly distirbuted without forming clumps, somethign that now happens, I wish this could be implemented

Do a new build, code was updated yesterday if I’m right 👍

same problem here, black spots at the long distance

I have the same problem, important to leverage clouds of Real Sky on Eevee, it will be super powerful when this is solved, I hope you can solve it before 2.80 release :)

Following Bretch suggestion the patch has been super simplified, and it's performance is even a bit better.

• Can you provide a test file that allows us to easily verify the performance increase?

I'm curious about one thing, how is this different form this @Lukas Stockner (lukasstockner97) implementation?

Shouldnt this option be in the solid mode pop-up rather or in addition to it being in the workbench render settings?

Is this still alive?

It seems that was a small temporary problem that has been already solved, I built Blender this morning and I had the problem, now I just rebuilt it and it seems everything is solved.

It also crashes when you try to open the material slot list

For me 5+1.

It's udnerstandable that this must be adopted for release, but right now was not something obvious for many of us, this has served as a good warning :)

@Campbell Barton (campbellbarton) do you think you could extend the "grace" period? so users can stay using the addons now that everyone is aware and addons are being translated, re enabling this IF statement, so addon devs are fully aware now, but users are not being able to work with addons, it feels like everything exploded, and it is not the case, so 2 weeks or 1 month more with the IF could be helpful for devs, and it will maintain users safe in general :)

I've been able to reproduce the problem, but just in Linux, in windows I don't get a crash.

@Stefan Werner (swerner) Intel said that they just uploaded 0.8.2 with that you said fixed!

This is understandable, but don't you think that you should have warned everyone clearly that this was going to happend?

Just stumbled upon this bug, what a big bug!

Would this affect objects without bump? Because we have those terminator problems also in objects without any bump and maybe this can also soft those problems.

In D4304#98317, @Ludvik Koutny (rawalanche) wrote:

In D4304#98312, @derek barker (lordodin) wrote:

Ive been testing with denoising the light passes instead of the images and it does a significantly better job keeping the texture data.

Look two posts above. There's a bug that causes textures to get too blurry.

I tired this on a Theory Studios build and it is amazing!

This is a pretty neat feature for sculpting!

Sorry, for the tokens thing, something happened to my browser.

I can´t understand why Vector Displacement not working on instances is not a bug.

Yes, I noticed it too lately, there is not much of a difference, at least not like before.

Sorry, fixed the file link.

I´m not sure where to put this, so I´ll put in this more generic thread, but please point me to the correct place if there is one.