• 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

question on Cr2 file to create a morph

kobaltkween

Brilliant
Contributing Artist
From what I've been told, DAZ doesn't _need_ INJ poses. You just put the morphs where they're supposed to be, and they're always listed. They only load when dialed in. Effectively, dialing "injects" the morph.

IMHO, that's messy and cluttered and doesn't give people the option of _not_ listing every morph they own, but I was explicitly told by several DS users that they found the lack of flexibility in how morphs were listed more flexible. So that's the way to go there.
 

Ken1171

Esteemed
Contributing Artist
Only if you do it by hand, and not if anyone ever saves anything with Poser. It's much, much, _much_ better just not to put non-library files in the library. For the same reason it's a bad practice to put textures and OBJ files in the library, it's a bad practice to put PMD files there.

The problem is that Poser doesn't require such files to be placed at a specific place. The result is vendors placing them everywhere, inside and outside the library, so we have no control or standards for how to handle this. It's pretty much a mess. Some vendors do put them in a separate folder, but the folder itself is still inside the library (doh!). This is why I keep mine together with the INJ/REM files, after manually removing the path info from the PMD. The down side of this is that it makes it impossible for other vendors to reference my PMDs if they want to make expansions, but that has never happened anyway, so I don't make it a priority. That's the only reason I can think of to justify creating external folders.

For Poser it is no issue but for DAZ it is a hassle to get INJ pose files,

This is only an issue in Poser. DS automatically places all morphs and UVs at the proper "data" folder, which is way more organized, and removes the burden of having to worry about where to place things. In addition, DS doesn't support morph injections, since ALL morphs always exist and are always accessible. They are only loaded into memory if you dial them, so it's memory efficient. The concept of morph injections only exists in Poser, where no morphs exist on the figure until you manually load them. One disadvantage of morph injections is that some may include lots of morphs you will not use, but they ALL get loaded into memory when injected into the figure.

One thing that makes life easier in Poser, though, is the awesome "Dependency Editor". It makes it a breeze to create complex morph interactions and put them into a morph injection. It also offers a visual interface to set several morph key frames into your morph, which can be cumbersome to achieve in DS. Such things are spread all over the interface in DS, making this kind of job a bit harder. This is a good example where both Poser and DS have their own pros and cons.
 

kobaltkween

Brilliant
Contributing Artist
The problem is that Poser doesn't require such files to be placed at a specific place. The result is vendors placing them everywhere, inside and outside the library, so we have no control or standards for how to handle this. It's pretty much a mess. Some vendors do put them in a separate folder, but the folder itself is still inside the library (doh!).
Poser doesn't require _any_ files to be placed _anywhere_. You _could_ put your textures and OBJ files in random folders. It's a bad practice, so people don't. Just like they also don't just put them loose in Textures, or even in Textures > Figure (unless they made the figure).

People aren't doing a consistent thing because the standard hasn't emerged yet. I used to have a bunch of "MAT" files that were camera files, before poses became the standard way to set material presets. And it was _years_ after the introduction of material collection presets before anyone besides a few techies used them as well as MAT poses, let alone instead of. Heck, I remember when OBJ files were often in Runtime or in Library. Poser World's old content put textures and OBJ files all over. Saying that right now, when we're only about two versions of Poser into people actually trusting PMDs to work, the community doesn't yet use a Morphs folder just like they do the Textures and Geometries folders doesn't detract from the fact that the obvious best practice is to be consistent with externally linked files, and put PMD files in a Morphs folder with internal structures and practices similar to the Geometries folder.

If Poser content survives, I won't be surprised if brokerages come to enforce a structure and naming convention for morphs as they do textures and meshes, and if that structure is consistent with the conventions they already have for textures and meshes.
This is why I keep mine together with the INJ/REM files, after manually removing the path info from the PMD. The down side of this is that it makes it impossible for other vendors to reference my PMDs if they want to make expansions, but that has never happened anyway, so I don't make it a priority. That's the only reason I can think of to justify creating external folders.
Or it's never happened because your morphs are in the wrong place. I know I've deliberately not only given up on using the morphs I own because of this practice, I've not even glanced at anyone else's for that exact reason. Why bother when I can't build off them? Especially when they're utility morphs like yours?

To be clear, I've done this in general, without any knowledge of the specifics of your products. I've just been burned so many times by other people's morphs I found useful but couldn't build off of that I've given up.

Also, the other benefit is namespaces. I don't have to worry about someone (including myself) accidentally overwriting my PMD files or bogging them down with complex names that are hard to scan. Everything is consistent, so everything is easy for me and my customers to find and/or avoid. Again, for the same reason the standards for textures and meshes exist now- and are equally unenforced by Poser itself, it's best practices to simply extend that standard to PMDs rather than come up with something new, inconsistent, and unable to work with the rest of the community.

You _can_ go out of your way to do something different that excludes everyone else from working with you, clutters up user's libraries with unfamiliar files, and makes it a bit harder for them to restructure their library (PMDs with similar names, needing to move the PMDs at all but not necessarily knowing about them, etc.), but why? There's zero benefit and lots of drawbacks.

Oh, and we will have to get a standard, or there will be no new successful Poser figures. Any successful Poser figure will have to have characters that are pure dial spins, and you can't do dial-spin characters without being able to count on injection working for you.
 
Last edited:

Faery_Light

Dances with Bees
Contributing Artist
With Toybox it places the morphs and the pz2 in the correct folder if you list that folder right.
The pmd file goes in the morphs folder, which I hat to create as Poser did not have one, and the INJ/REM file in th ePose folder.
Alisa has taught me to be consistent and it makes it easier for me as well as for the .
 

Pendraia

Sage
Contributing Artist
Just a quick note Faery as it looks like Ken is helping you out...I have often dialed in the morph in Poser and then exported as a cr2. Opened it in DS and exported and saved as an object file and then loaded it via Morph Loader Pro. I haven't had any problems with this method so far. It's how I get the Poser only characters across to DS. IIRC I did write a tutorial for this which can be found in the DS forum...it's possibly one of the earliest posts in there though as I transfered it across from the old forum.

Also just a quick note on morphs in DS I love being able to see all the morphs as someone who spins morphs regularly when in DS it's wonderful and easy to use. It also has a really good search function if you are looking for a particular morph.
 

Ken1171

Esteemed
Contributing Artist
Oh, and we will have to get a standard, or there will be no new successful Poser figures. Any successful Poser figure will have to have characters that are pure dial spins, and you can't do dial-spin characters without being able to count on injection working for you.

I agree on your points, but the fact is like you said it yourself - there is no standard, and different people have different opinions of what is the "right way". Some people even made videos trying to explain to Poser users how to organize a runtime, but it has now been over a decade, and it's still a mess. Even Dawn and Dusk have PMDs inside the library, and I have already suggested moving it out for Dawn 2.0. There were many occasions when I needed to reference Dawn's PMD, but it's location was unpredictable. Even I have moved it's default location because I don't like company names in content paths.

Perhaps what's really bad in Poser is that SMS has never fixed the most basic issues, like NOT embedding geometry into saved props, NOT saving OBJs on the CR2 folder, and NOT saving files with absolute paths for the textures. There were many vendors giving SMS suggestions on how this could be fixed (me included), but they just won't do it. And what's most - they broke the CR2 files in Poser 11, saving files with multiple redundant root notes, making a mess that I always need to clean-up after. I had this reported years ago, but no fixing was ever done. If there will be a Poser 12, it will inherit all of these issues. perpetuating old things into the next version.

But all this is nothing comparing to the most serious Poser problems of all - it's inability of working with a single mesh internally, which breaks OBJs it creates. After the original dev team was disbanded, I have little hope this will ever be fixed. We just have to live with how it is. No rules, and hope people will behave. We cannot force them to do anything.
 

Semicharm

Eager
I agree on your points, but the fact is like you said it yourself - there is no standard, and different people have different opinions of what is the "right way". Some people even made videos trying to explain to Poser users how to organize a runtime, but it has now been over a decade, and it's still a mess. Even Dawn and Dusk have PMDs inside the library, and I have already suggested moving it out for Dawn 2.0. There were many occasions when I needed to reference Dawn's PMD, but it's location was unpredictable. Even I have moved it's default location because I don't like company names in content paths.

Perhaps what's really bad in Poser is that SMS has never fixed the most basic issues, like NOT embedding geometry into saved props, NOT saving OBJs on the CR2 folder, and NOT saving files with absolute paths for the textures. There were many vendors giving SMS suggestions on how this could be fixed (me included), but they just won't do it. And what's most - they broke the CR2 files in Poser 11, saving files with multiple redundant root notes, making a mess that I always need to clean-up after. I had this reported years ago, but no fixing was ever done. If there will be a Poser 12, it will inherit all of these issues. perpetuating old things into the next version.

But all this is nothing comparing to the most serious Poser problems of all - it's inability of working with a single mesh internally, which breaks OBJs it creates. After the original dev team was disbanded, I have little hope this will ever be fixed. We just have to live with how it is. No rules, and hope people will behave. We cannot force them to do anything.
No kidding. Somethings have gotten better over the years, as I remember older Poser items with everything dumped into a zip without any subfolders or organization at all and the artist left a note in the readme specifying all of the folders they expected you to create to get textures and the such where they were expected to be. Other issues and conventions (or lack thereof) haven't been fix and likely never will.

The root nodes issue in P11 is annoying when trying to make cross compatible shaders. Sure, I could make separate mat files for Firefly and Superfly and not worry about it, but I guess I'm lazy and don't want to save and load mat files every time I switch renderers while cross testing. Of course, mats that would otherwise be compatible with older versions will have an extraneous root node that can't be deleted. I did find, however, that the Remove Detached Nodes button will do the trick. The problem is that you'd have to do that with every material zone on the item. So, I ended up adding a script to the mats that, on older versions, goes through all of the materials and runs the script for that button.
 

Ken1171

Esteemed
Contributing Artist
@Semicharm One of the annoying things they changed in Poser 11 is that pasting a copied material now creates a duplicate instead of replacing the existing material. I don't know in what planet creating a duplicate would be an advantage. I have filed a petition to avoid duplications, but they replied claiming that ending up with duplicates is the "correct" way to handle this. Go figure.

For orphan, detached nodes, there is the Poser wacro you have mentioned, but I like to use D3D's XS plugin instead, because it adds loads of extra functionality that is not available in Poser. For example, in DS we can select multiple MAT zones and edit their properties globally in 1 move. We can't do that in Poser, but with XS we can do that, and much more. It's a must have. :)
 

Semicharm

Eager
@Semicharm One of the annoying things they changed in Poser 11 is that pasting a copied material now creates a duplicate instead of replacing the existing material. I don't know in what planet creating a duplicate would be an advantage. I have filed a petition to avoid duplications, but they replied claiming that ending up with duplicates is the "correct" way to handle this. Go figure.
It is now. You can also select the node(s) you want to replace and choose "replace" instead. It took some getting used to.

For orphan, detached nodes, there is the Poser wacro you have mentioned, but I like to use D3D's XS plugin instead, because it adds loads of extra functionality that is not available in Poser. For example, in DS we can select multiple MAT zones and edit their properties globally in 1 move. We can't do that in Poser, but with XS we can do that, and much more. It's a must have. :)
Yeah, that's just one of the things I miss from DS when working in Poser. I'll have to look into XS. I had some other plugin some years ago, but it was really flaky and wasn't updated for Poser 11. That does nothing for my particular issue though, as I'm not going to burndon my users with buying an extra plugin either. Not when I can automate this specific task for them with a few lines of python.
 

SSGBryan

Inspired
I would just point out that there is a difference between “there are no standards” and “I don’t want to follow standards, because it interferes with my ‘creativity’”.
 

Ken1171

Esteemed
Contributing Artist
I would just point out that there is a difference between “there are no standards” and “I don’t want to follow standards, because it interferes with my ‘creativity’”.

Most Poser veterans eventually come to a certain way of organizing their runtime because it makes it faster to locate contents that way. For example, I always remove brands and company names from my library paths because I search contents by figure name. It's surprising how many people do that - not because they were told to, but because it makes life easier. I wish I knew that when I got started. This is how I organize the runtime structure in all of my products, and sometimes HW asks me to change it because it may reference HW contents, like Dawn, and they use a different structure with their company name in it.

For the longest time I have suggested people quit adding company names and brands to library paths, but they refuse to. To each, their own. This also happens in DS, where the runtime structure is much more organized, and it follows a standard, but it doesn't keep people from adding company names to library paths, making it HARD to find contents.

So I suppose things can get messy even when we do have a standard. Different people cannot agree on how they want to do things, and we have to live with that.
 
Top