-
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
Sculpting Dawn in Blender
- Thread starter unreal
- Start date
That's good to know.
unreal
Noteworthy
Out of order would produce explosion (a'la using the a poser exported welded mesh). Loads without error. Useless, though.
In this case, it's even worse. They are in the right order. But they are not in the right groups. So it won't even load. The groups must be the same for it to load. Then it has to be the same order in the same groups, for it to work.
There are already a bugs on that new OBJ import/export. The nice thing about this one is I can cast it as general. While it hurts Poser use of OBJs as FBMs, it's not Poser's fault. It's completely Blender's. And it most certainly will screw up something else. It's actually kind of hard to find. The way Poser uses OBJs made it visible.
unreal
Noteworthy
Bug Filed. That took a while.
I included a little python script to analyze and compare the OBJ files, so they could easily see the problem. And actually use that code in automated OBJ tests, if they want. The quick little script lets them verify that vertex order, group composition, and face winding order are maintained on an OBJ imported then exported.
Much thanks to Ken for patiently guiding me through the opaque process Poser uses to load figure meshes from OBJs. I learned a lot. Would
have been nice if any of this stuff was documented (hint hint) rather than being discovered then staying resident in the brains of assorted peeps.
Poser's OBJ export is so orderly that the Blender bug was not triggering. It only became apparent when I imported the source OBJ (from the geometry) directly.
The Blender add-on... It was written to make up for a bug in Blender 3.x. The correct interim solution is to use 2.9 which doesn't have the bug. Blender already (versions < 3.1) works just fine for creating morphs from "bare metal" as it were. ie: the un-morphed original mesh.
But it's trickier to go the other way. But it's just the inverse. This is taking a Poser morphed figure, exporting it to further edit in Blender, then re-loading it as a new morph. Since the add-on does this, too, it's still useful
I included a little python script to analyze and compare the OBJ files, so they could easily see the problem. And actually use that code in automated OBJ tests, if they want. The quick little script lets them verify that vertex order, group composition, and face winding order are maintained on an OBJ imported then exported.
Much thanks to Ken for patiently guiding me through the opaque process Poser uses to load figure meshes from OBJs. I learned a lot. Would
have been nice if any of this stuff was documented (hint hint) rather than being discovered then staying resident in the brains of assorted peeps.
Poser's OBJ export is so orderly that the Blender bug was not triggering. It only became apparent when I imported the source OBJ (from the geometry) directly.
The Blender add-on... It was written to make up for a bug in Blender 3.x. The correct interim solution is to use 2.9 which doesn't have the bug. Blender already (versions < 3.1) works just fine for creating morphs from "bare metal" as it were. ie: the un-morphed original mesh.
But it's trickier to go the other way. But it's just the inverse. This is taking a Poser morphed figure, exporting it to further edit in Blender, then re-loading it as a new morph. Since the add-on does this, too, it's still useful
unreal
Noteworthy
Me too as the performance in 3 in blazing. Some things went from fast to instant. OBJ i/e was one of those things. But it wasn't bad before and 2.9 works
Like Miss B said, 3.x is all RC level so it's a pre-release bug anyway. Not horrific. But important to Poser devs who use Blender. I guess the 3 or so of us
The bug is also in 3.1.1 so it hasn't been fixed in nightlies, yet. They did fix an OBJ scale problem, and a mat group problem. They caused a bit of confusion in that "keep vert order" on export is not selectable. I figure someone thought: you'd always want that if you imported with that. Why risk someone not exporting with it. If the OBJ was imported in vert order, it will always be exported that way (unless you change the mesh topo or vert groups, of course). Would be nice if there was a quick way to see if a mesh was imported in vert order. I'm exploring where they keep that meta-data. My best guess is it's a json string data block named starting with a '.' as the GUI apparently hides those. Which means someone can't accidentally screw it up.
unreal
Noteworthy
Well, I need to stop. I'm confusing myself. Looking through the Blender source code, I see the exporter (still) as python. The OBJ importer exporter has been an "add-on" which is python.
Looking through the add-on, it defines the GUI (the panel of options) and the exporter has keep_vertex_order clearly defined, but that option is absolutely not in export. It does, however, in "true" lead to a pass in the if.
Confused by that.
Near as I can figure from the add-on, the way "keep vertex order" is used during import; blender's native object is made in the same order. It comes down to an API method accepts an ordered entry for vectors and faces (winding order). It translates OBJ groups to vertex groups and creates them the same way as well.
The exporter writes them back in Blender's internal order. Obviously, just like with Poser, if you change the mesh topology, you destroy that. Unlike Poser, it doesn't have to change the mesh topology to do what it does
Looking through the add-on, it defines the GUI (the panel of options) and the exporter has keep_vertex_order clearly defined, but that option is absolutely not in export. It does, however, in "true" lead to a pass in the if.
Confused by that.
Near as I can figure from the add-on, the way "keep vertex order" is used during import; blender's native object is made in the same order. It comes down to an API method accepts an ordered entry for vectors and faces (winding order). It translates OBJ groups to vertex groups and creates them the same way as well.
The exporter writes them back in Blender's internal order. Obviously, just like with Poser, if you change the mesh topology, you destroy that. Unlike Poser, it doesn't have to change the mesh topology to do what it does
unreal
Noteworthy
Cool, the Blender 3.x OBJ export bug is being worked on. That was quick
As for my confusion: from the developer: the importer is still python, but the python exporter is no longer used it's been replaced by a new C++. (the python exporter code is still in the source but unused). The bug is in the new C++ exporter code.
How Blender keeps order: on import it constructs it's own internal Object with the same structure/order as the OBJ file. Which means the Blender Object inherently duplicates the OBJ object. Reconstituting the OBJ means it just has to be exported in it's own Object order (writing OBJ groups during this process is where the bug is). This native ordering of the Object is why the order stays with copies of the Object in a Blender file.
As for my confusion: from the developer: the importer is still python, but the python exporter is no longer used it's been replaced by a new C++. (the python exporter code is still in the source but unused). The bug is in the new C++ exporter code.
How Blender keeps order: on import it constructs it's own internal Object with the same structure/order as the OBJ file. Which means the Blender Object inherently duplicates the OBJ object. Reconstituting the OBJ means it just has to be exported in it's own Object order (writing OBJ groups during this process is where the bug is). This native ordering of the Object is why the order stays with copies of the Object in a Blender file.
unreal
Noteworthy
The included OBJ importer (and exporter) in Blender is an add-on (this means you can enable or disable it). It's part of the official add-ons (blender maintained and included). You can enable or disable specific import/export formats as you wish. I tend to turn off formats I'm not using.
Add-ons in Blender run seamlessly in the GUI. They can add entire menus, add menu items, add elaborate features. When you disable OBJ i/o it simply disappears as one of the formats from the export menu.
The OBJ import and export window has options. Keep vertex order is one of those. As is "poly groups" You want both when working with figure meshes, depending on what you intend to do with the mesh. And, the source mesh. If you plan on using the OBJ as a morph target it has to keep vert order.
Blender actually keeps order on the import, when it builds a native Object to represent the imported OBJ. Conversely, export always happens in the native Blender Object order. I think this is why they took it out of the export menu; it does nothing. If the object was imported in order, it exports in that order.
You need vertex groups if you export to use the OBJ as a FBM target (Those will be the actor names)
Does that all help?
FYI: my Poser uni-mapper add-on takes 3 meshes and outputs a mesh in the same format as the original "unimesh". The first mesh *is* the original mesh, imported with vert order and poly groups. This is used as reference for the map. The second mesh is the zero'd welded mesh exported as morph target). The third mesh is the welded mesh with any Poser morphs you then wish to edit in Blender. When you're done with your edits, selecting the 3 meshes in order and pressing "Write poser OBJ" writes all the edits back out, in the same structure as the original. It uses the zero'd weld mesh to map back to original. At least for Dawn, it doesn't take any more time that just exporting as OBJ normally.
unreal
Noteworthy
No worriesThank you!
unreal
Noteworthy
OK. Finished the add-on, tested with Dawn and LF. It seems to work. More testing then I'll post. It's actually not much code at all. 175 lines; 10% blank lines, 20% is error checking, 50% is add-on GUI.
Blender already can sculpt the original OBJ mesh and output that same mesh with new shape. This process is only needed if you want to sculpt a version of the mesh that has already been morphed in Poser. Because Poser can't actually output a morphed version of the mesh that can be sculpted then loaded as a FBM.
It adds a panel to Blender's scene:
3 inputs to do it's magic:
Assuming 1 was a unimesh (that is, the geometry OBJ), then when it's reshaped by 3, 4 is unimesh, which can be sculpted and exported as the same structure. This can be loaded in Poser as a FBM (which was my original concern). It may also be usable in DS. Dunno.
If you haven't picked something for 4, it will copy 1 and apply 3 to that copy. Be warned, hitting the button with an existing 4 will reshape it back to initial. It is, however, undoable. At least, I coded it to be so.
Takes about a split second to do this map+copy+reshape. more testing. Tomorrow. I have steaming chicken fried rice calling my name...
Blender already can sculpt the original OBJ mesh and output that same mesh with new shape. This process is only needed if you want to sculpt a version of the mesh that has already been morphed in Poser. Because Poser can't actually output a morphed version of the mesh that can be sculpted then loaded as a FBM.
It adds a panel to Blender's scene:
3 inputs to do it's magic:
- Original mesh
- A poser exported zero'd unsubd'd version (for mapping)
- A poser shaped version of the same; using morph brush, whatever.
- OUTPUT a copy of the original mesh, shaped like 3, using 2
Assuming 1 was a unimesh (that is, the geometry OBJ), then when it's reshaped by 3, 4 is unimesh, which can be sculpted and exported as the same structure. This can be loaded in Poser as a FBM (which was my original concern). It may also be usable in DS. Dunno.
If you haven't picked something for 4, it will copy 1 and apply 3 to that copy. Be warned, hitting the button with an existing 4 will reshape it back to initial. It is, however, undoable. At least, I coded it to be so.
Takes about a split second to do this map+copy+reshape. more testing. Tomorrow. I have steaming chicken fried rice calling my name...
unreal
Noteworthy
They closed the bug with 99% fixed. I haven't tested it. They said they have to wait for the import code to be be changed to C++ for a complete fix. Something about how face groups are converted to vertex groups. I think It's because in OBJ, there's no exclusion for faces. A face can be in multiple groups. In Blender a face can be only in a single group. The vertices and edges can (naturally) be in multiples, but not faces. Currently, they opt for the first group a face shows up in to be the one.
unreal
Noteworthy
Turns out Poser does something similar, for different reasons.
unreal
Noteworthy
2 things. The bug is 99% fixed. There is an ambiguity in OBJ files that can cause it to not work correctly. Nothing that Blender can do. It's a "Poser thing". With unimesh coming, probably no point in going after that 1%
Argh! Now I found the Poser OBJ oddity (ambiguity) that defeats Blender's "keep vert order". The 1%. Apparently, Dawn has it. In Dawn's case, the assumption the importer makes holds. You can import the original Dawn mesh into Blender and produce morphs load load error free.
But when trying this for one of Dawn's clothing items, It fails. The mesh imports, order is held. But one of the actors (groups) fails. This seems to be the way the group is constructed in the original OBJ. For this item, you can't construct morphs in Blender. It cannot reconstruct the unimesh OBJ the same way it came in. (You can see this in DS OBJ import and export occasionally. So I assume they have similar issue with ambiguity)
The test: I imported the original OBJ, keeping vert order. Then I changed the scale (just to change the vectors, Poser won't create a morph if the vectors have no deltas; it's a "no op"). Load that as a morph target. As far as Blender is concerned, it exported the verts in the same order it got them. Part of it loads, but one actor doesn't. This has something to do with non-contiguous faces. That is, there are "island faces". Apparently, this causes ambiguity.
I have to add back a "backwards" feature in my add-on. Because what still works is to edit the poser exported split mesh (with it's messed up verts, but messed up in a way Poser expects). Keeping vert order, exported by Blender and loaded by poser correctly. Of course, sculpting a split mesh is messy in Blender. But the addon can map the Poser exported split onto the unimesh which can be edited. Then I can project that unimesh back onto the split and load that into Poser just fine (that map works both ways, after all
If I had to guess, the source OBJ was grouped automatically. That might have been the source of weirdness.
Argh! Now I found the Poser OBJ oddity (ambiguity) that defeats Blender's "keep vert order". The 1%. Apparently, Dawn has it. In Dawn's case, the assumption the importer makes holds. You can import the original Dawn mesh into Blender and produce morphs load load error free.
But when trying this for one of Dawn's clothing items, It fails. The mesh imports, order is held. But one of the actors (groups) fails. This seems to be the way the group is constructed in the original OBJ. For this item, you can't construct morphs in Blender. It cannot reconstruct the unimesh OBJ the same way it came in. (You can see this in DS OBJ import and export occasionally. So I assume they have similar issue with ambiguity)
The test: I imported the original OBJ, keeping vert order. Then I changed the scale (just to change the vectors, Poser won't create a morph if the vectors have no deltas; it's a "no op"). Load that as a morph target. As far as Blender is concerned, it exported the verts in the same order it got them. Part of it loads, but one actor doesn't. This has something to do with non-contiguous faces. That is, there are "island faces". Apparently, this causes ambiguity.
I have to add back a "backwards" feature in my add-on. Because what still works is to edit the poser exported split mesh (with it's messed up verts, but messed up in a way Poser expects). Keeping vert order, exported by Blender and loaded by poser correctly. Of course, sculpting a split mesh is messy in Blender. But the addon can map the Poser exported split onto the unimesh which can be edited. Then I can project that unimesh back onto the split and load that into Poser just fine (that map works both ways, after all
If I had to guess, the source OBJ was grouped automatically. That might have been the source of weirdness.
unreal
Noteworthy
Well, the problem is not Dawn's mesh, it's more about how Blender translates an OBJ structure to native. Dawn is perfectly valid OBJ.
With the Dawn mesh:
Dawn works fine in the old exporter, but not the new one (still; 1 face doesn't resolve correctly, they say).
A counter example is Alexis clothing. Neither the old or new Blender importer will import the OBJ in such a way as to export an OBJ suitable for use as a FBM.
I think I understand... I found the bug to happen when poly groups in the OBJ are not contiguous. OBJs can be that way. It looks like Blender has to juggle group targets when that happens and it doesn't always do it in such a way that the resulting OBJ has the exact same structure as the imported OBJ.
This is not the fault of the OBJ. It's a perfectly valid OBJ. It's a limitation of how Blender translates OBJ to native Objects. OBJs can be structured in such a way as to make it easier for Blender to do it right. It seems Poser exported OBJs (vert order aside) are constructed in such a way that Blender translates them accurately (ie: in such a way that they can be exported and used by Poser as FBMs).
All this only matters (to me) for using Blender to sculpt FBMs. So I handle the cases in the add-on.
I am going to look for the exact OBJ structure that triggers the bug, though. Worth knowing.
With the Dawn mesh:
Dawn works fine in the old exporter, but not the new one (still; 1 face doesn't resolve correctly, they say).
A counter example is Alexis clothing. Neither the old or new Blender importer will import the OBJ in such a way as to export an OBJ suitable for use as a FBM.
I think I understand... I found the bug to happen when poly groups in the OBJ are not contiguous. OBJs can be that way. It looks like Blender has to juggle group targets when that happens and it doesn't always do it in such a way that the resulting OBJ has the exact same structure as the imported OBJ.
This is not the fault of the OBJ. It's a perfectly valid OBJ. It's a limitation of how Blender translates OBJ to native Objects. OBJs can be structured in such a way as to make it easier for Blender to do it right. It seems Poser exported OBJs (vert order aside) are constructed in such a way that Blender translates them accurately (ie: in such a way that they can be exported and used by Poser as FBMs).
All this only matters (to me) for using Blender to sculpt FBMs. So I handle the cases in the add-on.
I am going to look for the exact OBJ structure that triggers the bug, though. Worth knowing.
unreal
Noteworthy
The Blender Add-on is here: GitHub - thoennes/poser-panel: A Blender Add-on to help working with Poser exported OBJ files in Blender
Download zip. Unzip, install the "poser panel.py" file throiugh the Add-on" prefs in Blender. There's a guide of sorts in the ZIP.
The add-on is actually general purpose, in that it allows mapping through 3 meshes that have specific relations between them. For Poser, it can create a unimesh OBJ version of a Poser exported OBJ morphed mesh.
Download zip. Unzip, install the "poser panel.py" file throiugh the Add-on" prefs in Blender. There's a guide of sorts in the ZIP.
The add-on is actually general purpose, in that it allows mapping through 3 meshes that have specific relations between them. For Poser, it can create a unimesh OBJ version of a Poser exported OBJ morphed mesh.