Render Passes 2009

[itriix]

Hi everyone,

I'm desperately trying to figure out a good approach to rendering passes. I know this topic has been covered over and over again but for some reason I still can't seem to find a simple approach. I could really use your help.

I'm aware there are many ways to do these things but once again that's what leads to my confusion. As a good learning experience to nail down my understanding once and for all on how to succesfully get render passes out of houdini into a comp program efficiently, i'd like to use my current little project as an example. This can be found here. It seems like it should be easy enough but everything i've tried just leaves me with incorrect or incredibly inefficient results. It's a coke can disintegration. It's two objects, the coke can... and then the particles. it's 2 million particles, so it has taught me quite a lesson in wanting to get the render passes methodology locked down because it just sucks having to rerender.

I want to have full control in comp to tweak the individual passes... for each object seperately. I also get a little confused trying to seperate this out because for example, you have the coke can, with particles in front of and behind it with the coke can inside of it. which tends to confuse me once again how to correctly seperate this all out. I feel like to a "seasoned" render pass user this example should be fairly common but a bit more above average is complexity when compared to the very few "tutorials" on render passes i've seen, that simply have objects, in front of or behind... not actually INSIDE of other objects.

These are the passes i'm looking to get out. passes for each object individually!

coke can: spec, diffuse, refl, paint, opac, shadow

particles: spec, diffuse, refl, paint, opac, shadow

My approach so far is "somewhat" like this:

Rebuild the materials so that they export: spec, diffuse, paint, refl, opac...

Then, the only way that I really know how at the moment, to get these passes PER object, are to break the objects up into takes... and then use two mantra nodes.

Example:

Coke_Can Take, where the particles geo node is set to Phantom

Particles_Take, where the coke can geo node is set to Phantom

Two mantra nodes. One for the Coke_Can Take and one for the Particles_Take.

Then set up the images planes to include spec, diffuse, refl, paint, opac...

Already though this seems a bit "redundant" when having to render. If this is a small amount of particles, then yeah maybe this wouldn't be so bad. But if I bump the particles up to MILLIONS+++... This starts to seem very INefficient, having to render it TWO times just to get it broken up into two different objects... this leads me to my next part that i get stumped and that is getting the shadows per object. Only way that I know of "at the moment", is create TWO MORE TAKES and TWO MORE MANTRA NODES... Apply the shadow matte shader to all of the objects in the scene for those takes. And in the "coke_can_shadow" mantra node, use the coke can shadow take. and set the particles to phantom. then do the same type of thing for the particles_shadow_take"... set the coke_can to phantom... create a mantra node for the "particles_shadow_take"...

However, now already at this point, that's 4 mantra nodes. and if i have MILLIONS of particles, something just starts to seem totally wrong about my approach. I also feel like i'm not setting this stuff up correctly in order to get proper hold outs.

And when I bring my passes (so far) into comp and multiply the diffuse and paint and add spec on top, it doesn't look anywhere CLOSE to what the "main" final render is supposed to look like. The edges also look horrid. I tried changing the interpretation method of the alpha it to "premultipled", "straight", "none"... all of them look terrible. So i'm definitely lost and could really use someones help! I've broken out passes before successfuly with other packages but i just can't seem to get a solid approach with houdini yet.

And yes, I've read the "ancient render passes pdf used with h8" where they implement 100000000000000000 takes. I don't know, but that 20 page pdf, i've gone through twice now, and i still feel/HOPE that can't be the best way to do this render pass setup!

So please, anyone, if you could guide me along, i'll follow directions to the T...

Thanks so much,

Jonathan

Edited November 9, 2009 by itriix

[sam.h]

I want to have full control in comp to tweak the individual passes... for each object seperately. I also get a little confused trying to seperate this out because for example, you have the coke can, with particles in front of and behind it with the coke can inside of it. which tends to confuse me once again how to correctly seperate this all out. I feel like to a "seasoned" render pass user this example should be fairly common but a bit more above average is complexity when compared to the very few "tutorials" on render passes i've seen, that simply have objects, in front of or behind... not actually INSIDE of other objects.

For this I would separate it into a coke can build and a particle build (so two different takes / sets of passes. For the coke can render I would set the particles to phantom. For the particle build I would just use the coke can as a matte object (so that you can just put the particles over the can)

These are the passes i'm looking to get out. passes for each object individually!

coke can: spec, diffuse, refl, paint, opac, shadow

particles: spec, diffuse, refl, paint, opac, shadow

If you are just using the spec/diffuse nodes then the shadow will be baked into the spec/diffuse pass. I think you need to do your own illuminance loop if you want an unshadowed spec/diffuse. Also opac seems kinda pointless ... or are you doing tears in the object?

My approach so far is "somewhat" like this:

Rebuild the materials so that they export: spec, diffuse, paint, refl, opac...

Then, the only way that I really know how at the moment, to get these passes PER object, are to break the objects up into takes... and then use two mantra nodes.

Example:

Coke_Can Take, where the particles geo node is set to Phantom

Particles_Take, where the coke can geo node is set to Phantom

Two mantra nodes. One for the Coke_Can Take and one for the Particles_Take.

Then set up the images planes to include spec, diffuse, refl, paint, opac...

That seems like the best way to do it to me (separate sets of passes) but you COULD do it in one render by using an ID pass. So add a vector attribute to each object which will be your ID and set the can to R and the particles to G. This way you can separate them in comp.

Already though this seems a bit "redundant" when having to render. If this is a small amount of particles, then yeah maybe this wouldn't be so bad. But if I bump the particles up to MILLIONS+++... This starts to seem very INefficient, having to render it TWO times just to get it broken up into two different objects... this leads me to my next part that i get stumped and that is getting the shadows per object. Only way that I know of "at the moment", is create TWO MORE TAKES and TWO MORE MANTRA NODES... Apply the shadow matte shader to all of the objects in the scene for those takes. And in the "coke_can_shadow" mantra node, use the coke can shadow take. and set the particles to phantom. then do the same type of thing for the particles_shadow_take"... set the coke_can to phantom... create a mantra node for the "particles_shadow_take"...

However, now already at this point, that's 4 mantra nodes. and if i have MILLIONS of particles, something just starts to seem totally wrong about my approach. I also feel like i'm not setting this stuff up correctly in order to get proper hold outs.

I rarely simulate at render time (IFD gen time) for this reason. Just precache the slow stuff to memory or disk. This way all you have to do at IFD gen time is read geo from disk and write it back in the IFD.

I don't understand what shadows you want? Just particle > can and that type of thing, or can > ground plane type stuff?

And when I bring my passes (so far) into comp and multiply the diffuse and paint and add spec on top, it doesn't look anywhere CLOSE to what the "main" final render is supposed to look like. The edges also look horrid. I tried changing the interpretation method of the alpha it to "premultipled", "straight", "none"... all of them look terrible. So i'm definitely lost and could really use someones help! I've broken out passes before successfuly with other packages but i just can't seem to get a solid approach with houdini yet.

So you are dividing by alpha first? Do your AOVs have the alpha in them? I usually have to copy the alpha to the pass > divide by alpha > mult add etc > mult by alpha.

I get annoyed with the COP context, I jsut don't us it for CG builds :/

And yes, I've read the "ancient render passes pdf used with h8" where they implement 100000000000000000 takes. I don't know, but that 20 page pdf, i've gone through twice now, and i still feel/HOPE that can't be the best way to do this render pass setup!

So please, anyone, if you could guide me along, i'll follow directions to the T...

Thanks so much,

Jonathan

I attached an example of what I have done with a build a while ago. I have shadows casting on the plate in the alpha of the beauty. I could get the actual alpha of the object because I have an ID pass.

I hope this makes sense!

[itriix]

Hello Sam,

Thanks so much for taking the time to respond to my post. I'll clarify a bit more of what i'm going for...

I will eventually add this coke can disintegration to a scene... a simple table and surrounding room (the room will be pretty far out so no need for shadow's and such on it)...

So as for the shadows: (some of this might seem a bit unecessary, but i'm also just trying to learn a good workflow because there will be times for sure that i HAVE to have multiple shadow passes broken up like this)

can > can (self shadowing in the rim area), particles, table

particles > can, table, particles (they self shadow)

As for the "re-rendering" vs all-in-one render... I actually DO have my particle's simmed out to disk already. However, I still feel there is quite a bit of "overhead" in rendering multiple times in order to separate the objects into individual passes, even if i am just loading the sim from disk. Especially in a case where there are MILLIONS+++ particles. For example, if the disk cache takes up 80 GIGS *which is quite easy to do with particle caches*, on disk... The time it takes to render multiple times, just to get objects separated out into passes, still seems to be a bit "inefficient"... In fact, just my 2 million particles takes up 17 GIGS... (over 120 frames)... It definitely seems "easier" to just make multiple takes and just render multiple times, but in the long run, for BIG BIG particle amounts (on disk), it seems like there should be a better approach. You pointed out two options, using OBJECT_ID and an illumance loop... I've never set up either in Houdini. It seems like it would be a good thing to know. Yes/No? Especially in cases like i'm discussing here. *as for my little project, 2 million particles/ 17 GIGS* isn't too terrible to just render multiple times in order to break up the passes, so i will keep that in mind but i still would like to have other options at my disposal incase i do run into a MUCH larger disk cache example and need to be more efficient at rendering it out.

*am i sounding crazy? am i totally wrong here? as far as i'm understanding it though, i just feel like here's what would be happening*

render the can: spec/diff/opac pass... *that involves loading the particles in*

render the particles: spec/diff/opac pass... *that once again, involves loading the particles in*

and "being unfamiliar with setting up the illum loop", as of now, if i wanted separate shadow passes, that would require rendering 6 more times *if my above mentioned shadow passes don't sound too crazy*...

can > can (wouldn't require loading particles)

can > particles (require loading particles)

can > table (wouldn't require loading particles)

particles > particles, can, table EACH would require loading the particles...

So all in all, that would be loading in the particles 6 times to get these passes... 2 for can and particle "spec/diff/opac" passes. 4 for shadows!

and then 2 more shadow passes that would be somewhat fast.

Am I totally thinking about this in the wrong way? Or would that be correct. And when I look at it like this, and i think about "massive amounts of particles" and how MUCH extra time that's taking just to load in, all those times, just for all those passes, I feel like there has GOT to be a better/more efficient way.

(i'll apologize now if i sound like i'm thinking too much)... i just really want to get a good, solid understanding for tackling whatever set of renderpasses i want/need... Do you think i can solve this problem with learning how to use the illuminance loop and object_id?

As for the comping:

(i was working in after effects for this because for some reason ae cs4's render preview is almost instantaneous when compared to shake)... so i stopped using shake for quite a while, but ae is annoying in it's own way too! So, tonight i'm going to go back and try out shake to see if i can get a nicer looking result... ) I thought i remembered hearing somewhere that shake can only handle 5 channels, and so exrs with many channels might not work unless having a special plug in? I don't know i guess i'll find out tonight about that one.

I'm going to upload some images of one of the "openexr's" broken up into my, MAIN, spec, diffuse, opacity... (this is before i've even started to attempt breaking this out into seperate can and particles passes)... The main render looks exactly how i want it, but the passes i don't think are necessarily coming out correct. They all seem "fairly correct" except for the diffuse pass... It seems to be a bit bright on it's top edge... And when I multiply my paint with my diffuse, i get a very bright spot there. I've uploaded a picture of this "error"... As for you're question about Alpha... None of my "aov's have an alpha channel... Should they? Also, one last thing I should bring up is something that could be causing some of my errors, is that, my coke can, fades out, *procedurally* with an alpha... that drives the particles!... the thing is, the material that's applied to my coke can, it would fade out correctly except for the specular... originally, the specular was still there in the render, even though the rest of the can disappeared... So as a quick and dirty fix *just was guessing*, i created an alpha parameter in the shader network, then multiplied the specular and opacity by it. this SEEMED to fix the problem.... as far as the "main render goes" however, i might have done this wrong... and this could be causing problems in my passes? *as i said, the main render looks exactly how i want it though*... it's only if i break it up into passes, do i get an incorrect look.

So as for tonight, i'll try and take my passes into shake and see if i can get it to match my "final" MAIN render. If I can get it to match, then i'll assume i was doing something wrong in after effects and that the way I set up the shader was correct. If not, then i'm going to have to look into it a bit further...

I truly do appreciate you taking the time to help out. I hope I don't scare you away with all of my "theories"/questions!

Thanks,

Jonathan

[sam.h]

Hello Sam,

Thanks so much for taking the time to respond to my post. I'll clarify a bit more of what i'm going for...

I will eventually add this coke can disintegration to a scene... a simple table and surrounding room (the room will be pretty far out so no need for shadow's and such on it)...

So as for the shadows: (some of this might seem a bit unecessary, but i'm also just trying to learn a good workflow because there will be times for sure that i HAVE to have multiple shadow passes broken up like this)

can > can (self shadowing in the rim area), particles, table

particles > can, table, particles (they self shadow)

As for the "re-rendering" vs all-in-one render... I actually DO have my particle's simmed out to disk already. However, I still feel there is quite a bit of "overhead" in rendering multiple times in order to separate the objects into individual passes, even if i am just loading the sim from disk. Especially in a case where there are MILLIONS+++ particles. For example, if the disk cache takes up 80 GIGS *which is quite easy to do with particle caches*, on disk... The time it takes to render multiple times, just to get objects separated out into passes, still seems to be a bit "inefficient"... In fact, just my 2 million particles takes up 17 GIGS... (over 120 frames)... It definitely seems "easier" to just make multiple takes and just render multiple times, but in the long run, for BIG BIG particle amounts (on disk), it seems like there should be a better approach. You pointed out two options, using OBJECT_ID and an illumance loop... I've never set up either in Houdini. It seems like it would be a good thing to know. Yes/No? Especially in cases like i'm discussing here. *as for my little project, 2 million particles/ 17 GIGS* isn't too terrible to just render multiple times in order to break up the passes, so i will keep that in mind but i still would like to have other options at my disposal incase i do run into a MUCH larger disk cache example and need to be more efficient at rendering it out.

For sure!

Use a delayed load geometry shader so the particles are stored in one place, and just referenced in the IFDs. You still have to load the particles each time you render a frame....

The illuminance loop was just so you could get unshadowed diff/spec. I wouldn't worry about that yet, The only place I have had to use that was when I needed to relight some pants on an actor. You should get your lighting close enough that you don't need that control in comp.

Yes, you can just render the can/particles in one set of passes (which kinda seems right now I think about it, since they will be the same 'material') and then use an ID pass to identify the particles/can in comp. I attached an example of this ...

*am i sounding crazy? am i totally wrong here? as far as i'm understanding it though, i just feel like here's what would be happening*

render the can: spec/diff/opac pass... *that involves loading the particles in*

render the particles: spec/diff/opac pass... *that once again, involves loading the particles in*

and "being unfamiliar with setting up the illum loop", as of now, if i wanted separate shadow passes, that would require rendering 6 more times *if my above mentioned shadow passes don't sound too crazy*...

can > can (wouldn't require loading particles)

can > particles (require loading particles)

can > table (wouldn't require loading particles)

particles > particles, can, table EACH would require loading the particles...

So all in all, that would be loading in the particles 6 times to get these passes... 2 for can and particle "spec/diff/opac" passes. 4 for shadows!

and then 2 more shadow passes that would be somewhat fast.

Am I totally thinking about this in the wrong way? Or would that be correct. And when I look at it like this, and i think about "massive amounts of particles" and how MUCH extra time that's taking just to load in, all those times, just for all those passes, I feel like there has GOT to be a better/more efficient way.

(i'll apologize now if i sound like i'm thinking too much)... i just really want to get a good, solid understanding for tackling whatever set of renderpasses i want/need... Do you think i can solve this problem with learning how to use the illuminance loop and object_id?

I think you should start basic and work in more renders passes as you need them, it is nice having heaps of control in comp but might not be necessary?

start with 1 render of can/table/particles, with an ID pass. what other control do you need?

As for the comping:

(i was working in after effects for this because for some reason ae cs4's render preview is almost instantaneous when compared to shake)... so i stopped using shake for quite a while, but ae is annoying in it's own way too! So, tonight i'm going to go back and try out shake to see if i can get a nicer looking result... ) I thought i remembered hearing somewhere that shake can only handle 5 channels, and so exrs with many channels might not work unless having a special plug in? I don't know i guess i'll find out tonight about that one.

Yeah, I think it is RGBA. I use seperate EXRs for each AOV. Maybe you could try Nuke, apparently it is the new hotness

I'm going to upload some images of one of the "openexr's" broken up into my, MAIN, spec, diffuse, opacity... (this is before i've even started to attempt breaking this out into seperate can and particles passes)... The main render looks exactly how i want it, but the passes i don't think are necessarily coming out correct. They all seem "fairly correct" except for the diffuse pass... It seems to be a bit bright on it's top edge... And when I multiply my paint with my diffuse, i get a very bright spot there. I've uploaded a picture of this "error"... As for you're question about Alpha... None of my "aov's have an alpha channel... Should they? Also, one last thing I should bring up is something that could be causing some of my errors, is that, my coke can, fades out, *procedurally* with an alpha... that drives the particles!... the thing is, the material that's applied to my coke can, it would fade out correctly except for the specular... originally, the specular was still there in the render, even though the rest of the can disappeared... So as a quick and dirty fix *just was guessing*, i created an alpha parameter in the shader network, then multiplied the specular and opacity by it. this SEEMED to fix the problem.... as far as the "main render goes" however, i might have done this wrong... and this could be causing problems in my passes? *as i said, the main render looks exactly how i want it though*... it's only if i break it up into passes, do i get an incorrect look.

I don't have alphas in my AOV EXRs, so i copy the beauty alpha, and divide the AOV by it.

Yeah, introducing shader opacity makes it a bit harder, I have had problems like this, I just played around with multing by the opacity and it fixed my problems.

So as for tonight, i'll try and take my passes into shake and see if i can get it to match my "final" MAIN render. If I can get it to match, then i'll assume i was doing something wrong in after effects and that the way I set up the shader was correct. If not, then i'm going to have to look into it a bit further...

I truly do appreciate you taking the time to help out. I hope I don't scare you away with all of my "theories"/questions!

Thanks,

Jonathan

Maybe you could post some EXRs and I will throw together a build?

[sam.h]

Oops! forgot to attach the ID pass thingy.

I usually get sampling issues at the intersection/overlap of the different IDs, so I have changed the pixel filter and it seemed to help ... the different IDs look like they add up to one now at least

idPass.hip

[itriix]

Seriously, thanks so much! I'm going to study you're file right now. I'll work on trying to separate my can/particles/table into passes and outputting a new set of .exr's tonight. I'll post my results in the morning. (it's midnight here right now) In the meantime, (if you're bored I'm posting an .exr from the images i posted earlier. I was unable to get the separated passes back together in comp to look like the original render. (I'm curious if part of it's due to setting up my shader wrong)... *note, this is just one .exr with multiple channels*, you suggested outputting multiple .exrs for each aov... so i'll make sure to do that with my new set of .exrs.

Anyways, i'm going to get back to work, I can't say it enough, THANKS once again though!

Jonathan

coke_can_disintegration_03.9_tk01.0060.exr.zip

[itriix]

one more thing i forgot to mention. in response to you're suggestion of using the delayed load: (without straying too far from this topic, i posted a question here at SESI's website, about why I might be having "different' renders, when using the delayed load shader)... It seemed a bit curious to me. So in my above renders, I wasn't using the delayed load anymore because it was a bit brighter, than if i just "loaded" my geometry in with a filesop... (which is much slower) but it gave me the "look" i wanted. Thoughts on why the delayed load would be rendering different than the same exact file loaded in from a file sop?

anyways, at the link, i posted a pic that shows a comparison. it seems very strange to me! okay, seriously back to work now i go!

Jonathan

Edited November 10, 2009 by itriix

[sam.h]

one more thing i forgot to mention. in response to you're suggestion of using the delayed load: (without straying too far from this topic, i posted a question here at SESI's website, about why I might be having "different' renders, when using the delayed load shader)... It seemed a bit curious to me. So in my above renders, I wasn't using the delayed load anymore because it was a bit brighter, than if i just "loaded" my geometry in with a filesop... (which is much slower) but it gave me the "look" i wanted. Thoughts on why the delayed load would be rendering different than the same exact file loaded in from a file sop?

anyways, at the link, i posted a pic that shows a comparison. it seems very strange to me! okay, seriously back to work now i go!

Jonathan

heh, that is strange! No idea what that could be :/

[sam.h]

Seriously, thanks so much! I'm going to study you're file right now. I'll work on trying to separate my can/particles/table into passes and outputting a new set of .exr's tonight. I'll post my results in the morning. (it's midnight here right now) In the meantime, (if you're bored I'm posting an .exr from the images i posted earlier. I was unable to get the separated passes back together in comp to look like the original render. (I'm curious if part of it's due to setting up my shader wrong)... *note, this is just one .exr with multiple channels*, you suggested outputting multiple .exrs for each aov... so i'll make sure to do that with my new set of .exrs.

Anyways, i'm going to get back to work, I can't say it enough, THANKS once again though!

Jonathan

Hmm, can't load that is shake :/ Hit me up with the new EXRs when you have 'em!

[itriix]

Hmm, can't load that is shake :/ Hit me up with the new EXRs when you have 'em!

Will do! and just in case, *i'm sure you caught this, but the .exr i uploaded was zipped...* incase you didn't unzip it...

Regardless, I'll upload the "new ones" in the morning!

Thanks,

Jonathan

***PS: I can post a .hip if you're interested. This project is just for fun, so I have no qualms sharing it with the community***

Edited November 10, 2009 by itriix

[itriix]

still hooking up some stuff, will be uploading the .exr's soon. but to start off, i'd have to say you're example helped me so much. Not only is this going to save me time in the long run of not having to "re-render" just for each object but also, i think it's helped me solve my problem i addressed earlier about thinking that my "shader" might not be hooked up correctly. I noticed as I was testing with the obj_id, that the particles were being occluded by the can, even after the can disappeared. it makes sense now why when i broke out my render into passes, i couldn't get it to look the same. the particles were being thinned out in those "occluded" areas. breaking it up into this simple, "red" and "blue" obj_id, helped me to "LOCATE" that issue!

Thanks,

once again, i'll be posting my results later on today

Jonathan

[itriix]

okay, so here is a .zip file with 6 .exr's... Beauty, Paint, Diffuse, Opacity (might not need that), Specular, Obj_Id...

Learned a few things today in the process...

1. I think i figured out WHY my delayed load shader version and my normal FILE SOP version of the renders were different. I'm still a bit new using the delayed load, and i noticed, when i was trying to break out passes, using the delayed load, that i couldn't get the passes out... i thought that was weird. so i just tried some stuff. Usually, I would use a GEO ROP to sim out my particles to disk. I would then create a GEO NODE with a delayed load shader on it that points to that disk cache. There would be NO NODES inside of the geo node. I think that's where the problem was. NOT SURE WHY, but, when I rendered as usual with nothing inside, i get a brighter look and no aov's. Therefore, i put a file sop inside, and pointed to the disk cache. I set the render flag to it, and then created a null and set the display to that. *so that i didn't have to load it in the viewport*. Then I clicked render. Voila, the color was back to the original render and i got my aovs again... any idea's why this works like this?

2. Learned that i needed to literally multiply my alpha by EVERY single exported pass in order to get my "aov's" correct. That sound correct? Well seems to have worked for me!

3. Learned that I could use the switch shop, to switch between the obj_id and the main material, using the RENDERPASS variable. Then set up a pre and post render script in the mantra rop that turned this on and off. I was stuck for a second though because I used one material originally, for all of my four peices of geometry *because this can was broken up into 4 peices*... then used a material overide in sops, for each piece's individual material to override the "texture map"... however, when i added in the switch shop, and plugged the output of the switch shop into an OUTPUT shop... that left me pointing my materials to that final OUTPUT SHOP... "thought that the material overrides at sops, would break down, since they were pointing to a different "shader"... however, this wasn't the case, they were able to locate that shader correctly even though they were pointing to the OUTPUT SHOP material instead! -- this leads me to another question. in the shader of my can, there are channel references to the "promoted" material level in shops. *common*... i created a channel reference for the "opengl" texture map to reference the "texture map" path on the material shop level. However, since this SINGLE material is applied to "four pieces" of geometry, each one of them having a material override in SOPS, for the "texture map"... it seems like the "opengl" texture map reference isn't really working... it's only noticing the first one. The viewport shows my coke can, with the "label" applied all over the geometry... *the label was the first texture map*.... However, it renders right. Maybe material overrides won't work like this for the open gl channels?...

4. OBJ_ID, you'll see when you take a look at my files. I'm not sure if I set it up correctly. I had the same problems as earlier, where if i didn't multiply the output by my alpha, etc etc... before plugging it into the output vop, it was still showing the entire object even when it had disappeared. therefore i did the multiplying and that seemed to work great. however, in some places they overlap "i assume at the same pixel space" and the colors turn magenta... i used blue and red! So, I think there is a way to fix that, but i'll let you take a look and see what you think about it anyways.

5. What do you suggest my "individual channel" extra image plane settings should be set at? I'm having a feeling i'm not setting those up correctly. For now, i just click the "add extra image plane" type in the name, set the location where it should be saved out. and that's all. Should i be setting the filtering? should i make it 16 bit instead of 32? Any other settings on there? Haven't dealt with comping that much in houdini yet but was thinking that maybe the couple images i was trying to get comped together, that weren't working out too great on the edges might have to do with fixing up those settings? yes/no?

6. Shadows... I'm getting some "pretty weird looking" shadow passes, when i tried playing around with that. I'll render one out and upload that in a little while. *can't put my finger on it, but almost seems as though the shadows on my "can" are inverted or something, when i break it into it's own render pass. I haven't used a "shadow matte vop" before, maybe i'm doing something wrong. I'm certain it's set up correctly though. So that leads me to think something might be wrong with the geometry, but i'm fairly certain it's fine too. otherwise i feel like the texture maps wouldn't be applied correctly. *if the normals were reversed or something like that*

7. Thanks again! I've learned a ton in the last NIGHT. I feel very good about it

Jonathan

exr.zip

Edited November 11, 2009 by itriix

[sam.h]

okay, so here is a .zip file with 5 .exr's... Beauty, Paint, Diffuse, Opacity (might not need that), Specular, Obj_Id...

Learned a few things today in the process...

1. I think i figured out WHY my delayed load shader version and my normal FILE SOP version of the renders were different. I'm still a bit new using the delayed load, and i noticed, when i was trying to break out passes, using the delayed load, that i couldn't get the passes out... i thought that was weird. so i just tried some stuff. Usually, I would use a GEO ROP to sim out my particles to disk. I would then create a GEO NODE with a delayed load shader on it that points to that disk cache. There would be NO NODES inside of the geo node. I think that's where the problem was. NOT SURE WHY, but, when I rendered as usual with nothing inside, i get a brighter look and no aov's. Therefore, i put a file sop inside, and pointed to the disk cache. I set the render flag to it, and then created a null and set the display to that. *so that i didn't have to load it in the viewport*. Then I clicked render. Voila, the color was back to the original render and i got my aovs again... any idea's why this works like this?

Hmm, so the way you have it at the moment means there is no delayed load going on, right? The way you have it now means that the particles will be written out into each IFD, are you writing out IFDs?

2. Learned that i needed to literally multiply my alpha by EVERY single exported pass in order to get my "aov's" correct. That sound correct? Well seems to have worked for me!

Yeah that seems right!

3. Learned that I could use the switch shop, to switch between the obj_id and the main material, using the RENDERPASS variable. Then set up a pre and post render script in the mantra rop that turned this on and off. I was stuck for a second though because I used one material originally, for all of my four peices of geometry *because this can was broken up into 4 peices*... then used a material overide in sops, for each piece's individual material to override the "texture map"... however, when i added in the switch shop, and plugged the output of the switch shop into an OUTPUT shop... that left me pointing my materials to that final OUTPUT SHOP... "thought that the material overrides at sops, would break down, since they were pointing do a different "shader"... however, this wasn't the case, they were able to locate that shader correctly even though they were pointing to the OUTPUT SHOP material instead!

The switching stuff sounds cool, might check it out sometime. I love the material parameter override thing in SOPs, been really useful for matte painting projects

4. OBJ_ID, you'll see when you take a look at my files. I'm not sure if I set it up correctly. I had the same problems as earlier, where if i didn't multiply the output by my alpha, etc etc... before plugging it into the output vop, it was still showing the entire object even when it had disappeared. therefore i did the multiplying and that seemed to work great. however, in some places they overlap "i assume at the same pixel space" and the colors turn magenta... i used blue and red! So, I think there is a way to fix that, but i'll let you take a look and see what you think about it anyways.

If you are viewing with a LUT it might do that. I had things like that happen but I will have a look.

5. What do you suggest my "individual channel" extra image plane settings should be set at? I'm having a feeling i'm not setting those up correctly. For now, i just click the "add extra image plane" type in the name, set the location where it should be saved out. and that's all. Should i be setting the filtering? should i make it 16 bit instead of 32? Any other settings on there? Haven't dealt with comping that much in houdini yet but was thinking that maybe the couple images i was trying to get comped together, that weren't working out too great on the edges might have to do with fixing up those settings? yes/no?

Meh, I always leave it at default

6. Shadows... I'm getting some "pretty weird looking" shadow passes, when i tried playing around with that. I'll render one out and upload that in a little while. *can't put my finger on it, but almost seems as though the shadows on my "can" are inverted or something, when i break it into it's own render pass. I haven't used a "shadow matte vop" before, maybe i'm doing something wrong.

7. Thanks again! I've learned a ton in the last NIGHT. I feel very good about it

Jonathan

Yeah, I think a value of 1 mean fully shadowed ... It is a bit strange.

[itriix]

the weird shadow pass. for this, i used a shadow matte vop. kinda strange looking huh?

Edited November 11, 2009 by itriix

[itriix]

Hmm, so the way you have it at the moment means there is no delayed load going on, right? The way you have it now means that the particles will be written out into each IFD, are you writing out IFDs?

Hmmm. no i'm not writing out ifd's. In order to get my particles to disk. I have a geo node, with popnet/attributes/material inside. I then have an GEO ROP. I use the geo rop, to create my particle disk file. I then create a GEO NODE in OBJ level (with NOTHING inside it)... apply a delayed load shader to it. I then point that delayed load shader to the particle disk file. If I hit "render" on a mantra rop, i get the "brighter", incorrect render, and NO aov's.

That's what lead me to trying to figure it out. So, I then layed down a file sop inside of that GEO NODE *with the delayed load shader* and pointed the file sop to the SAME particle disk file. I set it as the render flag and create a null and point to that null for the display. Then if I hit render, it works correctly. (i was under the assumption that as long as the "delayed load shader" is applied to a GEO NODE at obj level, it will override ANYTHING that's inside of it. So, i'm not sure, am i not doing this right? Should I be doing it different?

[sam.h]

Hmmm. no i'm not writing out ifd's. In order to get my particles to disk. I have a geo node, with popnet/attributes/material inside. I then have an GEO ROP. I use the geo rop, to create my particle disk file. I then create a GEO NODE in OBJ level (with NOTHING inside it)... apply a delayed load shader to it. I then point that delayed load shader to the particle disk file. If I hit "render" on a mantra rop, i get the "brighter", incorrect render, and NO aov's.

That's what lead me to trying to figure it out. So, I then layed down a file sop inside of that GEO NODE *with the delayed load shader* and pointed the file sop to the SAME particle disk file. I set it as the render flag and create a null and point to that null for the display. Then if I hit render, it works correctly. (i was under the assumption that as long as the "delayed load shader" is applied to a GEO NODE at obj level, it will override ANYTHING that's inside of it. So, i'm not sure, am i not doing this right? Should I be doing it different?

I thought that the delayed load was in addition to things you have in you OBJ, haven't played around with it. I think there is some good stuff in the docs about it?

[itriix]

wahoooooooo!... i think, it's just that ae sucked and shake rocked for comping this

because i just set up the shot in shake and it seemed to work WAY better! (i haven't tried to seperate stuff out with the obj_id though)... i'll wait for your example. not really sure how to go about using it yet. Anyways, i'm upping some pics. Now instead of having horrid edges, i'm having "eaten" away edges. But it's still progress in my opinion. Haven't used shake in A LONNNNNNNNNNNNNG time, so i'm sure i'm just doing something wrong. And I noticed something strange when I brought in my passes into shake. The r and b channels for my passes were switched, so the paint looked BLUE for example. The beauty pass didn't have this problem. I guess shake got a lil confused with the "single channel" exrs?

Edited November 11, 2009 by itriix

[itriix]

I thought that the delayed load was in addition to things you have in you OBJ, haven't played around with it. I think there is some good stuff in the docs about it?

Hmmm... I actually couldn't find "TOO" much on the delayed load in the docs. I've just been gathering info here and there from the forums and playing around with it myself. From my understanding, it OVERRIDES any geometry inside in SOPS... As a quick test to reaffirm this, i just layed down a HUGE sphere in one of my geo nodes with the delayed load on it. set the render flag to the sphere. Clicked render, and still got my "delayed load shader particles" not a sphere. and not a sphere with particles either. HOWEVER, from what it seems now, the problem with the my different "renders", i think has something to do with the information that is saved out with the GEO ROP... I'll have to test it later, but i have a hunch that if i used a MANTRA ARCHIVE instead of a GEO ROP, and pointed my delayed load to THAT file, i wouldn't even need the "file sop" inside, like i'm doing at the moment.

Hmmm, all just theories, i'll test it out and post results about that

[itriix]

just noticed it's a bit hard to see the difference in the two "shake" renders up above... so i did a side by side for closer observation. The "good" beauty pass is on the left... *that's how it should look*, and the image on the right is the "comped" pass. As you can see if you look closely, edges are being eaten up. anyways... gonna keep playing around!

[sam.h]

wahoooooooo!... i think, it's just that ae sucked and shake rocked for comping this

because i just set up the shot in shake and it seemed to work WAY better! (i haven't tried to seperate stuff out with the obj_id though)... i'll wait for your example. not really sure how to go about using it yet. Anyways, i'm upping some pics. I'm still getting some "eaten" away edges. Haven't used shake in A LONNNNNNNNNNNNNG time, so i'm sure i'm just doing something wrong. possibly... maybe. Oh, and something strange i noticed. When I brought in my passes into shake, it had put some of the channels into the wrong channels. so at first, my PAINT for example looked blue, because it had the r and b switched!

Great I like shake! nice, simple and logical most of the time

That channel order thing is SO annoying. When the planes aren't named RGB (they might be diffuse.r etc) shake freaks

That build looks right, just make sure matte mult is unchecked on your switchmatte nodes ...

Those EXRs you zipped don't open in shake for me, must be a dodgey shake version or something that we have here

with the ID pass, just reorder it to make mattes for colour correcting/whatever your passes ....