HI Sybren.

OK, I did my best to try to update this for 2.81, since it's super important to save render time in big scenes with animation, but it's too advanced for me, I have no idea on how the new depsgraph work at all or how to apply this patch, I went file per file doing the changes manually to each file and trying to adapt it, but I reached a point that things have changed so much that I don't know what to do, my programming level is not so advanced.

In D4960#133717, @Metin Seven (MetinSeven) wrote:

In D4960#131896, @Martin Felke (scorpion81) wrote:

• Improved the gaussian smoothing algorithm and using this instead of openvdbs standard gaussian

Cool, @Martin Felke (scorpion81)! 👍 Looking forward to try the new Remesh modifier. When can we expect it in the Blender master?
Thanks!

BTW @Lukas Stockner (lukasstockner97) I'm eager to see your changes and how do you deal with the alpha thing in the lights, I'm learning a lot from your patches :)

True, then the best thing would be to do what you say, focus in finalizing this patch so lights are not transparent :)

In D5769#132935, @Ludvik Koutny (rawalanche) wrote:

Well, I would not clutter UI with fakes that someone may, or may not use. If you don't want to see the light, then you can simply turn off the Camera ray visibility flag. If you want to see the light but don't want it to occlude other lights, then simply turn of Shadow ray visibility flag. All that's really needed here to cover most of the production scenarios is that every single of these flags works correctly with area lights :)

I tried to find where is the alpha of the light managed, but I'm unable to find it, so I'm very curious with your evolution on this patch @Lukas Stockner (lukasstockner97) :)

Well, I agree in that having the light as a opaque object should be the expected behaviour, I imagine that if the problem is that is stacks two lights then one of them should be disabled or at least disable it's emission capabilities, that we we would not have double light, but the alpha should be 1.0 as soon as we make the light visible, at least I cannot imagine any other situation where I could want to have a 0 alpha light.

Of course please! Go ahead, I’m just trying to help and learn, if you want I imagine I can give you permissions in this patch or you can update yours, it doesn’t matter :) the idea is to have this working because it’s a small leap forward of being a finished patch :)

Is Optix for GTX cards planned for 2.81?

I found another limitation, some clue on where to look to try to fix it is welcome.

Uploaded a new diff in a different patch with updates to this:

I agree with @Martin Felke (scorpion81) here.

After fighting with this all day, I think that I know why all the lights are enabled/disabled all at once, correct me if I'm wrong, but this

OK, I updated this to 2.81 and it works.

I will check T65038.

This has more than a year.

Some information about this?

Just a thing, we use "Use Scene Lights" and "Use Scene World" a lot in look&dev.

@Alexander Adamov (alexaadamov91) if you uninstall Blender, do you still have the problem?

Volumetrics don't have an On/Off button since some versions ago, they are automatically enabled as soon as you have a volumetric shader in the scene.

You mean half way the frame, or half way the animation?

Can you show your world setup?

It seems also that this patch introduced a bug that when a light is inside a collection, and you enable compositing and save the file the collection with the light looses their users and disappears from the scene, the light it's still in the blend file, but since there is no collection it's not instanced in the scene.

Great feature.

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.