• 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

Where should Poser geometry files go? Best practices.

Ken1171

Esteemed
Contributing Artist
Just to clarify, Teyon, who said this, is not a vendor - he is a Smith Micro employee, and he is saying, if I am understanding correctly, that stores insisting that the obj files be in the geometry folder and not in the character folder is what is "messed up and tedious and not vendor friendly".

Thanks for clarifying it, Alisa.

I'm starting to realize the bigger issue is that Poser also isn't consistent about what it does. It's not as if every time you save a cr2 an obj with a matching name is created.

In that particular aspect, Poser is very consistent. If you save a new item to the library that didn't exist before, it will place the OBJ in the same place as the CR2, PP2, etc. However, if the item already exists in the library and you save it to a different runtime, it will preserve the existing OBJ to avoid confusion with duplicates. This is actually a GOOD thing, because we can create several variations of the same item without duplicating it's geometry. I think this is consistent and beneficial in more than one way.

Another question... how do i create a prop for Poser, or DS for that matter, and NOT have embedded geometry? Usually to create a prop in Poser I just import an object and save it to the library. Is that what creates the embedded geometry. I guess you can tell, I'm pretty new at this still.

There is no way to create a prop without embedded geometry in Poser. The way things are is that you save it to props library with embedded geometry, and then extract it later and fix the wrong path in the PP2. NetherWorks has a "Poser Save File' script that automates that, and even exports the OBJ without embedding it. Instead, it just asks if you want it extracted, and where to place it.

To be honest Richard, I'm not even sure what the difference is between a prop or an object?

A figure has rigging with bones, while a prop has no rigging, and therefore no bones. Both can have morphs, but only a figure can be rigged with bones. That's the difference in a nutshell.
 

Gadget Girl

Extraordinary
Contributing Artist
But isn't that counterproductive to have to go back and save out the geometry for the prop and then resave the prop? IS there an option to save the prop's geometry as a separate obj rather than having it saved first as embedded?

You don't quite have to resave out the geometry. If your prop started by you importing in an obj file, once you've saved the prop to the library you can just remove all the geometry data created in the .pp2 and put in a link to the original .obj file. That being said, this behavior at least makes a kind of sense to me, on Poser's part because you don't need multiple files. The downside as I understand it is that this can make things very bloated, especially if you are using multiple versions of the same prop in a scene, which with some props like plants can be common.

To be honest Richard, I'm not even sure what the difference is between a prop or an object?

I know Ken answered the prop vs. figure question, but in case by object you meant obj, when you import an obj into poser it treats it as a prop, not as a figure, unless you add rigging to it. Assuming you didn't rig the item, when you save it to your library that imported .obj file will become turned into a .pp2 file. That file will include all the geometry information that was in the .obj file as well as some Poser specific stuff like what it should parent to if it's a smart prop. At that point you don't need the obj file at all anymore (assuming it's for your own use).

In that particular aspect, Poser is very consistent. If you save a new item to the library that didn't exist before, it will place the OBJ in the same place as the CR2, PP2, etc. However, if the item already exists in the library and you save it to a different runtime, it will preserve the existing OBJ to avoid confusion with duplicates. This is actually a GOOD thing, because we can create several variations of the same item without duplicating it's geometry. I think this is consistent and beneficial in more than one way.

Okay, you're right that does make sense, and it's what I assumed Poser always did until right around the time I started this thread. I think it confuses me now because I've learned of the times when it doesn't behave that way (mostly when making brand new figure from scratch so to speak).
 

Ken1171

Esteemed
Contributing Artist
Okay, you're right that does make sense, and it's what I assumed Poser always did until right around the time I started this thread. I think it confuses me now because I've learned of the times when it doesn't behave that way (mostly when making brand new figure from scratch so to speak).

I find it quite annoying that when we edit and modify an item, Poser will create a new OBJ, but ignore the location of the existing one. If the item already exists, and Poser KNOWS its location, it would make sense the new OBJ would reuse that same location, but no - it places it at the wrong path (in library instead of geometries), and introduces a wrong path into the Poser file for us to fix.

The same happens when I create a new prop, and Poser ignores the location of the original OBJ, and decides to embed it anyways - no questions asked. That's why I always use NetherWorks "Poser File Save" script when saving Poser files, not only because it asks me where to place the OBJs, but it also remembers the last locations, and will NOT overwrite existing thumbnails if they already exist. These are big time-savers in content creation!

But it's important to know that this is a known issue, and quite often vendors are requesting this to behave properly in the SMS internal forums. As for as we keep asking, SMS will do it at some point. :)
 

Gadget Girl

Extraordinary
Contributing Artist
You know, I'm thinking maybe I need to stop impatiently twiddling my thumbs waiting for Netherwork's stuff to make it over here, and make some quick scripts for my own use to do some of this. The thumbnail thing is another thing that would be a huge time save for me.
 

RAMWolff

Wolff Playing with Beez!
Contributing Artist
I really really want ToyBox.... Grrrrrrrrrrrrr Joseph, why did you shut down your store at RDNA so fast! :mad:
 

LisaB

HW3D Vice President & Queen Bee
Staff member
Co-Founder
As has been stated, the reason why we and other stores require OBJs to be in the Geometries folder is due to:
  • making an add on texture pack for a clothing item or a prop with embedded geometry will also share the original OBJ along with the add on. Solution - external OBJ file
  • absolute paths - Ken1171 explained it well here. Customers can move files around in their libraries in ways we cannot predict or control. By having the OBJs and texture files being held to their absolute path, we can maximize the customer experience of products working as they should.
I like that Poser now saves my OBJ in the cr2 folder because it eliminates me having to extract it myself. All I need to do is move my OBJ in my LB folder in Runtime:Geometries, change the path in the cr2 and I'm done.

This was supposed to be done for pp2 files as well with the latest Poser version but I have not yet had opportunity to test if it is the case. Right now for a prop file I must copy my pp2 files to PWizard, run the OBJ Extractor on each prop, copy them back, rename them from what PWizard named them and edit the path to the OBJ for each prop. It's a time suck. And if I screw it up or make a change I often have to repeat it.

So, no. We are not being stubborn or resisting change or evolution or advances in technology by requiring external OBJs. Until there is a method ensures customers moving files around will not affect absolute paths we are going to stick with how we are doing it.

Please show us how it can be different and can make sense for both the customer and the content creator and we will happily adopt a new method.

Thank you.
 

eclark1894

Visionary
Here you go a free utility to do prop files, stripping the geometry out and saving it to a user designated Geometry directory. Big thanks to John Hoagland: Vanishing Point: Free Item: Item Specifications: Geometry Stripper (Windows Application) for Poser Pro, Poser 7, Poser 8, Poser 6, Poser 5, Poser Pro Pack, Poser 4, and other 3D Content and 3D models
There ya go! That's what I need. I only hope John can make a mac version, but if he can't and all you have is a mac to use, You can try running the utility under WINE on the mac.
 

eclark1894

Visionary
As has been stated, the reason why we and other stores require OBJs to be in the Geometries folder is due to:
  • making an add on texture pack for a clothing item or a prop with embedded geometry will also share the original OBJ along with the add on. Solution - external OBJ file
  • absolute paths - Ken1171 explained it well here. Customers can move files around in their libraries in ways we cannot predict or control. By having the OBJs and texture files being held to their absolute path, we can maximize the customer experience of products working as they should.
I like that Poser now saves my OBJ in the cr2 folder because it eliminates me having to extract it myself. All I need to do is move my OBJ in my LB folder in Runtime:Geometries, change the path in the cr2 and I'm done.

This was supposed to be done for pp2 files as well with the latest Poser version but I have not yet had opportunity to test if it is the case. Right now for a prop file I must copy my pp2 files to PWizard, run the OBJ Extractor on each prop, copy them back, rename them from what PWizard named them and edit the path to the OBJ for each prop. It's a time suck. And if I screw it up or make a change I often have to repeat it.

So, no. We are not being stubborn or resisting change or evolution or advances in technology by requiring external OBJs. Until there is a method ensures customers moving files around will not affect absolute paths we are going to stick with how we are doing it.

Please show us how it can be different and can make sense for both the customer and the content creator and we will happily adopt a new method.

Thank you.
Actually Lisa, over at the SM forums, I'm being advised not to use those OBJ files that Poser creates and just use the original OBJ files instead. BTW, what's PWizard and where can i get it?
 

Ken1171

Esteemed
Contributing Artist
Actually Lisa, over at the SM forums, I'm being advised not to use those OBJ files that Poser creates and just use the original OBJ files instead. BTW, what's PWizard and where can i get it?

Unless the item is a prop, that is actually NOT an option. Even if the item is a prop, and you have edited the material zones, you can only use the new OBJ exported from Poser, since the original OBJ will not contain your changes. If you can use the original OBJ, then go for it - but there are many cases where things will only work with the new OBJ created by Poser. For figures, the original OBJ will NOT contain the body grouping, so only the new OBJ can be used.
 

Glitterati3D

Dances with Bees
For figures, the original OBJ will NOT contain the body grouping, so only the new OBJ can be used.

Well, that depends, Ken. I group my object before I bring them into Poser. I'm sorry, but Poser grouping sucks.

But this is where we end up when using absolutes - in an artistic environment, there are no absolutes. Not even file location.

That's why the brokerage houses eventually put in the requirements as they exist today - because the mess made out of the file structure was unwieldy and expensive to provide tech support for.
 

eclark1894

Visionary
Well, that depends, Ken. I group my object before I bring them into Poser. I'm sorry, but Poser grouping sucks.

But this is where we end up when using absolutes - in an artistic environment, there are no absolutes. Not even file location.

That's why the brokerage houses eventually put in the requirements as they exist today - because the mess made out of the file structure was unwieldy and expensive to provide tech support for.
I'm not saying that the brokerages don't have a reason for doing what they're doing. I'm also not saying that Poser doesn't have a reason for what they do. I just want someone to tell ME why they do what they do and most importantly why they can't see to get together on a standard way of getting it done. I'm thinking that someone needs to assemble a Content Creator's tool set.
 

Ken1171

Esteemed
Contributing Artist
Well, now you know the reasons. The way content stores have standardized things have more or less established the ways things are supposed to be, and that's a good thing. Once we have contents in installed in Poser, we still have the freedom to rearrange the library folders the way we like. I, for once, tend to remove company names from it and organize contents purely by figure name. But this is only possible if the OBJs are kept in the Geomeotry folder, and textures kept at the Textures folder. :)
 

LisaB

HW3D Vice President & Queen Bee
Staff member
Co-Founder
Actually Lisa, over at the SM forums, I'm being advised not to use those OBJ files that Poser creates and just use the original OBJ files instead. BTW, what's PWizard and where can i get it?

It depends on how you group your object and other things.

PWizard is a program that contains wizards to perform specific functions - Conforming, DialWiz, MATMOR, OBJ Ripper, Packaging, Squisher

It was created by KatKlaw Designs in 2002 and I think I got it at Renderosity back then. I do not think it is still available. I only use it for OBJ Ripping.
 

Miss B

Drawing Life 1 Pixel at a Time
CV-BEE
Now there's a utility from out of the past. I don't think I ever got it, but I remember the name from back in the day.
 

Glitterati3D

Dances with Bees
I'm not saying that the brokerages don't have a reason for doing what they're doing. I'm also not saying that Poser doesn't have a reason for what they do. I just want someone to tell ME why they do what they do and most importantly why they can't see to get together on a standard way of getting it done. I'm thinking that someone needs to assemble a Content Creator's tool set.

But THAT'S what we have been trying to tell you - there is a method to the madness.

The bottom line is simple - if you want to sell products in brokerages that follow the standards set out, then you have to follow them. Honestly, that's enough reason, I think.

I understand WHY the standards are in place - simply because the STILL MOST ASKED TECH SUPPORT QUESTION AT DAZ is "where is the content I just installed?"

That's expensive, tedious, tech support. Money better spent on better, faster product out the door.

I feel the same way about ReadMe files. Talk about an exercise in futility. No one reads them except the testers and they are a complete and utter waste of time and effort.

They answer the question - where is the content I just installed - but no one bothers to READ them. No. One.
 

eclark1894

Visionary
But THAT'S what we have been trying to tell you - there is a method to the madness.

The bottom line is simple - if you want to sell products in brokerages that follow the standards set out, then you have to follow them. Honestly, that's enough reason, I think.

I understand WHY the standards are in place - simply because the STILL MOST ASKED TECH SUPPORT QUESTION AT DAZ is "where is the content I just installed?"

That's expensive, tedious, tech support. Money better spent on better, faster product out the door.

I feel the same way about ReadMe files. Talk about an exercise in futility. No one reads them except the testers and they are a complete and utter waste of time and effort.

They answer the question - where is the content I just installed - but no one bothers to READ them. No. One.

Actually, I do. And for that very reason... to find out where the content is. Particularly the textures. Always have done this.
 

eclark1894

Visionary
Speaking of reading the Readme files... just read John Hoagland's reasons for why the object file is better to use than the pp2 file:

"Why use obj files instead of putting the geometry information in the prop file?
-Less memory intensive: when you add another copy of the prop to the scene, Poser only has to reference one obj file.
-When you save a scene file, Poser saves the reference to the obj file rather than saving the geometry information.
-obj files can be imported into other programs, pp2 files can not.
-Some marketplace sites require that prop files reference external obj files."
 

LisaB

HW3D Vice President & Queen Bee
Staff member
Co-Founder
Speaking of reading the Readme files... just read John Hoagland's reasons for why the object file is better to use than the pp2 file:

"Why use obj files instead of putting the geometry information in the prop file?
-Less memory intensive: when you add another copy of the prop to the scene, Poser only has to reference one obj file.
-When you save a scene file, Poser saves the reference to the obj file rather than saving the geometry information.
-obj files can be imported into other programs, pp2 files can not.
-Some marketplace sites require that prop files reference external obj files."

We are one of those that do require prop files to reference external geometry. One reason is if someone wants to make an add on for your prop, like a texture pack, they aren't including the prop obj itself in the pp2s they make. There was a time when mat files did not apply to props so each color had to be saved as a new pp2. Some of you with older LB plants and flowers will see this in your libraries. That's why I moved to cr2 files.
 

eclark1894

Visionary
Hey, one more question... how will extracting the geometry from a prop affect props that have moving parts? Especially in DS? For example, several props in my house, like the doors on the rooms, refrigerator, etc., and my stable and even my winchester rifle props have moving parts. Will extracting the geometry affect the origins of the geometry? If so, is there anyway to compensate for that?
 
Top