For the limited space on the library palette the naming could consist of a easy to memorize part that is visible and some alphanumeric part that is not visible in Poser and that makes the file unique.

Something like "Some Shirt_2f3ee91635d7897a71209f02d01280e5.".
This should give plenty room for combinations until there's a better filesystem coming.
The maximum path lenght should be 256 characters for NTFS. With more then 244 it can cause errors however. Maybe the full hash with 32 characters is to long.
With an 8 character hash, like svdl suggested, there would still be ~281.5+e12 combinations for the hash alone, if restricting to 0-9 and a-f. Long before this number of files is reached the OS will have trouble and there is no such harddisk capacity available today anyways.

Yep. There are shortcomings on Poser's side. They should make it a open source project for Poser 8. :tt2:

Back to filenames or product naming. I don't know why someone want his name in the filepath or visible in the application (i.e. Poser) if the ReadMe contains it already.
At first, when I had very few products, I used to keep the files in the order they came from marketplaces.
E.g.: ":Poser nRuntimeLibrariesCharacter"

That was not a big problem because there were 1) few products and 2) few vendors at all. Now there are products of hundreds of vendors and this system is confusing. A good solution would have both, the new Poser user and the long time Poser user, in mind.

Example of the structure of some of the products I have installed:
"..ReadMe's"
"..RuntimeGeometries"
"..RuntimeLibrariesV3Body"
"..RuntimeLibrariesCharacter"
"..RuntimeLibrariesPose"
"..RuntimeTexturesCharacter"
"..RuntimeTexturesCloths"
"..RuntimeTexturesClothsTemplates"

If there are let's say 20+ products of one single vendor then it makes sense to place them in one folder with the vendor name.
But that is rarely the case. Reality is that there are many many folders with vendor names and very few peoducts in them.
Often it's only 1 product.

"..RuntimeLibrariesV3Body"
That makes not much sense for example. There are only some .pz2 files in that folder.
The reason for the "!" and the reason for the location of this folder I can not see.

"..RuntimeLibrariesPose"
Sure, I expect poses in "..Pose" and not in "..Geometry" or "..Python". Needless to name the folder and needless to place that ! there. The word "Poses" I won't even see in Poser's library palette because the product name is so long already.

"..RuntimeTexturesCloths"
"..RuntimeTexturesClothsTemplates"
This is good. In the texture folder it makes sense to gather all textures per vendor.
The templates however can be located in one templates folder.
"..RuntimeTexturesTemplatesCloths" looks better and makes finding templates easier because if one looks for templates, he will look for some folder called "Templates" and for the vendor maybe after this.

"..RuntimeLibrariesCharacter"
This one is good too. If one installs a single product it's quickly to reorganize this structure.

In the case of "..RuntimeLibrariesCharacter" one quartal later the user won't know anymore what the single vendor-named folders contain.

For giving credit it can be helpful if there's a dummy file with the vendor name along with the pose files. Hair colors for example or any other stuff. It's more useful than placing the vendor name in the file path because it is visible if the library palette is opened to load the mat pose or the mesh.

For the hierarchy is to add: Below "Geometry" comes the geometry. - Similar to the case of "Template".
A geometry could be clothes, hair, props. These are broken down logically.
Clothes can be
"..GeometryClothesMenShoes"
"..GeometryClothesWomenShoes"

And so on.
Fantasy clothing also belongs to some real world category. Plate, leather, chain, scale armors belong to Armor etc...
Some magic wand belong to primitives --> cylindrical --> staves --> wands. - Or whatever. Have a look at what gaming industry does.

Real world industry gives some good example patterns for clothes and other stuff like houses, furniture, vehicles.
Hair can be sorted by it's default style, props can be sorted by their function.
A house would be somewhere around "..GeometryPropsdwellings"

From elementary particles up to stars and galaxy clusters everything can be classified and sorted.
If one creates a whole new universe the real world may fail to serve with some sorting pattern. In this special case it's ok to place the universe in whatever folder you want. As long as it sticks to Poser's file system.

It's less a problem of  what some rules say than of fixing imperfect and incomplete rules for those who need detailed rules.

I didn't say it's all your fault, Unicornst.
However, the vendors are as well as the customers able to say what they want to have changed or why they do things in a certain way. Referring to some rules all the time doesn't work out well.
I know the "rules" and they don't say anything about unique file names, conventions, directory structures or databases.

Some ReRo people read this and can notify the responsible people of MP about the complaints.
They can change their rules or come with some reason why not to do it.
I write it here because in the end there will be different things that bother different people. A thread like this is a good place to write down all the wanted changes and all the complaints about what is going on.

"Someone who thinks logically provides a nice contrast to the real world." - someone said. :p*

There are vendors which do a good job with their products and files but some just mess things up. I won't give examples for good nor for bad vendors here.

Was about time for such a rant...

At some point I had to reorganize the Runtime because after installing many products there is no way to find what you have installed. The stuff ends up just everywhere.
Now the Runtime is ~50GB, ~300k files and Textures is ~ 22GB, ~40k files.
Imagine what a mess it would be if the files would all be where they would have extracted too.
As it is now it's still not always easy to find a certain item if it's in a folder with the vendors name because I don't remember the vendor but the product and to which category it belongs.

Havin a structure like:
ABC:Dress
ABCD:Dress
ABC1:Dress
ABCH:Dress
...
Does not make it easier to find the dress I was looking for.
Since I have every product registered in a DB it's easy to search.
But the DB wasn't part of the product and it's a pain in the ass having to refer to each and every texture, mesh, whatever file that comes with a product. Besides this, it's somewhat funny that external tools are required to keep track of files.

Someone said it already: Thumbs.db - I don't want to see any of these files installed to my Runtime. Sure, it's easy to keep the computer from doing so, but that doesn't mean that it is my job to watch over each file that is written to disk. And someone who can't program or script or use DB's will have to manually sort the extracted files til the end of all days. Or longer...

What I would love to see is:

1. Hashset, creation date, rev. nr. as part of the filenames. At least for textures.
2. Because it's very unlikely that filenames appear more than one time this way, it don't means that I wan't 10 same textures in 10 different named files.
3. Not like 10 different character morphs that are named all the same. (See point 1)
4. Some DB script file that makes it easier to register the files in the system DB. No matter what DB is choosen.
5. Some thoughtful naming of products. Some XYZ-Hair is cool, but XYZ often don't say much about the geometry - or basic style - of this hair. And "long hair" is a bit vague, isn't it?
   Often there is already some realworld name for some type of hair or clothing. Using it may ease the search procedere.

A readme that contains important information. Not 100 thank you's and a endless list of installed files. The list of installed files should be part of a seperate file and the DB script.
It's nice to see that the product consists of a few hundred files but I doubt I will ever check pesonally if every file was extracted/installed to the right location. That's a job for the system and not the reader of the ReadMe. In many cases the ReadMe could be reduced to the really important things: Product name - also already as part of the file name -, Vendor name and contact information, Product creation date and Product revision if applicable.

Product promo images - especially if scattered throughout the whole Poser directory - are not too useful AFTER I have bought and installed the respective product already.

Readme can be done in TXT format. In rather rare cases PDF or TEX is needed. I can't stand any DOC, WRI, ... files anymore if all that they contain can be done with TXT..

Maybe it would be a good idea to talk to e-frontier about directory structures and file names and the little room for filenames on the library palette.

A PZ3 shouldn't be extracted to the Runtime folder IMO. And even less it should be in some folder that gives no hint that there's a PZ3 file inside 20 more subfolders. - A little exaggerated.
Some people seem to think that it's cool to immortalize themselves in the Runtime by creating folders that simply don't belong there.
There is for sure some existing directory where such content can be installed because it's somehow similar to whatever is already in the specific directory.
P4 compatibility is nice. - If optional.

...

I wonder how long it would take till someone beats me if I start naming things like "chip: small, many pins" or "effect: 200kN, 5cm, 1450K, on model" in reports. Yeah right... That would be big fun.

This is the end...

There are some dynamic clothes for V4:
entrepot3d.com/joomla/
Also you can make your V3 conforming clothes partially dynamic.

Quote - I am using Poser 5

 

I have a tShirt I modeled for A3 in C4D.

Want the tShirt to fit V4.

 

I can tweak each vertices one buy one in C4D.

But would be a lot faster if Poser cloth room could tweak the tShirt automatically

 

 

Normally if ya put a tShirt on V4 and cloth it, it drapes like cloth on the I axis,witch is what the cloth room is for.

 

But I want to know if I can use the cloth room to make a lose bad fitting tShirt to shrink up and be skin tight on all 3 axes X,Y,Z.

Do not want the tShirt to fall to the earths gravity.

Want V4 to be the gravity and the tShirt fall to V4.
So the bottom of the sleeves would fall up.

 

And if I can some tips on the settings would be helpful.

 

Thanks

RorrKonn
http://www.Atomic-3D.com

I remember that you have asked some time ago about any solution to this very problem.
Is there no shrink-wrap in C4D or what didn't work?

Since the geometry is already in some human-like shape, the Poser clothroom should be sufficient for this.

Agreed. If I buy something it should goddamn work and not cause me even more work. >.<

This is what the file contains at the beginning:

Tempest Raster Image Format
(C) 2000 - 2002 Pixels
Version *1 1 0

ImageBounds [0.000000 0.000000 255.000000 255.000000]
CompCount 4
CompSize 1
ChunkSize 4
RowBytes 1020
GammaSize 256
Gamma [ 0.000000 0.003922 0.007843 0.011765 0.015686 0.019608 0.023529...*

Could stand for (SH)adow(M)ap and would make sense if you chose to reuse shadowmaps.
That's only a logical conclusion because of the found data in the file. 0 to 255 looks like the standard dimension of a shadowmap (256x256) in Poser. The Gamma data makes then sense too if the file is related to shadows.

Maybe Poser creates these files if you enable this feature and save the scene. It could reuse the shadow maps then if you load the scene again and doesn't require a new calculation of shadows.

Poser has a render engine? :lol:
It's prolly based solely on programming knowledge of the 80's of last century.

Well, if you look with a debugger what Poser is doing then you may notice that it really recalculates from scratch if changes occur in the material room.
If you move the camera in preview, not mat. room, then it doesn't recalculate everything that has procrdural shaders applied to it. Most of them are not even visible in preview mode.
It only recalculates things that are displayed in preview, e.g. no raytraced reflection.
I have not noticed yet that it recalculates for example a tile pattern applied to some surface that is visible in preview while I move the camera. Ergo I assume it stores such stuff in memory and does only another calculation for render.

Somewhat disappointing is the performance of P7 in material room. With many shaders consisting of 100+ nodes and no or small image maps I experience noticeable delays now that I had not with P6 on a much weaker system in 2005.

To answer the memory question:
Most images require more memory then procedural shaders. For some texture sized 1000 x 1000 you can place many shader nodes. I would say around 25 to 30.

Hobby. The company had it (rather for recreational purposes) and I got it then too. Makes buying new stuff less cost intensive for stuff that can be used for work.
Without this benefit I doubt I would ever have bought Poser or add on content or at least the runtime would be very very small.

What's confusing now? :lol:

Maybe this helps a little:
I used metric system in Poser 7 and looked what height said figures have.
Next I imported these figures to CATIA and looked for their height again.
There was no physical simulation done because it won't matter for Poser or D|S or many other apps that don't have FEM and phys. sim.
After I got the height from CATIA I posted the results here.
Finally I added the Pose data  for the figures and mentioned that I-DEAS came to the same results for height as CATIA because I imported them to that suite as well.

The scale related stuff was that 1m SI is 0.930234m in Poser 7.
The other numbers are related to the figures height since obviously there is some confusion about how their height can be interpreted correctly.

-tow

Forgot to mention the figures pose:

V3:
Neck Bend -4°
Chest Bend 2°
Abdomen Bend 2°
rButtock Twist -3° / rButtock Side-Side 1° / rButtock Bend 1°
rThigh Twist -3° / rThigh Side-Side 0.5° / rThigh Bend -2°
rShin Bend 3°
rFoot Twist -2° / rFoot Side-Side -2° / rFoot Bend -3°
rToe Twist -1° / rToe Bend 5°

V4:
rFoot Bend -24°

What is not listed here is set to zero. Same for left side.
V3 is somewhat posed to achieve a Pose similar to that of V4 with bent feet only.

BTW, I get the same heights as stated before if importing the figures to I-DEAS.
In both apps the height was determined by measuring the distance between the farthest antipodes of the objects.
e.g. the distance between feet sole and highest point of the skull. There was no applied weight of the figure nor any other physical pressures.

Quote - .... ummm... Us foot or international?
[ducking and running]---------------------------->

I used the international foot (304.8mm) and inch (25.4mm) for conversion as you would see if you look at the results. The US survey foot defined as 1200/3937 m is to regional limited for this purpose. OTOH, the ~610nm difference are in Poser only relevant if figure or prop dimensions exceed 10^6 ft.

For me it looks like this:
Height of V3 in Poser 7:         1929.7520838843mm
Height of V3 in CATIA V5R17: 1795.121mm

Height of V4 in Poser 7:         1923.4654936285mm
Height of V4 in CATIA V5R17: 1789.273mm

The values for height are the same as used in CAM  for programming the machines with CATIA.
It uses SI standards and Poser 7 use something else.
1m as defined by SI is 1.0749983337525826834968405798971m in Poser 7.
Or 1m in Poser is 0.930234m SI.

There is no inch, feet, link, furlong, fathom, whatever.

But for those that use these units:
V3's height in Poser 7 is: 6 ft 3.97449149150 in (periodic -> 787401574803149606299212598425196850393700)
V3's height in CATIA is: 5 ft 10.674 in

V4's height in Poser 7 is: 6 ft 3.7269879381 in
V4's height in CATIA is: 5 ft 10.443 in (periodic -> 818897637795275590551181102362204724409448)

If you want a figure that is [n] mm high you simply apply this scaling to it.
However, Poser does not really care about anything smaller then 0.001 in whatever scaling you'd chose.

If the competition doesn't get in the way of other content production - clothing mainly.
A figure without clothes is almost as useless for quick pictures as a figure without morphs.

If D|S / Cararra will be one product and Poser / Shade too, then it's prolly linked with more work for the user. Using the D|S/Cararra app to Morph and pose and import to Poser/Shade to render. :S
And 2 more apps on my To-Learn list. I need a coffee now and forget about these horrors...

P.S.: Calling Python works well atm. Sometimes a slight delay, but I guess it's much less than 500ms before the dial reacts.

Yeah I totally forgot the joints, lol. Some Python should be able to take care of this. If not then maybe it's time to say goodbye to this usage of joints.

IMHO Poser shows some good advance from P4 to P7. There was great advance from P1 to P3 too but these version are a little old and different to be compared. If there's support for external renderengines in P8 that would be wonderful.
Anyways, DAZ's figures don't show this advance. Compared to Poser, they are more P4 level.
V2 was nice to use when it was actual, V3 was also nice to use but there were also many sessions in texteditors to fix the shoddy  files. V4 and 4.1 are even worse if it comes to textediting sessions. Often V4(.1) works fine, but if it doesn't then the big hunt for the error starts.
I have nothing against DAZ but if I buy a figure it should work. If it's a freebie and I have to fix some things than it's ok. But it isn't.

And just like ClawShrimp said for the other figures, V4 Base is totally useless for an Poser user. It's not even useless but it is annoying because if I can't change the figures appearance without much effort (deformers, modeling app), than it fails the concept of the target app.The free V3 Base is useless without Morphs, but for it is free it is a great figure.

By taking into account what customers say I mean to try to implement it in a product. If signs are that the implementation would cause more trouble than there was before it might be better to forget about compatibility. Similar to what SGI does with hardware for example.

Ican not tell how much DAZ cares about wishes and problems that users encounter because I don't know the responsible people at DAZ. From other industries I can tell however that, if one doesn't care about norms and other standards, the product is not made with perfection in mind but rather money. DAZ's INJ files and file management are no nice sight.

That this can cause higher costs is probable and costs bring me already to the hardware.
3D and HPC would fit together excellently. HPC and hobby is the problem.

I think most people buy new hardware if the old is either defect or so damn slow and outdated that almost nothing really runs on it anymore. looks at his dusty Alpha 733MHz...
While 64bit computing and PCI Ext. are stuff that was wide spread in the 90's and high tech in the 80's, for consumer PC's it's still top notch. The resulting huge rendertimes and low quality meshes to be able to render at all on mediocre systems are things that IMHO won't change during the next few years.

"Mass market" figures, clothes, environments will likely stay at some medium level, but if scripts and materials get better used, the result must not be that bad. Using these possibilities and focus on one app leave much room for improvements without much higher system requirements.
If there's a new figure, than this is something that should be used for it. A mindless thrown out figure-line is maybe good for business but not for improvement. Curious Labs/E-frontier did a  better job regarding this issue and Poser/Shade.