Loading...
> >

Problems with 3Delight standalone

desleadeslea Posts: 27
edited April 2014 in Daz Studio Discussion

TL;DR Summary

First problem: Connection between renderdl and i-display buggy, falls out mid-render. New problem, reproduced, but not consistent in timing or surrounding events. Seems to be a failure of the TCP-IP connection between the two but the firewall doesn't think it's doing it (according to logs).

Tried running the render without i-display in play, which led to -

Second problem: 

collecteddirectory>renderdl file.rib -nd

with rib statement 

Display "render.tiff" "file" "rgba"

yields an almost-empty TIFF, which is unreadable by graphics programs and when subsequently opened in i-Display shows as blank, despite the renderdl command window showing the expected narrative and elapsing the expected amount of time. Various other possibilities excluded. This does not seem to be a new problem; I'm only detecting it now because it's the first time I've tried to render and save outside i-Display (previously I saved from i-Display's Save Image As menu option).

Both problems have been reproduced on two machines, both running Win8.1 x64, i7 quad core, 16gB RAM (substantially similar config, but not clones). There have been no new Windows updates or programs installed, or even a restart, between the last successful render and the new fails.


Detail

I'm running 3Delight Standalone on a Windows 8 x64 box. I have been outputting .RIB files from DAZ for a while now and rendered them successfully with 3Delight by right-clicking the RIB file and selecting Render With 3Delight. My son also does this on a similar-spec laptop, so I have some scope to reproduce issues.

Yesterday, both he and I started having crashes mid-render in i-Display. By watching the firewall logs, I came to the conclusion that the problem was with the connection between renderdl and i-Display. (renderdl communicates with i-Display over TCP-IP). I couldn't figure out why, and still don't have much idea. There have been no new Windows updates or programs installed, or even a restart, between the last successful render and the new fails.

As a workaround I tried running my render from the command line without using i-Display by typing:

collecteddirectory>renderdl file.rib -nd

After a few hours (about the expected timeframe) the script had concluded with no major errors (just the usual "resetting to box" type stuff), return to command prompt. There was a render.tiff file in the collectedirectory (expected behaviour).

However, the file properties (in both Windows Explorer and the command window) still show render.tiff as virtually empty and last modified at the time of renderdl launch. By the way, all my old renders successfully rendered in i-display have exactly the same thing - a small placeholder render.tiff file that doesn't appear to have anything in it. I've never detected it before because I've always used Save Image As in the i-Display to save as PNG, So it looks like the empty TIFF problem is a pre-existing one that I've had for as long as I've had 3Delight.

Graphics programs can't open the tiny TIFF. Typing i-display "render.tiff" launches i-display with a blank grid (which is consistent with the file information). I've checked in my bin folder (including for hidden files) and searched the whole computer for any other render.tiff. It doesn't seem to be anywhere else.

The relevant line in the RIB file reads 

Display "render.tiff" "file" "rgba"

so it really should have outputted to collecteddirectory\render.tiff.

I still have the original renderdl command window open, so if the file information is somehow sitting somewhere and I need to run a command to pipe it to the render.tiff file, I can do that. I can't figure out from the renderdl doco whether I'm supposed to do something to connect the dots.

And/or, if anyone has any thoughts on how to keep the TCP-IP connection between renderdl and i-display alive, I'm all ears. It wasn't a forcible disconnect by my firewall and there's no clear consistent pattern of behaviour just beforehand. My system did seem to be fighting off a hack yesterday, so I suppose it's possible i-display was somehow being thrown out along with the intruder traffic, but my firewall certainly didn't think it was disallowing it.

Thoughts?

Post edited by deslea on

Comments

  • desleadeslea Posts: 27
    edited April 2014

    If it's of use, here's a dump of my renderdl variables:

    C:\Program Files\3Delight\bin>set
    ALLUSERSPROFILE=C:\ProgramData
    AMDAPPSDKROOT=c:\Program Files (x86)\AMD APP\
    APPDATA=C:\Users\removed\AppData\Roaming
    asl.log=Destination=file
    CommonProgramFiles=C:\Program Files\Common Files
    CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
    CommonProgramW6432=C:\Program Files\Common Files
    COMPUTERNAME=removed
    ComSpec=C:\WINDOWS\system32\cmd.exe
    DELIGHT=C:\Program Files\3Delight
    DL_DISPLAYS_PATH=C:\Program Files\3Delight\displays
    DL_SHADERS_PATH=.:C:\Program Files\3Delight\shaders
    FP_NO_HOST_CHECK=NO
    HOMEDRIVE=C:
    HOMEPATH=\Users\desle_000
    LOCALAPPDATA=C:\Users\removed\AppData\Local
    LOGONSERVER=\\MicrosoftAccount
    LUXRENDER_ROOT=C:\Program Files\LuxRender
    MAYA_PLUG_IN_PATH=C:\Program Files\3Delight\maya\plugins
    MAYA_RENDER_DESC_PATH=C:\Program Files\3Delight\maya\render_desc
    MAYA_SCRIPT_PATH=C:\Program Files\3Delight\maya\scripts
    NUMBER_OF_PROCESSORS=8
    OnlineServices=Online Services
    OS=Windows_NT
    Path=c:\Program Files (x86)\AMD APP\bin\x86_64;c:\Program Files (x86)\AMD APP\bi
    n\x86;c:\Program Files (x86)\Intel\iCLS Client\;c:\Program Files\Intel\iCLS Clie
    nt\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\
    WindowsPowerShell\v1.0\;C:\Program Files\Intel\Intel(R) Management Engine Compon
    ents\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Pro
    gram Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program File
    s (x86)\Intel\Intel(R) Management Engine Components\IPT;c:\Program Files (x86)\A
    TI Technologies\ATI.ACE\Core-Static;C:\Program Files (x86)\Windows Live\Shared;C
    :\Program Files\3Delight\bin;C:\Program Files\LuxRender
    PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
    Platform=HPD
    PROCESSOR_ARCHITECTURE=AMD64
    PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
    PROCESSOR_LEVEL=6
    PROCESSOR_REVISION=3a09
    ProgramData=C:\ProgramData
    ProgramFiles=C:\Program Files
    ProgramFiles(x86)=C:\Program Files (x86)
    ProgramW6432=C:\Program Files
    PROMPT=$P$G
    PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
    PUBLIC=C:\Users\Public
    SESSIONNAME=Console
    SystemDrive=C:
    SystemRoot=C:\WINDOWS
    TEMP=C:\Users\DESLE_~1\AppData\Local\Temp
    TMP=C:\Users\DESLE_~1\AppData\Local\Temp
    USERDOMAIN=removed
    USERDOMAIN_ROAMINGPROFILE=removed
    USERNAME=removed
    USERPROFILE=C:\Users\removed
    windir=C:\WINDOWS
    XBMLANGPATH=C:\Program Files\3Delight\maya\icons

    And here are the relevant parts of the renderdl output:

    c:\localrib\luciusnarcissahogwarts_collected>renderdl -nd luciusnarcissahogwarts
    .rib
    # Rendering luciusnarcissahogwarts.rib ...
    3DL WARNING D2045: PixelFilter reset to 'box' 1x1 (display driver requirement)
    3DL ERROR R5050: Cannot run more than one 3Delight free license at once (1)
    3DL INFO R2093: object '' (displacement 'shader_Displacement_2', surfac
    e 'shader_Surface_2') used only 5% of its displacement bound
    3DL INFO R2093: object '' (displacement 'omDispStandard', surface 'omUb
    erSurface') used only 0% of its displacement bound
    3DL INFO R2093: object '' (displacement 'omDispStandard_1', surface 'om
    HumanSurface') used only 30% of its displacement bound

    c:\localrib\luciusnarcissahogwarts_collected>i-display "render.tiff"

    (The licensing error was because I had just run a test in another command window, but that was to i-display, so I didn't learn anything of use for this problem. I don't think the licensing was the reason this didn't work though - it didn't terminate the process, and it wasn't the case on the other computer which had the same behaviour).

    Post edited by deslea on
  • Takeo.KenseiTakeo.Kensei Posts: 1,303
    edited December 1969

    If you really think the problem comes from the firewell you could disable it on local networks

Sign In or Register to comment.