This is kind of super important for any third party render engine

You can test some of the sampling patches in our build, in graphicall.org, the bonemaster build

In D8794#215681, @Evan Wilson (EAW) wrote:

In D8794#215579, @Juan Gea (juang3d) wrote:

I applied this patch succesfully to our build, but I see no difference, I'm trying the Moana VDB set and the memory consumption is the same, do I have to do something to enable it?

Hi @Juan Gea (juang3d). Did you grab a copy of the necessary files off of github and add them to your library folder? And did you compile your build using the CMake option WITH_NANOVDB?

I suspect the problem is in the file:

In D8794#215681, @Evan Wilson (EAW) wrote:

In D8794#215579, @Juan Gea (juang3d) wrote:

I applied this patch succesfully to our build, but I see no difference, I'm trying the Moana VDB set and the memory consumption is the same, do I have to do something to enable it?

Hi @Juan Gea (juang3d). Did you grab a copy of the necessary files off of github and add them to your library folder? And did you compile your build using the CMake option WITH_NANOVDB?

In T80384#1010294, @SavMartin wrote:

You have seen this development that is doing weeks ago??

https://twitter.com/jfranmatheu/status/1302237084191805441

I applied this patch succesfully to our build, but I see no difference, I'm trying the Moana VDB set and the memory consumption is the same, do I have to do something to enable it?

I have my doubts about this being a good solution:

A custom AOV to hold an override material could be good. For when you want an AOV that includes the whole scene (like with a custom depth AOV)

Ok, no problem, this is fully compatible with master, I just did it with 2.83 to be sure, but this has not changed at all in 2.91 :)

@Jeroen Bakker (jbakker) if you can please change the branch to 2.83, I configured master because I imagine I cannot define this for 2.83

Diff fixed

I may have done the patch the wrong way, I mean, the green part should be 0.0 and the red part the 1.0, my fault with git diff, I will update this.

Hi Jacques!

Awesome, thanks! 👍

Hey @Brecht Van Lommel (brecht) was this useful at all? :)

Ok, I tried to generate a patch, may not be perfect because some of the modifications along the time, but the problems should be just a matter of ui, in case you have any problem, and you will be able to overcome any problem in seconds I guess.

In T68919#981000, @Brecht Van Lommel (brecht) wrote:

@Juan Gea (juang3d) do you have a patch combining scrambling distance and dithered sobol?

BTW another question regarding this, at what values have you tested?

Thanks for testing it.

About this:

I think while the explanation is clea@2r, this is still problematic, since makes virtually impossible to use Cycles in a mixed pipeline, may not be a bug per se, so that's why I created this devtalk thread, but it's clear that since there are several "industry standard" adoption efforts, this should be one, because mixing Z-depths with other engines is currently no possible.

@Richard Antalik (ISS) I think what @Ruymán (ruyman) is trying to explain that when you have some custom preferences modifed in blender locally, then you create a custom app template but don't overwrite those preferences Blender is not respecting that user preference, but rather is re-loading the factory setting, and that's not desirable at all.

In D4960#174748, @Brecht Van Lommel (brecht) wrote:

In D4960#174743, @Juan Gea (juang3d) wrote:

@Henrik Dick (weasel) what you ask for is a ton of work, the development of this feature has been a lot of work, and the already requested changes means also quite a lot of work.

It's not a lot of work to add voxel remesh to the Remesh modifier. The operator is already there for sculpting, it's a matter of exposing the same properties. The way it was implemented, the code is already easy to reuse for a modifier.

Not saying that @Martin Felke (scorpion81) has to do it. Just that any developer that has worked on modifiers should be able to get that working quickly.

@Henrik Dick (weasel) what you ask for is a ton of work, the development of this feature has been a lot of work, and the already requested changes means also quite a lot of work.

Agree, @Julian Eisel (Severin) @Jeroen Bakker (jbakker) this is a super important feature for the sculpt process, more even than for the edit mode process.

@Jeroen Bakker (jbakker) we are dying for having your Ok to thiiiis :D

devtalk.blender.org and mention the developer you want to notice with an @ usually they notice it :) (admin delete this message after a while if you think it’s better)

O agree on this, if it’s working as designed there are two possibilities:

Hey @Dalai Felinto (dfelinto) or @Brecht Van Lommel (brecht) I'm not sure how this goes into the curfew, but it's a very interesting feature for many many people, who may review this?

In D6554#154268, @Stefan Werner (swerner) wrote:

I have a patch for viewport denoising that supports OIDN - unfortunately it works different than this one. We should coordinate for a unified approach.

It might be useful to enable OptiX denoising for CPU rendering too - when you have scenes that exceed VRAM or rely on CPU only features (decoupled volumes, OSL) you might still want to leverage GPU denoising.

In rBd5ca72191c36f3022db8fa5a17d933ee82c82d30#253979, @Patrick Mours (pmoursnv) wrote:

Yeah, it's not a hardware limitation, since Pascal has software emulation for RTX in the driver. This won't give you much of a speed boost of course, since it is essentially what the CUDA implementation of Cycles does already. But to cause less confusion as to why it is faster on some cards and slower on others we wanted to make the OptiX backend in Cycles available only available on RTX cards for the time being. You can change that yourself in code as explained in the link. And we may change that in the future too. There are no concrete plans yet though.

I noticed that the Optix denoiser can be enabled only when you use an Optix GPU.

This is not buildable anymore, something changed in

BMEditMesh

and it's not possible to use

em->ob

anymore.

Then may there be a problem with the stats and not with the memory?

I think this is rather important because we tend to use different scrpits to scatter objects, or to procedurally modify a scene, and it feels like a big memory leak.

This is the script, in case it's lost from pastebin :)

In the end I've been able to apply this, I had to resolve some conflicts but it's working :)

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

Cool, thanks for the update. In the mean time I've installed the Bone Studio build. 👍

😊

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

I'm still eagerly awaiting the implementation of the Remesh modifier in the Blender alpha builds. Why is there no reviewer at the moment?

While I understand this, this kind of information should be made available for the devs, it’s important and interesting, it should not be treated as a bug, but it should be treated in some way, and the curfew is a good opportunity to help organizing this kind of things IF they make sense :)

@Brecht Van Lommel (brecht) @Sergey Sharybin (sergey) what do you think about this patch?

In T71253#806621, @Sam Van Hulle (sam_vh) wrote:

Suggestion: Shadow Catcher BSDF

• Basically a Principled BSDF whose primary rays are invisible to the camera.
• Automatic camera mapping of the backplate or environment texture, and usage of this when seen in secondary rays on other objects.

It can be resumed in this phrase really:

Basically, be sure to have scale applied to any object in the simulation, the "scale up"operation with the apply operation could be your problem.
Also be sure to check the "Liquid" checkbox or the sim will be done but you won't see any particles.

This is happening because the domain pivot is not in the correct place.

I think it's a great plan.

It's the same behaviour I saw with the patch earlier, so may be the same problem that existed for the cycles preview window.
I can confirm this problem too since we use Box mapping extensively and we saw our scene going pink suddenly

Impossible (for me) to build this against current master code

In intern/cycles/blender/blender_object.cpp, in line 529 there is a typo:

In D3607#150148, @Brecht Van Lommel (brecht) wrote:

@Juan Gea (juang3d), this is how things work in Renderman and Arnold (and for what it's worth, I'm the one who implemented LPEs and light groups in Arnold).. The group name is a property of the light there. It also fits better with LPEs if every light only has a single group, and will have better performance.

Even if lights are only in a single group, it's still possible to sum light groups together, but if it takes more setup time then. In my opinion we should make prioritize the typical use case.

@Alex Fuller (mistaed), I think your fix indeed works, but it might be obsolete once I've made further code changes here, not sure yet.

In D3852#149748, @Sergey Sharybin (sergey) wrote:

Well, if there is too much discontinuity between UI and API and internal code it's not that great. Having those in sync helps a lot figuring out where things came from and where to look for them.

Unfortunately, i don't have strong suggestion here. Calling things "fluid" isn't 100% correct because it also covers "smoke", and i am unaware of a technical term which will cover both of them.

Braindump on possible ways:

• Accept the confusion, move on with the current state, refine/adjust as we go later on
• Have Smoke and Fluid exposed as separate modifiers (same as it is currently), have Mata as a backend.
• Converge everything to Fluid
• Find a proper common term for fluids and smoke.

But Iam also curios to hear from @Campbell Barton (campbellbarton) on this topic/

Why not let the user to deal with this manually? As much give a warning, but let the user decide

In D3607#149087, @Brecht Van Lommel (brecht) wrote:

I'm reviewing this and doing some fixes to get this ready for 2.82, along with D4837.

The main thing I would like to change is the "LG " prefix. Ideally in the future we could support also other passes than combined for light groups (using LPEs perhaps), and in general I think it's good to indicate that this is a "Combined" pass.

I'm thinking of naming like this for OpenEXR, though I'm not entirely sure about the preferred order:

RenderLayer.Combined.LightGroup
RenderLayer.LightGroup.Combined

In the compositor and image editor this should then display as Combined.LightGroup or LightGroup.Combined as the pass name, or maybe even later it can explicitly understand these as light groups.

Does that make sense? Any preferences on the order?

I cannot build this because it says that BLI_bvhtree_overlap_ex is declared twice:

As far as I know this is expected behaviour, domain settings (size and position) is only sampled at the begining of the simulation, so even if you move it, it will have no effect.

@Lukas Stockner (lukasstockner97) With permission of Dorian, author of the new scatter plugin, where this texture is packed, I prepared a scene that shows the problem.

Hey @Lukas Stockner (lukasstockner97) I've been able to test the patch again, and maybe the problem was mixed with something else, because I don't get the crash anymore, that's awesome :)

@Lukas Stockner (lukasstockner97) I'm going to test again and if it fails again I'll try to prepare an example blend file that always crashes.

In D3509#146648, @Alex Fuller (mistaed) wrote:

Hi @Juan Gea (juang3d)

Not sure if it might be related, but I reverted the virtual destructors for anything inheriting from ImageSlotTextureNode so that only ImageTextureNode has the new UDIM destructor update. I found that textures like environment maps weren't freeing properly which might be what you're running into, although it was asserting for me but I am building in debug mode and haven't tried a release build yet.

Ok, after testing it in our build I think there is some memory leak related to this, we tried a texture that comes with the scatter addon and it crashes with this: