I've been recently trying to set things up so that I can minimize the problem I'm sure we've all had when we've assigned a light shader SHOP to a light, but we want to “link up” the functionality of the light object in the Shading/NoShop tab. The reason is that this tab is front-and-centre and easy to get to - and it's the only thing AKAIK that directly affects the light in the viewport in terms of cone size, brightness, etc. Therefore, really, it's a mis-named tab - it should be the “viewport” tab or something similar.

Anyway - regardless of where you like your light SHOP to live, in /shop or in a subdir in the light itself, I need to manually link up the obvious things like colour and cone size so that the SHOP controls these, in order to get feedback in the viewport. Problem is, there's a number of these settings, such as lighttype, that can't be linked due to the style of widget(AFAIK - correct me if I'm wrong!), so you're constantly flipping back and forth between the tab in the light and it's SHOP to coordinate them. Is there something that might be done to alleviate this? In a way, the “no shop” tab in light objects is more accurately like the OpenGL tab in surface SHOPs. It would be nice if this was made a little more standardized - perhaps you could get a light OpenGL tab in a light SHOP? Also, it would be great if the OpenGL supported functions were somehow standardized - in other words each function has standard names and locations(just like /obj/light1/dimmer for example). this would allow your customized light shaders to be wired up more completely, and more quickly to the OpenGL light support.

Also - a little thing - I'm personally finding that there's a truly evil little thing in $HFS/houdini/scripts/defaultscene.cmd - it puts that terrible little “fastShadow” shader into a default light. The reason I consider this evil is that it acts *on top of* whatever SHOP you may wish to assign. That has caused me endless troubles when I've missed it. Yup, I've altered the defaultscene to not contain that in $HOME, but it seems like such a terrible, confusing thing to stick in there. Wouldn't a default, quickie raytraced shadow SHOP work better as a default “lookee here - a shadow” light?

Cheers,

J.C.

Howdi John.

I find the “No SHOP” tab thing annoying too and I think it would be a great idea if there was OpenGL tab for Light SHOPs.

The only way (that I know of) to link menu/toggle parameters like “lighttype” is to use an OTL and drag the entire Light OP into the Parameters Type Properties window. Then delete what I don't want. This uses the autolink feature and all those “hard to get at” parameters now work. I just tweaked my Uberlight OTL to use more of the Light OPs parameters. Pull it apart to see how I have different things setup.

http://www.stickylight.com/FLinks/OPLights.otl [stickylight.com]

I haven't test all of the “Light OP Controls” yet to make sure they work but the few that I did test worked fine.

Just a quick overview of the OTL. There are two things, a Uberlight SHOP and a Uberlight object. The Uberlight SHOP is just a port of Larry Gritz's Uberlight. THe Uberlight Object is a wrapper for the Light OP, Uberlight SHOP, and a couple of other things. The Uberlight Object provides a sort of visual feed back of most of the Uberlight's parameters. The contents of the Uberlight OP are as follows. A Light OP. Inside the Light OP is a SOP network which provides the visual feedback. Inside this Light OP is also a SHOP Network which holds the Uberlight shader. To use just create a Uberlight Object and the shader and everything else are embedded neatly. (semi neatly).

One point of interest is the “Type of Light” parameter. The “Type of Light” controls the Light OP's “Light Type” AND the “Type of Light” parameter in the actual uberlight SHOP. The Uberlight Object's “Type of Light” parameter is a drag and drop autolink of the SHOP's parameter. In order to control the Light OP's “Light Type” for OpenGL feedback I autolinked that too but then hide the parameter. With the parameter now part of the Uberlight OP I used a callback opdef script to change the “Light Type” parameter, which in turn changes the Light OP's “Light Type”.

jim.

Heh heh - you're doing more or less what we're doing. We have a honkin' huge UberLight port here, too. You've gone a step farther than me in the setup department, though - I see you've made that object, which contains a standard light, which in turn contains the shop, etc. Good idea. I actually made a new “light” that contained the SHOP and all the links - but since Houdini only allows one light, it meant effectively replacing the default one. Didn't like that. Should take a look at your approach, plus all this other stuff with the linked lightypes.

All that aside, however, I think SESI should think about standardizing this whole light/OpenGL thing. Feels a little cut 'n paste between the old method and the new OTL/NWN…

Cheers, and thanks for the file

J.C.