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.

IMHO this should be included in Master, this is an awesome tool, for example to be able to clean up grass from grass patches that are distributed over a space, when you have to remove those parts that are inside the road but they should not, for example, this is great!

Any evolution regarding this? Specially now that the Code Quest started?

I would like to add two suggestions to Alembic:

Ok, thanks :)

How is this going?

Most of the time I’m from mobile, but I’ll look a way to join there :)

I’m trying to think in what I just said, to explain it in another way, once you have all the particles split it in bigger voxels, calculate each separately and interpolate the result this split could even be configurable so you could adapt it to a number of threads or parts, you could even avoid the interpolation part to have a preview, if you want the exact same result as we have now you just configure 1 thread and that’s it, if you want to require less memory during the process (and that is totally outside my small knowledge of Blender code and C++) you could configure 32 voxels for 16 threads, this way you only need in memory the working amount of particles, so less particles per voxels so theoretically in my wonderful perfect world that only exists in my mind you would need less memory per thread but more time for calculating the interpolation of the defined voxels when the are all complete... again... I’m not sure if this is a nonsense, but I’m trying to imagine how could it be solved as a logical problem :)

Since this is a voxelization process (I’m assuming that) couldn’t you split the work in bigger boxers, save in memory just the voxels if each zone limit, work each zone with one thread and once it’s completed merge or interpolate those voxels limits?

It´ñs working great, I´m prepairing a tutorial related to this.

I assume you solved the motion blur problem yesterday because now I got Motion Blur in Cycles with the latest fracture build!

And I just noticed your sample with the surface deform, yes, it could be similar to surface deform, but using particles instead of meshes and with the abiltiy to break those meshes based in distance from underlying particles or something similar.

On a side note, maybe this motion blur thing can be also applied to the actual Fracture Modifier results, since if we don´t bake the results to keyframed objects we don´t have motion blur, but this removes the ability to have a non broken object using the Perform Merge option, wich is super useful with glass.

Yes, think about a grid of particles, with the Molecular Addon you have the ability to make that group of particles to behave as a solid object, and using forces and collisions you can make that group to split or break, it is similar to the old days when Sotimage made use of Lagoa Unified simulation system.

But then... how does elbeem fluids do the motion blur with Cycles?

No motion blur in particle systems remeshed.

Exactly, this is very useful to be able to use fluids in production via Alembic.

So... how is this going?
Is some alternative to this already implemented in Master, since we can take multiple geometry samples I though something could be already implemented, just asking.

Yeah, decoupling tile sizes could be also a solution, in the end the target is to have a fast render and a fast denoiser avoiding the overhead of small tiles, so if the denoiser works better with bigger tiles the render could be divided in bigger tiles just for denoising, but since I don´t know the inners of the system I don´t know if it´s possible, but since you propose it, I assume it should be possible :)

Why not make the denoise as a post-render pass as other render engines?
This would kill the small-tiles problem because the denoise could be done with bigger tiles, I never understood why the current implementation does the denoising at the same time of the rendering.