Hi all, can anyone tell me why sometimes and only sometimes, when i make a conforming article of clothing that all works fine in the Pro pack, but with the .obj in the correct place, Poser 4.03 tells me it can't load it and gives me the "Out of memory" message. I know the memory message is irevalant, the obj is the exact same file, same name in the same place in the Geometries folder. This happens about one in five items. thanks in advance... Colm...

Whenever I've seen this problem, it's been because the path to the .obj file (as specified in the .cr2 file) for an object is incorrect. Why you would see it work with the Pro Pack, and not Poser 4.03, I don't know; I'd think you would see the problem in both cases, unless PPP parses filenames differently. Bottom line is, look at the appropriate .cr2 file. Hope this helps!

As i stated in the above. The obj is in the correct location. The location that is specified in the cr2 and the same location that the error reads.

Also I can add that if you have a geomitry swap it wont swap to the new geomitry , but the lines leading to the object file are correct

Hi Colm, I've been whatching your struggle with this problem. And I haven't jumped in because I don't have any idea why this is happening. I was kind of hoping someone else knew the answer. But it looks like it's a tough one. At this point. All I can say is if you can zip up and e-mail me one of those clothing items (.obj&.cr2) that gives you that problem with 4.03. I'll see if I can find out what's going on. The things I do when trouble shooting are: 1.) re-make the phi file and convert the mesh to conformer again to see if it does the same thing. 2.) take the clothing apart. Part by part and create a new conforming garment minus each piece to see if there is a certain body part that is giving Poser 4.03 problems. Yes...It's time consuming ;-) One other thing. I'm not a big fan of using existing .cr2's on new clothing items. I know it's easier for some people to do that. But there are a lot of lines in cr2's dedicated specifically to it's original .obj and texture files. And It's very, very easy to leave in information that can conflict with your new item. Creating .cr2's from scratch is the only method I recommend. ScottA scottasba@aol.com

One other thing....There very well could be a backward compatability issue going on here. And nothing we do can fix it. But it's odd that not many people are complaining about it. JKeller found a bug with the PPP that nobody else seemed to see. And it was a big one. The Spherical JP's on one side of the figures wouldn't show up! Yet nobody complained or saw it for a long time. ScottA

Funnt the mapping doesnt make any difference in ppp though strange that?

Allright what about the alternate geomitry problem? hehe

Thanks scott, thanks Chrome...:)

I had this same problem....Looked at the path in the CR2s, and it matched, including case. It was driving me nuts. Just for grins, I moved the .obj to a core folder (installed with poser) and renamed it to 8 characters, updated the cr2, and it worked. It seems to be a path issue, but it's odd as some will work while others wont.

It may not be your problem, but I've found (I think...) that the Mac requires the initial colon (:runtime:geometries:...), whereas the PC doesn't.

Is this possibly related to the geometry .rsr file? Colm, has it created an .rsr for the .obj when you first tried loading it, and if so have you tried deleting the .rsr? I've been making a few custom conforming figures lately that I've tested extensively in P4 and PP and haven't run across this bug. Hope this helps. Oh and FYI, Scott, when I reported the Spherical fall-off zone bug to CL it turned out they already knew about it and were testing the fix for it in SR2 at that time. That bug was introduced with SR1 and fixed with SR2.

JKeller jut fyi it wasnt getting as far as creating an rsr file so that wasnt the cause ,by process of elemination I found the fault that was effecting colm and I was something to do with the mapping as after I remapped the effcted objects the effect whent away strange?? the objects where allready mapped and worked fine in ppp so bit of a ponderer that also it only effected about 15% of the objects even stranger :-)

Hmmm... very strange. In that case it seems that in the initial mapping, something was created that P4 didn't like but PP had no problem with. Was UVMapper used for the initial mapping or another program?