when I transform a light LOP, it behaves weirdly in that the light handles (both transform and light properties handles) stay at the origin but the light itself moves; however, when I edit the transform handle again (which remains at the origin), the light snaps back to the origin before it starts to apply the new transform. Hopefully, the attached video explains it a bit better. What I want is that when I move the transform handles of light, everything belonging to that light (all handles) moves with it in space, how can I achieve this?

I'm not positive about the answer but it may be in here [www.sidefx.com].
Still seems to be being fleshed out

I was using relative paths on the lights' primitive path parameter (I left off the forward slash at the beginning), but once I changed it to absolute path the lights started to behave as expected. Any idea why this behavior? because when I left off the forward slash, the light still ended up in the correct part of the hierarchy in the scene graph. What is the major difference between the relative vs absolute path here?

traileverse
I was using relative paths on the lights' primitive path parameter (I left off the forward slash at the beginning), but once I changed it to absolute path the lights started to behave as expected. Any idea why this behavior? because when I left off the forward slash, the light still ended up in the correct part of the hierarchy in the scene graph. What is the major difference between the relative vs absolute path here?

I didn't think there was such a thing as relative paths. Perhaps one part of the code is sanitizing the input by adding the slash, and another part, the handle, was using it as is--therefore unable to locate the prim.

jsmack

traileverse
I was using relative paths on the lights' primitive path parameter (I left off the forward slash at the beginning), but once I changed it to absolute path the lights started to behave as expected. Any idea why this behavior? because when I left off the forward slash, the light still ended up in the correct part of the hierarchy in the scene graph. What is the major difference between the relative vs absolute path here?

I didn't think there was such a thing as relative paths. Perhaps one part of the code is sanitizing the input by adding the slash, and another part, the handle, was using it as is--therefore unable to locate the prim.

interesting, could be something like that, guess I could inspect the usd code to see if that’s happening.

traileverse

jsmack

traileverse
I was using relative paths on the lights' primitive path parameter (I left off the forward slash at the beginning), but once I changed it to absolute path the lights started to behave as expected. Any idea why this behavior? because when I left off the forward slash, the light still ended up in the correct part of the hierarchy in the scene graph. What is the major difference between the relative vs absolute path here?

I didn't think there was such a thing as relative paths. Perhaps one part of the code is sanitizing the input by adding the slash, and another part, the handle, was using it as is--therefore unable to locate the prim.

interesting, could be something like that, guess I could inspect the usd code to see if that’s happening.

It doesn't hurt to submit a bug report. You could find out if it's intended behavior or not.

Hi there,

I tried to replicate the issue but I could not. Could you confirm which houdini version are you using and perhaps share the file? I would love to have a look at it.

yolandac
Hi there,

I tried to replicate the issue but I could not. Could you confirm which Houdini version are you using and perhaps share the file? I would love to have a look at it.

Sure, see attached. I did this on 19.5.448

The good_light has an absolute path while the bad_light has a relative path.

There are no relative USD prim paths, don't confuse node paths and USD primitive paths, these have no relationship to one another. I guess you can think of LOP nodes' primitive pattern parms more like the group parm on SOP nodes - they allow you to specify on what subset of the underlying USD data the nodes should operate on.

npetit
There are no relative USD prim paths, don't confuse node paths and USD primitive paths, these have no relationship to one another. I guess you can think of LOP nodes' primitive pattern parms more like the group parm on SOP nodes - they allow you to specify on what subset of the underlying USD data the nodes should operate on.

ahh, I see, this is what @jsmack was saying. I get that now.

npetit
There are no relative USD prim paths, don't confuse node paths and USD primitive paths, these have no relationship to one another. I guess you can think of LOP nodes' primitive pattern parms more like the group parm on SOP nodes - they allow you to specify on what subset of the underlying USD data the nodes should operate on.

This sounds like a bug that malformed input is handled differently depending on the code path.