RGB mattes for plants pulling alpha from image

Started by kmac, October 28, 2015, 02:17:03 PM

Previous topic - Next topic

kmac

Hi all,
so basically i am trying to generate what would be an object or material id...
I can generate the r g or b alpha with the constant shader, but hit an issue with my plants with multiple default shaders.. i need to maintain the alpha, but apply the b to the output for the rgb matte..

or do i need to look at this in a different way, not rely on what is coming out of the alpha and do some separate render for the mattes that relies on the colour information in the rgb.

pushing terragen through the feature pipeline for the first time, and not just using in for 2.5 D work, but actually relying on full renders.. obviously trying to sort out the best ways to get things out in the shortest amount of render time as well.. my rgb mattes right now are still running about 25 min a frame, but at least this way i can turn all lights, shadows, and atmos off.. just takes the time for calculating the displacement and mb...

any thoughts would be appreciated.. also any thought on comping all this back together in regards to premult not premult alphas. Surfalpha vs tgalpha - the aovs don't comp back in the way i am used to out of something like vray.

thanks!

k

Matt

#1
Welcome to the forum!

You can use a Default Shader with pure luminosity and set diffuse and reflectivity to 0. If there are other shaders above this that have opacity textures, the opacity will be respected.

So, if I assume the object has a typical shader setup with a Parts Shader (or a Multi Shader), and you want to give the object a pure blue colour, you could just put a luminous Default Shader after the Parts Shader or Multi Shader.

If you need to ID individual parts of the object by putting the luminous shader after any of the subcomponent's shaders, that should work too.

Unfortunately this is the only way to get an ID pass out of Terragen at the moment (that I know of), but we might be able to add a specific ID render element in future.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

I just checked this with a Constant Shader and that works too. I thought it might not respect the opacity of the input shader, but it does. So no need for a luminous Default Shader after all.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Matt

Regarding comping... your company has a Nuke gizmo called TerragenRead (or ReadTerragen) that might simplify things. It was used on some commercials last year. With that you can CC individual channels (maybe with ChannelCorrect?) If you can find that it should give you a good starting point even if you prefer to break it out and do something different.

Basically, most elements should be comp'd additively, so you can just Plus them together just like you would with VRay elements. But there are some things that can be confusing until you realise what's happening. For example, the surface elements are held out by the atmosphere, and can even be tinted as they are held out by the atmosphere at different wavelengths, which can be a bit confusing. But this allows the atmosphere RGB elements to plus over the surface RGB elements to produce the final RGB. The same is true of the alpha elements. The atmosphere alpha is actually an RGB triplet because of the spectral nature of the atmosphere, but you can use this information to properly tint distant objects rendered in other renderers (by inverting the spectral alpha, you get something you can multiply over the objects). You don't need this to comp the TG atmosphere over the TG surfaces, however, because the surfaces are already held out and tinted by the atmosphere so that they can simply be plus'd together.

I can go into more detail or clarify something if you have any questions.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

kmac

After the parts shader! yes, so much more sense. :) no messing around inside the default or multishader...

Basically because there are vray renders going "between" terragen layers - trying to sort out the best way to put it all back together and avoid halos..
I'll hunt for that gizmo from commercials. That sounds promising :)

thanks!

k

kmac

unrelated question - we are working native stereo.. is it worth using the new stereo camera ability inside terragen, as opposed to imported separate baked out fbx cameras?

thanks again :)

krista


Matt

Technically you can probably make the TG stereo camera match whatever the original stereo camera is doing. And that would be cool to use TG's stereo like that. If you're working in a bubble making your own cameras then that will probably work well. But if you're working with cameras from other packages, multiple shots, multiple versions of each shot, you want to be confident that TG is doing the same as everything else, so separate left and right camera import is probably best. Unless every single shot has the same interoccular and convergence?

Matt
Just because milk is white doesn't mean that clouds are made of milk.

kmac

It would be cool! Unfortunately not in a bubble :) And those values won't be consistent.. So separate camera import it is.

Thanks for the aov comp explanation...  That totally helps. I've never really had to deal with mixing in elements from other renderers in a full render kind of way.. In the enviro bubble usually just have the luxury of importing the objs
Thus far been fun pushing this through the pipeline.. Learning a lot. Pretty sure I will have 100 more questions before we're done. :)

And all my rgb mattes are now on the farm :) thank-you!

Krista


bobbystahr

something borrowed,
something Blue.
Ring out the Old.
Bring in the New
Bobby Stahr, Paracosmologist