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

Simon Kapeniak szymon.kapeniak at gmail.com
Wed Apr 15 13:18:01 EDT 2009

Ha! I had some time to play with it and I love it! Brilliant  idea, thanks!

(I used to hear about similar node in some *big studio allowing making
expressions this way instead of Point SOP. )

This gonna be my favorite SOP for a while :)


2009/4/11 Steve Gustafson <sgustafso at gmail.com>:
> 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

More information about the Sidefx-houdini-list mailing list