Refresh Images (CTRL-i) ignored by Iray

Hey guys. I'm having this problem and it's pretty annoying. Essentially it means I have to restart Daz Studio if I want Iray to pick up an updated texture. Is there a render cache or something or why is this happening?

Comments

  • macleanmaclean Posts: 2,438

    This is an old bug. I reported it months ago and it was confirmed by the Dev team. I *think* they said it was fixed, but I don't know in which version. I'm using a 4.9.2 beta and it's still an issue.

    Btw, for anyone who thinks they don't get this bug, it's not quite as simple as it seems. The texture refresh seems to work most of the time in the viewport - but when you do a render, Iray uses the old texture.

  • bluejauntebluejaunte Posts: 1,861
    edited July 2016

    Yeah texture refresh in viewport works every time for me actually. I found a way to at least work around it. Set Iray to 'Interactive' and use the viewport Iray. Enable 'Automatically Refresh Images'  in that Surface tab context menu. Now after modifying the texture (I use the PSD directly while tweaking to save more time), all I have to do is switch away from 'NVIDIA Iray' to something else like 'Texture Shaded' and back again in the viewport drop down. Now the texture is updated.

    Edit: After more testing, the PSD bit is actually what makes this work.

    Post edited by bluejaunte on
  • macleanmaclean Posts: 2,438

    Interesting. I reported it for ,jpgs, although I did mention it wasn't working with .psds either.

  • Here we are in 2018 and the problem still persists.
    Not only, that, there is also still no cache control or options for Iray.

    Does anybody have a workaround?

  • InkuboInkubo Posts: 744

    When I'm altering texture images on a model, I create a WIP scene with just the one model so I can save, click the New button to wipe out everything, then Open Recent to reload my scene and see the changes. It's annoying that reloading images doesn't work, and of course the bug should be fixed, but because reload times are quick when the scene is very spare, the save/new/reload cycle doesn't seem too onerous as a workaround.

  • TheKDTheKD Posts: 2,676

    Yeah, I noticed that. I was tweaking a texture, it looked tweaked in viewport, but in render it was the old one. The only way to workaround it that worked was saving iterative(image01 image02 etc), then plugging in the new iteration each new test render.

  • Inkubo said:

    When I'm altering texture images on a model, I create a WIP scene with just the one model so I can save, click the New button to wipe out everything, then Open Recent to reload my scene and see the changes. It's annoying that reloading images doesn't work, and of course the bug should be fixed, but because reload times are quick when the scene is very spare, the save/new/reload cycle doesn't seem too onerous as a workaround.

    What I do instead is to save and directly re-open my current file. Cuts down on interaction overhead, I prefer longer load times to having to go back and forth (and still having to load the full scene when I want to see the changes in the actual scene).
    But even when using an interim temp file, you can skip the "New" thing, too - no need to explicitly clear the scene, DAZ does that implicitly when opening a file. (At least for me, DS 4.10 on Win 10 x64)

    TheKD said:

    Yeah, I noticed that. I was tweaking a texture, it looked tweaked in viewport, but in render it was the old one. The only way to workaround it that worked was saving iterative(image01 image02 etc), then plugging in the new iteration each new test render.

    Yes, that's probably the most practical work-around.
    However, I like the idea of just having to overwrite a texture map once, in order to have it take effect in all its usages (say, a specular texture is also used in top coat, etc - let alone across different instances (surfaces, whole models...) - that it still reeeeally bugs me, and usually instead of tracking down all the instances of a file being used, I tend to save, reload, do something else while the scene loads, and come back.

    Maybe the whole attitude adjustment of making use of the time otherwise lost waiting I'm currently trying to force myself through is useful for other disgruntled users as well...

    In the meantime, I'm waiting to see what Helpdesk staff are going to say. It seems I can't link to my ticket, but I'll try to keep this up to date

  • InkuboInkubo Posts: 744
    svArtist said:
    ...you can skip the "New" thing, too - no need to explicitly clear the scene, DAZ does that implicitly when opening a file. (At least for me, DS 4.10 on Win 10 x64)

    Sometimes I'm overly cautious! I'll try it your way next time :-)

  • Inkubo said:

    Sometimes I'm overly cautious! I'll try it your way next time :-)

    Better safe than sorry!
    It may be possible there are disadvantages (I've only started playing around in DAZ again and my scenes aren't too involved) - save conservatively. Should you in fact discover any issues, please let us know :)

  • Apparently, Help Desk weren't quite as aware of this as I thought.
    Here's the last exchange, please let me know if you have some useful additional info (Sure fire way to reproduce, different behavior, etc) - and I'll forward it in the ticket.

    In the mean while: Another work-around is, of course, to use the LIE (Layered Image Editor) to trigger an update. It's not ideal, but faster than reloading the scene :)
     

    • Emma H Wednesday at 17:28
      Hi Ben,

      I apologize, I did test this quite a  bit and can not reproduce this issue. Please send me a video (starting at the load of your figures in to the scene), so that I can see exactly how you are able to produce this error.

      Thank you,
      Emmalee
    • Avatar
      Ben Philipp Today at 05:42

      Oh, pardon me - I thought this was a somewhat documented thing.
      Here I tried to document the behavior in different situations: https://www.youtube.com/watch?v=xwzAZe_hiOo

      To note: I can't find a step-by-step way of reproducing the behavior, but it seems it happens when I'm using a lot of RAM (I loaded a bunch of things so 12 out of 16 GB of physical memory were used in this video).
      I think maybe Iray prefers a private cache when resources are scarce, and only a change in a texture's reference will trigger an update - when the file name stays the same, it'll keep using the cached one.

      GPU in use: NVIDIA GeForce GTX 1060 6GB

    • Avatar
      Ben Philipp Today at 05:43

      Oh, and: Even after switching to some other texture, the old outdated texture will still be used for the original file when switching back to it.

     

  • svArtistsvArtist Posts: 19
    edited January 2018

    Umh... guys?
    I'm not 100% sure, but upon testing it a couple of times, it seems the issue (at least for me) can be avoided by making sure no render windows are open when the images are refreshed / the new render starts.
    (See ticket excerpt below)

    Can you confirm/disconfirm?

    ___

    • Emma H Yesterday at 23:08

      Hi Ben,

      Thank you for sending over this video. When you are rendering in Iray, it appears that you did quit out of the render, however, the partially rendered images were never closed. (I can see that these were not closed in the bottom left corner of the video.) If you close out of these so that no render windows are open when you attempt to render with an updated textures, do you still experience this error?

      Emmalee

    • Avatar

      Ben Philipp Today at 06:10

      Son of a gun!
      Indeed, I just tried it a couple of times and making sure no render windows are open upon refresh/re-render does seem to help!

      That being said: I would still regard this behavior as a "bug" (well, undesired).
      Also, I almost can't believe that every time this happened, I had a render window open (I'm just not sure, it seems so unlikely)

      Can this still be addressed in an update?

      Thank you so much for your help thus far anyway :)


     

    Post edited by svArtist on
  • Cris PalominoCris Palomino Posts: 11,151

    If the render window is open, the resources used to produce the render must remain unchanged so that the render can be resumed... otherwise, the "current" state of the render is no longer congruent with the resources used to produce it and the render must be restarted. Changing resources at any point between start and finish violates the very concept of "resume." Closing the render window serves as an indication to the application that the render is finished (will not, cannot, be resumed), and therefore the resources can be refreshed.

  • If the render window is open, the resources used to produce the render must remain unchanged so that the render can be resumed... otherwise, the "current" state of the render is no longer congruent with the resources used to produce it and the render must be restarted. Changing resources at any point between start and finish violates the very concept of "resume." Closing the render window serves as an indication to the application that the render is finished (will not, cannot, be resumed), and therefore the resources can be refreshed.

    Oh, that makes sense. I didn't think about the "resume" function. When I hit "Cancel", I usually mean it - I wish there was a distinction between cancel and pause (So we could simply leave the half rendered windows open and compare them directly, without saving them to disk first)

    But thank you for clearing that up!

Sign In or Register to comment.