• Welcome to the Community Forums at HiveWire 3D! Please note that the user name you choose for our forum will be displayed to the public. Our store was closed as January 4, 2021. You can find HiveWire 3D and Lisa's Botanicals products, as well as many of our Contributing Artists, at Renderosity. This thread lists where many are now selling their products. Renderosity is generously putting products which were purchased at HiveWire 3D and are now sold at their store into customer accounts by gifting them. This is not an overnight process so please be patient, if you have already emailed them about this. If you have NOT emailed them, please see the 2nd post in this thread for instructions on what you need to do

Converting Between Poser and DAZ Studio

Ken1171

Esteemed
Contributing Artist
Conversely, I have never given DS a second look until I became a HW vendor. I never thought I would, but I started supporting both Poser and DS in the majority of my products since 2013, and it's like working in double. Nowadays I believe this has become something REALLY rare - so much that I had trouble transferring my products to Renderosity, where they have separate threads for Poser and DS - they assume the public for each won't even talk to each other. HW may be the only company making figures for both platforms, and believe me - it's like doing each thing twice. It's definitely not something we should take for granted. :)
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
I believe that's why the majority (except for a small hand-full) of DAZ PAs stopped working with both software apps. It's double the effort, and I guess they felt it wasn't worth it.

When I was still hanging out on their forums, and using earlier versions of DS, 98% of my Runtime was comprised of products that were also Poser compatible. Now I can use them in Poser if I want, which I can't easily do with Genesis products.
 

unreal

Awesome
Conversely, I have never given DS a second look until I became a HW vendor. I never thought I would, but I started supporting both Poser and DS in the majority of my products since 2013, and it's like working in double. Nowadays I believe this has become something REALLY rare - so much that I had trouble transferring my products to Renderosity, where they have separate threads for Poser and DS - they assume the public for each won't even talk to each other. HW may be the only company making figures for both platforms, and believe me - it's like doing each thing twice. It's definitely not something we should take for granted. :)
I've often wondered at this. I can't help but think that there should be a way to automate this.

I suppose both have incomplete APIs. And probably not good documentation and/or libraries for accessing their file formats directly.

How close would you say something like this is, conceptually?
 
Last edited:

RAMWolff

Wolff Playing with Beez!
Contributing Artist
I would be nice unreal but it will not happen any time soon. Never say never but there is no love lost between Poser and DS. Can you imagine the kind of brilliant coder/script maker to undertake that sort of thing? There are probably legalities they would have to look into as well as they would have to have permission for either side to dig that deeply into things like automating rig and weight map transfers and so much more. That's all proprietary stuff there so more than likely it will remain a pipe dream.
 

Ken1171

Esteemed
Contributing Artist
I've often wondered at this. I can't help but think that there should be a way to automate this.

I suppose both have incomplete APIs. And probably not good documentation and/or libraries for accessing their file formats directly.

How close would you say something like this is, conceptually?

Pretty much what RAMWolff said. Poser and DAZ did not part ways in friendly terms, and they keep progressively becoming more incompatible by the day. In the beginning, around DS 1 and 2, DAZ was still catering mostly for the Poser market, but later on that shifted more towards contents dedicated to DS, and then they have eventually completely departed from Poser - for good. No looking back.

It is easy for people to forget that DS4 was rebuilt from ground up to support Genesis, so that is not just a figure - it's a software and content designed specifically to its own platform. So much that not even DS 1, 2, or 3 support Genesis, so how could Poser? Not only that, but that is a copyrighted platform, so no one could just "borrow" the concept without DAZ legal authorization.

And it doesn't end there - there are also the incompatible materials, like it is with most 3D software. There is no way to reconcile that with scripts, because these materials are not open standards, and also, they have patent licenses behind them, which again, creates a legal issue that makes compatibility impossible. Even before DAZ departed from Poser contents, it was already like that.

The same applies to the incompatible weight maps between Poser and DS. Dawn 2 is a TriAx figure, which is basically identical between Poser and DS, but the weight maps are incompatible. Even the simplest thing, like bone placement use different standards, so Dawn2 in Poser and DS would not have the joints exactly at the same places, and neither did the original Dawn. That's because the numerical joint coordinates in Poser and DS use completely unrelated values and scales, so there is no way to simply copy one to the other (I tried).

In short, Poser and DS have become pretty much incompatible, and this keeps becoming more so over time. Basically the only thing that remains compatible are morph shapes, but only from DS to Poser, since Poser doesn't support unimesh (yet). That's why we have to work in double when supporting both platforms. We have to rig twice, and then create the materials twice (and hope they look the same).

As I understand this, Paul has finished the DS version, and is currently working on finishing the Poser version. There is no magic button to create the other version, and I doubt there will ever be one. We just have to do it twice.

Hope that answers the question.
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
I'm also hoping Chuck Taylor (a/k/a nerd) and the Poser dev team are able to get the unimesh issue resolved, and I'm hoping before the end of the year, but from what I understand, it will probably be a lot longer. :(
 

Ken1171

Esteemed
Contributing Artist
I'm also hoping Chuck Taylor (a/k/a nerd) and the Poser dev team are able to get the unimesh issue resolved, and I'm hoping before the end of the year, but from what I understand, it will probably be a lot longer. :(

Most of us thought it would take much longer, perhaps years. However, Rendo made a public announcement earlier this year where they claimed we should have unimesh in Poser in a matter of months, not years. Even though their initial estimate hasn't materialized, this is not the kind of thing that should be rushed. I can't emphasize enough the scale this entails, meaning it's a HUGE undertake that requires basically rewriting the Poser core. This affects all Poser functionality, so changing the core can potentially break everything else. That's why this is taking time. Nonetheless, Bondware was optimistic we should have unimesh Poser still this year. We will have to wait and see.

For those who are wondering, unimesh in Poser should make it easier to bring some kinds of Poser contents into DS and other programs. For example, if we export a Dawn2 body shape from Poser, we should [finally] be able to load it in DS as a morph target. As it stands, Poser basically destroys geometry when exported, meaning they cannot be used as morph targets in other programs. Using the Morph Tool in Poser can sometimes explode the geometry (spike it out) because the tool expects unimesh, but finds split geometry instead. I like creating characters with Dawn to animate in Reallusion iClone, but I can't do it from Poser because this requires unimesh.

I could make a very long list of reasons why Poser needs unimesh internally, but you get the idea. I believe Poser will be much more competitive in this market once it supports unimesh. :)
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
Poser basically destroys geometry when exported, meaning they cannot be used as morph targets in other programs. Using the Morph Tool in Poser can sometimes explode the geometry (spike it out) because the tool expects unimesh, but finds split geometry instead.
Ohhh, boy did I ever have a surprise the very first time I imported V4 into Blender so I could try creating some clothing for her. I had absolutely no idea that she would come in as around 68-69 pieces. I nearly fell on the floor when I saw it.

That said, however, one of the great things about Blender is, you have options on how you want to import . . . split pieces or a single piece.

Here's a few screenshots so you can see what I mean.

1) The default import of an OBJ:

ImportV4-1.png


2) Here's what I see when I change the settings so she'll import as one OBJ:

ImportV4-2.png


All I did was select Keep Vert Order, and check Poly Groups, and here's what I see when she's been imported:

V4InBlender.png


In the Outliner palette at the top right, there are two items when you click on the "+" sign next to her listing. If you click on the "+" sign next to the first, it gives you the list of 68-69 items you would see if you did a default import. The second is Vertex Groups, and when that "+" sign is clicked a long list of all her vertex groups appears, and if you happen to click (maybe double click) on one, options will appear in the Properties Panel at the bottom right.

I've never played with any of them, so have no idea what's what as far as that goes, because I've only imported characters so I could play with creating clothing for them. I've never gotten to the point where I wanted to play with morphs for a character.

Anyway, I don't know if other modeling apps have this type of choice when importing characters. I also have Silo, but don't use it as often, so haven't checked to see if it gives you that option, or not.
 

Ken1171

Esteemed
Contributing Artist
You can export OBJs directly from Poser with verts welded, but the welding will never end up with the same original figure's vertex order, so even if you weld it back into 1 piece, the original vertex winding order is already lost. The proper way to do this is to use the existing OBJ from the Geometries folder - never export any geometries from Poser.

This is one major thing the unimesh Poser version will finally fix.
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
These are the posts culled from the Dawn 2.0 Underway thread, so please continue the conversation in this thread going forward, so we can keep the Dawn 2.0 Underway thread about Dawn 2.
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
The proper way to do this is to use the existing OBJ from the Geometries folder - never export any geometries from Poser.
That's exactly how I did it. I imported V4 from my Poser Runtime. I've never exported anything directly from Poser.
 

Ken1171

Esteemed
Contributing Artist
The first time I had imported a Poser figure in 3DS MAX to make content for it, I didn't know of unimesh, or if MAX would support that. Comes down MAX does NOT support it, and as a matter of fact, none of Autodesk products do. Therefore the early bunch of products I made for Poser were all using split geometry back in 2004, and for many years to come, I thought that was the only way. MAX cannot import unimesh figures without splitting the geometry, which led me to (incorrectly) assume all Poser figures were split.

In the same way that 3DSMAX didn't support unimesh, Poser didn't as well, so for the longest time I believed groups could only exist with split geometry. My first hints that something was wrong was when I realized the figure vertex count was larger after exported from Poser or 3DSMAX, comparing to the original. But until then, for all means and purposes, whatever grouped geometry I imported into MAX or Poser ended up split, so there was no way for me to know it wasn't split before importing.

Nowadays I know that there are only a few programs that support unimesh (DS, Modo, Blender and Lightwave). I wish I knew then what I know now. So whenever I tell people NOT to auto-group things in Poser, or use geometry exported from Poser, I am implying all this long history of misunderstanding about how things really worked. I don't think the Poser manual ever explained any of this, so I am not surprised when people get caught into this same pitfall so often nowadays.
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
I'm glad Poser will accept anything grouped in Blender. The only thing it won't accept is anything rigged in Blender, which is sad because they have a neat add-on plugin called Rigify. I haven't played with it, but the end product would have to be kept in Blender start to finish. I know a lot of folks who do all their work in Blender, including rendering the final scene or animation. I haven't done that yet, so any rigging I eventually do will have to be done in Poser.
 

Ken1171

Esteemed
Contributing Artist
Rigging is completely different between Poser and Blender. It is completely different between ANY program I know of. The only kind of rigging that is cross-compatible between Poser and DS is legacy spheres, because it doesn't store weight maps - they are generated dynamically in real-time. That's why transferring rigging in old legacy V4 works so well, and it is geometry independent.

PS: This has advantages over modern rigging, because if we change a single vertex in Dawn, it affects the entire figure rigging. Conversely, we can completely replace the geometry with legacy rigging, and it still works. :)
 

unreal

Awesome
Does DS still support geometric weight controls (the spheres and capsules)?

Isn't triax LBS supported by both? I thought Dawn and Dawn 2 were triax LBS on both platforms. While G4-8 are DQS, thus not even remotely supported in Poser.

Does DS support blended multiple maps/methods per actor per axis, as does Poser? You can actually get very nice bends using spheres & capsules with multipliers and such. And the geometric controls transfer between meshes much better than WM'd verticies.

You can have different WM's in Poser and switch them. no one really does that. I did it with some dev clothing. The base WMs are geometric. Then there's a set that is a copy, but flattened into WMs, then tuned and set to replace. For copy, you can copy using the geometric, then flatten and tune in the target. Most joints (fingers, especially) don't need any tuning. Shoulders and hips always do.

When I'd really like to make for D2 is a set of donor clothing items. For instance, shorts have WAY different movement at the hips, due to the opening. Same with jockeys, and at shoulder: tshirts, crew and vnecks, tanktops, and at ab, crop tops. A body stocking moves very different and makes rubish donors.
 

Ken1171

Esteemed
Contributing Artist
@unreal Yes, both Poser and DS support legacy rigging (spheres-based). One thing that causes confusion is that Poser has never "named" anything it uses, while DAZ gives things fancy names, like "TriAx", "D-Force", and "D-Formers". That gives people the wrong impression that DS supports more things than Poser does, just because those things simply have no name in Poser. Legacy rigging is identical in both Poser and DS, which is why legacy figures work in both with no changes. TriAx is also identical in both programs, but the weight maps, coordinate system, and scale are different in DS, which makes them incompatible. They both operate identically, though.

The multiple maps per join = TriAx, which DS is no longer using in their recent figures. It's now a single map per joint, which is why Genesis needs 2 bones on the thighs and shoulders.

However, the rigging in Genesis is not "dual quaternions". It uses a game engine rigging called "SimpleBone", which is supported in Poser, but nobody would use that since it's way inferior to TriAx. SimpleBone is used in Poser to be able to export figures to game engines, and nothing else. "Dual quaternions" is a mathematical method used to calculate rotations without gimbal locks we encounter in regular Euler rotations, and Poser supports it, too. So much that my "Scatter Tool" was already using it in Poser 11, and now also in Poser 12. As another example, Poser 10 was using dual quaternion rotations in it's support for the Kinect motion capture long ago. In other words, "dual quaternions" is NOT a rigging system - it's just an alternative fancy way of calculating joint rotations in both Poser and DS. I just think DS uses it more extensively than Poser does, but it's supported in both.

One fancy thing is that Poser allows mixing legacy spheres rigging and painted weight maps in any combination. A figure in Poser can use both at the same time! :D
 

unreal

Awesome
Well, "triax" makes sense. It's LBS with different maps for each axis.

I have no idea what d-force is, or d-formers. I was under the impression that they licensed some dynamic cloth simulator tech from someone. I thought it was the same people (person/company/whatever) who long ago licensed a simulator to Poser (v 5, iirc). In any case, that hasn't been changed in what, almost 20 years. I assumed "d-force" was a marketing name for whatever was their licensed tech. Like superfly. Luckily Poser doesn't just name (re)stuff. :p

Firstly, simple skinning: iterate each vertex on the mesh and bound each vertex to a certain bone. Secondly, linear blend skinning(LBS): each vertex is influenced by multiple bones, and each vertex has a certain influenced weight with each influencing bone. Compared to simple skinning, LBS is a classic way to do skinning, it can create natural animation. Thirdly, dual quaternion skinning(DQS): based on the same strategy as LBS, DQS converts rotation matrices to quaternions and compute normalized quaternions, using the related joints’ weight internally, rather than using the rotation matrixes directly.

quaternions already avoid gimbal lock. We use them in engineering for that reason :). From what I gather, dual quats contain rotation AND translation info. Poser can already output rotations as quats (in the API). Doesn't do *dual* quats that I know of. I've used Posers quats, to move animations in and out of a game engine that used quats for figure bone rotations. Keyframes were done as translations and quaternions. that is, you specified a time index, each of the 4 values of the quat, plus the 3 values of the translation. A blank space delimited. For each bone that was moving. Pretty simple. It was actually relatively easy to dump that info from Poser. Since poser could load BVH, I could apply, tune, and dump from poser. Much easier than other ways. It was also realtively easy to convert their skeletal and mesh format to Poser.

But Poser doesn't doesn't support DQS. Seems like it could. But I can see why it wouldn't. From what I've read comparing the skinning methods, 3 axis maps LBS would produce better bends with less corrections/hacks needed than any single map. Regardless of DQS. Disney said so. They seem to know some stuff :)

DQS produces bulges, though. How is DS countering that?

Ahhhhh. I get it.

Sure, for different coordinates, scales, they're are known on both ends. They would convert. And the rotations of the bones would be the same. calculating quat + translation, dual quat, rotation matrix (3x3) + translation, or a transform matrix (4x4).

But what matters is how a mesh vert is affected. And that's not just the rotation of the bone. It's the algortim used to calculate how the rotation moves the vert (as a function of 3D position, rotation, etc.). Anything other than the same skinning method and the WM, bulge map, JCMs etc. are useless. Because the skinning method is different. Each has to use different corrective methods and/or values.

I had a thought. For a lot of clothing, looser stuff, DQS might be good enough. Can DS do triax on a figure but DQS on something else? That might be nice.

But... well, Dawn is using triax LBS in both apps. Which means that they should be using the same function to move a mesh vert in response to it's rotations and such. Shouldn't the same weights apply? And bulges? And JCMs?

nuts. My brain exploded. what a mess.
 

Ken1171

Esteemed
Contributing Artist
Poser and DS use different cloth sims, where the one in Poser is, like you said, from 20 years ago. DS has a more modern one, and they have named it "d-force". Poser has no name for it, so it's just generic "cloth sim". Same thing for rigging - in Poser it's just generic "rigging", while DAZ has named it "TriAx", even if it's the same thing Poser uses. I believe giving things fancy names is the way DAZ advertises DS features, while Poser has traditionally avoided any kind of hype about anything it does - which is why so many users only know a very small portion of what Poser can do.

As for DQS, you are basically telling me it's TriAx with DQ for calculating rotations, where TriAx is the actual rigging method, and DQ is how rotations are calculated. Personally, I rather keep those things separated, since TriAx can be used with either Euler or DQ rotations - it doesn't care how we calculate joint rotations. For instance, Poser uses TriAx with Euler rotations, while DS does the same with DQs. In either cases, it's still TriAx rigging under the hood.

The "dual" in DQs comes from the necessity of using 2 sets of quaternions to be able to make 3D rotations. The reason is that a single quat can only provide 4D rotations, for which we have no practical use. Sometimes people omit the "dual", but if you are getting 3D rotations from it, you can be sure it's a dual quat. Poser supports both Euler and DQs. Like mentioned above, I have used it in my scripts, and the "Game Dev" Poser version (Poser 10) used DQs on their Kinect mocap support. For the record, dual quaternions (also known as "Euler Parameters") were around since the mid 19th century, so this is not something new. DQs are just more used nowadays because computers can calculate them fast enough to be useful. It's a similar thing with fractal graphics, which we can find painted on vases from ancient Greece, but only became more popular nowadays because computers have become fast enough to calculate them quickly.

To the best of my knowledge, DQs can only calculate rotations, which is a peculiar property of Complex numbers DQs are based on. There is no challenge in calculating translations, since plain old linear algebra can handle it. Mathematicians have spent a great amount of time trying to resolve rotation gimbal locks, which is why DQs were conceived. If you look at the 4D math used in DQs, it's actually crazy complicated even to understand it, since we cannot visualize 4D space in our 3D world. It would make no sense to use that to calculate things like translations, which can be easily solved with linear algebra.

If you want to calculate both translation and rotations, better use matrices, since those provide both - but are affected by gimbal locks. Matrices only support Euler rotations, so we have to choose. There are ways to convert from matrices to DQs, and vice-versa. But if you opt for DQs, translations have to be calculated separately, which is how I did in my "Scatter Tool" script for Poser. Neither methods are faster or slower - the difference is on handling gimbal locks (or not).

As for your question, both SimpleBone and TriAx can use JCMs, but not bulge maps, since that would require extra maps, and only TriAx can have those. In general, ERCs are independent from the rigging method, so I believe any rigging system can use them. SimpleBone used in Genesis 3/8 can use ERCs to make up for the lack of bulge maps, which make these figures heavy on pose correction morphs.

For the other questions, DS supports legacy (spheres-based), TriAx, and SimpleBone rigging systems. Poser supports them all as well, but SimpleBone tends to be reserved only for exporting assets to game engines. It would make no sense to downgrade the rigging quality if it's going to be used in Poser itself. Loose clothing is hard to rig, no matter what rigging system Poser or DS offers. The way all of these rigging systems were designed was to conform tight outfits. There is no easy way around this.

Indeed, Dawn and Dawn2 use TriAx, which is the best out of the alternatives we have in Poser/DS. Although the way TriAx works in Poser and DS is basically identical, DS uses a different coordinates system and scale, plus the way the weight maps were implemented is incompatible with Poser. That might be a consequence of DS being unimesh internally, while Poser is not. Poser is soon to receive a unimesh version, so the rigging might change somehow, but that is an internal change - perhaps not something users would notice. That might make Poser even more incompatible with DS, but that was to be expected when we look at how things have progressed so far.
 

unreal

Awesome
JCMs are morphs. They are driven (linearly) by a parameter.

Hmmm. In morph scripts I made, for mirroring JCMs across even combinations of actors, I didn't have a problem with separate meshes. They were annoying but they could be overcome. I actually mapped the mesh parts to a single mesh; each "unimesh" vert had an array of actor.vert_idx that was len=1 or more. This was for left-right symmetric meshes like a figure. It identified the mirror actors, checked that their meshes were, in fact symmetric (actually, it used that to confirm mirror). It could find them by name AND mesh mirror. It found the axial actors as well.

It adjusted a precision until it found symmetry.

I even checked the JCMS for symmetry. Found a few screw ups in LF, the mesh and a few in the JCMs.

Not sure what tools exist to move things between Blender and Poser but I learn a lot coding conversions myself. Currently working on importing importing morphs as a bunch of shape keys. At least, this has worked manually.
 

Ken1171

Esteemed
Contributing Artist
JCM symmetry is on the list of requested features, and looks like it will be added to Poser 12. Like Charles Taylor has mentioned, Poser already has morph symmetry in the Morph Tool, so that could be adapted to create the missing JCM symmetry. That's something I will greatly appreciate. :)
 
Top