Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 14 9:14 am)
Hi Dizzi, It would appear that Poser does not like (i.e., can not handle) identical names internally. That is why if you load a box prop (named "box") it will be named "box_1" ... load another identical one and it will be named "Box_2" ... etc. I believe the same thing holds true for texmaps but evidently, Poser does not automatically rename texmaps the way it does with props. It would appear that Poser does not care where (i.e., path) the texmaps came from ... and only uses the "name" after loading. If you are controlling the names of the texmaps, may I suggest that you use the same technique that Poser uses, e.g. test_1.jpg, test_2.jpg, etc. cheers, dr geep ;=]
Remember ... "With Poser, all things are possible, and poseable!"
cheers,
dr geep ... :o]
edited 10/5/2019
This makes sense, geep, since Poser is not refering to a file, per se, with loaded geometry (it's all internal after load), but is refering to a file with texture images. I think that they do this, as other 3D applications do, to conserve memory since large bitmaps take up vast quantities of it. For Material nodes, the thumbnail is just a small bitmap representation of the full-sized image. And during renders, the images are loaded then, hopefully, unloaded from memory. That all said, it is hilarious that Poser cannot distinguish texture image files by path. I realize that 'red.jpg' is not a good filename, but isn't the entire idea of OS and file system to organize so as to avoid these issues? If I specifically point to a particular file, darnit, I want that file referenced always. Why would Poser need to search for an explicitly referenced file?
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
re: " ... but isn't the entire idea of OS and file system to organize so as to avoid these issues?"
Hi kuroyume0161, Yes ... but ... YOU are the controlling factor when something is loaded ... i.e., you specify the path, e.g., subfolders, etc. and Poser is neither an OS nor a file system, per se. ;=] I don't know (but I suspect) that Poser does not keep track of a "path" after it has loaded something. It only knows an entity by it's internal name, hence, duplicate names cause problems. Some path names can get pretty long and if Poser stored the complete path for all of the items that it has loaded, it would require more memory. I am guessing that one of the Poser programmers made an executive level decision to not save the entire path after an object (or map) is loaded. Just a guess, I could be wrong. cheers, dr geep ;=]
Remember ... "With Poser, all things are possible, and poseable!"
cheers,
dr geep ... :o]
edited 10/5/2019
Even 10,000 path names of 256 characters each only utilizes 2.56 MB of memory (this is an overly extreme case to show that this is a non issue). The "Poser programmer" who made the executive level decision was wrong - and is hopefully otherwise unemployed. ;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
re:"The "Poser programmer" who made the executive level decision was wrong ..."
Hi kuroyume0161, You have a valid point ... but may I add that much of the code that is written is probably modular and, as such, a programmer may ... (out of necessity because of time constraints - you know the good ole "deadline" ;=] ) ... use someone else's code (module, subroutine, whatever) which may appear to be exactly what is required to "do the job." This can (and probably does) cause problems such as the one we are discussing. 'Tis not a perfek world Cherrie, n'est pas? (rhet) cheers, dr geep ;=]
Remember ... "With Poser, all things are possible, and poseable!"
cheers,
dr geep ... :o]
edited 10/5/2019
yes, Poser 5 also cannot handle textures with the same name in the material room. BUT P5 at least takes the textures from the locations they are referenced in a PZ3 and CR2 (runtime:textures:...) but P6 just takes the texture it likes... Maybe it's because i just added the P5 runtime to P6... i'll try replacing the P6 standard runtime with a link to the P5 one...
when i buy items or find frrebies i rename the files and edit the inj/rem/mat/etc Model (unimesh/judy/jessi/dork/etc) Name (mandy/malia/julia/etc) Part (head/body/eyes/etc) Type (trans/bump/disp/etc) UniF-Malia-Head-Tex.jpg UniF-Julia-Body-Bum.jpg lately ive taken bump/disp/trans maps and combined them into one map to save memory/time/space RGB=BDT :) this is just extra work for convinience later but the renaming part, ensures nothing gets crossed
So you added the P5 runtime TO the P6 runtime? That might be your issue. P6 uses some files for setup from it's runtime that P5 also used, and they may be different. CL and every single person who's replied on the subject that seems to know what they are talking about, says to reference the p5 runtime as an additional runtime, and NOT to merge them together.
Way too many people take way too many things way too seriously.
I think we need a Poser forum sticky, Dr. Geep: Before installing Poser 6, turn OFF antivirus software. Before running poser 6, install the latest driver update for your video card. Do NOT merge older runtimes with the new P6 runtime... just link them as additional runtimes in poser 6 I think each of these has been asked and answered about 4 times a day for the last week. Of course, when I installed Poser6 for the first time, I forgot to turn off my virus software.. LOL! Fortnately, I remebered reading aboutthat here...
Way too many people take way too many things way too seriously.
They do recommend that you keep your texture file names unique. From the readme file: ------------------------- - Texture search: In previous Poser versions, textures were occasionally specified by their file name only. Since in that case the search mechanism has to search with just the name, it will find the first texture with a matching name. Please keep your texture names unique to avoid loading the wrong texture when opening legacy scene files. Poser 6 always stores an application relative path or an absolute path (whichever is appropriate) in the scene file. Also, the Poser 6 Texture Manager always displays the full path of all loaded or previously loaded textures, facilitating to find out from where textures got loaded. -------------------------- Mike
Yes, I read that... and then laughed. As if the content being loaded is completely created or managed by the user at all times. I have gigabytes of content, a very insignificant portion that I created. It would take months to make all of the texture names unique (between texture image file renaming and updating the Poser library files). Again, that's why file systems were developed. And, believe or not, software runs on the OS which manages the file system, to which all file system facilities are available. Nevermind. Maybe the programmer/very long term computer user in me is frustrated by this oddness. ;)
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 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.