Prop morphs don't show up in Queue Manager 11.1???
Hi, does anyone else have a similar experience. Lately I'm noticing that prop morphs are not showing up in Queuemanager. Alas I don't remember if it was after the upgrade to 11.1 or even how long this has been going on. But look at both bags below. It's a simple prop that you can close. If you render it in the background, the bag is closed as expected. But if you send it to QM, all of a sudden the bag is open??
Just BAFFLED & any feedback would be appreciated.
-- oh darnit, I'm apparently not allowed to upload pictures.
Well, maybe somebody recognizes this without the pic's....
Recently, I've used Queue 184.108.40.206338 to network render animations which had morphing props, and the morphs changed correctly with the scene's keyframing. All were Win7Pro or Win7Ultimate machines.
What OS do you have, and what P11Pro/Queue build are you on?
I think the full installer was 220.127.116.11759 and the updater patch was 18.104.22.168764 and there was no Queue-only SR for remotes (aka render slaves).
Are you using just a single machine for both scene set up and Queue rendering?
I use w7pro as well, on a single machine. I have an ESXi server with a couple of w7pro VM's, but haven't been able to get QM to link to those QM's either. They seem to be talking to each other, but the local QM always uses the local queue. If I indicate that it just should use the remote queue's, it just waits until I enable the local queue.
But I digress: my QM is 22.214.171.124764, and my PoserPro is 126.96.36.199764 as well.
WTF?! As a new user I have to wait 9500 seconds = 2.6 hours before I can do a new post?? This is something new? Haven't seen this BS before. And my first post here was 2 years ago. New user?! Do you have to get dead before you can graduate to proby level?
Three hours and counting.... at least get your arithmetic right.
The build number must match among all machines; the server/VMs would need to have the same build of Queue as the workstation, or they will not acknowledge each other. The render job wouldn't get sent out at all.
Since DLM offered no 34759 or 34764 for my remotes which have only Queue installed, I re-installed 34338 on a workstation so that I could still use Queue across the network.
But since you're only using Queue on the local host (the workstation itself), there won't be any build number discrepancy. You did get a render done, so it doesn't seem to be the firewall blocking communication among Poser, Queue, and FFrender64.
Hmmm... is the .pmd (Poser Morph Data) file stored beside the PZ3?
Yes, I know about the QM version numbers having to be the same, and I think I somehow got that done. But I can check that one.
The PMD is indeed beside the PZ3...
Well, until 3 hours later, Ciao!
No need to check the build number on the workstation; its Poser and Queue executables install together, so they will certainly have matching build numbers. It's only a potential issue if you're using remotes (render slave machines).
I don't have any idea how to solve this. Anybody else have an idea? Please jump in, because I'm stumped.
Could I just downgrade to one of the previous QM versions? Or would I have to downgrade PPro as well?
I don't think that would solve your problem; if you had a build number mismatch on the remote VMs, they wouldn't get any assigned render job from the master's Queue.
That doesn't show as a render with missing morphs, but rather as no render job sent at all.
I suppose there would be the possibility that some Queue bug was introduced in SR10.
You could look in C:\Users\admin\SmithMicroDLM\Downloads\installed and see if the 188.8.131.52338 installer is still there. Running that would revert both P11Pro and Queue to 34338.
But I think it more likely that something else is the problem. Is the runtime containing that shopping bag on a different hard drive than the P11Pro executable? Or maybe an external hard drive? Is that runtime in a shared folder?
I'm just brain storming here.
Is the runtime containing that shopping bag on a different hard drive than the P11Pro executable? Or maybe an external hard drive? Is that runtime in a shared folder?
Yes, I have one humongous assets runtime on another (Hybrid) drive, since P2010.
P11 is now on the C-drive as that is SSD. Non of the runtimes is shared.
But we're talking two things here:
Not being able to use a remote QM, and what you describe is exactly what's happening. The local (master) queue doesn't assign anything to the remote QM's.
I THOUGHT I had upgraded the remote QM's to the same version numbers by starting an install process and then just selecting QM, but I have to check. Especially because everybody is saying that SM didn't provide a separate QM with 11.1.
The morphing bag is something recent. I've stepped over to QM renders about 4-5 months ago (background rendering was good enough for me), and I'm sure I would have noticed morphed props not rendering properly. It's something I've been noticing the last couple of weeks, and I'm not even sure it happens with every morphed prop - didn't test that yet.
The only thing that comes to mind - major change wise - that this MIGHT have started since the upgrade to 11.1.
But I'd have to test this by downgrading to the previous P11, I still have that installer.
But it would involve work with breaking stuff possibilities, while I have a viable workaround available: background render. So to be honest, I don't see myself getting around to this very quickly...
It would be nice though, to know if other people have this same issue. If not, there's something in my setup that doesn't compute, even down to your suggestion that I put it in the same runtime as the PP executable (ain't gonna happen).
If there are more people with this, then the QM will be upgraded automatically by SM.
Just checked my VMWare server: the QM's on my running win7 virtual machines are NOT the same version as the master QM, so that is clear now. One more to go...
Is the hard drive with your content (things you've bought, made yourself, etc) runtime library on a secondary drive within the computer, or an external hard drive? If external, does it consistently show as the same drive letter every time you boot up?
If your workstation is on build 184.108.40.206764 (Poser Pro and Queue builds will be the same), then the remotes won't be usable, as the last Queue-only update was 220.127.116.11338
Run DLM on the remotes, and you'll see 34338 is the latest available Queue-only update.
So, build number discrepancy explains the remotes not responding; if you need to be able to use remotes, re-install Poser Pro 18.104.22.168338 on the workstation.
The failure of the morph is something else, but I don't know what.
It would be interesting to see if other morphing props work.
Try this claymore lightsabre at Renderosity or claymore lightsabre at ShareCG.