transforming lights in solaris

   1144   10   3
traileverse
Member
227 posts
Joined: Nov. 2015
Online
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?

Attachments:
light_transform_solaris.gif (1.3 MB)

hou.f*ckatdskmaya().forever()
User Avatar
Member
5 posts
Joined: April 2021
Offline
I'm not positive about the answer but it may be in here [www.sidefx.com].
Still seems to be being fleshed out
traileverse
Member
227 posts
Joined: Nov. 2015
Online
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?

Attachments:
Screenshot 2022-11-28 194656.png (16.7 KB)
Screenshot 2022-11-28 194709.png (17.7 KB)

hou.f*ckatdskmaya().forever()
User Avatar
Member
6431 posts
Joined: Sept. 2011
Offline
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.
traileverse
Member
227 posts
Joined: Nov. 2015
Online
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.
hou.f*ckatdskmaya().forever()
User Avatar
Member
6431 posts
Joined: Sept. 2011
Offline
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.
User Avatar
Staff
3 posts
Joined: April 2021
Offline
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.
traileverse
Member
227 posts
Joined: Nov. 2015
Online
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.

Attachments:
light_prims_behaviour.hiplc (403.0 KB)

hou.f*ckatdskmaya().forever()
User Avatar
Staff
214 posts
Joined: Feb. 2008
Offline
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.
traileverse
Member
227 posts
Joined: Nov. 2015
Online
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.
hou.f*ckatdskmaya().forever()
User Avatar
Member
6431 posts
Joined: Sept. 2011
Offline
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.
  • Quick Links