Loading...
> >

Daz Studio 4.12 Pro, General Release! (*UPDATED*)

1…2223242527

Comments

  • jpetersen1jpetersen1 Posts: 148
    edited October 2020

    I just upgraded to 4.12.2.50 64-bit Public Build.

    I can load a file. but the Viewport goes black, the two drop-down menus in the Viewport disappear. No way to see the assets.

    The file Renders, but if I try to Save As, the app crashes.

    Post edited by jpetersen1 on
  • DoctorJellybeanDoctorJellybean Posts: 7,890

    Did you perhaps upgraded while DS was running? Video drivers up to date?

  • jpetersen1jpetersen1 Posts: 148
    edited October 2020

    No, the old version wasn't running when I upgraded.

    My video drivers are up to date as of a few months ago.

    I used DIM to install all the files related to the 4.12.2.50 64-bit Public Build release.

     

    The same thing happens each time. I select an existing Scene that I've saved previously. I need to edit and render. It loads. The Viewport goes black. The two viewport dropdown menus disappear (it's not a problem with lights). I can render. If I try to save the Scene after rendering, the app crashes. There's no way to view, edit or save a Scene.

    Well, now the app won't even load. I guess I have to go back to square one... uninstall and reinstall. I wasn't having problems with the older version. I wish I had never upgraded.

    Post edited by jpetersen1 on
  • TotteTotte Posts: 13,497
    jpetersen1 said:

    No, the old version wasn't running when I upgraded.

    My video drivers are up to date as of a few months ago.

    I used DIM to install all the files related to the 4.12.2.50 64-bit Public Build release.

     

    The same thing happens each time. I select an existing Scene that I've saved previously. I need to edit and render. It loads. The Viewport goes black. The two viewport dropdown menus disappear (it's not a problem with lights). I can render. If I try to save the Scene after rendering, the app crashes. There's no way to view, edit or save a Scene.

    Well, now the app won't even load. I guess I have to go back to square one... uninstall and reinstall. I wasn't having problems with the older version. I wish I had never upgraded.

    Have you checked the video optiomization settings?
    Which machine, videocard and OS version does this happen on?

  • jpetersen1jpetersen1 Posts: 148
    edited October 2020

    Okay. I de-installed, re-installed. This information might be important to others, as well. I did some trouble-shooting...

    The same problems were there after re-installing so... I closed and re-started the app.

    This time, instead of trying to load in one of my scenes (which were created with the old version), I created a completely fresh scene when I opened the app. I saved it as a scene. THEN I loaded in my old scene, and this time I was able to save the old Scene with the new version without the app crashing (there might be other problems, but I'll deal with those as they come up).

    In other words, SOMETHING about the old scene is confusing the new app. But... if you create a fresh Scene and render it, and save the Scene, and then load the scene from the older version it works. So... I don't know what kind of meta-data DS might be using, or what kind of configuration is happening before or during a render, but it seems to require a freshly created scene FIRST before loading in the old ones, otherwise there is something it doesn't recognize or process correctly.

     

    I have several plugins, including LAMH, so I don't know whether those parameters are confusing the new version, but maybe this is enough information to give a heads-up about bringing older Scenes (including those created with help from plugins) into the new version of DS.

     

    Post edited by jpetersen1 on
  • TotteTotte Posts: 13,497

    Plugins can cause a multitude of issues specially they are old.
    I have some here (mac os 14.6) but I can open older scenes and I do have reality installed still, and LAHM and some others. you could disable plugins you no longer use just to see if that fixes it.

     

  • dramenondramenon Posts: 52
    Richard Haseltine said:
    pkinnane_44e978d933 said:
    RayDAnt said:
    ooofest said:
    Fixmypcmike said:

    Either Daz Studio or the Octane plugin clearly isn't getting some sort of expected response from the other needed to complete the shutdown process. And given that the Iray plugin clearly is getting whatever communique it needs in at least one of these final two test cases, I'm inclined to believe that this is a fault with the Octane plugin and not Daz Studio itself.

    Hi - I have been investigating this issue.  It is still happening on 4.12.2.  I think I know why....

    The plugin calls DzMainWindow::addShutDownCheck(DzShutDownCheck *check) to register a DzShutDownCheck function.

    DzMainWindow::addShutDownCheck(DzShutDownCheck *check) is defined in dzmainwindow.h of the 4.5.0.114 SDK.  However it is not documented in the 4.5.0.114 SDK documentation.

    DzShutDownCheck is also not documented.

    Is it possible the DAZStudio 4.12.2 has changed the behavior of the DzShutDownCheck?

    Paul

    There are documents in the zip with the headers. As for the behaviour having chnaged, I'm told not and it seems that there's little to change since these features are used by the plug-in developer to clean up their code on close:

    The behavior of a DzShutDownCheck subclass is the responsibility of the developer of the plugin implementing it - DzShutDownCheck::needsCheck() and DzShutDownCheck::doCheck() are pure virtual member functions. When an instance of a DzShutDownCheck subclass is added to the list of shutdown checks, via DzMainWindow::addShutDownCheck(), it is placed in a list that is processed during the main window's close event, immediately before it emits the aboutToClose() signal. During said processing of said list, the DzShutDownCheck subclass' needsCheck() is called and its return value is used to determine whether or not its doCheck() should be called. If the DzShutDownCheck subclass' doCheck() is called and its return value is true, the application is allowed to continue closing. If, however, its return value is false, the close event for the main window is ignored - because the check has indicated that it is not ready (e.g., the user cancelled, data is not finished writing, etc) to shutdown.

    Is the reasolution to this on the Octane side? 

     > This symptom only started since Daz 4.12.1.17. < 

    Is this being addressed ? 
     

  • IvyIvy Posts: 7,153

    Happy Halloween

  • 3Diva3Diva Posts: 11,287
    Ivy said:

    Happy Halloween

    That's really cool! Nicely done, Ivy! :D

  • IvyIvy Posts: 7,153

    Thank you very much Diva :)

  • Dolce SaitoDolce Saito Posts: 148
    edited October 2020

    Just got the .60 Beta.

    - Filament doesn't work with "Scene Only" lights, where all lights are emissive wall/ceiling surfaces. It is just a black scene that way.

    - On a scene with 2+ hd characters, if filament is active (with dome light) and drawing settings -> tone mappings are 1.00 burn / 0.00 crush; increasing or decreasing exposure via +/- causes long wait time and during this time daz studio is unresponsive.

    Post edited by Dolce Saito on
  • ooofestooofest Posts: 36
    edited October 2020
    pkinnane_44e978d933 said:

    Hi Richard.  You can see above from the log I posted that doCheck is returning true, however DAZStudio is not shutting down.

     

    PluginDzShutDownCheck::doCheck() returning true

     

    So to me, this is looking like a DAZStudio bug - particularly is it has only just started happening with recent DAZStudio versions.

    Thanks

    Paul

    I previously reported this to Daz Support and they wanted to claim that it was an Otoy plugin issue, but from the logs I see above there does not appear to be anything wrong on that side - all the returns coming back from Daz look clean relative to the plugin's actions.  The conversation with Paul seems to have hit a wall.

    As a slightly frustrated Daz + Octane plugin user, I am wondering if this is considered a bug for their backlog, if I should once again open a ticket (and reference this conversation, or other consideration to take.

    Post edited by ooofest on
  • MEC4DMEC4D Posts: 5,249

    It is not that it don't works, this function is not enable in Filament draw style, Filament only reflect Enviorment , spot and distance light , no other surfaces or shaders so emitters will not work, it is a draw style not full render engine , same with glass shaders on a object in Filament , you need a background to see the object and not just vacuum space . Filament works best with Enviorment as reflections are the true reason for PBR

    felix_nukem said:

    Just got the .60 Beta.

    - Filament doesn't work with "Scene Only" lights, where all lights are emissive wall/ceiling surfaces. It is just a black scene that way.

    - On a scene with 2+ hd characters, if filament is active (with dome light) and drawing settings -> tone mappings are 1.00 burn / 0.00 crush; increasing or decreasing exposure via +/- causes long wait time and during this time daz studio is unresponsive.

     

  • PendraiaPendraia Posts: 3,591

    Very cool Ivy...

     

     

  • TotteTotte Posts: 13,497

    Love it! Very well done!

  • benniewoodellbenniewoodell Posts: 1,900

    Is anyone else having troubles with keyframes? With the new updates, both the general release and the beta, if I select a character, right click and select children, then go down to the timeline and click create a keyframe, it doesn't create a keyframe for all the bones. It was working just fine with whatever the latest release in July was which was the last time I was doing a lot of keyframing and needed to set keyframes to every bone to set poses. Did something change that I'm not aware of? 

    Also, I went back to 4.12.0.86 because I have Face Motion because the keyframes that are created with that script will not save in the later versions, and I realized a feature that was in that one that has been taken out of the newest versions. In that one, I am able to click on a keyframe and drag it along the timeline, whereas with the newest editions that function is not available. I have to open keymate in order to move the keyframes along the timeline. It seems for new folks to Daz that can't get Keymate anymore, they should be able to move keyframes around the timeline other than copy and pasting which has been breaking meshes for me (like the other day a character's eyes completely distorted to breaking apart). 

    But the not being able to select all children and then adding a keyframe for every bone not working is really hindering for animation. I'm just wondering if anyone else has that issue or if I'm the unlucky one trying to finish up this fight sequence and constantly having to hand key every single bone every few frames. 

  • ImagoImago Posts: 4,899

    I'm having same issues and I'm stuck on 4.12.0.86 like you and all the other animators.

    It looks like they have fixed something in the latest beta. the copy-paste works fine there but the keyframes must be created using the "Create keys" button on the timeline, otherwise you can't select and move them. For some reason the keys created moving the char in the workspace lacks of something that makes them impossible to move along timeline unlsess you select the root of the char and hit "create keys" using the "Node recursive" option on.

  • alexhcowleyalexhcowley Posts: 2,310
    jpetersen1 said:

    Okay. I de-installed, re-installed. This information might be important to others, as well. I did some trouble-shooting...

    The same problems were there after re-installing so... I closed and re-started the app.

    This time, instead of trying to load in one of my scenes (which were created with the old version), I created a completely fresh scene when I opened the app. I saved it as a scene. THEN I loaded in my old scene, and this time I was able to save the old Scene with the new version without the app crashing (there might be other problems, but I'll deal with those as they come up).

    In other words, SOMETHING about the old scene is confusing the new app. But... if you create a fresh Scene and render it, and save the Scene, and then load the scene from the older version it works. So... I don't know what kind of meta-data DS might be using, or what kind of configuration is happening before or during a render, but it seems to require a freshly created scene FIRST before loading in the old ones, otherwise there is something it doesn't recognize or process correctly.

     

    I have several plugins, including LAMH, so I don't know whether those parameters are confusing the new version, but maybe this is enough information to give a heads-up about bringing older Scenes (including those created with help from plugins) into the new version of DS.

     

    I seem to be having similar problems.  I downloaded and installed 4.12.1.118 today on my test and setup PC.  I managed to generate an Ultrascene scene and save it but when I specified file menu, new, the application immediately crashed.  I've also tried loading an old scene and part of Herschell Hoffmeyer's Hydra.   Both of these crashed on loading. 

    DAZ Studio then refuses to load until I reboot the PC.  As noted above, it then crashes whenever I try to do anything.  

    Any suggestions will be gratefully received. 

    Cheers,

    Alex.

  • IvyIvy Posts: 7,153
    Imago said:

    I'm having same issues and I'm stuck on 4.12.0.86 like you and all the other animators.

    It looks like they have fixed something in the latest beta. the copy-paste works fine there but the keyframes must be created using the "Create keys" button on the timeline, otherwise you can't select and move them. For some reason the keys created moving the char in the workspace lacks of something that makes them impossible to move along timeline unlsess you select the root of the char and hit "create keys" using the "Node recursive" option on.

    yes I too am afriad to move from the 4.12.0.86 public build thats what I am using too. 

  • IvyIvy Posts: 7,153

    @Pendraia &@Totte

    Thank you very much for the nice comments and watching :)

  • MEC4DMEC4D Posts: 5,249

    I saw it on Youtube , I give you a thumb up ! nice job as usual Ivy ! 

    Ivy said:

    @Pendraia &@Totte

    Thank you very much for the nice comments and watching :)

     

  • Richard HaseltineRichard Haseltine Posts: 96,696
    benniewoodell said:

    Is anyone else having troubles with keyframes? With the new updates, both the general release and the beta, if I select a character, right click and select children, then go down to the timeline and click create a keyframe, it doesn't create a keyframe for all the bones. It was working just fine with whatever the latest release in July was which was the last time I was doing a lot of keyframing and needed to set keyframes to every bone to set poses. Did something change that I'm not aware of? 

    The button at the bottom of the Timeline is for Create Keys (Filtered) - its exact behaviour is controlled by the drop-down menu next to it, the Key Creation Scope menu. Object creates keys for all nodes and properties on the object, and all of its children, even if the actual selection is a child; Node Recursive behaves like Object, but starts from the primary selection rather than the object (if they are not the same); Node keys only the Primary Selection. The last entry, Properties keys all properties selected in the Dopesheet - and those have to be seelcted as properties, not nodes or groups.

    Create Keys (Filtered) in the pane's option menu is not the same, and is not like the previous behaviour of the Timeline.

    It therefore matters how you are creating your keys.

    That said, there are still things being worked on here - for example, the Properties option not working on selected groups comes with a "currently" attached, and drag-and-drop is another area that is still receiving attention.

    benniewoodell said:

    Also, I went back to 4.12.0.86 because I have Face Motion because the keyframes that are created with that script will not save in the later versions, and I realized a feature that was in that one that has been taken out of the newest versions. In that one, I am able to click on a keyframe and drag it along the timeline, whereas with the newest editions that function is not available. I have to open keymate in order to move the keyframes along the timeline. It seems for new folks to Daz that can't get Keymate anymore, they should be able to move keyframes around the timeline other than copy and pasting which has been breaking meshes for me (like the other day a character's eyes completely distorted to breaking apart). 

    But the not being able to select all children and then adding a keyframe for every bone not working is really hindering for animation. I'm just wondering if anyone else has that issue or if I'm the unlucky one trying to finish up this fight sequence and constantly having to hand key every single bone every few frames. 

     

  • Richard HaseltineRichard Haseltine Posts: 96,696
    Imago said:

    I'm having same issues and I'm stuck on 4.12.0.86 like you and all the other animators.

    It looks like they have fixed something in the latest beta. the copy-paste works fine there but the keyframes must be created using the "Create keys" button on the timeline, otherwise you can't select and move them. For some reason the keys created moving the char in the workspace lacks of something that makes them impossible to move along timeline unlsess you select the root of the char and hit "create keys" using the "Node recursive" option on.

    Are you selecting the actual keys? And are you selecting then moving, rather than trying to do both with a single click? (The latter is acknowledged as a sub-optimal behaviour, though I think it may not always be necessary.)

  • benniewoodellbenniewoodell Posts: 1,900
    Richard Haseltine said:
    benniewoodell said:

    Is anyone else having troubles with keyframes? With the new updates, both the general release and the beta, if I select a character, right click and select children, then go down to the timeline and click create a keyframe, it doesn't create a keyframe for all the bones. It was working just fine with whatever the latest release in July was which was the last time I was doing a lot of keyframing and needed to set keyframes to every bone to set poses. Did something change that I'm not aware of? 

    The button at the bottom of the Timeline is for Create Keys (Filtered) - its exact behaviour is controlled by the drop-down menu next to it, the Key Creation Scope menu. Object creates keys for all nodes and properties on the object, and all of its children, even if the actual selection is a child; Node Recursive behaves like Object, but starts from the primary selection rather than the object (if they are not the same); Node keys only the Primary Selection. The last entry, Properties keys all properties selected in the Dopesheet - and those have to be seelcted as properties, not nodes or groups.

    Oh! Thanks so much for clearing that up, Richard. That drop down menu must either be new since my last animation project I did in June, or I must have accidentally changed it without knowing as I've honestly never paid attention to it before, it's always just the block that seperates the set key and the copy and paste key buttons to these tired eyes lol. It's set to node right now, I just tried object and the keyframes are coming in when I select all children and hit the set key button next to it. You just saved me hours of yelling at my screen lol, thank you! And thanks for letting me know there's more being worked on as well! 

  • IvyIvy Posts: 7,153
    MEC4D said:

    I saw it on Youtube , I give you a thumb up ! nice job as usual Ivy ! 

    Ivy said:

    @Pendraia &@Totte

    Thank you very much for the nice comments and watching :)

     

    Thank you Cath, I'm happy you enjoyed it. & I am greatly honored you follow my YT channel. smiley

  • ImagoImago Posts: 4,899
    Richard Haseltine said:
    Imago said:

    I'm having same issues and I'm stuck on 4.12.0.86 like you and all the other animators.

    It looks like they have fixed something in the latest beta. the copy-paste works fine there but the keyframes must be created using the "Create keys" button on the timeline, otherwise you can't select and move them. For some reason the keys created moving the char in the workspace lacks of something that makes them impossible to move along timeline unlsess you select the root of the char and hit "create keys" using the "Node recursive" option on.

    Are you selecting the actual keys? And are you selecting then moving, rather than trying to do both with a single click? (The latter is acknowledged as a sub-optimal behaviour, though I think it may not always be necessary.)

    I first select the keys and release the click then I click again and try to move them, exactly how I do in 4.12.0.86.

    In 4.12.0.86 works correctly, in next versions doesn't.

    But luckily in the latest beta something has been fixed but it still needs some work, asI said before, copy-paste works fine but only keys created with the commands in the timeline can be moved.

  • cm152335cm152335 Posts: 421
    alarm_dog_15d1b74c2d said:

    I'm running 4.12.1 on a Win10 laptop.

    Once I get booted up, it'll run for a few seconds, or a few minutes, and then just close spontaneously.

    Anybody else seeing this?

    Thanks!

    you must provide more infos than only - "win10 - laptop" 
    please provide infos about  - GB memory ? - video card type and memory ? 
    it supposed that you use an i7  provcessor!
     

  • dramenondramenon Posts: 52
    ooofest said:
    pkinnane_44e978d933 said:

    Hi Richard.  You can see above from the log I posted that doCheck is returning true, however DAZStudio is not shutting down.

     

    PluginDzShutDownCheck::doCheck() returning true

     

    So to me, this is looking like a DAZStudio bug - particularly is it has only just started happening with recent DAZStudio versions.

    Thanks

    Paul

    I previously reported this to Daz Support and they wanted to claim that it was an Otoy plugin issue, but from the logs I see above there does not appear to be anything wrong on that side - all the returns coming back from Daz look clean relative to the plugin's actions.  The conversation with Paul seems to have hit a wall.

    As a slightly frustrated Daz + Octane plugin user, I am wondering if this is considered a bug for their backlog, if I should once again open a ticket (and reference this conversation, or other consideration to take.

    Can someone at Daz acknowledge that this is a bug or needs a ticket. 
    If you use Octane render > You can not save any changed Preferences to Daz Studio because Daz Studio needs to be forced shutdown in the Windows Task Manager. 
     

  • Richard HaseltineRichard Haseltine Posts: 96,696
    pkinnane_44e978d933 said:

    Hi Richard.  You can see above from the log I posted that doCheck is returning true, however DAZStudio is not shutting down.

     

    PluginDzShutDownCheck::doCheck() returning true

     

    So to me, this is looking like a DAZStudio bug - particularly is it has only just started happening with recent DAZStudio versions.

    Thanks

    Paul

    I'm going to post this straight:

    Obviously we cannot see what is happening within the Octane plugin code, only what is happening around it when attached to the debugger.
    --
    There is a task/runnable that the Octane plugin is starting in the global thread pool that is not completing. Since Daz Studio (4.12+) is waiting for threads in the global thread pool to cleanup before it closes (to prevent crashes and/or potential data loss during shutdown), the application is not closing until cleanup of the global thread pool times out. This used to default to a very long time (i.e. many hours), but a pending release reduces this to 3 minutes max. This wait occurs after plugins are shut down [virtual void DzPlugin::shutdown()], but before the pane is deleted or the plugin is unloaded.
    --
    If this is a task/runnable that is truly intended to run for the duration of the plugin's lifetime, it should not use the global thread pool, rather it should use its own QThread instance.
    --
    Note, use of API such as QtConcurrent make use of the global thread pool.

  • mindsongmindsong Posts: 1,693

    maybe DAZ devs can add a 'save current workspace' (unnamed) menu/button, or "autosave workspace before likely-to-crash-render" preference checkbox so the constant crashes don't repeatedly return us to our pre-crash-shutdown state, or corrupt our current workspaces as we kill 'lost' DS instances floating in arbitrary states in the task manager (?)

    this would be useful, regardless the plugin "idiosynchracies" we may experience.

    I often start DS, reset my workspace and shut it back down, just to get a good workspace save before resuming my crash-render activities

    pffthhht

Sign In or Register to comment.