Parenting lights ... multiplied ...
Lights, Lights Everywhere
I'm pasting a question from Renderosity that I found in the Poser 11 forum. I'm hoping someone can jump in and answer it (here and there if possible)
"I think I have gone brain dead as I can't figure this out If you create a light fixture as a figure and add one body part, no matter how many light fixtures you add to a scene the body part internal name never changes If you want load a light set parented to that light fixture, no mater where that light fixture is in your scene it loads in the right spot based on that never changing internal name of the body part.
However if your light fixture is a prop, the internal name changes each time you load it like fixture for the first time added and then fixture:1 for the second time added to the scene.
Is there any way to parent a light set to multiple light fixture props where the internal name keeps indexing up or fixture:1, fixture:2, fixture:3
I could have sworn I have done this before , but I might be imagining. (In my case my memory was the second thing to go,. Don't ask what the first was)
Not sure if it is possible to load a prop where you edited the pp2 to make the lights load parented to the prop which would also solve what I am trying to do.
Doing a series of night scenes with varying light poles and light fixtures on buildings and the fixtures are all props
TIA in advance for any advice And if you want to call me stupid, go ahead since I already know that."
Can this be done?
rlowens68 last edited by
With magnets if you edit the CR2 / PZ3 etc and remove the actor numbers :1 , :2 etc. They will apply to whatever you currently have selected in the scene. And there is the catch, they apply to whatever you have selected, so you better be sure you have what you're trying to apply them to the item you have selected.
This may also work with parenting light sets. I have no idea.
I believe you can also change the parenting to current prop, current actor etc. Though not totally sure as it has been a while since I've done it, and I'm lucky if I can remember what I did yesterday much less something from a while back. Lol.
anomalaus last edited by anomalaus
@boni from what I see, the :number suffixes are strictly figure relative, while props not parented to figures when loaded get incrementing _number suffixes.
Props applied to different figures will acquire the figure's colon suffix number, which keeps their internal names unique when they are singularly applied to different figures. Were you to apply a second prop/light of the same type to a figure which already sports one, the second application will acquire an incremental underscore number suffix in addition to the figure's colon number suffix, in order to keep them uniquely named.
It is certainly possible to have lights load with props and figures (I regularly parent a camera and child light to figures which load from the library). The problem comes when a second such figure gets loaded, as the Poser developers' mindset was reportedly fixated upon cameras and lights being scene parented objects, with entire lighting sets envisioned as being replaced with a subsequent light set being applied from the library. That perception prevented the simple operation (not to mention the current hard limit of 8 lights supported by OpenGL previews, though that could change) of loading a second figure-camera-light combo from preserving the original figure's camera and light while adding a second such figure. Since the figure, camera, light definitions in the library already contain a hard-coded figure reference number, the new figure was assigned a different colon number suffix, but the parented camera and light both replaced the original figure's parented camera and light. Not what is expected.
I have previously worked around this by defining a library .cr2 with a different colon suffix, including the camera and light, preventing the replacement on loading a second figure.
I regard the functionality you have discovered as a bug, but I having had two decades of hammering my head against inflexible design preconceptions, I am utterly over it.
The solution I would propose is a Python Script to replace Poser's own library loading routines, but so much of the required Python API is still not exposed, that it may not yet be possible. Nor are the previously RDNA hosted library replacement utilities still available (I'm not sure whether they were Windows only or worked on MacOS as well).
My apologies for the negativity, but I'm currently stressed out of my brain with preparations for nativity and new year celebrations to the point where I only want to have to deal with them biannually, or less. [/rant] ;-/