BUG REPORT: dzApp->getContentMgr()->findFile() not working

pkinnane_44e978d933

BUG REPORT: dzApp->getContentMgr()->findFile() does not appear to be working correctly in DAZStudio 4.9 (but it is in DAZStudio 4.8).  For example, the code below returns "".  The walnut.png file is present in C:\Program Files\DAZ 3D\DAZStudio4 Public Build\shaders\iray\resources\walnut.png.

Thanks (I have also reported this in the 4.9 release thread - apologies if this is not approriate).

Paul

rbtwhiz

This is not a "bug." The DzContentMgr class is described as:

The manager that is responsible for all the content folder & file trees that are accessible from the content library.

The description on DzContentMgr::findfile() states:

Given a partial path (a file path that is relative to a content directory) this function traverses all folders of the specified mapped directory types in the following order (NativeDirs, PoserDirs, ImportDirs, BuiltInDirs)

As the ./shaders folder is considered to be more "plugin" or "resource" than "content," the DzContentMgr::findfile() function is not going to find a file that resides within it. Hence the empty string return value.

The following will give you the absolute path of the file in your example:

const QString absFilePath = QString( "%1/iray/resources/walnut.png" ).arg( dzApp->getShadersPath() );

-Rob

pkinnane_44e978d933

Thanks Rob

The doco for DzContentMgr::findBaseDirectory() is....

Given an absolute path, this method traverses the content directories and attempts to find the base (mapped) folder.

If I...

DzContentFolder *folder = dzApp->getContentMgr()->findBaseDirectory("C:/Program Files/DAZ 3D/DAZStudio4 Public Build/shaders/iray/resources/walnut_spec.png", true);

Then folder returns with "C:/Program Files/DAZ 3D/DAZStudio4 Public Build/shaders/iray".

So findBaseDirectory() thinks walnut_spec.png is in a content folder.

So I believe that either findBaseDirectory() is bugged, or findfile() is bugged - take your pick :-)

Paul

 

 

linvanchene

pkinnane_44e978d933 said:

Thanks Rob

The doco for DzContentMgr::findBaseDirectory() is....

Given an absolute path, this method traverses the content directories and attempts to find the base (mapped) folder.

If I...

DzContentFolder *folder = dzApp->getContentMgr()->findBaseDirectory("C:/Program Files/DAZ 3D/DAZStudio4 Public Build/shaders/iray/resources/walnut_spec.png", true);

Then folder returns with "C:/Program Files/DAZ 3D/DAZStudio4 Public Build/shaders/iray".

So findBaseDirectory() thinks walnut_spec.png is in a content folder.

So I believe that either findBaseDirectory() is bugged, or findfile() is bugged - take your pick :-)

Paul

 

 

@ walnut example.

How exactly are Base directories defined?

 

@ vase example

compare:

http://www.daz3d.com/forums/discussion/comment/1024672/#Comment_1024672

additional steps performed:

- installed content with the DIM in Studio Pro BETA - version 4.9.1.30

textures for content installed with the DIM were found in OctaneRender for DAZ Studio 3.0.6.13 (64 bit)

textures for content installed with DAZ Connect are NOT found in OctaneRender for DAZ Studio 3.0.6.13 (64 bit)

-> It is not a DAZ Studio 4.9 issue in general but an issue with certain directories like resources or DAZ Connect.

 

rbtwhiz said:

Given a partial path (a file path that is relative to a content directory) this function traverses all folders of the specified mapped directory types in the following order (NativeDirs, PoserDirs, ImportDirs, BuiltInDirs)

 

Is it possible that the path indicated in the Content Directory manager under

Content Sets

Content Directories

DAZ Connect Data

is not checked when cylcing trough NativeDirs, PoserDirs, ImportDirs, BuiltInDirs

 

?

rbtwhiz

Its actually a case of being "caught in the middle."

The DzContentMgr API has evolved a bit since the 4.5+ SDK was published (i.e., it has gained support for mapped MDL directories, among other things). Said evolution has not been published as an update to the public SDK in large part due to the fact that issuing an SDK update has a ripple effect on end users that has historically been rather inconvenient for them. We've tried very hard to mitigate that as much as possible this time around. That being said, we do recognize that exciting/new areas of Daz Studio are not accessible to plugin developers (but are, to varying degrees, to script developers) and we have been discussing the best way to address that while maintaining ABI compatibility.

The version of DzContentMgr::findBaseDirectory() that you are using (because it is the only one that existed when the 4.5+ SDK was published) had no concept of what a mapped MDL directory is and so the useImportFolders parameter represented whether or not to look in Poser mapped directories and other mapped import directories. As part of this evolution of DzContentMgr, and being that MDL is not native to Daz Studio, MDL mapped directories have been recently added to the list of directory types considered to be "import folders" for the DzContentMgr::findBaseDirectory() function. The additions to the DzContentMgr API include an alternate version of DzContentMgr::findBaseDirectory() that allows a developer to specify an enumerated DirectoryTypes value, similar to the second argument to DzContentMgr::findFile(). Further, the list of enumerated DirectoryTypes values has grown. One of these new enumerated values is MDLDirs, which represents a value of 0x10.

One thing you may be able to do (I'm in transit, so I cannot confirm at the moment) is include the 0x10 value with the second argument to DzContentMgr::findFile(), so that it behaves in a manner that is more consistent with DzContentMgr::findBaseDirectory():

DzContentMgr* contentMgr = dzApp->getContentMgr();const QString absPath = contentMgr->findFile( "/resources/walnut_spec.png", DzContentMgr::NativeAndBuiltInDirs | 0x10 );if( !absPath.isEmpty() ){	;// perform work}

To be exactly consistent with DzContentMgr::findBaseDirectory(), you would also need to include the new CloudDB (0x20) and CloudDir (0x40) enumerated DirectoryTypes values as well.

-Rob

pkinnane_44e978d933

Rob, thank you for taking the time to fully explain what is happening in this situation.  Your proposed code to resolve he problem works!  Thanks
.

Paul