prman 17 volume rendering vs mantra

[jonp]

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

[Alanw]

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 October 19, 2012 by Alanw

[Alanw]

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

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

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 October 19, 2012 by Alanw

[lisux]

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.

[jonp]

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?

[Alanw]

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.

[horizon1231]

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...

[Alanw]

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 October 23, 2012 by Alanw