trouble with texture file cache



  • Does anyone have any experience with forcing a texture reload via Python?


  • Poser Ambassadors

    mat.ShaderTree().UpdatePreview()



  • @shvrdavid really? Isn't that just forcing the UI to reflect what's been changed in materials?

    From the poser.AppLocation()/Runtime/ui folder, the PoserMac.xrc (or Poser.xrc file on Windows, IIRC) shows "Reload Textures" to have a command ID of 1559, so

    poser.ProcessCommand(1559)
    

    would probably do exactly what @F_Verbaas wants.



  • @shvrdavid I don't like the tone my first response may have conveyed, and it's too late to edit. I had intended to express surprise at an unexpected consequence of an UpdatePreview() call, and actually went and looked up the manual (which makes no mention of the texture cache) between my first two paragraphs. Your answer is correct for forcing the texture preview and UI to reflect python changes to materials except when cached texture changes need to be forced through, AFAICT.


  • Poser Ambassadors

    No worries. I guess you could write the code to empty the cache as well. Then it would have to redo that as well.



  • For my needs (and I think that's what F_Verbaas was asking for too) it would suffice if a script would only reload a single texture of the currently selected materials...

    You know it:
    You have a large scene. You just change a single texture file in image editing and want to see how it looks.
    Just this darn single texture!

    Instead Poser reloads the whole texture cache: every bloody single texture file of every prop and figure in the scene!

    Depending on the complexity of your scene this can take long enough to have a tea while waiting (or several, if you make incrementing changes).
    Now if a Python script could tell Poser "reload this single texture!", that would be it!

    Just dreaming! ;o)
    Karina



  • @karina just think of it as exercising the system for memory leaks ;-) Unless you've turned off auto-save or forgotten to save explicitly before you execute that one last change, go off to have tea while you wait for the spinning cursor or tapping foot, only to come back and find that Poser has successfully leaked all of its memory and left you a nice, steaming core dump on your desktop. D-X



  • Grunt! Yes, that's all I need for a perfect day...
    B.t.w., did you notice that I accidentally invented a new smiley? Look at the "just dreaming" line in my previous post:
    ... a twinkling, smiling Hitler...
    ! ;o)

    Blimey!



  • Thanks all.
    Just to explain:
    I am making a 5 button 'bridge' between Marvelous Designer and Poser.
    The process-in-a-nutshell:
    P1 - In Poser press button 1 in Poser to start MD with the special interface functionality.
    P2 - In Poser press button 2 to load figure mannequin into Poser and make it available to MD as 'avatar' (MD lingo for a figure)
    M1 - In MD press button to load avatar in A or T pose (garment models are stored in any of these 2 poses)
    In MD drape/load garment around the avatar, or do whatever it is that MD users do when they use MD,.
    M2 - In MD press button to morph avatar to the shape Poser specified.
    M3 - In MD press button to make garment available to Poser
    P3 - Press button to load posed garment into scene.
    In Poser render or do with it whatever Poser users do when they use Poser.
    During a session you can repeat P2, P3, M1, M2, M3 in any sequence that makes sense. M3 morphs the avatar between A, T, and posed. For example, if you find the jacket model you have available is a size S and you loaded an avatar size XL, put your figure in Poser on a crash diet and do P2 again, or do a slash-and-merge in MD to grade it to XL.

    I tried to keep the process lean and mean by using standard file names. The garment object that MD exports is named forPoser.obj, the texture file MD exports with the garment is always named 'forPoser.png'. New export from MD will over-write files previously written. New import .obj into scene will over-write old one, unless you decide, in Poser, to rename it (button P4).
    Problem there is now is that Poser, when loading a new definiton exported from MD, does not realize the texture file forPoser.png is not the one in the cache and shows the new garment .obj with the texture loaded before.
    A full 'reload textures' takes ages to complete, indeed, as Karina says, I need to tell Poser to 'reload this single texture'.
    I make do now by producing an .mt6 file and reloading it.
    I did try the processCommand(1559). Not sure what I did wrong there, but results were pretty dramatic.
    I will try the mat.ShaderTree().UpdatePreview() route. It sounds promising.

    The MDBridge software: to appear soon here on this stage.



  • @shvrdavid
    Now that you mention it:
    import os, shutil
    cache = os.path.join(poser.PrefsLocation(), 'PoserTextureCache')
    shutil.rmtree(cache)
    os.mkdir(cache)

    would do the trick I think.
    Not sure if Poser will like that, though. It would probably ruin some indexes.



  • @f_verbaas if that were effective, surely it could also work with a single image purged from the texture cache?



  • @f_verbaas I don't see anything called 'PoserTextureCache' in the Poser Prefs location on macOS, which is typically ~/Library/Application Support/Poser Pro/11/, or Poser, if one doesn't have the Pro version. There's a RenderCache folder in there, with all the exr and tmp files from full and partial renders.

    Aha! The PoserTextureCache folder lives in poser.TempLocation() on macOS, not poser.PrefsLocation().

    Everything in there appears to have a .exr extension tacked onto the original filename, whether it be a .jpg, .png, .tif or .bmp, etc.



  • Yes thought about that.
    As said I am not sure what the results are for Poser so I better not go down that route.
    The mat.ShaderTree().UpdatePreview() method had no avail.
    I think I will stick with a simple method: rename the texture files and modify the .mtl file before loading the .obj.