Loading...
> >

LIE causes tdlmake to run forever and fill temp storage disc

barbultbarbult Posts: 23,932
edited December 1969 in The Commons

I am running the latest 4.6.2.118 DAZ Studio on Windows 7 64 bit.

I discovered that when I use the Layered Image Editor (LIE), tdlmake is spawned over and over, reprocessing the same LIE tif file again and again. Each time tdlmake runs, it creates a new file in the temp folder. This keeps happening, even during the image render and even after the render finishes!

I first discovered this problem while using the Image Overlay product to add freckles to a Victoria 5. It doesn't seem to matter what model I use or what image is used in the LIE layer. I tried a simple primitive cube with a simple texture and one LIE layer, and the same problem occurs.

The image renders and looks fine. If I hadn't been monitoring processes, I may not have noticed this. I sometimes leave long renders running unattended overnight. The fact that tdlmake keeps generating these files even after the render finishes, makes me worry that it could have completely filled the disc. I imagine it is slowing the render down, too, since it is running the whole time and using some of the CPU.

Here is an excerpt from the log file in a test where I used the Victory Lane Board as my prop and added the Victory Lane Ground as an LIE layer. (The problem is not restricted to these props or textures, this is just one of many tests I tried.)
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Ran tdlmake on image E:/DAZ3D temp/d4.tif
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg
Loaded image add_board_simple_tx.jpg
Loaded image VictoryLaneGround.jpg

So I'm wondering if this is a DAZ Studio bug or if it is unique to my configuration.

«134

Comments

  • WendyLuvsCatzWendyLuvsCatz Posts: 38,053
    edited December 1969

    I know at least one person who already has submitted a bug report on this
    as I never render in studio have not experienced it as I only use LIE to create composite textures I then save from the Daz temp folder to.another place before deleting and reloading in map channels.
    I HAVE to do this to use LIE with carrara and iClone my software renderers of choice.
    just sharing as it might prove a useful temporary workaround until they fix it.

  • barbultbarbult Posts: 23,932
    edited March 2014

    Thank you Wendy. I'll file a help request then, too, to see what DAZ can tell me about the problem. How do you save the LIE file? Do you just make a copy of the TIF file that gets created in the temp storage, or is it some other file in the temp area that you save?

    Post edited by barbult on
  • WendyLuvsCatzWendyLuvsCatz Posts: 38,053
    edited December 1969

    yes
    I go to Daz temp in Daz 3D my dicuments and save them usually as png in the original texture folder under a new name then load them from there and save as a character preset so I can load the .duf in carrara.
    throw the stack undo script by AdamR in to the studio window also before saving for good measure

  • mjc1016mjc1016 Posts: 15,001
    edited March 2014

    It's not LIE, really, it's the file that tdlmake is trying to convert. Usually, it's either a tif in a form that it doesn't understand/compression scheme it doesn't like or the file is corrupted. Tdlmake is rather finicky...especially when dealing with tif files. It only likes a subset of all the possible flavors that tifs come in...

    One way around it is to manually run tdlmake on the files...and either set them as tif OR use png or jpg.

    Another possible cause...mismatched layers in LIE...if they aren't the same size, tdlmake can have trouble generating the mipmaps. LIE should present it as a single image to tdlmake...but for some reason when the layers aren't the same size it seems to mess up what resolution it should be.

    A third possible reason...it just doesn't like the image.

    And, the temp file should clear when DS is closed.

    Post edited by mjc1016 on
  • SimonJMSimonJM Posts: 5,970
    edited December 1969

    I had this, suddenly, with what looked to be the same two images being repeatedly re-created (as files with new names) - both during a render but also when the scene was loaded. It was for two mat zones, both of which had LIE 'elements' added.
    Luckily I recalled that SickleYields had posted a 'solution of sorts' on the RuntimeDNA forums (under the DAZ/Reality section) and provides a freebie that swaps in and out a dummt tdlmake program. That worked enough for me to get round the problem.

  • barbultbarbult Posts: 23,932
    edited December 1969

    wendy♥catz said:
    yes
    I go to Daz temp in Daz 3D my dicuments and save them usually as png in the original texture folder under a new name then load them from there and save as a character preset so I can load the .duf in carrara.
    throw the stack undo script by AdamR in to the studio window also before saving for good measure

    Wendy, your method is working for me. Thank you for the suggestion.
  • barbultbarbult Posts: 23,932
    edited December 1969

    mjc1016 said:
    It's not LIE, really, it's the file that tdlmake is trying to convert. Usually, it's either a tif in a form that it doesn't understand/compression scheme it doesn't like or the file is corrupted. Tdlmake is rather finicky...especially when dealing with tif files. It only likes a subset of all the possible flavors that tifs come in....
    mjc1016, thank you for your response. Since LIE made these TIF files, if it made incorrect ones, it still seems like a bug in LIE that needs to be fixed.

    One way around it is to manually run tdlmake on the files...and either set them as tif OR use png or jpg.
    I'm certainly willing to try this. Can you point me to any instructions for where to find tdlmake and how to run it manually? I didn't know that was a possibility until you mentioned it. That might be easier than Wendy's method (which is working for me in the mean time).


    Another possible cause...mismatched layers in LIE...if they aren't the same size, tdlmake can have trouble generating the mipmaps. LIE should present it as a single image to tdlmake...but for some reason when the layers aren't the same size it seems to mess up what resolution it should be. A third possible reason...it just doesn't like the image. And, the temp file should clear when DS is closed.
    Yes, the temp files are cleared when DS is closed.
  • barbultbarbult Posts: 23,932
    edited December 1969

    SimonJM said:
    I had this, suddenly, with what looked to be the same two images being repeatedly re-created (as files with new names) - both during a render but also when the scene was loaded. It was for two mat zones, both of which had LIE 'elements' added.
    Luckily I recalled that SickleYields had posted a 'solution of sorts' on the RuntimeDNA forums (under the DAZ/Reality section) and provides a freebie that swaps in and out a dummt tdlmake program. That worked enough for me to get round the problem.

    SimonJM, I searched the RuntimeDNA forums and found a message from a user named callad. It was aimed at Luxrender/REALITY users. It said that when the dummy tdlmake was active, you couldn't render with 3delight. But then there was a bunch of discussion about scripts and executables that I confess I didn't understand. Is that the message that you remember, of was there something from SickleYield that I didn't find?
  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    barbult said:

    mjc1016, thank you for your response. Since LIE made these TIF files, if it made incorrect ones, it still seems like a bug in LIE that needs to be fixed.

    Open a command prompt and run

    tdlmake (input image) (output image) (can also use the tdl extension).

    Wendy's way is a pretty good way to do it, too.

  • RuphussRuphuss Posts: 2,631
    edited December 1969

    same problem with skin overlay
    ticket sent already

  • SimonJMSimonJM Posts: 5,970
    edited December 1969

    barbult said:
    SimonJM said:
    I had this, suddenly, with what looked to be the same two images being repeatedly re-created (as files with new names) - both during a render but also when the scene was loaded. It was for two mat zones, both of which had LIE 'elements' added.
    Luckily I recalled that SickleYields had posted a 'solution of sorts' on the RuntimeDNA forums (under the DAZ/Reality section) and provides a freebie that swaps in and out a dummt tdlmake program. That worked enough for me to get round the problem.

    SimonJM, I searched the RuntimeDNA forums and found a message from a user named callad. It was aimed at Luxrender/REALITY users. It said that when the dummy tdlmake was active, you couldn't render with 3delight. But then there was a bunch of discussion about scripts and executables that I confess I didn't understand. Is that the message that you remember, of was there something from SickleYield that I didn't find?

    Gah, I meant Callad - sorry!

    It allowed me to laod the scene with the 'affected' materials and get to the surfaces tab and replace them and rebuild them - which then went on to work correctly. before it was swallowing all my CPU in running the tdlmakes and the interface was pretty much non-responsive. The instructions on installing and using were ok for me: in effect you are supplied a couple of BAT/cmd files and the files for DS to get them to be run, plus a dummy tdlmake executable. Thus you can turn off and on the use of the dummy tdlmake. With the dummy tdlmake 'active' you will not be able to get 3Delight to render, but as it was written with Reality/LuxRender uses in mind that was not too much of an issue.

  • JaderailJaderail Posts: 0
    edited December 1969

    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

  • barbultbarbult Posts: 23,932
    edited December 1969

    SimonJM said:
    barbult said:
    SimonJM said:
    I had this, suddenly, with what looked to be the same two images being repeatedly re-created (as files with new names) - both during a render but also when the scene was loaded. It was for two mat zones, both of which had LIE 'elements' added.
    Luckily I recalled that SickleYields had posted a 'solution of sorts' on the RuntimeDNA forums (under the DAZ/Reality section) and provides a freebie that swaps in and out a dummt tdlmake program. That worked enough for me to get round the problem.

    SimonJM, I searched the RuntimeDNA forums and found a message from a user named callad. It was aimed at Luxrender/REALITY users. It said that when the dummy tdlmake was active, you couldn't render with 3delight. But then there was a bunch of discussion about scripts and executables that I confess I didn't understand. Is that the message that you remember, of was there something from SickleYield that I didn't find?

    Gah, I meant Callad - sorry!

    It allowed me to laod the scene with the 'affected' materials and get to the surfaces tab and replace them and rebuild them - which then went on to work correctly. before it was swallowing all my CPU in running the tdlmakes and the interface was pretty much non-responsive. The instructions on installing and using were ok for me: in effect you are supplied a couple of BAT/cmd files and the files for DS to get them to be run, plus a dummy tdlmake executable. Thus you can turn off and on the use of the dummy tdlmake. With the dummy tdlmake 'active' you will not be able to get 3Delight to render, but as it was written with Reality/LuxRender uses in mind that was not too much of an issue.
    I'm not using Reality. I only render in 3delight built into DS 4.6. This all sounds like more than I want to attempt at this point, but I do appreciate that you shared the information.

    I also tried the suggestion to run tdlmake in a command prompt window manually. I did that successfully on the tif created by LIE, but unfortunately manually creating the tdl file in the temp directory didn't stop the never ending tdlmake that just kept going. I guess I would have to use a dummy tdlmake somewhere along the way in this process, too.

    Until DAZ fixes this, I think I'll have to stick with Wendy's method. It is kind of cumbersome, but it is something I understand now, and it worked for me.

  • barbultbarbult Posts: 23,932
    edited December 1969

    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?

  • SimonJMSimonJM Posts: 5,970
    edited December 1969

    barbult said:
    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?
    That was kind of my thought too!

  • ChoholeChohole Posts: 33,604
    edited December 1969

    SimonJM said:
    barbult said:
    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?


    That was kind of my thought too!

    I don't think there is a way at this present moment in time. Howver filing your own bug reports does make it easier for the tech guys to see that this is a general problem and they will check all the reports on the same problem

  • JaderailJaderail Posts: 0
    edited December 1969

    Opps forgot the tracker was gone. I have not had a DS issue in sometime now. This one I have seen.

  • Zev0Zev0 Posts: 7,064
    edited March 2014

    barbult said:
    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?

    I had exactly the same issue a few weeks ago..Made working on my LIE product impossible because viewport kept freezing, and rendering took forever. It kept hanging in intervals. Glad I'm not the only one who experienced this. Even a fresh re-intall didn't solve the problem. I did get it working eventually, but only because my main hard-drive died and I had to buy a new one and re-install a new OS and DS etc lol

    Post edited by Zev0 on
  • TotteTotte Posts: 13,865
    edited December 1969

    This seems to be a Windows only problem as I've been running wild with LIE and tldmake seems happy about it.

  • barbultbarbult Posts: 23,932
    edited December 1969

    Zev0 said:
    barbult said:
    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?

    I had exactly the same issue a few weeks ago..Made working on my LIE product impossible because viewport kept freezing, and rendering took forever. It kept hanging in intervals. Glad I'm not the only one who experienced this. Even a fresh re-intall didn't solve the problem. I did get it working eventually, but only because my main hard-drive died and I had to buy a new one and re-install a new OS and DS etc lol
    That is interesting. Maybe the problem is caused by something that gets left behind from an older version of DAZ studio when an update is installed, since when you started fresh on an empty disc, it worked OK. I assume you are using Windows, like I am. Totte reports no problem on MAC.

    Your customers who are experiencing this problem can't use your overlay products very well and are unlikely to purchase new LIE products unless this is fixed by DAZ. As a PA, can you put some pressure on them to fix this?

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Totte said:
    This seems to be a Windows only problem as I've been running wild with LIE and tldmake seems happy about it.

    Well...it's sort of a Windows only problem...I've never had tdlmake (Linux native) go nuts like that...but I've had the included version do it.

    I'm beginning to wonder, if it's come on all of a sudden to multiple people if the common element isn't Windows related?

    Almost all the times I've had it happen to me, it has been image related and tdlmake choking on the image. If Windows has recently updated something with the native image handlers, that could be causing it. That could also explain why Mac and Linux aren't affected, as they don't use the same image routines as Windows. So if the dlls that handle image processing have been changed...anyone know specifically when the problems started?

  • TotteTotte Posts: 13,865
    edited December 1969

    mjc1016 said:
    Totte said:
    This seems to be a Windows only problem as I've been running wild with LIE and tldmake seems happy about it.

    Well...it's sort of a Windows only problem...I've never had tdlmake (Linux native) go nuts like that...but I've had the included version do it.

    I'm beginning to wonder, if it's come on all of a sudden to multiple people if the common element isn't Windows related?

    Almost all the times I've had it happen to me, it has been image related and tdlmake choking on the image. If Windows has recently updated something with the native image handlers, that could be causing it. That could also explain why Mac and Linux aren't affected, as they don't use the same image routines as Windows. So if the dlls that handle image processing have been changed...anyone know specifically when the problems started?

    What I mean is that is seems to work without problems on Mac OS X which makes me think something related to Windows is the problem.
    On OS X the only problem is non-ASCII filenames for images which makes tldmake to choke.Had that happen a few times.

  • barbultbarbult Posts: 23,932
    edited December 1969

    Well, I have a render dated March 7, 2014 that used Zev0's Skin Overlay for V5, and I didn't notice a problem then. But, since the image renders fine even with the problem, I may not have noticed anything. It seems that I would have noticed the viewport slowdown, though. I'm sure I wasn't monitoring processes or looking at the temp folder at the time I rendered that image. I reopened that saved scene today and I do see viewport lag. And tdlmake is going wild creating file after file in temp. So, I can't say for sure whether I had the problem on March 7 or not.

    If it is a Windows update issue, then Zev0 should see the problem occur if he applies all updates after reinstalling the OS.

  • Zev0Zev0 Posts: 7,064
    edited March 2014

    barbult said:
    Zev0 said:
    barbult said:
    Jaderail said:
    Please Report this error to DAZ 3D if you have not done so all ready. There are at least 2 reports up now that you can add too if you wish. Thank you for your time.

    I have written #165265 LIE slows viewport and tdlmake runs repeatedly on the same file

    I don't know of any way to find, look at, or read error reports submitted by other users since Mantis was disabled. Is there a way?

    I had exactly the same issue a few weeks ago..Made working on my LIE product impossible because viewport kept freezing, and rendering took forever. It kept hanging in intervals. Glad I'm not the only one who experienced this. Even a fresh re-intall didn't solve the problem. I did get it working eventually, but only because my main hard-drive died and I had to buy a new one and re-install a new OS and DS etc lol
    That is interesting. Maybe the problem is caused by something that gets left behind from an older version of DAZ studio when an update is installed, since when you started fresh on an empty disc, it worked OK. I assume you are using Windows, like I am. Totte reports no problem on MAC.

    Your customers who are experiencing this problem can't use your overlay products very well and are unlikely to purchase new LIE products unless this is fixed by DAZ. As a PA, can you put some pressure on them to fix this?

    Yes I have contacted Daz about the issue. Seems like a very isolated problem, but still, is extremely annoying to those it does effect.

    Post edited by Zev0 on
  • Zev0Zev0 Posts: 7,064
    edited March 2014

    barbult said:
    Well, I have a render dated March 7, 2014 that used Zev0's Skin Overlay for V5, and I didn't notice a problem then. But, since the image renders fine even with the problem, I may not have noticed anything. It seems that I would have noticed the viewport slowdown, though. I'm sure I wasn't monitoring processes or looking at the temp folder at the time I rendered that image. I reopened that saved scene today and I do see viewport lag. And tdlmake is going wild creating file after file in temp. So, I can't say for sure whether I had the problem on March 7 or not.

    If it is a Windows update issue, then Zev0 should see the problem occur if he applies all updates after reinstalling the OS.

    Oh hell no lol. OS Updates will wait till this product is done. Cannot go through that again. I am already behind schedual:(. That is if its OS update related. Either way I won't take the chance.

    Post edited by Zev0 on
  • barbultbarbult Posts: 23,932
    edited December 1969

    Zev0 said:

    Yes I have contacted Daz about the issue. Seems like a very isolated problem, but still, is extremely annoying to those it does effect.

    isolated problem - does that mean that they are not able to reproduce the problem there?
  • Zev0Zev0 Posts: 7,064
    edited March 2014

    In a way yes. However Richard did find some irregularities in the script, so that is being looked into. Whether that is part of the issue relating the problem we experienced, I have no idea. Could be anything really, something that does not agree with our systems.

    Post edited by Zev0 on
  • vwranglervwrangler Posts: 4,871
    edited December 1969

    Microsoft recently did an update that was meant to affect TIFs. There's some exploit that was being seen in the wild that used malformed TIF headers to gain control of a user's system. If LIE/tdlmake is running into TIFs with headers that Windows doesn't like, even if they're perfectly normal and otherwise acceptable, maybe it's affecting how tdlmake handles them? Or maybe tdlmake itself is creating files with headers malformed in a way that Windows doesn't like.

    Maybe this is something to do with it? No idea. I haven't really run into it myself as yet.

  • mjc1016mjc1016 Posts: 15,001
    edited December 1969

    Yes, tdlmake does make tif files...the tdl format that it uses is a tif with 3Delight info stuffed into the header...and mipmaps.

    There were also two updates in the March updates that could affect image handling.

  • Zev0Zev0 Posts: 7,064
    edited December 1969

    Conveniently, my issues started in March lol.....

Sign In or Register to comment.