Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 29 7:57 am)
One little nit: it's "textures" and not "Textures" for the folder name. Might not make a dif, but that's the case. I don't understand how this remains an issue. If one assembles their textures within Poser, having said textures in the 'Runtime:textures' folder somewhere, and saves to the library, even as a preliminary step, these assignments will be done correctly by Poser. Then you can go about fiddling with the Poser file for other production needs.
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
I know if you use Pbooost it's a real problem. I also spend a lot of time correcting the references because Pbooost locks up Poser if they aren't correct. I'm surprised at all the experienced creators who don't do this. Btw, it doesn't make a difference if it's spelled textures or Textures. :=)
My idea of rebooting is kicking somebody in the butt twice!
Yes, textures.. I capitalize all Folder names by habit, only using lower case folder names when it is temporary.
I agree, this should NOT be an issue. Poser has been around more than long enough for people to understand the correct referencing, but more than half of all the products I have that use images at all, do it wrong.
A good many of them by some of the most reputable modelers and texture artists in the community. :(
I've even had emails (after my recent DAZ post) by so called(self proclaimed) professionals who swear blue that Poser will ALLWAYS run a search instead of going directly to the file indicated, which is absolutely not true.
It is simply that the incorrect methods are used so often, and often by those that are expected to have the answers, that this myth is accepted as truth by so many.
Message edited on: 12/11/2004 05:42
"Ditto" to all the above, PLUS: PLEASE give your textures unique names: eg: "Lilybelles_mfd1_red.jpg" - NOT just "red.jpg" I use Correct Reference (free version - I know the Pro version allows for this) and while I find it invaluable, an annoying quirk of the prog is to grab the first (alphabetically) texture it comes accross with the required name EVEN if the image IS referenced correctly. For example, if a texture is referenced as "Lilybelles/red.jpg" CR will change the reference to (eg) "Amanda/red.jpg" even tho' the original reference was correct. Grrrr.....
looniper;
Are you sure about this? Every source I've seen says that the second of your examples preceded by a colon, i.e. ":yourfolders:image.jpg", is the correct reference to use, with Poser automatically assuming the "Runtime:Textures" part.
The main problem I've come across (only in freestuff, admittedly) is in items which have absolute, Windows-style file references - "c:program filescurious labs..." etc. That's a major pain if your default folder happens to be "e:poser 4".
And don't forget, if you want to your product to be Mac compatible, you need to keep the texture name less than 30 characters (including the .xxx suffix) and you path less than 60 characters. That were starting frorm Runtime can become a problem. Runtime:textures is (if I counted right)16 characters leaving you only 44 characters for the rest of the path. This should be sufficient but I've seen lots of paths that were a lot longer than 60 characters. Things set up like Runtime:Textures:merchantnametextures:productname:merchantnameproductnameimage.jpgthat were 80 or more characters long. This may make finding the texture shorter for PC users but it make it interminally long for Mac users since you have to find each texture manually when you load the product. I don't buy twice from merchants who do that to me. Not saying you shouldn't start from Runtime, just that you should keep in mind the path length if you do.
"Do not meddle in the affairs of cats, for they are subtle and will piss on your computer." -- Bruce Graham
Attached Link: http://forum.daz3d.com/viewtopic.php?t=5167
Link is to a thread at DAZ - the one where I found out about the texture path thing. The hard way. I think I'd rather attach the textures manually than go through something like that. (A big problem is the way P5 keeps textures in memory. Once it finds the wrong texture, even if you manually change it to the right one, it keeps rendering with the first texture. Since SR4, sometimes even restarting Poser isn't enough to get it to let go of the old texture.)FWIW, over at DAZ they were saying that that path length limit is a Poser limit, not a Mac limit. If that's true, perhaps it can be fixed with a patch. They should at least fix that for Poser 6.
I'm baffled as to why this issue keeps on coming up. It's totally beyond me that any creator can know so little about the creation process that they can't get a simple thing like this right. And if this happens at DAZ with a brokered product, it's even worse. Because in the broker FAQ, they specifically devote a section to this. And it tells you exactly what looniper said 'Runtime:textures:etc, etc'. DAZ also specify the amount of characters for PC/MAC, and generally spell it out in simple language for all to see. I have nothing against MPE or any other app, but I'm suspicious of automated processes like this. But, at the very worst, a creator should manually check these things in notepad before submitting any product. And I'll echo lilybelle's call for unique names. Add a prefix to all your textures. DON'T call it 'shirt.jpg'. Add your initials, the size of your underwear or your granny's date of birth - anything to distinguish it from all the other 'shirt'jpg' texts we all have. mac
especially when, 6 months later, you finally get around to using it, and you don't get credit because we don't know who it was..at least put something in the readme..vanity is not a crime when making things..;)
I wish I'd said that.. The Staircase Wit
anahl nathrak uth vas betude doth yel dyenvey..;)
I am certain steerpike. The references you are referring to are strongly responsible for correct references being such a rare instance. :(
Say you are testing the above theory, and make a MAT that goes to ":mytextures:my_test_texture.jpg".
Well, that MAT is going to work just fine, because you don't have any other files named my_test_texture.jpg. So it is suddenly belived that the ":mytextures..." reference is reliable.
But add an "otherpeoplestextures:my_test_texture.jpg" to the mix and you quickly find the flaw.
I agree too, that unique naming is important.
While correctly referencing an image will find the right file, it will NOT load that file if one by that name is already in memory.
2 pairs of shoes in poser.
(mat)Load "shoes.jpg" onto the first one.
(mat)Load a Different "shoes.jpg" on the other.
Something didn't work right. ;)
Gee, not one person has corrected my spelling of corqect in the subject line. :(
Ah, Robo2010, yes.
PZ2(pose), CR2(character/figure), PP2(prop), FC2(face), and so forth. Any of them can contain references to images.
Message edited on: 12/11/2004 11:17
You spelled 'plea' corqectly, so all else was forgiven. ;0)
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
Now, if DAZ broker FAQ says that a proper texture path looks like :runtime:textures:blahblah:abc.jpg why are all textures referenced without :runtime:textures: ? At least for all the stuff I got recently. Just took a look at the current freebie... all references begin with "pdxjimsClothes".
Yesterday's the past, tomorrow's the future, but today is a gift. That's why it's called the present.
edit: I wrote this only after reading the first post, then I read all the other posts about unique naming. Oh, well. :)
While the subject is up, I'd like to add my .02.
Folks, please NAME your files uniquely! I'm referring to readme's and such here - "readme" just doesn't cut it. EVERY product has a readme, not just yours. Please put the name of the product somewhere in the filename (preceding is best imho). This way we don't have to rename your file to make it unique, and we can just dump it where we put such things.
This is a huge pet peeve of mine, and it goes way beyond Poser or even 3D content. File distribution is one of those areas where one person (the producer) can save many people (the consumer) work with virtually no effort. When producers fail to do this, the five seconds it takes to correct the error is multiplied by the number of consumers who downloaded the product.
Similarly, I wish producers would organize their directory structures properly. Take Kozaburo as an example. Here we have a producer who has taken the (probably inordinate) time to give us irreplaceably valuable products for free, and he won't take the time to standardize his directory structures. I just had to reinstall all of his hair recently and I extracted all of his files at once. There were five or so directories where his hair ended up. Five! It may sound like I'm nitpicking here, but I'm not. It's not that I object to the thirty seconds of work required to fix it. What I object to is the idea of hundreds or even thousands of people ALL having to put in thirty seconds of work each to fix it when the producer could have done all of that work in thirty seconds. There's also the principle of the thing; my God man, you put all of that work into those beautiful creations, and you can't name the readmes uniquely, or standardize your directory structure?
Obviously, I don't want to pick on Koz here. I just used his work as an example because it's something just about everyone uses and it fits my peeve to a "t."
Message edited on: 12/11/2004 12:56
Message edited on: 12/11/2004 12:59
My own experience is that Poser itself can do some weird things with recording texture references. That is, Paser 5, and maybe not the latest version, but change a texture in the Material Room and it is possible for the new file to record the data in an incorrect form. I'm semi-confident that SR4 has done something about this. Also, as a Poser 5 user I have been led to believe that Poser 4 is more restrictive on the organisation of folders.
Echoing and adding to Svigor's comments:
Ditch those self-important exclamation marks!
While you may be (rightly) very proud of your product, to me and others it's just one of many and no more important than any other so pleeeeeeeeease don't put it in a folder called:
"!!!!MyWonderfulNewProductName/monster_red.jpg"
DO use a generic (to you) folder structure and stick to it for all your products:
"MyFolder/monster/monster_red.jpg"
These is a texture folder for goodness sake, and your product won't get used any more just beacause it's at the top of the list...
Message edited on: 12/11/2004 13:50
Just another reason I have long since refused to allow installers to install anymore. If I did I would have a folder list spanning several thousand folders deep! And TONs of errors.
Everything first goes to a blank folder then I manually inspect (correct as needed) then manually install keeping everything neat, orderly (for my logical arrangement that is) and the many many thousands of READMEs neatly tucked in that maker's texture folder for reference. And if I'm not too busy I even create a Readme for those who forget...else I 'forget' who made it!
Oh, and P5 uses "textures" but P4 uses "Textures"
AND on the topic of:
I'm baffled as to why this issue keeps on coming up. It's totally beyond me that any creator can know so little about the creation process that they can't get a simple thing like this right.
Reference my previous post of the absurd usages these days of MAT, MOR, INJ, REM, and NULL - do they really all mean the same thing??? Many of today's creator seem to think so?!
'Now, if DAZ broker FAQ says that a proper texture path looks like :runtime:textures:blahblah:abc.jpg why are all textures referenced without :runtime:textures: ? At least for all the stuff I got recently. Just took a look at the current freebie... all references begin with "pdxjimsClothes".' That's the broker's mistake. No question about it. BUT . . . please note that this is a freebie which did NOT pass through daz's QA control. If it had, that would have been corrected. (Although, to be quite honest, if it's the weekly freebie on their site, I think it should be checked by DAZ). Just one point about the DAZ broker FAQ. These reccommendations are NOT optional extras. They're put up to tell brokers what to do before a product is submitted. If the product doesn't come up to standard, it'll be sent back to the broker for correction. Or if it's something small, DAZ will fix it. But the point is for brokers to send in 'clean' products, so that QA don't waste time fixing stupid mistakes. In reality, what can happen is that someone gets lazy, or says 'Oh, QA will fix it'. QA are up to their necks in products to test, so occasionally things slip through. And with 250+ brokers making products, the occasional starts to become a lot more obvious. mac
While texture paths are not case sensitive, try changing just one letter in a Geometry path or even geometries for Geometries when using P4.....SCREEECH! "item not found..." However P5 don't seem to mind minor discrepancies in the Geometries folder as long as it's spelled correct.
Message edited on: 12/11/2004 15:52
From indepth experience with the Poser file format, I find the inconsistency in case-sensitivity to be extremely annoying. In some cases, keywords MUST be case-sensitive, or the file will raise an error. In other cases, eh, who cares: the keyword can be cased as you please. This is lazy programming practice. If you want case-insensitivity on ALL keywords, lower case ALL keywords. If you want case-sensitivity on ALL keywords, use it on ALL keywords. One of my plugins has a dictionary of 168 Poser keywords (not to mention five String Resource lists), but I had to construct the dictionary as a struct with two fields: the string and a boolean to determine whether or not the keyword is case-sensitive (for as many as I have encountered that are not anyway). Obviously, this lackidasical approach extends into paths - textures is 'who cares', but Geometries is 'strict sensitivity'. Make up your friggin' minds, CL!
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
Oy. You know, that always confused me. Sometimes, case matters, and sometimes, it seemingly doesn't. I could never figure it out. I did notice that some folder are capitalized, while some are all lower-case, which struck me as odd, not to mention inconvenient.
I'm not going to complain about freebies, even at DAZ. Hey, they're free! But thanks for the heads-up. I will run CRPro on my "Dave" runtime before trying to use the item.
On the topic of case, does anybody know why Poser 5 makes all library entry names begin with capital letters? Or does this only happen on my system? If I add a figure, prop, pose, whatever and call it 'my entry one', Poser immediately displays it in the library as My Entry One'. It's really, really annoying. If I want upper case, I'm quite capable of pressing CAPS, thank you very much. mac
Well this grew much larger than I'd planned. I suppose I should be relieved that I am not alone in my frustrations, but I am left more disturbed by it being so prevelant that so many are upset over it. Perhaps a number of product creators have seen this thread and will make that minute bit of effort to correct their products before release in the future, or have found that the way they have done things in the past is not the 'right' way. If that is the case, at least some future releases will be less likely to go the wrong route. After all of this, I am again sorely tempted to create a reference correction program specifically for product developers, but assembler under Windows is a bloody nightmare, I never got around to learning C, and VB would make a 5mb download out of a simple tool like this. :( sigh ..and of course I know nothing of programming for Mac. Maybe Java? hmm.. I'll look into it. :) I could add in a few other tools I've been wanting but can't find. dlk30341 rather than render all of those items to make thumbnails, if they have the RSR version you can grab P3D0 Explorer and the RSR plugin to convert back and forth. :) Small download, work well and quickly, and a lot easier than making 32 renders for a product just to get thumbs.
Java, yes! That would be a superb choice. The process isn't intensive enough for the interpreted nature to cause very noticable slow-downs. And, it would be usable on both Windows and MacOS X. I don't think there is anything that can be done about MacOS 9-. ;( If you decide to do this and go that route, I'd be happy to help you out with the Java and Poser file parsing. Of late, I've been including both PNG and RSR for my products to placate both sides.
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
This is exactly why I make my mat files from the cr2 or the pz2, so the incorrect path thing won't happen. It takes all of 30 seconds to find the "material" beginning and copy and paste, erase all offending extras and then saving it. I never could understand why a utility was needed to make mat files, it's really quite easy to make them yourself. And it also teaches you about the cr2/pz2, so if for some reason the mat file isn't working, you'll know the file structure well enough you can fix it and not spend the next hour trying to figure out why it doesn't work. To me, it's kind of like hand coding webpages...if you use a utility all of the time to do it all for you, when something goes wrong you aren't going to have any idea where to look....so knowing the structure that you are working with is very important. :) As an avid Poser user myself, it drives me nuts to have to correct path names and texture references (on things I purchase, freebies doesn't bother me at all )...I know that things slip through once in a while, but on purchased items they really do need to be checked more then once ;) Now, if I could just get people to purchase my products LOL!!!! Pendy
I've actually started to include PNG's myself. It's more of a "comfort" thing I think then anything else, because as mac has pointed out, ProPak, P5 and Daz Studio convert them automatically. But as a merchant, it doesn't take me anytime to convert the rsr's to the png files and that way I can also test them in whatever application they are needed for :) Pendy
kuroyume0161 is correct that if you let Poser save the references (even as an initial step) then there shouldn't really be a problem. However, lets not forget that people making free content do so by using there valuable time and resources to add something to the 3D community. Mistakes do happen I'm sure most content creators would either remidy bad file reference errors, or prevent future errors, if they became aware of them. People brokering items, here at Renderosity, that don't load into the specified software should have the product/s removed until it's fixed. So, my question to the above postees is 'what brokered items at Renderosity do not load into the specified software'?
Vendors, as well as others, should consider QuickMAT from Hogsoft. It makes MAT's for you directly from within Poser so the references are taken from a Poser-created file. It will also capture an image (even a rendered image), and builds both the .rsr and the .png - and all "on the fly." Even if not using QM, then simplying running CorrectReference Pro before zipping the product, would find and fix any malformed references... Many of Hogsoft's products are designed as much for vendors' use as for end-users. [ Full disclosure: I'm a beta tester for Howard of Hogsoft, and originator of a few of the conceptual ideas implemented by Howard in CRPro and QM/Hub. ]
That's a little pricey. Not horrible, but it comes out to about $52 for QuickMAT and CRPro. I can do all of this for free with careful work and P3dOExplorer. $15 for QuickMat makes it worthwhile though.
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
"what brokered items at Renderosity do not load into the specified software" You're missing the point here I think. Incorrect references in the way we're discussing WILL work some times. The problem is, incorrect references, while they technically function, will not always function correctly if there is another image by the same name anywhere in the Textures path. And when they do work, they take a very long time to load whereas loading is virtually instant when done correctly. Most MAT file creators out there create incorrect(incomplete) references, and the product creators using them don't bother to take all of 5 seconds to check. In the end, Everyone who gets that product suffers for their laziness. I've had a slow day here today, only archiving 19 products. But of those 19, all were released this year, and only 2 had correct referencing. So you can see it is on an 'occasional' problem. This sort of referencing is not an error in spelling, it is either something forgotten or left incorrect as a matter of laziness. To make an analogy from my subject title, a better one would be if I had neglected to enter one at all. ;)
In post 12 above, I link to a post at DAZ I made regarding a reference problem. That particular product also has a joint problem, reported in July, and still not fixed.
Here's another item that gets frequent complaints:
http://www.daz3d.com/shop.php?op=itemdetails&item=1483
There are visible seams on the shoulders and neck. You can even see them in the promo images.
Layingback, does QuickMAT make Poser 5 MATS, nodes and all? I've been using Netherwork's P5 MAT Writer, and it works pretty well. In fact, it's the only program I've tried that does. But it's a bit cumbersome to use. I'd be willing to pay for something that made it easier. If it worked.
randym77, Yes, QM will do all MATs, including P5 (as long as you have P5 of course :-) There is 1 caveat, to quote Howard from his website: "There is, unfortunately, one extra thing to remember when making MAT poses with Poser 5 material nodes with QuickMAT... If you have some Poser 4 content in your scene (you usually will have!) then the nodes themselves don't actually exist unless you've looked at them in the material room once. If they don't exist, they're not exported to QuickMAT and they don't end up in the resulting MAT file. So to ensure the materials you want have P5 nodes, just look at each material in the material room before firing off the MAT save through QuickMAT."
That's what makes using P5 MAT Writer a pain. You have to go into the Material Room and click on every part you want included in the MAT. I guess it's a P5 limitation, or I'm sure Howard would have found a way around it. :-) So, what advantages does QuickMat have over P5 MAT Writer? And is it easy to edit the resulting MATs, if necessary?
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
For those who visit the DAZ forums, you'll know this is a real peave of mine, but after another mind numbing day of building installers, and spending at least 75% of the time correcting references, I thought I would bring it here as well.
When you reference an image file for textures in Poser (4) you MUST path it correctly, or you may as well not have a path at all, because Poser is going to ignore it.
"image.jpg" will get the same results as
"yourfolders:image.jpg"
"textures:yourfolders:image.jpg"
or any of these preceeded with a :
All of these are Wrong.
The only method that Poser will use to go directly to the file is this.
"Runtime:Textures:yourfolders:image.jpg"
(or with a preceeding : but there is no need of it)
Failing to reference images correctly means poser is going to search the entire contents of the "Textures" folder and its subs for all files by that name THEN get around to loading one of them.
Not only does this slow things down dramatically (more the more you have installed) but it can find the Wrong file by the Right name.
It's just as easy to reference correctly as it is to do so incorrectly. The only difference is, the users of your products don't end up with MATs applying the wrong image in a texture and they don't have to wait wile Poser churns through a hundred products' textures to find it.
Message edited on: 12/11/2004 04:41