Volume procedural - Density/sampling shift

[adrianr]

Having some problems with volume procedurals I'm hoping someone can help me out with. If I load the density volume into a filecache and render the geo container straight, I get image A. If I load the density volume into a CVEX shader, perform a volume sample on it, and bind it to density, I don't get image A, I get something different. As I understand it all volumesample is doing is taking the volume primitive, getting a sample position, and returning the float value of the voxel at that position. So why is it giving a different result than a direct render? It looses a lot of detail. It also seems to put a ceiling limit on the density, and no amount of overcranking in the shader gets it back; Why would this happen?  

Firstly, is my understanding of what is happening correct? Secondly, is there anything else going on with the volume procedural that I need to look out for? Octree divisions are set to 1 so that should just be a straight 1:1 voxel/sample right? 

Have attached a simple debugging scene with a frame of a sim locked (hip file is ~210mb, sorry about that but I couldn't replicate the issue with a basic noisy volume to the same degree). I've just included the density for the sake of upload/download. You should just need to hit save to disk on the yellow filecache in pyro_direct so the procedural can read it, then render the 'mantra_direct' and 'mantra_procedural' to see the difference. Made initially in H16 but I resaved it with a H15.5 friendly volume shader. Any problems with the file let me know.

https://drive.google.com/open?id=0B_LM0kYodjpYNUpERkFBNWp3ZjA

[Skybar]

I've come across this before but I'm not sure why it happens. It could be how it samples the volume, actual voxels vs. the procedural. If you increase the volume quality on the mantra rop it gets a lot closer, but also increases the rendertime. Not sure if it's possible to get a 100% exact match while also keeping the rendertime the same. Actually, looking in the docs it says this that I've forgotten about, so it makes sense increasing the volume quality:

"When using this procedural, you should always specify an explicit bounding box. If you don’t specify a box, parts of your function may appear clipped in the render. The default rendering quality for VEX volume procedurals is set in relation to the box size, so larger boxes will use a larger ray march step size. You can adjust quality from the default using vm_volumequality."

[adrianr]

Hey Skybar, thanks for the reply. Bounding box is explicitly set, just using the same as the direct render. I had thought about volume quality but wasn't sure why it should be set any different if all else is equal. Would be a double hit too given it will already increase render times when I start to introduce advection - Would rather not trash my times twice with a volume quality increase too! I will chain up some renders going now with some higher settings and report back. 

Edit: Ok feel a bit stupid for not checking that first! However not all good news. To match the direct render I have to go to a volume quality of 2, which takes the comparative render time to 1:19, up from 19 seconds for the direct render, for the same(ish) look. This seems a bit mad, and I'd love to know more about what is going on under the hood that is causing this to happen? Is volume quality not a relative setting with direct renders? How can it sample the volume so much more so much faster for a direct render and not for a procedural? 

Edited April 29, 2017 by adrianr

[Skybar]

I think when you just render a volume, it knows how many and how big the voxels are. When you are using procedural it doesnt, it just got the bounding box - so it will "dice" that box using volume quality. Probably not the correct term but thats how I understand it. And its relative to the box size, so you need higher volume quality the bigger it is to keep the "voxels" the same size. I guess. 

[adrianr]

I see, that makes sense. Shame, because it may render this technique null for this (no pun intended). I'm looking at crazy render times for the close up shots at these settings. I'll keep poking around to see what I can do but may need to look into another technique.