Is it to generate those gizmo shapes you see when you change the light type to Grid, Point, Sphere, etc?

If so, how is it able to get some of the parameters from the network inside it, but others are defined somewhere?

What I mean is, I was just expecting to either have the whole logic/code inside or none if it's a compiled OP.

I am not too sure how specifically lights work in Houdini, but I know if you create an object level python operator, it serves as both a subnet and a code container, thus allowing you to do both

There are other examples of nodes like this. The Instance object node does some magic, in addition to having a subnet that serves the purpose of where the objects are instanced at render.

I can imagine this is possible to do via the HDK, but at a more accessible level, you can do this with a python object operator

magneto
Is it to generate those gizmo shapes you see when you change the light type to Grid, Point, Sphere, etc?

If so, how is it able to get some of the parameters from the network inside it, but others are defined somewhere?

What I mean is, I was just expecting to either have the whole logic/code inside or none if it's a compiled OP.

Not quite understood where is your doubt, but lights have a second layer of logic behind. Note, that light in Houdini is just an interface for a light/shadow shader, because this is what Mantra is expecting. Any standard light in Houdini refers internally to some light shader (ASAD for non-geometry types). They are not inside the object to not to pollute a scene and keep your light renderer agnostic.

Lights are digital assets. Network inside defines the gizmo's shape. The difference is, that lights are processed by SOHO (prior rendering) in a different way than geometry objects.

Soho scripts called wranglers are set to recognize light's parameters suitable for passing through to light shaders, so that single light works with many renderers.

So light parameters like a ‘Color’ are picked up by a wrangler and translated into to a renderer specific form. From that so called shader string is constructed and sent to IFD file.

You can see what exactly is happening in $HH/soho/python2.6/wranglers

hth,
skk.

Further, you can create your own asset wrapper on top of a Houdini light.
If you open up the Edit Operator Type Dialog on an asset, in the first Basic tab, there is a parameter called “Representative Node”. If you have a light object inside your asset, you can set the Representative Node to be this Light object. Houdini will then treat this top level asset node as a light by all the various widgets in Houdini (bundles, light linker, etc) and SOHO for rendering where you place Render Parms on the asset top parm interface as that is the only thing that counts wrt Rendering and Lights.

In current builds, the Python Object has the Representative Node parameter greyed out so if you wanted a Python operator as part of your Light object's logic, you will have to put it inside an asset.

Thanks guys, appreciate your replies.

So how can I make some object with some geometry nodes and “mark” it as non renderable gizmo so it looks like say a camera or a light gizmo? Or is this what you are describing with Representative Node option Jeff? If so, I will try this when I get home.

Also what is ASAD and SOHO?

Thanks again, I like these kinds of details.

Yes the Representative node parameter can make a Houdini Asset take on the properties of a Light if you point it at a light contained in side the Asset.

ASAD is an acronym for “All Singing And Dancing” or in other words, a tool that contains everything. I believe I first heard ASAD with respect to a Renderman custom light written way back that contained all the bells and whistles for lights including gobo's and barn doors. Hunt around OdForce or the Houdini Forums for reference to the ASAD light.

SOHO is an acronym for “Scripted Output of Houdini Operators” and is used to generate render scene description files for various render engines (Mantra ifd, RenderMan rib, MentalRay sl, etc). SOHO is triggered by executing various Houdini ROP Output Drivers (Mantra, RenderMan, MentalRay, etc). It is written with Python making it possible to quickly customize the scene description output. Many facilities like to author their RenderMan rib files in specific ways. By customizing SOHO you can quickly re-format the rib file to your liking. It also gives users the ability to support unforeseen and net new features between releases of Houdini. Having said that, most times Side Effects will put these changes in for new releases of RenderMan when reported.

Thanks Jeff, very informative reply. I will be sure to try these out at home.

I never heard ASAD used in 3d before, but I first heard it in the movie fight club