I nest takes into a parent take, and then use a Wedge ROP on the parent take, which renders the children.

@Swann: this is great modelling. I'd like to ask what sort of approach do you do when you chamfer surfaces together? Do those pieces even share the same topology? And how procedural do you get?

For example, in a hard-surface model I was making, I use a lot of cookies to find the creases, and use an HDA to create a crude kind of chamfer. Procedurally, this worked well because I could always move the pieces and the chamfer would move along with it.

Last question: do you use NURBS at all?

To add: there are some instances (no pun intended) where instancepoint() (and I think it is in the context of hou.hscriptExpression()) where it returns a -1 or None, and so it seems like a sanity check is necessary for places such as accessing indices from an array/tuple/list.

This doesn't seem to crop up when hscript instancepoint() is used directly.

I know this has been quite a long time, but I was looking for an answer to this exact question, and I've found the method called hou.hscriptExpression() that may do the trick.


instancepoint = hou.hscriptExpression('instancepoint()')

Hi, there. You can use the Lattice SOP in Points mode (as opposed to Lattice mode).


edit: hmmm… there doesn't seem to be the appropriate bending behaviour in Lattice…. I guess you can ignore this piece of advice.

Copy that. So it's the surface model VOP after all.

I'm also thinking of using two or more lighting model VOPs to separate out the resulting responses (by dialing down the appropriate inputs), then process individually, then mix them in together before going out.

It's a bit of a hack, so I'm eager to have a look at the surface model node soon and see if there's something more elegant.

Thanks again.


best,

lernie.

Hi Rob, thanks for the help. I'm a bit surprised to find that the output refers to the ROP context. My original plan was to boost or attenuate the pre-computed values such as ‘diffclr’ on their own just before they get piped into Cf in the shading network.

Do you an idea how to go about this in the most direct way? Thanks again.


best,

lernie.

Hi, pardon me if this is a dumb question, but according to the documentation on the Lighting Model VOP (http://www.sidefx.com/docs/houdini11.1/nodes/vop/lmodel) [sidefx.com] there are several documented outputs such as diffclr, ambclr, etc. However, the default output of the Lighting Model node is only color and BSDF. How does one access those other outputs?

Thanks.

@silvina: Thanks heaps for your advice: by creating a new camera and using that to render the bug is no longer present.

But for completeness I attached the scene file nevertheless because I managed to reproduce the problem and some other notable features cropped up. It took me awhile to be able to reproduce it; I still don't know exactly what causes it, but I put it down to a ‘state’ problem, whereupon I load a particular ('suspicious') scene and it ‘corrupts’ Houdini to exhibit the bug as long as the session is open. If I close Houdini and re-launch, the bug doesn't show up.

-The attached scene was created in that same Houdini session where the bug started happening.
-The scene was tested by re-launching Houdini and loading the scene; the bug is there when using a Scene View camera.
-In addition, the scene, very strangely, loads very slowly, which may or may not have something to do with it. Opening the hipnc file I notice that there are named referenced to my original ‘suspicious’ scene that shouldn't be there.
-Again, rendering with a new camera (non-Scene View) seems to correctly render the object.

Thanks Rob and silvina for taking the time.

(I couldn't find a thread with a similar problem as I am having)

My problem is that my geometry appears to move when I attempt to render it as I am inside the geo's network (assuming that the transform node of the geo has been moved).

For example:
-I created a simple box (or default file node) and moved it <1,0,1> in world space using its scene transform node. This renders fine. (I'm using the Scene View ‘camera’ to render to MPlay)
-Then I dive into the geo's node and render here. The render presents the box at around <2,0,2>.
-Then I go back up /obj level, try rotating the transform node around Y at 45 degree increments, and then diving back down the geo network each time before I render. The result is the geo being positionally placed around around <1,0,1> (radially), though no actual rotation on the geo is being applied.

I'd like to know if this is a known bug, or if there is a way to circumvent this behaviour. I've already positioned up some geometry in my small scene and proceeding to texture it; that's why I'm diving down to geo level where my shopnet, uvprojects, and materials are located. But this behaviour is making my objects a moving target.

Many thanks!

I have been searching the forums looking for a solution to this. Apparently, the limitation is still there.