Poser Pro 2014 SR4. This has been happening a lot lately (happened under SR3 and earlier as well), and I'm wondering what causes it.

I load a figure. It shows in my hierarchy panel. It appears in the parameter panel. Everything looks normal, except it's simply not visible in the scene (nor is it visible when viewed with the grouping tool active). The geometry has failed to load, I guess.

If I clear my cache and close and reopen Poser, the figure will usually then load as expected. 

Today, however, I'm finding that the figure will load just fine after reopening Poser, but then the next figure or the one after that fails.

I have checked the paths in the CR2. They're all fine. However, the geometries in question are all named some variation of House1.obj, House2.obj, and so on.

Now, I would think that a piece of software was smart enough to know that when a file calls for house1 it means house1, and when the next file calls for house2, it means house2, not house1 that's already been loaded or even bluehouse that's got a path to an entirely different runtime and was loaded in a previous scene. So it shouldn't be confoozled simply by geometry with similar names as long as they're not identical. (I mean, they must have different paths, at least). But that doesn't seem to be the case, entirely.... which makes having a large runtime with lots of house-something.obj's a bit of a problem, as you never know which ones will suddenly trigger this geometry crosstalk.... or whatever it is that's happening.

Has anyone else come across this issue? It's completely stopped me in my tracks. I suppose, if what I THINK is happening is really the cause, I could rename all the obj's to something unique and change the references in the CR2's. But I'd rather not have to. What do you guys think?

Do the group names in the OBJ file exactly match the group names in the CR2 file?

Open both in a text editor.

Search the OBJ file for "g"

Search the CR2 file for "geomHandlerGeom"

group names should be one word, no spaces or colons. 

I have not experienced this with 2014. But I don't load much 3rd party content. Is it happening with the stock content? 

Also, there is an SR5.1 available. So you're actually 2 SR's behind, if you're still on 4. 

Is there a particular reason you're still using SR 4?

Yes, they match. The only thing that looks different from other CR2s that I've looked at is the BODY actor:

actor BODY:2

{

storageOffset 0 0 0

geomHandlerGeom 13 BODY  

}

And BODY does not appear in the obj. But obviously I have no idea whether that should be an issue at all.

I have not experienced this with 2014. But I don't load much 3rd party content. Is it happening with the stock content? 

Also, there is an SR5.1 available. So you're actually 2 SR's behind, if you're still on 4. 

Is there a particular reason you're still using SR 4?

Yes. There had been reports of SR5 mangling obj importation, and that's a critical part of my current workflow. I was waiting until 5.1 had been out just long enough to ascertain that it didn't have any new deal breaking bugs before I installed it. And this issue was workable, until.... today. Edit: Don't know about stock content. Like texture crosstalk, it seems to require a particular set of unlikely variables (identical group name, identical texture map name?? despite being different maps) in two models, which doesn't happen often -- unless you're building a big village full of "houses" with a lot of  what should be different "roof.jpg's" on their should be distinct "roof" groups, if that makes any sense (and if it isn't based on a totally wrong supposition).

Edit again: I'm hoping Phil will tell me it's just something wrong with a particular set of CR2's and that I can fix them and be on my merry way! :)

So anyway, I did some poking around and tried to replicate what I did to cause this to happen -- which wasn't difficult. Retracing my steps, I apparently loaded a scene with a couple of props referencing objs called "house1.obj" and "house2.obj". Then I closed the scene and, in the new one, tried to open a couple of figures (located in a different runtime) which also reference objs called "house1.obj" and "house2.obj." Poser, I assume, then started searching for the objs in the cache, found a couple that seemed to match, and tried to load them. And I got invisible figs. When I emptied my cache and closed and reopened Poser, I am guessing that it began its search in the correct runtime. But then, when I tried to add a couple more houses (by the same vendor, no less), they also referenced objs called, you guessed it, "house1.obj" and "house2.obj". So while the first ones showed up, the second set didn't. And when I tried yet another set, they also.... argggghhhh.... referenced objs with the same names. LOLOLOL. 

To be sure every one of these objs has a different path. But the caching -- I'm guessing -- takes precedence over that. Whether that's a problem with SR4 or just a Poser thing, I don't know. But since it has happened on occasion prior to SR4, I don't think it's unique to that particular service release.

I searched in my runtimes, and it turns out I have nine "house1.obj's" (and that implies an equivalent number of "house2's" cause you wouldn't call it house1 if there were no house2.). I don't want to know how many plain "house.obj's" there are. But I'm thinking all of them need to be renamed with something a bit more.... distinct.

What surprises me is that someone who couldn't decide what shoes to put on a Vicky, for example, hasn't come across a similar problem with "shoes.obj" -- because if my theory is correct, you'd think there'd be an epidemic of invisible figures. So it does make me wonder what other variable is causing this to happen. 

Could be a bug with SR4, I suppose. In which case, an upgrade is in order. But, as I mentioned earlier, a similar thing has been happening with textures... forever... and it's never been fixed, probably because it's actually pretty rare. Hmmm.

1 In the listfiles utility did you check Poser found the right files and not ones with a similar name in another Runtime higher up in your library?

2 Is there a scale issue maybe, with the geometry being scaled huge or tiny and actors relying on some external scale parameter to be represented correctly?

This is why I don't understand the anti-'vanity' folders crowd. It's impossible for a vendor to know what other vendors are naming their files. So if you keep them all in your own folders/directories, names won't get crossed and Poser (shouldn't) get confused, and you should be able to name your files whatever you want, assuming those names make sense. house is a pretty generic term. I don't think I would use that term, but then again, you don't want a file name that is 3 to 5 words long either. But abbreviations would work, and should result in mostly unique names the majority of the time. Combined with keeping them all in the appropriate 'vanity' folder, there shouldn't be problems like this. 

That's my logic anyway. I come from the school of being very precise and keeping naming conventions and files in the exact order and directories they belong in, and using that same method with everything every time. That way it's easy to find and no one gets confused.

@FVerbass -- That's exactly what I do think happened. Poser chose the first files that seemed to match, rather than the ones that actually did match. But surely it shouldn't do that. There are a limited number of nouns for common items -- and some content creators are going to come up with the same names for materials, objs, group names, and so on.

Also, not a scale issue. As I said, after I cleared my cache the first time, the initial set of invisible figures loaded just fine.

Edit: Didn't think of the listfiles script. Brilliant way to check. Thanks for the tip.

@Shane -- Vanity folders didn't help this time. None of the obj's were just sitting in the same folder. They'd have overwritten each other. And they are in vanity folders. Some of them are even in completely different runtimes. Precise names, however, may have been the solution. And I'm with you there. Consistent and precise naming is absolutely essential if you're to be organized (I get it from legal training). But you can't force a standard on content creators, and some are always going to use generic names for things. Poser shouldn't spazz out when they do. LOL.

You're right they would have overwritten each other. well then I'm clueless. I've never had that issue.  I need more liquor. that'll help me understand it. 

If it makes you feel better, I just had to reinstall my intuos drivers cause windows just randomly decided to lose them, so my pen was going backwards on the screen. so yay! on a night of problem-solving for both of us.

...

Frankly, I think it was easier when everything related to a particular model was located in one folder: textures, geometry, and so on. Poser just had to look in that one place. I wonder what the reasoning behind moving these things to separate geometry and texture folders was? Because speeding up the loading doesn't seem to have happened, judging from the number of times I get a non-responding Poser ticking through 400 GB in 23 runtimes searching for some geometry or texture that it loaded just fine half an hour ago.

Edit: I had problems with my Wacom too! Had to install some very old legacy drivers. Latest update was for Vista. LOL. Still worked, thankfully. Yep, I dunno. This whole thing is a mystery. But I like solved mysteries. :D

Edit again: To be fair to Poser, 99 times out of 100, I'll bet the non-responding lengthy search comes from a path error in the file. Just that in this case, paths were all correct. Odd. :)

I wonder what the reasoning behind moving these things to separate geometry and texture folders was?

    I think it has to do with re-usability. Referenced items like texures and geometries typically are restricted from distribution so for supporting content you have to rely on what is installed. if you want to bring your Vicky derivative you should know where the geometry file is located or add an install procedure.

Edit again: To be fair to Poser, 99 times out of 100, I'll bet the non-responding lengthy search comes from a path error in the file. Just that in this case, paths were all correct. Odd. :)

Was that an absolute reference or a relative reference? Were cases of pahnames OK? There is an ambiguity with lowercase and uppercase. DOS and windows systems traditionally were non-case sensitive in path names. Apple and Unix systems AFAIK have always used path names that were case sensitive. Poser working on both Mac and PC has been adhering to the more strict Mac convention. When Windows abandoned the 8 chars max filename length and started to allow spaces etc. in path names life got even more complicated and sometimes confusing. Agree that Poser does surprisingly well in most cases but can sometimes cause other surprises.

@FVerbass --- Ahhhh. Interesting.

What you say about distribution makes sense.

There are indeed spaces in the geometry folder path names for 6 of the objs that troubled me in this specific instance. I didn't think this would be an issue, as even the content distributed with Poser sometimes has spaces in the geometry/texture folder names. Of course, just because partners do it, that doesn't mean it's always going to handled smoothly, I guess. 

Unix is indeed case sensitive -- at least I recall from working with software that ran in a Unix emulator that commands were case sensitive. No idea about Apple. I think most of the time Poser glides right over case ambiguity. I can't say I've paid any attention to it. I will in future. :) 

Thank you

The BODY does not contain any geometry so those lines should be:-

actor BODY:2

{

}

The index number may vary but must be consistent within the file.

Thank you, Phil!

I wondered why every other CR2 I saw didn't have them. If they're not needed, I'll take them out. :)

If you have a generic or duplicate name for a Geometry or Texture then Poser will sometimes find the wrong one even if your paths are correct. This is a long standing bug, that may, or may not have been addressed in the latest version of Poser, but definitely still existed in Poser 2012 SR3. 

I will also point out the fault in putting the Geometry or textures in the same folder as the file referencing them by giving you an example. Open the Poser 6 Jessie cr2 in a text editor (from any version of Poser after 6) and compare the paths in the file to where the files actually reside. Oops. That is one example as to why it is a bad practice. It is also not in keeping with the Poser published standard on how to do things. (From the Poser manual itself.) The one saving grace is that when Poser can't find a referenced file it will, usually, look first in the folder that you loaded the CR2/PP2/etc. file from before looking where it is supposed to look (Runtime:Geometries for example.) 

So please put things where they belong and, if it is a referenced file, name it something unique. :) It will serve you better and remove headaches that are easily avoided. 

"When Poser can't find a referenced file it will, usually, look first in the folder that you loaded the CRS/PP2/etc. file from before looking where it is supposed to look..."

I thought that was the case, which is why I wondered why we put assets in other folders, when our software looks in the folder with the Poser file first?

I'm not sure what you're getting at with the Jessie CR2. "figureResFile :Runtime:Libraries:character:Jessi:Jessi.obj" What's wrong with that? To be sure, most of that path is or should be totally unnecessary. It seems to me, that if your geometry and CR2 are in the same folder, you should be able to write "FigureResFile:Jessi.obj." and have it work no matter where that folder is located. (And suddenly all those incorrect path issues and absolute paths to vendors documents folders just vanishes. Poof! Problems gone!)

The advantage of having everything in one folder would be that it would be easy to uninstall content -- just delete the folder -- or to move it to another runtime. As it is, you have to chase down files that may or may not be in a whole variety of different folders, including misspellings of "geometries" and "textures" and the long list of vanity "morphs" folders you end up with in the first level of your runtime hierarchy. And explaining the runtime folder structure to newbies is a pain. If were simple, as in "put your figs here, your props here, your hair here", we could save a lot of time that is currently spent giving people tutorials on how to install stuff.

I mean, if someone has written an incorrect path in a CR2 or PP2, then they've written an incorrect path. Poser is going to hiccup whether the asset files are in their "proper" folders or are in the folder with the CR2/PP2 itself... Except -- as you point out -- if they're in with the CR2/PP2, Poser will be able to find them. I'm becoming less convinced that ditching the geometry and texture folders altogether is a bad idea. But I am willing to listen. If there are good reasons to keep the assets separate other than, that's how the manual says it should be, then I'd like to know.

Edit: I'd like to know because, when I use freebies from places like Turbosquid, etc (or when I purchase models in OBJ form) and import them and then convert them to props, I can't be bothered to create a bunch of new folders. So I just put everything for one model together in one folder. If there's something inherently wrong with that, I would like to know. :)

(Btw, I don't make or release content, so I don't care whether there's a standard in the Poser manual that most creators are only half using. I'm concerned with what's most convenient to me as the end user of the Poser software.)

Just a note: I've seen this happen when Poser gets confused and thinks an object doesn't have any material zones. The object will load, its geometry will load, but because there are no materials present and, for some reason, Poser has allowed that to happen, the object will not be rendered in the Preview or Render pane - There are no materials to render.

This has happened to me when either Poser borks up for whatever unknown reason that "borkup_code_764" was loaded for or Poser has to scramble for memory and has decided, arbitrarily, to ditch references for fussy things, like material zones. (Typically, in the latter case, everything goes black, first. Then, things start to "disappear", usually whatever information I forgot to save. :) )

Given what Poser has to deal with, sometimes, this is, admittedly, a rare thing and not reliably reproducible. On imports, I see it most when I've been fussing with an object and cause the problem, myself, using external software.

As detailed above, the most common cause is a CR2 (or other similar file format) loading with geometry reference errors.

LOL. Yeah. Poser does do some odd things when it get low on memory. Hell, I do odd things when I get low on memory. In my experience, most errors of this nature are, by themselves, pretty rare.

In the case of the missing figures, though, I'm not sure there's any geometry reference error, per se. Unless the reference to geometry in the BODY in the CR2 is causing problems, there's nothing wrong with any of the figures that didn't load.

I guess when you're loading a Vicky or two, plus clothes, and some props, the likelihood of repetition in geometry or material names is quite small because most of the assets are different in nature. But when you're loading several villages with 50 different houses (made by dozens of different vendors), the likelihood of repetition in geometry and/or material names is quite high. So high, in fact, that it's reached 100%. :D :D I'd gotten used to the houses inadvertently wearing each other's textures. But the geometry thing was new to me.

So it turns out that this is a known and old bug.

I was just reading through the documents that came with a Netherworks script I picked up some time ago. It mentions this precise issue, and the utility (Creator's Toybox) has a function for setting unique obj names to fix it. Hah. Netherworks solves problems before I even know I have them! What a guy!

(The same script has also been updated to make some changes to DSON imported figures which converts them to native figures. Works like a dream. While Genesis 2 figures can be exported from DS with a Gen4 UV -- if you have the product needed to give them that UV --, the material names are different, so MC6's and MATposes don't work. But the materials do. I also note that the HD morphs do work -- if you change the subdivision type and then increase it to 2 or 3 for final render. Sweet! It was a really nice holiday surprise for me. :)) Happy January 2!

I was just reading through the documents that came with a Netherworks script I picked up some time ago. It mentions this precise issue, and the utility (Creator's Toybox) has a function for setting unique obj names to fix it. Hah. Netherworks solves problems before I even know I have them! What a guy!

Ah, interesting. I love useful scripts and Netherworks makes some great ones! I might have to go pick this one up. :)

I was just reading through the documents that came with a Netherworks script I picked up some time ago. It mentions this precise issue, and the utility (Creator's Toybox) has a function for setting unique obj names to fix it. Hah. Netherworks solves problems before I even know I have them! What a guy!

Ah, interesting. I love useful scripts and Netherworks makes some great ones! I might have to go pick this one up. :)

Take a look before the sale ends on January 5. Most are at least 50% off. I just discovered Netherworks a few months ago (despite using those of his scripts that come with the default install of Poser). Can't believe I didn't pick up some of these the moment they were released. :)