Jump to content

frustum buffer with mantra volume rendering ?


Recommended Posts

I'm wondering if there is a way, quick or not, to introduce a frustum buffer in to a Mantra volume render. I'm rendering some very huge buffers (500x3) that , of course, need to fly in to camera ( don't they always ;) . I'm running in to serious swap issues and wondering if some type of camera frustum clip/buffer/something might help exclude all volumes not visible.

Cheers !

J.

Link to comment
Share on other sites

Maybe you could split your volume into chunks and cull the bits that are outside of camera frustrum. Attached a file to show what I mean. In my file I haven't got the divisions right on the little volumes... but you could just set that based on the XYZ divisions and resolution of your original volume.

EDIT: there must be tools to do this already since volumes can be split and distributed on a farm ....

split_volume.hip

Edited by sam.h
Link to comment
Share on other sites

Maybe you could split your volume into chunks and cull the bits that are outside of camera frustrum. Attached a file to show what I mean. In my file I haven't got the divisions right on the little volumes... but you could just set that based on the XYZ divisions and resolution of your original volume.

EDIT: there must be tools to do this already since volumes can be split and distributed on a farm ....

thats true ... I never thought about looking at the distributed slicing to cut up the volume. Thanks for taking the time to put a hip together I'll dig a little deeper :)

Link to comment
Share on other sites

thats true ... I never thought about looking at the distributed slicing to cut up the volume. Thanks for taking the time to put a hip together I'll dig a little deeper :)

No problem!

I was also thinking that 64bit would help a lot if you aren't already using it...

Link to comment
Share on other sites

I ended up just creating a volume from an invert camera frustum based on near/far clips and then using that in a volume mix to subtract from the original sim volume everything outside of those bounds. Hopefully this will help my ram issues ( swapping over 16 gigs per frame , ouch)

Edited by essencevfx
Link to comment
Share on other sites

so this worked if anyone is interested. It seems then that Mantra does not care if the volume is in the FOV or not....strange. Cut my render

times in half as well. :)

I think this a case of where you should be using I3D volumes instead of geometry.

-Drew

Link to comment
Share on other sites

  • 2 weeks later...

Hey Drew

I just saw this now since we're running into similar problems. Is there a reason why i3d is superior for this type of thing? I've always assumed that the new volume context is effectively superior to i3d, and therefore would replace it. But I admit that I haven't researched it too much.

Thanks

Marc

Link to comment
Share on other sites

Hi Marc,

I just had a look over UT/UT_VoxelArray.[Ch] and it looks like it has evolved quite a bit since last time I checked, so my comments may not be relevant. It may be the case that I3D and geo volumes have equivalent properties for filtering and paged access, but I'd check this with support if the evidence suggests not. One thing to be aware of is that reading and writing large volumes to IFD files can be very slow, so you probably want to have them pre-saved as bgeo's and use deferred loading for rendering. If the geo volumes are paged that would mean that mantra is paging from inside an IFD file, I'll be interested to hear what you discover.

Cheers,

Drew

PS it's nice to be talking about something besides how to compile HDK stuff on windows ...

Hey Drew

I just saw this now since we're running into similar problems. Is there a reason why i3d is superior for this type of thing? I've always assumed that the new volume context is effectively superior to i3d, and therefore would replace it. But I admit that I haven't researched it too much.

Thanks

Marc

Link to comment
Share on other sites

I'm mainly intrigued by the lack of information out there about this I must say. I think a mail to support would go a long way :). We're doing some quite serious volume building on something and it's becoming more important to know how the backend works. Especially now with Sony's Field3D stuff out in the wild, it would be nice to compare them properly so we can make an informed decision.

Things like frustum volumes (or non-square volumes at least) and sparse fields are fairly important these days one would imagine.

PS it's nice to be talking about something besides how to compile HDK stuff on windows ...

I'm sure :). Sadly the last thing I compiled on Windows was on NT in 1996, so I'm afraid my knowledge is a bit...er .. dated. Otherwise I would gladly share the load.

M

Link to comment
Share on other sites

Yes I was actually a bit shocked that Mantra dosen't have any frustum volume options. Having to hack something together out of a string of 5 or more volume sops per prim ( and pyro has 13 ) = not ideal ;) ....for a huge rendering and RAM difference. Using the frustum clip chopped ram and rendering times in 1/2.

Edited by essencevfx
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...