Arnold for rendering particles?


#1

Hello!

I want a solution for rendering lots of particles (>1million) in 16bit. Maya’s hardware renderer can’t do it in 16bit and Mental Ray can’t cope with that many particles.

Has anyone used Arnold for rendering particles or nParticles?

It is supposed to be very fast at rendering LOTS of particles, but I just can’t find any meaningful documentation on this topic. The page on the Solidangle website is lacking, somewhat.

Specifically I need to know how to connect up the paticle sampler info node to a colour ramp so that I can render the particle’s rgbPP.

If anyone out there has rendered Maya particles with Arnold, please can you tell me what that connection should be, or if there is any documentation online.

Thanks!


#2

I don’t know about rendering particles with Arnold but u could try Exocortex Fury, Krakatoa or Renderman as an alternative.


#3

I hadn’t considered Exocortex Fury - I thought it was Softimage only.

Thanks for the tip!

The studio I work in does already have a few Arnold licences, so if there is someone out there who has experience rendering Maya particles with Arnold, I would be interested to learn how it works.


#4

Just did a quick test, not using particleSampler got random rgbPP on an nParticle without needing to add that as an exported attribute in the Arnold section of the particle shape.
Then I got age by adding that as an exported attribute.
The easiest way that I have found to get point data into shaders is to use the aiUserData nodes. In this case the aiUserDataColor worked for both rgbPP and age. Just connect the aiUserDataColor node into your final shader wherever you want…aiStandard, aiUtility, whatever. Add the name of the attribute to sample in the Color Attr Name section of the aiUserDataColor node. rgbPP or age or whatever attribute you want. Both of those worked for me using the aiUserDataColor even though one is a float and one is a vector.

Set your ‘render points as’ attribute to the type you would like and rock out.

Arnolds ability to handle point data in shaders is bananas!


#5

just keep in mind, fury and krakatoa render particles in pixel-space, which might be an issue when dealing with z-depth and accumulation of particles.

A always would prefer render particles with Renderman , Mantra or Arnold (rendering RiPoints/Disks with a world scale). It just looks more realisitc.

Just my 2 cents…


#6

By pixel space do u mean that the particle size is limited to the pixel size, if so u are correct about Krakatoa, Fury however does not limit the size to pixels u can have larger particles and smaller ones also for z-depth i never had a problem though i mostly use the depth pass in comp.


#7

That’s the ticket!

Thanks very much, Fox.

Now, why can’t Solidangle put that in their documentation? I dunno…


#8

I meant they dont change particle-size based on their distance to camera, like having a realworld sphere-size (at least as a far as I know and from what I’ve always seen and tested myself). So you set a point-size, either sub-pixel or a lot bigger but every particle will be rendered that big. In Renderman, Arnold and Houdini you are dealing with realworld-scale, either as RiPoints, disk-size in houdini or in Arnold as well. I find that pretty important when dealing with depth.


#9

First off sorry for diverting from the Arnold rendering part but here is a test using point particles with same default particle size and the emitter is a volumetric cube emitting particles away from the camera, the particles closer to the camera are bigger and the ones futher away are smaller so i guess this means that Fury isn’t rendering particles in pixel-space, also added a spot light with shadow just for fun.


#10

hmm … interesting. Thats is indeed world scale. Is that just rendered as points or “cloud-like” shape like old-school sw-particles in maya?

Thougt Fury would be pixel size as krakatoa is. Haven’t tested Fury yet. Would be able to render say 20M particles in this style?


#11

After a morning of Fury, I can tell you that it is very fast.

Here is what 20m particles with motion blur switched ON and 4 x multisampling looks like:

(note the time taken to render this image is 13.26 seconds)


#12

I was in the beta for Fury for Maya and it’s come a long way since the first versions that i tested, but i say that i can handle millions of particles, i think the largest amount i tested was 40 mil and had a decent rendertime, the particles in the image i rendered are default points but it also supports cloud and nparticles so u can go crazy with it.
Nice render dansidi did u use a fluid for the motion, one thing i found using fury is that since it uses the GPU for rendering the particles once u go over the memory limit fury will give and error and for that i try not to use motion bur or depth of field from Maya instead i use those as passes in comp so i will use the most out of the GPU memory.


#13

Here is a Krakatoa test, which is comparable to Fury in quality and speed. Very impressive results, I think.


#14

So,since you are doing these tests, I am wondering how Arnold does with that particle count?
Have you given it a try yet?
I am pretty sure it will be slower, but just wondering as Krakatoa and Fury aren’t part of our pipeline, would be great if you can give it a render.
Just for info.
Thanks!


#15

I’d also be interested to know. Any chance for some feedback?


#16

Arnold was fast but the results were not what I wanted. I had problems successfully passing opacityPP to the rendered particles - the documentation is not fantastic in regards to rendering Maya particles.

I suppose different renderers have their strengths. Arnold seems to be excellent at rendering high poly count scenes, but its particle toolset is not so well developed. That’s fair enough and I respect Arnold for what it can do.

I will use Krakatoa from now on for rendering large amounts of particles. It has great results and very useful tools for what I am trying to do.

A plus point for Arnold: I contacted their support team via twitter regarding their online help page lacking detail. To their credit, they added a new screenshot of the setup on their website for me. That’s good support! (The setup they described still didn’t work for me, but you can’t have everything can you?)


#17

On the contrary, its really fantastic for rendering particles as well. I’m surprised that the setup didn’t work for you. Perhaps you didn’t turn off the “Opaque” check box in the particle shape node? Its on by default as an optimization measure. Also, for particles since you will have a lot of overlapping transparent points, you might need to increase the transparency depth setting in Render Settings. There is a Min Pixel Width mode for particles in Arnold as well where you can clamp the minimum size of particles to avoid anti-aliasing issues. Lemme know if you need an example scene setup for testing.


#18

Thanks Sachin.

A sample scene would be extremely helpful.

The problem I can’t get around is that I cannot see any change in the render if I change the opacity of my particles, either per-object or per-particle.

I tried increasing the transparency Depth in the render settings as you suggested but it made no difference that I could see. (This is not mentioned in the Arnold tutorial, by the way)

I am attaching a screenshot of a small test setup showing the opacity settings, render settings, Arnold settings on the particle object and the viewport for the camera. You can see the sort of effect I am going for in the viewport - lots of low-opacity particles overlapping and building a smooth wispy smoke effect. I just cannot get Arnold to obey the opacity properly. Help!


#19

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.