[Sidefx-houdini-list] python as a vex code generator

Steve Gustafson sgustafso at gmail.com
Sat Apr 11 19:12:57 EDT 2009


Blah, fine, it's on the Exchange.

2009/4/11 François Duchesneau <sidefx at trinix.ca>

> Hi Steve,
>
> this mailing list doesn't allow you to attach a file.
>
> Steve Gustafson wrote:
> > Hey everyone. So, I've decided to waste a little bit of my weekend by
> > playing around with the idea of using HOM to generate VEX code - and then
> > wrapping it up in an HDA. Thought I'd go ahead and share my first attempt
> > here (needs more of a tune-up before going to the Exchange).
> > I've attached an OTL that does something (mildly) useful with code
> > generation. It basically gives you SOP-level vex code entry. This VEX
> code
> > is wrapped up in an inline vop, within a context where all point and
> > primitive attributes have been imported and exposed as variables of the
> same
> > name as the attributes themselves.
> > So, it's sort of like having attribute expressions that are compiled down
> > into VEX code. The key advantages over VOPs: you don't have to setup any
> > importAttrib vops, any addAttrib vops, *or declare data types* anywhere:
> > that's all handled by the code generator. So it's a very quick way of
> > writing simple expressions that modify attributes, while still getting
> the
> > perfomance of compiled VEX.
> >
> > A valid expression could be:
> >
> > P *= foo + bar; foo = bar + 10;
> >
> > And so on. I also went ahead and threw in channel referencing, using <>
> > brackets. I.,e.,
> >
> > foo = <../some/parm> + <../some/other/parm>;
> >
> > paramater vops are auto-generated for each path given, and then the path
> > being referenced is automatically linked onto the parameter of the
> vopnet.
> > So it's still vex, but it'll read in animated parameters.
> >
> > I'm curious to know if anyone else has been trying anything similar...?
> Any
> > different approaches? In particular, for anyone that's tried it, have you
> > had many synchronization issues? I.,e., the code generator not being
> > triggered by callbacks in a few cases where it should be?
> > I see a lot of potential uses for code generation, provided that the
> methods
> > of hooking everything in are stable and simple enough. One of the reasons
> > I've always preferred SLIM over shader development in Houdini was
> > specifically because of SLIM's generative templates - which was pure code
> > generation. It got ugly sometimes (TCL code...), but you could do
> anything
> > with it. For instance, one of my generative slim templates would wrap
> code
> > around its inputs, then re-evaluate the inputs many times per shading
> > sample, while switching between different sets of lights between each
> > sample. It allowed me to, basically, create full polynomial texture maps
> in
> > a single render pass.
> > Imagine if each VOP node could have an optional Python script that
> allowed
> > you completely override the code generation process. RFE?
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Sidefx-houdini-list mailing list
> > Sidefx-houdini-list at sidefx.com
> > https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
> >
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>



More information about the Sidefx-houdini-list mailing list