Running script in the background

onix

I can't find any way to put a script in the background so that it could keep running without blocking interface.

Since all scripts behave the same way I guess it is not possible, so maybe Daz developers could fix that problem?

Ideally, even multiple scripts could be allowed to run at the same time.  Technically I do not see any problems with that.

If scripts inevitably block interface it severely limits their usability. even when using something that does not require user interaction it is preferable to bring the main on to top so see what is happening there sometimes it may be useful to halt script. or kill it if it does not respond anymore, now if script hangs, you are screwed and lose your work, there is no way to access DAZ interface anymore.

Nonblocking scripts potentially can introduce some problems with race conditions but I think they can be safely ignored and dealt on individual basis.

This feature could bring Daz scripting to an entirely new level making scripts almost as functional as plugins. As a bonus, it can improve CPU utilization because Daz only uses 2 threads most of the time so it will not hurt performance at all even if the script does complex CPU intensive work.

Richard Haseltine

There was some discussion on non-modal scripts, essentially the advice was be very, very careful if you try it - and it's probably better not to. Depending on your goal you might want to look at the post-load callback samples: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/start#elements

onix

Thanks, looks like I am finding some info about that but I would love to get some reference to any information on how it can be done.

My goal is actually to create a controller interface for something that resembles VR gloves. So the script itself must run all the time, react to the information it gets from outside and perform appropriate tasks.

for example, I select some body part  or item in the scene and  use VR glove to manipulate it transferring my hand pose into the pose of that object

or alternatively can link various scene objects with individual controllers

 

 

 

Praxis

Here's a link to Rob's post on this topic.  Summary: The official way to do what you described is to use the SDK to create a new plug-in DzPane.

 

BUT: The post-load callbacks mechanism referred to by Richard may do all or most of what you want?:  It lets your script(s) get control any time an event occurs whose signal is exposed to script.  Your event-handler script does whatever you want (quickly, so as to appear to be non-blocking) and returns control to DS.  Its not as flexible as a plug-in, but it is cross-platform, and potentially very useful.  I'm surprised that there's very little mention of its use in the forums  Here is an outline of one way I've used it:

1. Create a DzNode to provide an interface between your script and DS.  It can be any kind of Node that suits your purpose - a Null Node, a DzGroupNode, a DzBasicCamera, etc. e.g. Create > New Null... Call it e.g. MyNode
2. Write a Setup.dsa script that is run once, on your development system, to install your post-load script into MyNode.  See http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/elements/post_load_script_data_item_add/start.  the key part is this (with sScriptRelPath pointing to your PostLoad.dsa described in step 4 below):

   // Create our data item; we want it to be saved with the nodeoDataItem = new DzSimpleElementScriptData( sDataName, true );// Set the path to our scriptoDataItem.setScriptFilePath( sScriptRelPath );// Add the data item to the nodeoElement.addDataItem( oDataItem );

3. Run the Setup.dsa, then save MyNode as a Scene Subset .duf  This will contain an "extra" data item on MyNode that tells DS to call your PostLoad.dsa script (see 4 below) each time MyNode is loaded into a scene on any target system, passing it any optional parameters you had set up in the Settings for the DataItem.
4. Write your PostLoad.dsa script, based on http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/elements/post_load_script_data_item_read/start:  The script creates and installs a callback for each event/signal you want to process - some examples: Scene::timeChanging(), or DzProperty::valueChanged() of e.g. a slider you created on MyNode, etc.  Save this script as per sScriptRelPath in step 2 above.  You could have each callback call its own dedicated script, or have them all call a single ProcessChange.dsa script as I did:
5. Write your ProcessChange.dsa script(s), based on the samples, e.g. callback_property_current_value_changed_renderer  I use a single .dsa that contains utility routines used by all the event-handlers, and it uses CallBack.getSender() to determine which signal triggered each particular call.  This is where you script whatever behaviour you want.  I put this script in the same directory as the PostLoad.dsa  As long as this script launches no modal dialogs it won't be "blocking".  For User interaction I use custom Properties of MyNode created by Edit Mode > Create New Property... in the Parameters Pane, with CallBacks set up to ProcessChange.dsa.  The other main thing to be aware of  for such script(s) is:  The script gets (Re-)Loaded each time one of its CallBacks is triggered, which means that none of its data persist between calls.  I get around this by storing all needed data in the DzSettings of a DzSimpleElementData in MyNode, installed via MyNode.addDataItem() and retrieved via MyNode.findDataItem().
6. Whenever you want your scripted facility in a scene, just Merge the MyNode subset .duf into that scene, save the scene, and re-load it.

Give it a try!

 

 

onix

Oh, what luck, just found your previous discussion about that issue and you replied here. 

If I understand correctly, Scene::timeChanging() is some sort of timer event which can be used for polling, so that may work because this is what my script should be doing by itself. But I wonder if the script will be reloaded over 4000 times a second how it will affect performance.

Creating a plugin is kinda out fo question for several reasons. so I am keeping all options open. I will have to try it and see what happens. 

p.s. Since you were trying to do it did you ever encountered any problems?

p.p.s.  timeChanging()  seems to be not a timer but timeline so it is not useful here.

p.p.p.s  Great, in the simple test, everything seems to work without any problems or crashes so far.  Also, scripts can be unblocked with just a few small changes.

the next goal is to actually make things go wrong to test Rob's theory.

 

 

Praxis

onix said:

p.s.2  timeChanging()  seems to be not a timer but timeline so it is not useful here.

Yes, timeChanging() is triggered only at each Frame of an animation.  You probably want DzTimer instead.

 

onix said:

 

p.s. Since you were trying to do it did you ever encountered any problems?

I've had no problems - but I'm not using Scene::timeChanging() or DzTimer::timeout().  My CallBacks project is just a Sun control that does a better job than the built-in Iray Sun Dial - it only has to respond to occasional User-initiated events such as changing the Latitude slider value, etc.  You VR project is much more ambitious - Good Luck!

 

 

 

onix

 Since you said "it seemed like a good idea at the time, but it wasn't." I expected that you encountered some problems. But I guess I will be the first who ever made such a thing.

But thanks anyway because your post made it possible :)