DAZ Studio Ignoring File Extensions

Finally think I figured out what is causing some mysterious file I/O issues in DAZ Studio, and I wanted to know if anybody else has run into this:

1. Create a sphere, export as "file-extension-test.obj"

2. Delete sphere

3. Create cube in a new fresh scene and save as "file-extension-test.duf"

4. In a new fresh scene, drag & drop or import "file-extension-test.obj" (sphere)

For me, this results in "file-extension-test.duf" (cube) being loaded, in both 4.6 & 4.8.

Can anybody else replicate this?

- Greg

Comments

  • rbtwhizrbtwhiz Posts: 2,296
    edited July 2015

    This is standard [intended] behavior for DAZ Studio. When any [supported, user-facing] non-native file type is placed adjacent to an identically named native file type, opening the native file is preferred over importing the non-native one.  In other words, DAZ Studio prefers to read its own formats when possible... because its files typically contain more readily useful information that pertains to itself and/or its way of doing things.  Further, when more than one native 'companion file' exists for a given non-native file, a DS[A/E/B] file is given precedence over a DUF file; a script can perform work on either side of causing a DUF to be loaded.

    -Rob

    Post edited by rbtwhiz on
  • mjc1016mjc1016 Posts: 15,001

    Rob, that only works if the two files are in the same folder, right?

    If the obj files are in a separate folder from the scene files, it should work as two different files, right?

    Or am I getting 'odd' (or normal, depending on your viewpoint) behavior because I'm running in Linux/Wine?

  • rbtwhizrbtwhiz Posts: 2,296

    The files are only considered 'companions' when they are identically named (sans file extension) and they are placed adjacent to (directly next to) one another; i.e. the only difference in their paths are the file extensions.  And just to be clear, this is only for user-facing non-native file types. Co-located, identically named user-facing native file types are handled individually.  Again, native file types are read (natively understood), so there is no need to look for a 'companion' that provides more/better information.  Non-native file types are imported (translated), so DAZ Studio will look for said 'companion' to provide more/better information in a language it already speaks before it attempts to translate.

    -Rob

  • mjc1016mjc1016 Posts: 15,001

    I thought that was the case, but after the original post and reply I wasn't 100% sure any longer.  Thanks for clarifying.

    And Algovincian, from that it sounds like the 'fix' is to save the obj to a different folder.

  • algovincianalgovincian Posts: 2,636

    Thanks for taking the time to clarify, Rob & MJC - I appreciate it.

    - Greg

Sign In or Register to comment.