Yeah, say I have tons of render nodes for different passes. If I just want to re-render a bunch of specific frames (not in order). What is a common method?

I'd say I'd use variables in ROP … and with a script I'd change ‘em accordingly…

like some buttons in a HDA which sets, let’s say $START and $END, accordingly to some predefined choices (1 to 240) or user defined with parameters… how that sounds?


cheers

You could setup the ROP dependency rendering too.

Wire all the ROPs together in a Merge ROP then use the Frame Dependency ROP and enter a frame list.

ah, thanks frame dependency YES

I was looking on the actual render nodes

oh yeah … I thought about merge at first… but I thought you were looking for frame ranges on certain passes only… not all passes together..

yeah I need to explore the frame dependency after this next render here but I'm guessing with different wiring and merges it can render certain stuff from ones vs others with the “strict” on the nodes.

I just didn't want to copy all the passes 20 times just to render out individual frames

It sure would be nice if there was a “strict” on a merge though (to make the ones above it only do that) so multiple merges could be used in different combinations from the same stuff. The Render Dependency will probably do most of the same thing though.

andrewlowell
Yeah, say I have tons of render nodes for different passes. If I just want to re-render a bunch of specific frames (not in order). What is a common method?

Hey Andrew,

That is just a quick attempt. Please have a look at this otl and the hip file. Is that what you were thinking of? Would be grate if you could test so I can eliminate any potential problem and post it to the exchange.

Worth of notice is that I had to embaded the hscript in otl using

opdef:.?selected.cmd

Funny but while doing some test in textport this script worked fine, but the same thing running from pre/post-render script, instead each, specified frame, printed every time only the last one. Looks like a bug to me…

Anyway, hope that helps

cheers
kuba

cool ! I'll test this out

andrewlowell
Yeah, say I have tons of render nodes for different passes. If I just want to re-render a bunch of specific frames (not in order). What is a common method?

make a pair of scripts: one that takes a hipfile name, a rop name, and a frame number, and then a second one that has a couple of foreach lines in it, and inside the foreach invoke the first script appropriately. For example:


set HIPFILE = “/my/hipfile.hip”
set ROPS = “BgDiff FgDiff BgSpec FgSpec”
set FRAMES = “1 4 22 67 102 103 104”

foreach rop ($ROPS)
foreach frame ($FRAMES)
render_hip_file $HIPFILE $rop $frame
end
end


That's obviously pretty brute-force and not particularly efficient. You'd improve on it by having a script that you can source within your running Houdini session. But that's the basic idea, anyway.

– Antoine

yeah when Python comes out I'm going to try to do a scripted asset that will take in every light that shines on an object/rig and generate render passes for each light etc. Going to try to stay away from the heavy scripting until then so I don't have an extra script floating around in my head but I definately get the idea.

I think your asset is really cool Kuba .. this should definatly come in handy … thanks a bunch.

I didn't find any errors etc and tried it out on different takes etc. Here's a few suggestions.

a. hide the default subnet parameters

b. I would think that frame by frame rendering would only be useful for renders that is 100% history independent, meaning no particles dynamics, etc. Otherwise the take would have to reload/calculate for each different frame which would take a long time. I don't know if there's any way to do a node by node option for your asset but that would be really great if you could.

Here is a small update

I changed slightly the script so there is an option to select multiply ROPs, but don't know why I'm having problems with reselecting each ROP after first selections. I'm using in the otl for the Type: OperatorList and for the Op filter: Any ROP. should work fine to me, but it doesn't. So sometimes I have to type each ROP manually.

Please note you can't use wildcards for that.

andrewlowell
a. hide the default subnet parameters

Do you mean, “Render” and “Render Control..” buttons - I think in ROPs you can't hide them

b. I would think that frame by frame rendering would only be useful for renders that is 100% history independent, meaning no particles dynamics, etc. Otherwise the take would have to reload/calculate for each different frame which would take a long time. I don't know if there's any way to do a node by node option for your asset but that would be really great if you could.

I added to the render script -l flag which sets from default ROP by ROP to Frame by Frame rendering for dependency networks. Is that what you thought about?

cheers
kuba

andrewlowell
yeah when Python comes out I'm going to try to do a scripted asset that will take in every light that shines on an object/rig and generate render passes for each light etc. Going to try to stay away from the heavy scripting until then so I don't have an extra script floating around in my head but I definately get the idea.

This is the sort of thing that really should be done in the shader, otherwise you're re-doing a huge amount of rendering needlessly. I'm not saying it's that easy right now to do it, but it's possible

Basically, you output deep rasters for each light's Diffuse and Specular (separately). The biggest problem is, you have to hard-code into the shader or VOPnet the max number of lights you can output.

Hopefully some day SESI will ship a single standard base shader VOPnet that has all these useful deep rasters as standard, and then all other shaders are built on top of the standard VOPnet so that you always get these deep rasters. Obviously, you don't have to actually use them (i.e. write them to disk) but unless the shader supplies them you're hosed.

Cheers,

Peter B

pbowmar
Hopefully some day SESI will ship a single standard base shader VOPnet that has all these useful deep rasters as standard, and then all other shaders are built on top of the standard VOPnet so that you always get these deep rasters. Obviously, you don't have to actually use them (i.e. write them to disk) but unless the shader supplies them you're hosed.

That would be *SO* useful.

yeah I didn't think about the deep raster approach but that would be much more efficient