Looking at the picture of the export optopns, above in this thread, try:

*  UN-checking "Full Texture Paths"
* CHECKING "Copy textures to destination folder"

   This will export a copy of the texture files alongside the exported OBJ, and reference them with no path name in the .mlt material file. The textures, .mtl material file, and OBJ must remain in the same folder with this arrangement. After doing this, try opening in the Windows model viewer again.

If this works, then there is some pathing name problem with the exports when exporting "Full Paths" (Like, the programs can't find the textures where there were after export). If this still doesn't work, then observe  *IF*  it really did export texture files along with the OBJ at all... If it did, open the .mtl file in a text editor and just check that the filenames of the textures are, in fact, correct.

So, the above post I made is *not* correct. The Gamma setting does NOT change the renderer... I misunderstood the response from my ticket.

I think what's happening, now, is that animating a color property causes the scene-wide Gamma setting to apply to that color, **in the Preview render only** not in the Firefly / Superfly render.

The cockamamie solution I came up with is to add series of nodes to apply an inverse gamma ( For instamce, 0.4545 for the default 2.2 document gamma) to an animated color, then multiply that with texture node output. The gamma value in the gamma node is animated, so that the gamma can be set to 1.0 before rendering the scene... So basically, the preview renderer now displays the correct colors with aniamted color properties, and the "corrective gamma" is set to "unity" before rendering the scene (since the actual Firefly / Superfly renderer never had the problem with animated colors, no correction is needed, so that "corrective" inverse gamma actually causes it's own problem if not set to unity).

IF you are using Windows (10 or 11), there's a built-in 3d model viewer. Exporting OBJ out of poser, for me, produces a result that opens correctly with textures in this model viewer. You can try opening the exported OBJ in that model viewer to see if it looks correct, If not, then the problem would appear to be Poser export settings. If it does appear correct in the Windows viewer, then it suggests there's a problem with the Truview importer (despite it working from other program exports, it's just a first experiment to discover the nature of the problem).

I received a response from a submitted ticket, very quickly, actually, kinda impressed, heh. I just took a few days to play around with it.

I *THINK* the below is correct. I didn't 100% understand the answer, but:
   It turns out the "Gamma Correction" setting under the "Firefly" render options will actually change the behavior of the Preview window. If Gamma Correction is "on", the preview renderer appears to use the SueprFly renderer to produce the preview. If the Gamma setting is "off", then the "firefly" renderer is used to produce the preview.

The way that the two renderers produce their "preview" is different.

I tried experimenting more, in general, with node settings and values to see the differences between teh two renderers, but I lost the plot a bit... too many unexpected variables and things I clearly don't understand. Like, the same material chain with the same settings/property values will priduce completely different color resuits in Firefly vs. Superfly,  but this depends on "unexpected" things, like whether the property is animated or not, deviation from default value (rather than just the straight value), etc...

In general, the major difference for the preview is that Gamma setting.

Replying to my own post... I forgot while posting this, "Simple Color" node just breaks completely sometimes, when animated. Other nodes like "hsv" will work, but always produce wrong colors in the preview renderer when the color is animated.

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.

This is version 12. It might be fixed in 13, but I can't check.

I have, indeed, created my own poses, but I've noticed the behavior described for all pose files, created by me or not.

It isn't that the pose won't apply (it does), the behavior is that applying a pose to a figure with IK on, which has many keyframes in the document, can take a long time, and can actually alter the already-created keyframes for that figure in the document.

As mentioned, I can use a completely blank pose file ( just open and close braces) and this behavior manifests. It seems like turning off IK on the target figure (if it's on) is a first step performed by Poser when applying a pz2 file in general. The observation that I can re-name the file to FC2 (an expression), and have poses apply with no problems seems to bear this out.
  That renamed FC2 file does require the edit as above, but that just seems to be because some library types will only read one top-level object whereas pose/character files will accept more than one.

Another way to see this problem:
   It seems that various conditions will cause IK application to calculate with greater error. One thing that causes this to a high degree is non-uniform scale of one of the IK segments, along the the "length" axis. For instance, load any poser figure, change the "yScale" of the thigh and shin to soemthing like 70%,  fix the foot position to be in reasonable range of the IK motion, then turn IK off and on a few times and watch what it does.
   Since pose application does this " IK off/on " each time, all existing keyframes of the pose get more and more messed up as every pose is applied form the library.

Sorry for bumping my own repeatedly..
I discovered a workaround is to move the created PZ2  (not CR2, typo above) pose file to the "Expression" library as an FC2 file, delete the XMP file, and hand edit slightly, and now it works to actually apply a full pose with IK on, quickly and without problems.

The hand edit is removing the second top-level document partition, just combining them and letting the I target actors be defined twice..The 2nd version of the IK targets have the correct position parameters, so they're applied properly.

As a quick note on this, I created a completely blank pose CR2 file  (  just  { }  ) and this behavior still occurs.

So, it seems that the IK  on/off  is a "hard coded" behavior of how Poser applies poses. Perhaps there's a reason for this, but this seems very non-ideal, heh.