Is it possible to get the directory of a script.

contessg

Hello,

I need to get the directory of a script I wrote because I need to use a file which is in the same directory.

The script can be installed in any folder and I have no solution to find how to reach the corresponding file.

I thank you for replies.

Richard Haseltine

function getScriptFolder() {	// Get the global file name value	var fileName = getScriptFileName();	if ( fileName == "" ) {		// If empty, return - e.g. script run from IDE		return "";	}	// Create a FileInfor object for the file name	var fileInfo = new DzFileInfo( fileName );	// use the File Info to get and return the path	return fileInfo.path();}

The script will return an empty string if run from the IDE, so you may want a debug option returning a known path for testing.

contessg

Thank you Richard, all works perfectly.

I suppose you saw my other question in the forum.

As you didn't reply, I suppose there is no way to get all the vertices of a geometry in one time as an array of DzVec3.

This function would be very helpful because the loop using getVertex takes 5 seconds if you work on a mesh having 300,000 vertices.

It is faster to export a OBJ file and read the vertices in this file (1s).

Is there a hope to have this function.... later?

Thank you again for your reply in this thread.

     Gérald

Richard Haseltine

I'm not aware of a way to get a full vertex list, no, and I'm not sure how much time it would save in processing. You can make a feature request via a Technical Support ticket, assuming no one comes in with an existing method https://www.daz3d.com/help/help-contact-us

hphoenix

IIRC, there is a SDK call to do just that, though I can't look up the exact object it is from, nor its exact syntax (is there a reason the SDK docs aren't also online?  seems like a simple thing to put online as well....)

So it should be pretty simple for DAZ to expose it to the Scripting API.  Just a question of when someone would get around to it.  There are several accessors like that, which would be very useful to have in the scripting language.

 

Richard Haseltine

hphoenix said:

IIRC, there is a SDK call to do just that, though I can't look up the exact object it is from, nor its exact syntax (is there a reason the SDK docs aren't also online?  seems like a simple thing to put online as well....)

Possibly because the cdoe itself isn't - also, at one stage (due to license rstrictions as I recall) the SDK was not free, while the scripting SDK always has been.

hphoenix said:

So it should be pretty simple for DAZ to expose it to the Scripting API.  Just a question of when someone would get around to it.  There are several accessors like that, which would be very useful to have in the scripting language.

I don't know why there isn't a scripted way to do this, but I would be wary of assuming it was simply down to not having got around to it.

contessg

Hello,

For me, scripting is a method to communicate between an application (Daz Studio in this case) and a compiled program I am writing.

@hphoenix: I fully agree with you, there a lot of functions which could be included in the scripting language. The arrays could be extended in particular the saving of a array in binary mode. This limitation to text file is really annoying. a "array.toFile()" in a file opened in binary mode would be very helpful.

@Richard: My propositions are just here to help. The scripting language is well done and works perfectly. I use this post to thank you to reply to so many questions. Without you, this forum would not be the same.

     Gérald

Richard Haseltine

contessg said:

@hphoenix: I fully agree with you, there a lot of functions which could be included in the scripting language. The arrays could be extended in particular the saving of a array in binary mode. This limitation to text file is really annoying. a "array.toFile()" in a file opened in binary mode would be very helpful.

You can use DzGZFile (instead of DzFile) to write to/read from a compressed file, treating it like a regular text file once created.

hphoenix

Richard Haseltine said:

hphoenix said:

IIRC, there is a SDK call to do just that, though I can't look up the exact object it is from, nor its exact syntax (is there a reason the SDK docs aren't also online?  seems like a simple thing to put online as well....)

Possibly because the cdoe itself isn't - also, at one stage (due to license rstrictions as I recall) the SDK was not free, while the scripting SDK always has been.

hphoenix said:

So it should be pretty simple for DAZ to expose it to the Scripting API.  Just a question of when someone would get around to it.  There are several accessors like that, which would be very useful to have in the scripting language.

I don't know why there isn't a scripted way to do this, but I would be wary of assuming it was simply down to not having got around to it.

Did not realize there were license restrictions (previously) on the SDK.  If they're not a concern now, might be a good time to put the SDK API pages online somewhere.  I know the code isn't online, but the reference pages would be simplicity themselves to put up....they're already in HTML format.

I should have chosen my words better, I wasn't implying that 'someone just hadn't gotten around to it', but that IF someone DID do it, it would be relatively simple to add....ONCE other things weren't more pressing.  I'm a software dev, and I know how scheduling and prioritization goes!

 

contessg

You are right, Richard, the DzGZFiles are very useful.
They allows to create file having the same size than a binary file.

Nevertheless, it is necessary to remember these file are text files so it is necessary to make a conversion from a string to a binary value (integer, float).
This conversion takes time. If you have to add the need to use a loop in a scripted language, a function becomes quickly unusable.
It is for this reason I started another thread.

A compressed file and a non compressed file are read at the same speed.
I suppose the time used by the decompression is compensated by a faster reading of a smaller file.
But they never will allow to work at the same speed than a binary file.
Technically, I think there is no difficulties to integrate this feature in the scripting language.

Richard Haseltine

For simple data types (possibly assembled into more complex objects) use JSON. Skipping the file opening etc. code:

var JSONdata = oMyFile.read();
var actualData = JSON.parse( JSONdata );

to read in and

var JSONdata = JSON.stringify( actualData );
oMyFile.write( JSONdata );

to write out.

 

contessg

Thank you Richard,

I saw these JSON functions but I didn't understand how to use them.

I make some tests and I come back to you.

Thanks again.

      Gérald

contessg

@Richard:
 I made some tests but I didn't find a fast method to transfer the float3 values to the vertices.
Have you an sample which could explain how to do this work?

@hphoenix:
I hope you will read this thread another time.
When you say that "there is a SDK call to do just that", could you tell me how to program the SDK, with what compiler?
I suppose the result of the compilation can be introduced in a script function. (What is it: a DLL?). For Windows of course.

hphoenix

contessg said:

@hphoenix:
I hope you will read this thread another time.
When you say that "there is a SDK call to do just that", could you tell me how to program the SDK, with what compiler?
I suppose the result of the compilation can be introduced in a script function. (What is it: a DLL?). For Windows of course.

@contessg I check the scripting forum regularly.....no worries about me seeing this.  :)

The SDK is a set of headers/libraries for C++ development for DAZ Studio.  It can be done in several different environments.  I personally work primarily in Visual Studio in Windows.  Using the SDK means building a PLUGIN for DS (which is, yes, a DLL).  It will function just like all plugins for DS.  However, I don't believe you can expose plugin functionality to the scripting engine.....at least, I do not know how.  There are some ways to work around that, such as by building a Pane-based plugin, using the script engine to find the pane object, and programattically accessing controls on it....but it's VERY limited.  It's also possible to drop files where such a plugin may be 'looking' for them, and such.

 

contessg

 

@hphoenix:

I thank you for your reply.

In fact, my only issue is the scripting language do not have the ability to export quickly the vertices to a file and conversely.
I need to have a fast vertices transfer between Daz Studio and my program.
Currently, the fastest way to send vertices to the program is to save a simplified obj file at each frame and read the vertices contained in this OBJ file inside the program.
A simplified OBJ file means: Vertices and Faces, of course, but without normals, texturevertices, groups and maps. This allows to save time.
I tried many way to save the vertices directly from a script function, but the result is always slower.

As you seem to know well the SDK programming,  could you tell me what is the method to develop these functions, where can I find the SDK, is it free?

hphoenix

@contessg - The SDK is free.  https://www.daz3d.com/daz-studio-4-5-sdk

Once you 'purchase' it, download it manually and unzip the files to a convenient location (near the root of the drive, to avoid long path/file name length issues.)

Yes, that's the current one.  There are pages in the SDK docs (which come with it) on getting started, though they aren't completely correct anymore.....you'll have to modify a few things to get it building.  Pick the first couple of plugin examples they bundle with it and get them building, to start with.

If you are wanting to build the highest-speed custom OBJ export, just write the text to a BYTE buffer, then write it block by block in binary mode to the file.  Though that's not going to be a lot faster than just writing it through standard FILE objects in text mode.  But do all your data extraction FIRST, then write it sequentially all at once to the file.

 

Cris Palomino

"I don't believe you can expose plugin functionality to the scripting engine.....at least, I do not know how."
---
Actually a LOT of scripting API comes directly from plugins...
---
Inherit a class that inherits QObject somewhere in its hierarchy, or inherit QObject directly. Use the Q_OBJECT macro to allow properties, public slots, and signals to be accessed via script. Use the Q_PROPERTY macro to expose properties to script. Use the DZ_PLUGIN_CLASS_GUID macro (or DZ_PLUGIN_CUSTOM_CLASS_GUID_OWNED depending if you need a ctor to take arguments) to register your class and create any requisite class factories. Use types in your API that script can deal with; i.e., const QString& instead of QString, int instead of int* or int[n], float instead of float* or float[n], etc. Look at the SDK samples. Pick a header in the SDK (e.g., DzNode), look at the SDK docs and the corresponding script API docs for that class and begin to build your mental map.

contessg

@hphoenix:
Thank you for your reply, I downloaded the SDK and I just started to look at the documentation.
A first read shows me a function which seems me very interesting :  "DzGeometry::getVerticesPtr()" in the Geometry class.
This function corresponds exactly to my wish. I suppose this pointer is the address of a DzVec3 array.
I just would like to save this array in a binary file. I will read the examples to try to find the solution.

@Cris Palomino:
Thank you for your help. I will follow your method when I will try to use the plugin in my script.
I have to understand a lot of things before that.