Weird problem recurring now solved after 4 years



  • Ever since I made my first Project E figure (which was a hybrid of my own mesh and V4's head) I had a super weird problem where I could only load up PE when SreeD was active. In OpenGL it would just crash with exceptions like SkinBlaBaseBlablax64.dll something or another, and StackHash_1e37. I learned to live with this for 3 years (as a true Poser user) by always starting Poser up in SreeD, and then switching to OpenGL. I reported it but we never solved the problem.

    Then in 2016 I made a new Comic figure based on the store version of Project E (which is coming soon btw) and that didn't have the problem, but then suddenly two days ago it came back. I tried it in PP11 and there was no difference.

    So I thought: to hell with this, and started debugging. I didn't feel like loosing yet another 4 days of work because Poser cannot handle exceptions like most software can. After 5 hours of debugging and comparing versions, I narrowed it down to the CR2 code. The PMD seemed ok because I could load an older figure referencing the new PMD.

    So I ran the last stable CR2 alongside the unstable one in Notepad++ and compared all the 40,000 lines of the code bit by bit (using compare tool). Then after two hours at the very end I discovered two odd nodes called: boneIndexMap and SkinWeights, and both has huge lists of numbers. The stable CR2 didn't have this. Then I whipped up my old PEV4 version and indeed, it had the same two nodes. I deleted them and suddenly both figures worked perfectly fine. Finally after four years I solved my problem... just two stupid blocks of meaningless code.

    So, does anyone know what boneIndexMap and SkinWeights are??? I did nothing unusual, just make morphs, delete morphs, program parameters, etc etc... Could it perhaps have something to do with the fitting room? That if a character gets used as a template, that it gets stuff added to its CR2 code?


  • Poser Ambassadors

    They are related to weightmapping for the figure. Aside from that I know little more.



  • @kageryu I have a hunch it might have to do with saving a figure that was used for the fitting room. The figure that got the extra nodes was indeed used for the fitting room and was thereafter saved to the library. This could be tested.


  • Poser Ambassadors

    Rex and Roxie don't have those lines.
    Paul and Pauline both have those lines.

    Basically, what you say is that if you save a figure AFTER using it in the fitting room?
    That both the new clothing and the figure get those lines when saved?

    To test.



  • @vilters yeah dunno. It was just a thought. Try if you want. I'm just happy I solved the issue, it was really annoying.


  • Poser Ambassadors

    @erogenesis
    Loaded Tanya ( a weightmapped figure)
    File import => Clothing object file
    Ran Fitting room for clothing to Tanya.
    Conformed new clothing to Tanya.
    Saved as Tanya2 to library => Individual, only the figure.

    => Result => No extra lines in Tanya2.cr2
    Sorry, don't know where those extra line come from, but from this test? Not from a Fitting room session.



  • @vilters hmm, weird! Ah well... cheers anyhow!


  • Poser Ambassadors

    @erogenesis
    Weird indeed.

    Paul and Pauline have the lines, but they work normally... Very weird.
    PS : Scotts Pauline improvement cr2 also has those extra lines, and she works too.



  • @vilters said in Weird problem recurring now solved after 4 years:

    @erogenesis
    Weird indeed.

    Paul and Pauline have the lines, but they work normally... Very weird.
    PS : Scotts Pauline improvement cr2 also has those extra lines, and she works too.

    I do have to say that I did see some odd single-lined entries in the weightmap sections of the codes, but they were so extensive that it would be impossible to single out. But since I deleted those two lines, no crash yet.


  • Poser Ambassadors

    @erogenesis

    More weird stuff. Maisie works and she also has those extra lines....

    My Tanya has seen the Fitting room at least a 1.000 times ( if not many more) as it is my standard testing figure, and she does not have the lines; So we can exclude the Fitting room "as probable cause".

    Tested 4 times now, with a grouped, an ungrouped, a fitted and a non fitted clothing.



  • @vilters the boneIndexMap in my unstable version does include a reference to a dummy prop that gets saved along with my comic figure, so maybe since its not strictly speaking a bone with joint relationships, poser gets discombobulated. If I have time this weekend I'll also play around a bit because it does sound weird that some figures do work with these two nodes and mine doesn't.


  • Poser Ambassadors

    @erogenesis
    can those 2 lines be related to the Control handles?

    Paul, Pauline + Scotts improved Pauline, and Maisie (so far all figures with control handles) seem to have those 2 extra lines.

    So check if your control handles still work as created? Just a wild guess after your prop remark.



  • @vilters na everything works fine as far as I can tell. I'll be back in a bit, just having dinner


  • Poser Ambassadors

    @erogenesis
    Nope, not the control handles. I created a few, but sorry Ero, No extra lines. LOL.



  • My short and limited research indicates SkinWeights are from Maya.



  • Maya? Hm. They were modeled in Max but all the rigging is purely Poser. But I think we can safely assume that the name 'SkinWeights' might be a word that gets used often.

    Its weird though because they don't really carry much information with them. Its like the boneIndexMap is supposed to denote some order. Why would that need separate specification? Maybe an addon to deal with the setup room's hap-hazard ordering of the bones?



  • The Figure system can be changed inside Poser Pro 11, if I am not mistaken - some thing like Poser Traditional as against Weighted mesh or something.



  • @ibr_remote ohh, that could be it. But I don't actually remember touching that, unless it can be invoked another way?



  • @erogenesis I think can be involved via python but that would require special coding. I don't know enough, sorry.



  • @ibr_remote Oh I killed it off using PFE (great app btw), but I'm just wondering how it got there. But yes, maybe a python routine. I still suspect Fitting Room somehow but vilters more-or-less ruled that out.