Scene Loader Sample Application can't load anything

TheMysteryIsThePoint

Hi everyone,

I got the SDK Scene Loader Application to build, but this call ALWAYS fails, with any of the scene files I've tried, including empty ones:

if( !loader.loadScene( filename ) )
        return 2;

The printed output is:

pg_ctl: server is running (PID: 3284)
C:/Program Files/DAZ 3D/PostgreSQL CMS/bin/postgres.exe "-D" "C:/Users/donal/AppData/Roaming/DAZ 3D/cms/ContentCluster"
Loading Scene Z:\Temp Stuff\scene_loader_test.duf...
Error Loading Scene: File Format Invalid
pg_ctl: server is running (PID: 3284)
C:/Program Files/DAZ 3D/PostgreSQL CMS/bin/postgres.exe "-D" "C:/Users/donal/AppData/Roaming/DAZ 3D/cms/ContentCluster"
pg_ctl: server is running (PID: 3284)
C:/Program Files/DAZ 3D/PostgreSQL CMS/bin/postgres.exe "-D" "C:/Users/donal/AppData/Roaming/DAZ 3D/cms/ContentCluster"

C:\Users\Public\Documents\My DAZ 3D Library\DAZStudio4.5+ SDK\samples\applications\SceneLoaderApp\..\..\..\..\..\exec\Release\x64\SDK_SceneLoaderApp.exe (process 3104) exited with code 2.
To automatically close the console when debugging stops, enable Tools->Options->Debugging->Automatically close the console when debugging stops.
Press any key to close this window . . .

Has anyone hit this problem?

Thanks,

Donald

TheMysteryIsThePoint

So, there are "Scene Files", and then there are "User Scene Files"?

// Standard DAZ Studio file extensions
#define DZ_SCENE_EXT            "daz"
#define DZ_OBJECT_FILE_EXT        "dso"
#define DZ_DELTAS_FILE_EXT        "dsd"
#define DZ_VERTEX_MAP_EXT        "dsv"
#define DZ_CUSTOM_IMAGE_EXT        "dsi"
#define DZ_ASSET_FILE_EXT        "dsf"
#define DZ_USER_SCENE_FILE_EXT    "duf"

TheMysteryIsThePoint

Is there any sample code on how to load a User Scene File, i.e. a .duf file, into a scene? The DZ_USER_SCENE_FILE_EXT define does not even occur anywhere in the SDK header files. What is even the distinction between the two file types? Where is the documentation on all of this located?

Thank you,

Donald

TheMysteryIsThePoint

Can someone confirm that DzAssetIOMgr::doFigureLoad() is what I'm looking for? To load a .duf file into the DzScene object?

Thanks

 

TheMysteryIsThePoint

I'm hoping that someone can help me. I consistently get an Access Violation with the following. Is there something that needs to be initialized, or am I completely on the wrong track?

int main( int argc, char **argv ) {

    int lvArgc = 1;

    DzApp app(lvArgc, argv, false, true );
    if( !app.init( DzApp::NoInterface ) )
        return 1;

    DzFigure* figure;
    DzError error = dzApp->getAssetIOMgr()->doFigureLoad("Z:\\test.duf", &figure); // access violation here

surreal

I think you maybe misunderstanding the purpose of the SDK Scene Loader Application. It creates an EXE not a plug-in(DLL). The EXE initializes an interface-less DAZ3D instance. The sample shows you how to incorporate DAZ3D into your own application.

It is not exactly to show you how to load a scene into a running DAZ3d application. Although the code for the DzSceneLoader::loadScene does demonstrate how you can load a scene file e.g. dzScene->loadScene(const QString &filename, DzOpenMethod method).

You code snippet will fail because you have not initialized "figure"
e.g. it should be "DzFigure* figure = new DzFigure();" 
NOTE: I assume you have included #include "dzassetiomgr.h" and #include "dzfigure.h"

also the filename should be "Z:\test.duf". 

e.g.

int main( int argc, char **argv ) {    int lvArgc = 1;    DzApp app(lvArgc, argv, false, true );    if( !app.init( DzApp::NoInterface ) )        return 1;    DzFigure* figure = new DzFigure();    DzAssetIOMgr* mgr = app.getAssetIOMgr();    if(mgr){        DzError error = mgr->doFigureLoad("Z:\test.duf", &figure);    }else{        return 1;  //Failed to get pointer to Asset IO Manager    }...}

 

If you just want a plug-in to load a scene file then you may be better starting with the Scene Info Pane sample and add a file name input field and a load button with "dzScene->loadScene(filename, DzScene::OpenNew);"         or "dzScene->loadScene(filename, DzScene::MergeFile;" if you don't want to open a new scene and just merge the scene with the existing.

 

TheMysteryIsThePoint

Thank you for responding!

A headless Daz Studio is exactly what I want. The plugin is working, but what I'd really like is a command line app I can execute from within Blender.

The code you cut/pasted doesn't work for me. With the single backspace, i.e. "Z:\test.duf" there's no crash, but doFigureLoad() fails with DZ_OPERATION_FAILED_ERROR. With a double slash, I get an Access Violation in doFigureLoad().

Everyone is saying "It's simple, just 1, 2, and 3..." But everything I've tried ends in an Access Violation. I have to believe that there's a missing piece that needs to be done when Daz is run like this, but I can't find where it's documented anywhere.

Thank you for your help, I am further convinved of the missing piece.

TheMysteryIsThePoint

Does figure really have to be initialized? The parameter to doFigureLoad() is a Figure**, implying that doFigureLoad() is going to set the pointer that figure points to with the address of the figure that was loaded, i.e. dzScene retains ownership of the internal figure's memory, I've just got a pointer to it. If that's not the case, why is the figure parameter not just a Figure*, or even Figure& then? I am actually more confused now than before :(

surreal

You may be correct regard initializing Figure*.  I did get an error when I tried a quick bit of code using your dzApp->getAssetIOMgr()->doFigureLoad(...) without initializing the Figure, however the error disappeared when I used app.getAssetIOMgr()->doFigureLoad(...). 

Reading the DzFigure class I see:
"For internal use only.
This constructor is called by the Framework when loading from a file so that certain initializations can be skipped that will happen later in the file load process."

Doing a quick scan online tells me that we should be using / instead of \\ or \

You are also correct in that dzScene->loadScene(...) does not appear to work.

Don't use doFigureLoad(...), use openFile(...) from DzContentMgr instead.

e.g.

	DzContentMgr* mgr = app.getContentMgr();	if (mgr) {		if (mgr->openFile("C:/tmp/Test.duf", true)) {	//true=merge into existing scene, false=new scene			t = dzScene->getNumNodes();			return t*10;	//File opened, return number of nodes in opened file by 10		}		return 3;			//Failed to get a open file	}	return 4;				//Failed to get a valid ContentMgr

 

surreal

An altered version of the samples DzSceneLoader::loadScene(...)

#include "dzscene.h"#include "dznode.h"#include "dzobject.h"#include "dzshape.h"#include "dzfacetmesh.h"#include "dzapp.h"#include "dzcontentmgr.h"#include "dzsceneloader.h"///////////////////////////////////////////////////////////////////////// DzSceneLoader////////////////////////////////////////////////////////////////////////**	Default Constructor.**/DzSceneLoader::DzSceneLoader(){}/**	Loads the scene from the given file, and prints file statistics to the console.	@param	filename	An absolute path to the scene file to load.**/bool DzSceneLoader::loadScene( const QString &filename ){	QByteArray	arr = filename.toLatin1();	printf( "Loading Scene %s...\n", arr.data() );	DzContentMgr* mgr = dzApp->getContentMgr();	if (mgr) {		if (mgr->openFile(filename, true)) {			printf( "Scene loaded successfully.\n" );			printSceneStats();			return true;		}		else {			printf("Error Loading Scene: %s\n", arr.data());			return false;		}	}	printf("Error getting ContentMgr:\n");	return false;}...

 

TheMysteryIsThePoint

Hi surreal,

Thank you again for your assistance.

All the examples get Access Violations at the same place: where the content is actually loaded.

Exception thrown at 0x00007FFF95675670 (DzCore.dll) in duf_loader.exe: 0xC0000005: Access violation reading location 0x0000000000000028.

Doesn't it seem like openFile() was trying to access some structure's member at offset 0x28, but the address of the structure was NULL?

You are saying that all of this code actually works for you? Can I ask how you linked it, then? Should PATH find the DLLs in the SDK first, or the same DLLs in the DazStudio install?

Thanks again.

TheMysteryIsThePoint

I went back and used the exact same .sln included with the samples, made the changes above, and still the same behaviour: openFile() crashes. This works for you?

surreal

I don't get any access violation errors with the original or the code snippets that I provided.

I did get an error when I first tried your dzApp->getAssetIOMgr()->doFigureLoad(...)  code snippet. 

When I added the =DzFigure() and changed \\ to \ it compiled and I was able to run the EXE file. I don't understand why it had any effect. I can only suspect I made some other change and failed to note what the change was.

However looking through the log I see that it did run but report an Error Loading Scene: File Format Invalid when trying to load the figure file.

I am using Visual Studio2017 on Win10. I did make a number of changes to the "Scene Loader Application" project's properties. e.g. it needs access to DzCore.DLL so the working directory needs to be the DAZStudio4 directory unless you have that in your path. Win10 security won't allow access to C:\ so I used a C:\tmp\ folder.

I will attach some snapshots of the properties I have on the "Scene Loader Application" project.

 

TheMysteryIsThePoint

Hi surreal, thanks again for your effort... you have no reason to be doing this, yet you are.

My config does not differ from yours in any significant way, but the behavior is constant: Access Violation in whatever function is doing the loading. I went so far as to write a plugin that calls DzScene::saveScene() just to create a .daz native file that the original SceneLoaderApp could load. (DzScene::saveScene() seems buggy in that it returns that horribly vague error code 98, but the log says it was successful) But now even the original SceneLoaderApp crashes in EXACTLY THE SAME FASHION, complaining about address 0x28.

If I may further impose, can I post a .daz file on Google drive to see if the original SceneLoaderApp crashes for you as well? The crash doesn’t seem to happen unless it is actually loading something In the right format.

Thanks again for all your trouble.

surreal

Ok

surreal

As time permits, it is nice to have a break from one's own projects (with their own set of bugs) now and again. Helps to see the world from a different point of view.

I did a test using my own "C:/tmp/test.daz" file, created/saved using DzScene::saveScene().

The original SceneLoaderApp code loaded it without any error.

I do get an error 98 when I try to save or load the .daz file to or from a folder protected by the operating system e.g. C:/ or ./ (i.e. application root)

Thus I use a folder like C:/tmp and make sure I know what permissions I have set on it.

 

TheMysteryIsThePoint

Hmm... that is EXACTLY what I did to test, since I didn't have a .daz file to test with.

OK, that's proof enough. It must be something in my setup, but I have no idea what... I have done nothing out of the ordinary. At least I know that I should keep trying. Thank you again.

TheMysteryIsThePoint

The scene loader app even as it ships in the SDK crashes with an access violation. I changed nothing, and it still crashes. To date, every single call that actually loads something has crashed. But those same functions, called in the context of a plugin, work perfectly. I am out of ideas.

surreal

Try changing the line

DzApp  app( myArgc, argv, false, true);

to

DzApp app( myArgc, argv, true, true);

You will also need to disable the aniMate2 plugin if you have it.

 

I just tried to run some tests on the samples. The standard Scene Loader Application sample no longer works for me. It fails at !app.init(DzApp::NoInterface)) if the app was created with makeInterfaceAvailable= false. I don't know if it is something DAZ has changed or Microsoft has changed.

Interesting in that the standard Scene Information Pane sample now does not compile for me. It fails during CustomBuild (cmd...).

TheMysteryIsThePoint

I had to disable both aniMate2 and one other plugin, but the end result was the same. Access Violation.

But some more evidence that the sample app is simply out-of-date:

1) The DzApp class has a virtual destructor, implying that it is supposed to be subclassed, but the sample doesn't do that.

2) At the bottom of DzApp.h, it declares "extern DZ_EXPORT DzApp *dzApp;" implying that there's some global DzApp object that will be referenced somewhere else in the code. Clearly there's only one app, so that kind of implies that the one created in main() should set it, instead of declaring a local one that no one else will have apointer to. But the sample doesn't do that.

Can we please have a dev give a couple of sentences explaning how the architecture is?