Jump to content
jonp

prman 17 volume rendering vs mantra

Recommended Posts

Pixar is promoting their new speed improvements when rendering volumes in RenderMan 17, so I was wondering if anyone has done an apples to apples comparison vs. mantra. I haven't done any controlled comparisons yet, but anecdotal evidence at work so far suggests it is still behind mantra. Can anyone share any more info regarding speed/memory tests?

-Jon

Share this post


Link to post
Share on other sites

I've done quite a bit of testing with prman 17's volumes lately while writing a Field3D implicit field DSO. ( a few tests here and I mention render times down in the comments)

tests below..

Edited by Alanw

Share this post


Link to post
Share on other sites

Here's a little test. This isn't apples to apples as far as settings are concerned, but more or less the quality of the result. I don't think they're necessarily equal on quality either, but close enough. (The mantra render could use a higher shading rate)

I tried rendering prman volumes directly (12.1 supports it), but soho's throwing an error, so all I have to compare with is my DSO for now.

The scene has x2 lights. (key + fill), and a voxel grid with (217 325 211) resolution.

mantra, using the liquid smoke shader from the material palette.

stochastic transparency is OFF

volume step size is 0.1

4x4 samples

1 shading rate

micropolygon mode

Generating Image: ip (640x480)

Plane[C]: Cf+Af[4] (16-bit float)

Render Time: 1:45.50u 1.86s 5.83r

mantra_smoke.jpg

prman, using a custom shader. (just an illum loop w/ density controlling Oi)

note the coarse shading rate. (it's the opposite in prman, where 4 is quite low quality)


ShadingRate 4
Attribute "dice" "rasterorient" [0]
Attribute "trace" "int maxdiffusedepth" [1]
Attribute "trace" "int maxspeculardepth" [1]
Attribute "trace" "float bias" [0.00999999978]
Attribute "volume" "string depthinterpolation" ["smooth"]
Attribute "volume" "string[1] refinementstrategies" ["uniformdepth"]
Attribute "volume" "float[2] depthrelativeshadingrate" [4 4]
Attribute "volume" "deptherror" [0.00392]
Attribute "shade" "string transmissionhitmode" ["shader"]
Attribute "shade" "string diffusehitmode" ["shader"]
[/CODE]

Rendering at 640x480 pixels, 4x4 samples

"ip" (mode = rgba, type = it)

Memory: 2290.08 MB

Max resident mem: 718.48 MB

Page faults: 0, Page reclaims: 243226, Swaps: 0

Real time: 00:14

User time: 03:00

Sys time: 00:01

prman_smoke.jpg

Once the buckets appear in my framebuffer, they both take the same time to render (roughly 2 seconds), but my DSO is taking approximately 10 seconds to load the 250MB field3D file for rendering, so all in all I think they're close to the same. Maybe some more folks who've tested both in production can comment.

This is with 24 threads @ 3.6Ghz

Edited by Alanw
  • Like 1

Share this post


Link to post
Share on other sites

Hey Alan thanks for he tests info.

I haven't tried prman17 yet, but I have been using mantra to render

Volumes with PBR quite a lot in the last months.

I think a better comparison would be to use pure ray traced PBR with

both engines.

In a full raytraced pipeline it is much easier to integrate elements

Rendered in mantra and prman, it is easier to get a coherent lighting.

Also try to use a bigger volume step size for mantra it radically improves

your render times and usually doesn't affect the quality too much.

Finally for me while prman keeps its pricing and keeps creating

micro polygons for ray tracing rather than implementing a pure

raytracing engine it won't be a competitor with mantra.

Share this post


Link to post
Share on other sites

Alan, thanks a lot for the information. I'm interested in testing out volume instancing in prman vs. mantra but haven't had the time to test thoroughly.

Also your work on getting pyro to render in prman looks really interesting.

Have you looked into using OpenVDB as a volume container as well?

Share this post


Link to post
Share on other sites

Alan, thanks a lot for the information. I'm interested in testing out volume instancing in prman vs. mantra but haven't had the time to test thoroughly.

Also your work on getting pyro to render in prman looks really interesting.

Have you looked into using OpenVDB as a volume container as well?

Hi Jon,

I have only breifly looked at OpenVDB's feature list. From first glance, I don't see any advantages over Field3D. I was hoping it would offer a mip-mapped storage format for performing filtered lookups, but it looks like it also requires point sampling voxel grids. (like Field3D)

The Field3D group has shown some interest on the subject at least.

I think it boils down to a pipeline decision more than anything. Otherwise, brickmaps are probably the best option for speed and quality.

Share this post


Link to post
Share on other sites

I think it boils down to a pipeline decision more than anything. Otherwise, brickmaps are probably the best option for speed and quality.

then why brickmaps haven't not been any option for field access method except pixar for those years? funny...

Share this post


Link to post
Share on other sites

then why brickmaps haven't not been any option for field access method except pixar for those years? funny...

My comment you quoted was discussing prman 17... I think you may have missed that.

I can clarify though.

prman 17's ImplicitField SDK has new methods for performing filtered lookups delineated by point p, dPdu, dPdv and dPdw (a filter region). If you want to take advantage of this, then you currently need to be using brickmaps.

Edited by Alanw

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×