A few questions if anyone has time, related to Poser 12:

1) The animation palette is quite a bit faster in Poser 12 than in Poser 11 (I think due to abandoning the calculations for displaying numbers and type letters in the keyframes, along with a generally slow string handling). However, I notice that, once a project gets pretty big, like 1000+ keyframes (not just frames of the project, actual keyframes, heh), it really starts to bog down Poser pretty quick again. This can clearly be seen when making changes to the scene (adjusting dials) or manipulating keyframes in the palette. Closing the palette entirely removes the lag, so it is reasonable to assume it's something to do simply with the palette trying to update its display.
   Do other people see this? Is there a way to fix this on the user end?  Any idea as to a cause?

2) I notice that the Preview renderer seems to be limited to displaying 5 lights concurrently. Turning on a 6th light will cause one of the other lights to not render. It doesn't turn "off" in its properties, it's light is simply not displayed in the preview. It's fine in a 'real' render (superfly or firefly).
   Is there a way to work around this, like a setting to increase the preview renderer's max lights? IS this an OpenGL limitation or a Poser limitation?

3) I've noticed that the Preview renderer craps out on "poser surface" or "Physical Surface" root nodes (the root nodes that work in the preview renderer, afaik) using materials that attempt to display the output from a chain of nodes that pulls from more than 5 textures (the "image map" nodes). This is not simply "having" > 5 image nodes in the material, it is specifically that the current chain of active data requires pulling from > 5 textures. After a 6th texture is pulled from, the material display in the Preview renderer starts doing weird stuff, like wrong colors, black textures, etc...
   The material is fine in a 'real' render (superfly, firefly).
   Is this a limitation of the preview renderer? Is it a limitation of particular drivers or software (doesn't seem like it)? Is there any way around this?

4) I'd like to use the PMD external binary morph files for objects with alot of morphs, to minimize save-file size AND to 'centralize' the source of morphs on particular objects (by using the PMD in the library, rather than the deltas being saved into each project file). However, the objects to which the PMD's apply may have new morphs added later.
   if the PMD in the library is updated with new morphs, project files that already had that object added will only reference the morphs (by a UUID in the save file, not the name of the morph) that existed in the PMD at the time the object was added to that project. If one tries to 'copy' , 'inject', or otherwise add the new morphs in the older project file,  Poser ends up adding them into a "local" PMD (referenced by "customuuid" in the save file) for the project file (so, saves it like  projectname.PMD along with the projectname.pzz or pz3 file), not as referencing the "library" PMD. This, in turn, causes PMDs with different data to spread all over the place...  one can't really use a PMD as an adjustable "central source of truth" for morphs  on an object.
   If that makes sense (heh), is there a way around this?  Basically, to add morphs to a PMD in the Library for an object, and have those 'import' into an older project in such a way that the central, library PMD is still used and not a 'local' PMD?

In reference to question #4...

I recall running into this problem, having more than one pmd being referenced by a scene. I recall it causing certain iterations of a scene being inconsistent with morphs present or carried over. My memory is a bit vague on the particulars. I think I worked around it by creating master pmd INJ files that I would apply to new iterations of a "clean" target figure. Again, my memory is vague on this point.

There's a handy bit of software for general pmd manipulations found here... I have it and it's a useful utility, unique actually, for this type of thing.

Binary Morph Editor

That being said I hardly use it anymore, other than to take a quick peek at certain things, because

My final solution to all of this was to turn off external binary and embed the morphs as a general rule. I haven't found the overhead to be terribly bad, and I'm talking hundreds of custom morphs in many instances. As far as being centralized, the morphs are just as centralized embedded in a scene or cr2 as they are in an external pmd, and transparent to a standard text editor to boot. They're just not compressed. Note that I didn't do this because of some perceived boogeyman of pmd corruption, rather the selling point of pmd for scene files, compression, just became moot to me. It's still a godsend for INJ.

Those are my observations on that particular question.

I'd say that Charles Taylor (nerd) could give more informed, elegant answers to all of these questions, he's a mod on several Poser forums here. There's a chance he might not see the questions here, on the Poser Official, though.

For number 2 There is a limitation in opengl of the number of lights that will work. I thought it was 8 rather than 6 but I could be wrong. I don't know if switching to screed preview will help or not.

3 the preview display is limited and will only show basic materials. I often turn off the hardware shading unless I do a comic render.

sorry, but I don't know about 1 or 4. I don't do animations usually and I don't use pmd.

If you open the animation palette on the far right side is an arrow.  Click that and the bottom option is to display the Key count in the little boxes.  So the code to do the counting is still there just that it is not displayed all the time.  So most likely Poser still does a count each time there is a change in keyframes.

As far as the slow down, the more keys you put in the more complex the math gets to figure out what the path is going to be.

above is a channel and a Key frame every 10th frame, all at the Zero point.  Also I put in one point at 75 which is about the half-way point on the time line and pulled it down.  Notice that the curve not only effects the Keys next to it, but also the 2nd set out.  Although it appears to become stable 6 points from the center that is not the case.  Each Key is Zero but the frames between those keys have some slight value change from Zero.  Even Frame 5 which has 7 keys between itself (5) and the center key (75) it still has a change you can see on the dial.  Granted it is small but it still is a change.  It appears that Poser will use all keys in a channel to try and create the Tween Frames so if your animation is 1000 frames long and you have 100 keys much more complex than the simple example above you can imagine the math involved in making a line try to flow through all those points.  And those Tween Frames are computed every time there is a change to a key Frame.

I forgot I posted this last year.  Thanks for the replies!   :3

I agree with ending up not bothering with PMD. My experience is that it seems to sometimes act unexpectedly (predictably, but unexpectedly; one forgets it's about to generate a new pmd after certain actions) regarding where the morphs end up being stored. Embedding all the deltas in the project file wastes some space, but the storage behavior is entirely expected. I still wish there was a "central source of truth" type system for morph application where fixing/updating or adding a morph to a figure's LIbrary PMD could immediately apply to all existing projects with the figure, rather than having to manually re-inject and fixup morph keyframes for every existing project.

The opengl note had me looking into that. It seems opengl1/2 had a *minumum* guaranteed support for 8 lights in the spec, so any implementation had to support at least 8, but could do any number.. just if one wanted universal compatibility, the "Max" was then 8 light. Apparently opengl3+ programs generally implement lights as shader functions rather than using the built-in gl lights, so no hard limit at all (spec or implementation), just depends on a particular programs shader program how many lights are supported.. I think.  I guess Poser's opengl implementation just stops at 5 lights for the preview renderer, if the above is correct.  But I could be wrong about all the above....


For the slow down in the animation palette, it makes sense that every added keyframe requires some recalculation of all previous keys on the parameter, since the graph is a continuous function, so to speak.
   One caveat, however, is spline breaks. I'd think that adding a spline break to a parameter would then break that function calculation. In other words, there's no need to calculate the continuous function further back than the most recent spline break... This doesn't appear to happen. One can keyframe every parameter on a figure and spline break them, then the very next frame can become laggy when adjusting parameters. I think this *should* be the behavior, but maybe it just isn't, heh.
  Regardless, I noticed as mentioned that simply hiding the animation palette makes all the lag go away. The slow-down seem to be entirely caused by something the animation palette is trying to do when visible. One thing was calculating all those numbers on the frame boxes (which can be turned off as mentioned, but perhaps should be cached anyway to make it fast), but something else is still making it get really bogged down when a bunch of keyframes exist in a document.