OTOY Forums

I might be off-topic, I am not sure this is what you guys are talking about - I am not english : )

My understanding of this is that some renderers -mental ray being the most performant I know at this level- are able to retreive some "PP attributes" (per-particle attibutes) from the maya interface. In the VFX domain, this is such an useful feature, because the renderer is able to read from sprites PP rotation, PP size, PP color, opacity and so on. This ability of the renderer makes night and day the usability of sprites - and instanced particles - in maya, because if the renderer does not read PP attributes, all the sprites will look the same: same size, same direction, etc.

As far as I know, per-particle shading is made by the use of the ramp shader (integrated in the particleshape node). While particles are given a PP id by different methods (age, position, random) their color value is determined by the U or V color in the ramp shader, according to their PP id. It is then possible to assign different shaders at different positions/values of the ramp shader (which is controlled in the particleshape tab), and then different particles are shaded with one of these shaders from the relationship between the particle ID and the position of the shader in the ramp.

I am away from maya so I can't validate what I'm saying, please double-check those statements : )

It is also possible to override all this shading behavior by assigning another shader to the particles, like in Jimstar's picture. Then the particles will still read PP attributes of the particleshape, but the shading will be overriden by the new shader (so no PP shading).

Very few renderers catch many PP attributes, I think that a better integration of the PP / spritePP attributes is one of the most missing feature in every renderer. Must be very complicated I guess! It's not like maya is full of fresh new clean code right?


*** yeah sorry it seems no shader is allowed in the color ramp for PP shading, you need to use the Particle Sampler Node, as explained in the maya manual: http://download.autodesk.com/global/doc ... d30e676540

Per particle attributes work just fine in maya when rendering any type of particle render including sprites its only the geometry instancing that doesn't seem to have access to the pp attributes as far as shaders on the individual geometry instances go. It does allow you to use pp attributes to control the geo instances rotations, scales, aim direction etc. just not shader assignment.

T.

Sorry, what I meant is that it's not every renderer (mental ray, v-ray, maya software, maya hardware) that can read the PP atributes and render them correctly.

No problem to get the rgbPP for every particle when loading the scene to Octane engine.
The problem is: Octane engine does not have the means to deliver distinct colors to a couple of objects that use the same material... So, if you have only one Octane material node connected to the particle, only this material node will be loaded (and reloaded in IPR) to engine. Otherwise there will be a situation when a million of Octane material nodes will be generated, one for each particle when loading the scene, and when reloading the scene, etc... The huge impact on memory...
And in addition, Octane materials have a lot more settings than just "diffuse color"...
I think in this case, the method TBFX wrote about (one base object for each material variant) is more effective and more flexible, as you can change not only "color" but any settings of any Octane material type for each particle variant...

JimStar wrote:No problem to get the rgbPP for every particle when loading the scene to Octane engine.
The problem is: Octane engine does not have the means to deliver distinct colors to a couple of objects that use the same material... So, if you have only one Octane material node connected to the particle, only this material node will be loaded (and reloaded in IPR) to engine. Otherwise there will be a situation when a million of Octane material nodes will be generated, one for each particle when loading the scene, and when reloading the scene, etc... The huge impact on memory...
And in addition, Octane materials have a lot more settings than just "diffuse color"...
I think in this case, the method TBFX wrote about (one base object for each material variant) is more effective and more flexible, as you can change not only "color" but any settings of any Octane material type for each particle variant...

Oh well. The feature exists in RenderMan and complaint renderers like 3Delight.

To be clear, it doesn't matter to the artist to which node the instancing material is applied. As long as you don't have to make "base objects," because that is horrible—that is essentially saying, "For a given effect, let's make the user generate every single possible material variation, and on top of the memory of building the Maya nodes, let's waste the user's time instead of the computer's time."

The ideal graph is just a particleSamplerInfo—or any kind of custom node that encapsulates iterating through the particles—that is piped into a single shader.

"Octane engine does not have the means to deliver distinct colors to a couple of objects that use the same material"

Does Octane translate switch nodes? Switch nodes and particleSamplerInfo do the same work in abstract: vary a shading parameter depending on what geometry is shaded. mentalray translates it I think.

Getting this right means real nature scenes: you can vary the color of trees and grass. Getting this right means all the best abstract particle effects: instanced geometry that aren't just duplicates. Getting this right means we can render MASSIVE scenes: lots of characters with varied textures. It's a good thing to implement. If it's not in the SDK, it should try to be.

doctorpangloss
The answer to your question "Does Octane translate switch nodes?" - is NO. You can see it by yourself: just start the Octane standalone, and try to create one material node, connect it to two distinct meshes, and render it such a way that one mesh will be green and another will be red. Perhaps I don't understand something and you will be able to do it, but I don't see the way to do it. So, if there is no way to do it in standalone - you should understand that it is not the SDK problem, it is the Octane engine architecture at the time... It does not have analogs of "switch" nodes AFAIK...
So, the only way to realise it at the time, is to load millions of unique copies of these material nodes (the same count as the particles count) to the engine at each scene reloading... It will eat the VRAM and translating time and restrict some dinamics when refreshing scene in the RenderView (the full scene reload will be needed to reload just particles or particles material attribute changed)...
Very ugly... I don't like such a way... I will try to find some other way, but I don't see at the time the other than this one...

Hi JimStar,

I'm not suprised there is no real solution for this at the moment as it's really Maya's failing in the particle instance node and what it exposes. I was certainly never hoping to have the control of a shader per particle instance and I'm not sure anyone else is either. I actually wasn't expecting to get the ability to shade particle instances differently at all simply because Maya doesn't natively do this. However one of your earlier posts in this thread gave me some hope that you could do something with the plugin to help a little.

Here is what I thought may be possible, though I completely get that it may not be and understand the reasons why.

With the particle instancer we can cycle through a range of different geometry to instance to a partical system using an expression or ramp etc. (as I would in my workaround above) All I was hoping for was a way to have a number of pre-built shaders already in the scene and be able to cycle through or randomly assign these to different instances in the system in the same way. If I create instances of geometry manually in my scene I can definitely assign different shaders to each one (I've tested this in the plugin beta 3.0) We just lack a way to do this to particle instances.

Again, I get it if this is not possible, I just wanted to be clear. My workaround works but with Octane we have voxelizing time and limited RAM to deal with so it's certainly not ideal. Having said that, having support for particle instances without seperate shading is way better than no support at all.

T.

I think I've found the way how to get the sterling pseudo-random Octane shading on the particles without using this rgbPP... With the full set of each material attributes adjustable...
Working on it...

OK, my way works...

A miracle worker has been found