QTscript, as far as I know, is only used for scripting in D|S, not unlike Python is in Poser. The 7th post down doesn't seem to agree with your statement that "DAZ|Studio is, for the most part, written in an interpreted scripting language (QtScript)"

Yes, there are some issues there, every model always will have some. However, the paws were a nice evolutionary jump over the P4 cat. And I think I made the right decisions on amount of detail vs. a polygon budget. And yes, the amounts of toe detail, and ear fold detail, inner mouth details, was territory I covered quite a few times. Clearly in the future, when the average computer hardware base is more robust, allowing me a larger budget to work with, I can address percieved weaker areas; assuming confidently that there will be newer versions of the cat

The format change is simply an evolution of ability to produce more aesthetically pleasing and functional joints, smaller footprints, and systems that are being tailored in specifics to replace the chaos of workarounds currently at work. Usuage may seem similar, but whats going on behind the pretty interface and your mouse button is very different. This isn't something that many people seem to understand, and its not worth arguing over until you see the results; which an imported file will never truely show, becuase it hasn't been crafted to take full advantage.

The shadows in D|S for the moment, are raytrace only.

Ah well, I had a huge response all typed, but I'm usually too wordy so I'll skip it, and post this instead. Being 3D-techy geeks, we look around at other programs all the time; i.e messiah, motionbuilder, etc. Sitting around thinking "It sure would be nice if we could rig our models using (insert program feature X here)" or " Wouldn't it be cool if it was this way instead" isn't as productive as trying to do something to make it happen.

:) "The weld seam fix is just not active in your version probably because an issue cropped up with it." I think you are missing the point with the analogy. Every effort is made to have feature compatibility, as long as its a feature where a comparable Daz|Studio function can be found, or implemented, as long as it won't ultimately handicap the application, or deviate from planned future functionality. Think of it as a new application that happens to have a very featured Poser importer. Work will clearly continue to try and make the importer convertion as successful as possible. I just wanted to spread some awareness that between two different systems sometimes things just don't translate.

What I am trying to say is that its like importing a Poser figure into 3DSmax. The importer converts all things applicable to 3DSmax native standards of doing things. Some things would never be translated because the underlying 3DSmax engine is not Poser, and the two handle tasks very differently. Its designing a figure animation system that does things found in other animation packages that make life easier, coupled tons of knowledge on what/how things are best sorted in formats to make content delivery easier, and then importing other existing formats, matching features to ours as best as possible. Not build a system tailored completely around importing Poser content. Now that doesn't mean that thing X that doesn't work now, won't work in the future. Just that the goal is the future more than it is the past. (Seam problem aside, the fix is just not active in your version probably becuase an issue cropped up with it)

The welded seams issue has a fix, its just not active in that version probably becuase it was causing problems elsewhere. But imo unwelded seams on models, and geometry stored in the prop rig file are examples of poor design choices on the part of the content creator. Unwelded seams in particular cause problems in many programs such as zbrush. Whether or not these issues ever get resolved for Poser imports really has no ultimate bearing on the abilities of D|S with its eventual native content. It was never meant to simply be a Poser format importer. Thats just a perk, like loading .obj is into a program like LW. The functionality will eventually begin to show that the two are a very different breed, both in what they do, and how. That said, a ton of effort goes into making sure everything gets translated across that makes sense to, that won't cripple the program's goals.

Zoom is focal length. Dolly is Camera move. What you would want to do is zoom until the wall looks flat, then dolly the camera out.

Before anyone asks, the edges at the waist are appearing becuase the original obj doesn't have its group edges welded. Any figure made in such a way will break apart at those seams while posing for right now.

O, and to see morphs per part, you have to have both the bone in Scene Hierarchy AND the morph channel in parameter pane selected. Little workflow issue there. ^^

Btw, there aren't really "parts" in DS. Solid mesh with bonevertice weight deformation, like other programs. I suppose the group info could at some point be used in a similar way as material areas for invisibility, but not atm. Morphs right now are kept in lists under parameters by choosing "Morphs"(the main channel is equivilant to BODY in Poser)from the pulldown. You can select Poser "part" equivilant areas there for morphs. "Ungrouped" is the translation controls etc.

There are two renderers, one is a antialiased OpenGL, the there is a renderman variant. Under Render settings make sure that OpenGL Render isn't toggled.

Yes but other stuff that took more than one day, took that day. So blame those things. I would try removing it and reinstalling. I have noticed through a few of the revisions that the linking to the runtime somehow gets messed up, and that the setting that messes it up is stored. Usually deleting the whole thing and reinstalling will solve it. I'm sure whatever causes it will be tracked down.