Custom density volumes

@Remy_Unity I really like the work that appeared in the HDRP/custom-density-volumes github branch on Saturday. I had to hack around with the code a bit because what I am doing requires the compute shader to read from a 3D render texture, but it was much easier to do than my previous crude hacking of the HDRP.

I do not have a nice demonstration yet but here is a simple image of an initial test. Its using the results from a 3D grid-based Jos Stam type fluid sim where each emitter can be its own colour, but this wont be obvious from this screenshot.

5 Likes

Thank you a lot :slight_smile:
This branch is a result from my hackweek project. I had some internal feedback saying that it would be nice to have it in the product, so I started moving it to the repository, and will try to continue working on it as much as I can.
For the moment, itā€™s very hacky, but Iā€™m happy to see that you were able to do something with it.
I thinking of ways to expose properties (like the render texture in your case) that wouldnā€™t need adding a lot of custom user code, but it might end up to something similar to the custom passes volumes (generic ones with exposed shader VS custom ones heriting from an interface)

If you have any feedback, I would be happy to hear about :slight_smile:

1 Like

Thanks! I have one, single narrow use for this at the moment so Iā€™m probably not the best person to provide feedback, but I will try. I will take a look at how custom pass volumes work.

I am currently working on a demo scene for what Iā€™ve done and hope to post a video within the next week.

Actually I found time to make a crude and early prototype video.

12 Likes

Wow, well, this is tipically the kind of use I had in mind for it :smile: But Iā€™m a totally noob when talking about fluid sim, so I didnā€™t try it at the moment.
Feedback would be appreciated :slight_smile:

@Remy_Unity it seems like at the moment if I have more than one custom density gameobject, the position, size etc of all the volumes are coming from the first one, and all the other positions etc are ignored unless I switch the first gameobject off, then they all act according to the values of the second one, etc. Any ideas? I only got half way through my investigation of why before I ran out of time for today. I was trying it with 3 custom density volumes that were all close together, but not overlapping.

@Remy_Unity I fixed the issue mentioned in previous post.

Inside the foreach loop in ApplyCustomDensityVolumes part of CustomDensityVolumeManager.cs I made this change:

//v.compute.SetMatrix(ā€œVolumeMatrixā€, m);
//v.compute.SetMatrix(ā€œInvVolumeMatrixā€, m.inverse);

cmd.SetComputeMatrixParam(v.compute, ā€œVolumeMatrixā€, m);
cmd.SetComputeMatrixParam(v.compute, ā€œInvVolumeMatrixā€, m.inverse);

Thanks for the fix @elbows !
Iā€™m still quite surprised by the behaviour you described, as I was able to have multiple custom density gameobjects in my scenes :confused:

Ah, I cant explain that since I had the same issue if I used your version of the code without any of my other changes. But obviously I dont have your sample test scene so its possible something about the way I setup the scene or HDRP settings/profile or something caused this, I dont know. Nor am I experienced with the CommandBuffer methods for setting computeshader stuff as opposed to the older way, I just ended up with that fix because I ruled out any problems with variable values on the C# side of things, and since some other stuff for that compute shader was already being set via CommandBuffer methods, I just tried applying the same logic to the matrix stuff too.

@Remy_Unity how hard do you think it would be to get a version of this working with RenderGraph? Iā€™ve been able to get my slightly modified version of your work going in HDRP 10.1 and 10.2, but only if I disable RenderGraph. And I understand that the non-RenderGraph stuff in HDRP is going away so my workaround has a short life-expectancy.

I dont know much about RenderGraph. Iā€™m prepared to learn and to try to do a RenderGraph-compatible version myself, but I dont want to spend a lot of time on it if there are stumbling blocks that would be hard to get round without Unity source code access etc.

Thanks.

I honestly donā€™t know, as I havenā€™t worked with RG code until now, and didnā€™t try merging the master into my branch since a while.

@Remy_Unity @elbows awesome stuff! Weā€™re doing some work along these lines as well however weā€™re also using several cameras to composite the effect in the scene onto different layers. Long story short weā€™re making use of Volume Layers and was wondering how we might go about setting which layer our custom density volume is rendering to? Technically I think we could work around our issue buy switching things up to keep the default layer for the custom density and switching everything else to another named layer though this would be less ideal

@WJRRO You could add a LayerMask property to the custom density volume, and filter them in the manager based on the current cameraā€™s visibility layer mask.

By the way someone made me aware that changes to HDRP were made in the following PR to enable render textures to be used with density volumes, and to enable full colour and allow different resolutions. I believe these changes got merged into the master branch a while ago.

Using 2021.1 beta I did get that stuff running but I encountered some issues that may or may not be a bug, and havent had time to dig into the cause yet. Iā€™ll post about this again when Iā€™ve had more time to try.

Iā€™m really confused about the status of the changes to density volumes covered by that pull request that I mentioned in my previous post.

Those changes were added to master when master was dealing with 11.x (2021.1). They made it into the changelog entries for 11.0:

  • Added a setting in the HDRP asset to change the Density Volume mask resolution of being locked at 32x32x32 (HDRP Asset > Lighting > Volumetrics > Max Density Volume Size).

  • Density Volumes can now take a 3D RenderTexture as mask, the mask can use RGBA format for RGB fog.

But since then master branch has moved on to 12.x (2021.2). The code changes and 11.x changelog entries for these features are still present in the master branch.

But when I look at the code and the changelog for the 2021.1/staging branch, that stuff isnt there! So I dont know if this was a mistake, or whether this functionality is not coming to 11.x/2021.1, or whether there is some other 2021.1(11.x) branch I should be looking at.

Any ideas @SebLagarde ? Thanks!

Iā€™m curious as well. Hoping this gets integrated! Weā€™ve been playing around a lot with it and have been getting some very cool results (cannot share now as this is for a commercial client but hopefully we can share results soon!)

It is incredibly unhelpful that I still dont know the plan/status of this feature being in 11.x. I note that there were lots of backports to 2021.1/staging in recent days but still no signs of this feature despite the fact its still listed in the master branch changelog as having been added in v11.

Hi,
The change you are seeing are on our master branch, it is part of 12.0 / 2021.2 version. It is a mistake that it appear as 11.0 in the master branch and this will be fixed. the 11.0 / 2021 version correctly donā€™t mention it in the 2021/staging branch

2 Likes

Thanks very much, that was all the clarity I needed!

Note to self and anyone else who may stumble into this in future:

If using a rendertexture that is updated on the GPU side with this system, dont forget to IncrementUpdateCount() on the texture whenever you update it, otherwise the HDRP will not detect any change and will not update the density volumes atlas.