ik chains bug (ticket submitted)

Comments

• Padone Posts: 3,476

  October 2019 edited October 2019

  UPDATE. I didn't receive any reply yet, this is somewhat odd since with other bug reports I usually got a reply within a couple of days .. let's wait for the next week.

  Post edited by Padone on October 2019
• Ruphuss Posts: 2,631

  October 2019

  so you really can fix feet to the ground for animation without any tremor ?

  never got this to work in studio
• Padone Posts: 3,476

  October 2019 edited October 2019

  Yes of course, this is what ik chains are for. Unfortunately it seems something is lost when saving and reloading the scene so it doesn't work as expected.

  See https://www.daz3d.com/forums/discussion/357776/ik-chains-explained

  Post edited by Padone on October 2019
• nonesuch00 Posts: 17,922

  October 2019

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.
• Padone Posts: 3,476

  October 2019

  nonesuch00 said:

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.

  That seems useful to be aware of. Please explain it better or point us to a discussion about it.
• wolf359 Posts: 3,762

  October 2019

  Ruphuss said:

  so you really can fix feet to the ground for animation without any tremor ?

  never got this to work in studio

  It will NOT automatically prevent foot/floor penetration during locomotion like a true IK solver would
• Padone Posts: 3,476

  October 2019 edited October 2019

  wolf359 said:

  It will NOT automatically prevent foot/floor penetration during locomotion like a true IK solver would

  I understand what you mean, but I guess it is better to comment on this to avoid confusion. A ik solver only cares about ik goals, so by itself it has nothing to do with constaints. A collision constraint to avoid object penetration may be implemented in professional animation packages and/or in advanced premade rigs.

  Actually daz studio only implements a first version of ik chains. It doesn't provide a premade human rig using ik chains. It doesn't provide advanced constraints. But you can use the ik chains to make your own rigs, that will allow to keep the ik goals in place during animation. For example to avoid the feet "sliding" among keyframes as it happens with 4.11 and below.

  Again https://www.daz3d.com/forums/discussion/357776/ik-chains-explained

  Post edited by Padone on October 2019
• wolf359 Posts: 3,762

  October 2019

  Foot to floor contact solving is an integral part of any IK system and has existed for decades. Even the vestigial poser has it. A global infinate floor plane that becomes impenetrable when ik is activated. Iclone pro has the same. except that iclone's can be toggled off for foot or hands in the same session (unlike poser which is all or nothing per session) Now that I am running DS 4.12, I can clearly see that calling this an IK system is quite a Charitable appelation. This system is effectively an upgrade of the old pin system that has to compete with the pose controls that were designed for still posing ....not Root locomotion.
• nonesuch00 Posts: 17,922

  October 2019

  Padone said:

  nonesuch00 said:

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.

  That seems useful to be aware of. Please explain it better or point us to a discussion about it.

  If there are nested groups (example you created groups and named them but as anyone that's bought a lot of DAZ 3D products from their store knows many products have nested groups in them already) and you open an animation you've made on the DS timeline that exceeds 30 frames and then go to the aniMate2 tab and just look around in the GUI on that tab by scrolling the timeline on that tab for example, what happens is the animation you made on the original timeline gets erased. It's still actually there but you have no access to it because the initialization process of transferring animate2 data to the DAZ Studio timeline clobbers it. To recover it you have to quit DAZ Studio without saving the scene and then reopen the scene.

  I remember also in the 4.12.x public beta thread in the DAZ Discussions section of the forum forum user Ivy complained about the same bug towards the being of the introduction of these new features.

  Furthermore, when I say there is a problem with nested grouping I've since discovered another bug in DAZ Studio related to nested grouping but unrelated to animation. If you use the Geometry Editor with nested groups in it to do something like hide toes that are poking through boots in a character that is a child of those nested groups then the geometry you hide (the toes in this example) only stays hidden as long as the geometry editor remains active. If you switch from the geometry editor to the translate gizmo as one example the hidden geometry reappears in the viewport and in any renders.

  In the examples about one nested group was three groups deep and another was four groups deep. The geometry editor bug disappears if the number of nested groups is 0, 1, or (maybe) 2. 

  I've submitted bug reports along with videos and scene duf and the DAZ 3D workers have reproduced both bugs.

  So if you like organizing your scenes by using groups & nesting those groups thematically you can be pretty sure that you are unintentionally causing all sorts of DAZ Studio functionality to not 'quite work as intended'. 

  Here you can see the way I've made my own groups in the attached image. The groups I've created aren't some radical never done before concept. It's expected they'd be used to organize scene data.

  Bug Report 307064

   

  So, I'm not sure if bug reports I file can be read by the public but the two bug reports I speak of are 307064 and 306870. Note that the 306870 bug has been marked as solved but it has not been. The original DAZ worker handed the bug report 306870 over to the DAZ worker handling 307064 for them to handle since it's expected that fixing the messing up 'group' functionality has a good chance of fixing both these bugs (and potentially a lot of other bugs). I'm not sure why they closed it already because although it's a very good guess fixing the group functionality will fix both bugs that's not been actually proven in code and tests yet.

  Since groups are naturally a way to organize and separate objects created via instantiation it's likely that the recent decision to stop multiple instances of the same version of DAZ Studio from running at the same time is related to the two bugs I mentioned above.

  Furthermore, I forgot to mention I also filed a bug related to 'duplicating node hierarchy' of the 'Eastern Dragon' that has an IK chain as part of the original product that's for sale in the DAZ 3D Store; well, doing that causes DAZ Studio to crash dump on me when I do it in DAZ Studio 4.12+ Again, this is likely related to group and instance code in DAZ Studio. That bug is 306668.

  So there you have it. 3 bugs I've reported in the month after DAZ 3D released the animation improvements with the 4.12.x series that all seem to be different but actually are pointing the finger at group and instance functionality. Those bugs are why after my initial excitement to try out the improved animation capabilities I stopped trying to learn animation in DAZ Studio. While I'm confident DAZ programmers will eventually fix the bugs you have to admit it's a big row to hoe as it's likely a pervasive mistake that requires the code to be meticulously worked through and tested.

  Also, a lot of those 'non-reproducible' render bugs we've all encountered in the past at one time or another, whether iRay or 3DL, might be manifestations of incorrect tree traversal because of broken instancing and grouping.

  I'm not complaining about the bugs, they happen, especially with such complicated code and algorithms, but I think if you find a bug and have in inkling of how to reproduce the bug you should report it to DAZ 3D as I know from the nature of these 3 bugs these have been around for at least 3 years. I also think you should submit the scene duf used to produce the bug to them and a video of you reproducing the bug, although I didn't actually submit a video until they requested it (because I had to go and download and install the freeware version of Bandicam to do that). 
• Richard Haseltine Posts: 96,712

  October 2019

  nonesuch00 said:

  Padone said:

  nonesuch00 said:

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.

  That seems useful to be aware of. Please explain it better or point us to a discussion about it.

  If there are nested groups (example you created groups and named them but as anyone that's bought a lot of DAZ 3D products from their store knows many products have nested groups in them already) and you open an animation you've made on the DS timeline that exceeds 30 frames and then go to the aniMate2 tab and just look around in the GUI on that tab by scrolling the timeline on that tab for example, what happens is the animation you made on the original timeline gets erased. It's still actually there but you have no access to it because the initialization process of transferring animate2 data to the DAZ Studio timeline clobbers it. To recover it you have to quit DAZ Studio without saving the scene and then reopen the scene.

  I remember also in the 4.12.x public beta thread in the DAZ Discussions section of the forum forum user Ivy complained about the same bug towards the being of the introduction of these new features.

  Furthermore, when I say there is a problem with nested grouping I've since discovered another bug in DAZ Studio related to nested grouping but unrelated to animation. If you use the Geometry Editor with nested groups in it to do something like hide toes that are poking through boots in a character that is a child of those nested groups then the geometry you hide (the toes in this example) only stays hidden as long as the geometry editor remains active. If you switch from the geometry editor to the translate gizmo as one example the hidden geometry reappears in the viewport and in any renders.

  In the examples about one nested group was three groups deep and another was four groups deep. The geometry editor bug disappears if the number of nested groups is 0, 1, or (maybe) 2. 

  I've submitted bug reports along with videos and scene duf and the DAZ 3D workers have reproduced both bugs.

  So if you like organizing your scenes by using groups & nesting those groups thematically you can be pretty sure that you are unintentionally causing all sorts of DAZ Studio functionality to not 'quite work as intended'. 

  Here you can see the way I've made my own groups in the attached image. The groups I've created aren't some radical never done before concept. It's expected they'd be used to organize scene data.

  Bug Report 307064

   

  So, I'm not sure if bug reports I file can be read by the public but the two bug reports I speak of are 307064 and 306870. Note that the 306870 bug has been marked as solved but it has not been. The original DAZ worker handed the bug report 306870 over to the DAZ worker handling 307064 for them to handle since it's expected that fixing the messing up 'group' functionality has a good chance of fixing both these bugs (and potentially a lot of other bugs). I'm not sure why they closed it already because although it's a very good guess fixing the group functionality will fix both bugs that's not been actually proven in code and tests yet.

  I think it's fairly normal to close a report that is linked to a different report, it avoids duplication of effort

  nonesuch00 said:

  Since groups are naturally a way to organize and separate objects created via instantiation it's likely that the recent decision to stop multiple instances of the same version of DAZ Studio from running at the same time is related to the two bugs I mentioned above.

  Totally diiferent kinds of instance, so I feel pretty sure I can say there is no connection at all.

  nonesuch00 said:

  Furthermore, I forgot to mention I also filed a bug related to 'duplicating node hierarchy' of the 'Eastern Dragon' that has an IK chain as part of the original product that's for sale in the DAZ 3D Store; well, doing that causes DAZ Studio to crash dump on me when I do it in DAZ Studio 4.12+ Again, this is likely related to group and instance code in DAZ Studio. That bug is 306668.

  Again, I see no connection to application isntances - there was a bug related to IK in legacy figuers, which was fixed in 4.12.1.x - do you still see the crash in the current Public Build?

  nonesuch00 said:

  So there you have it. 3 bugs I've reported in the month after DAZ 3D released the animation improvements with the 4.12.x series that all seem to be different but actually are pointing the finger at group and instance functionality. Those bugs are why after my initial excitement to try out the improved animation capabilities I stopped trying to learn animation in DAZ Studio. While I'm confident DAZ programmers will eventually fix the bugs you have to admit it's a big row to hoe as it's likely a pervasive mistake that requires the code to be meticulously worked through and tested.

  Groups, yes, but nothing there is related to instances - duplication is not instancing, about the only thing they have in common, that I can think of, is creating new nodes in the scene.

  nonesuch00 said:

  Also, a lot of those 'non-reproducible' render bugs we've all encountered in the past at one time or another, whether iRay or 3DL, might be manifestations of incorrect tree traversal because of broken instancing and grouping.

  Again, I am not seeing any connection here. This seems like a case of having a hammer and so everything looks like a nail.

  nonesuch00 said:

  I'm not complaining about the bugs, they happen, especially with such complicated code and algorithms, but I think if you find a bug and have in inkling of how to reproduce the bug you should report it to DAZ 3D as I know from the nature of these 3 bugs these have been around for at least 3 years. I also think you should submit the scene duf used to produce the bug to them and a video of you reproducing the bug, although I didn't actually submit a video until they requested it (because I had to go and download and install the freeware version of Bandicam to do that). 

   
• Padone Posts: 3,476

  October 2019 edited October 2019

  nonesuch00 said:

  If there are nested groups .. what happens is the animation you made on the original timeline gets erased .. To recover it you have to quit DAZ Studio without saving the scene and then reopen the scene.

  So if you like organizing your scenes by using groups & nesting those groups thematically you can be pretty sure that you are unintentionally causing all sorts of DAZ Studio functionality to not 'quite work as intended'.

  I'm not complaining about the bugs, they happen .. as I know from the nature of these 3 bugs these have been around for at least 3 years.

  Thank you for the explanation and the workaround. Yes I saw other discussions reporting problems with nested groups. As for bugs being around for 3 years I guess either they consider them not critical, or fixing them would require some major reworking. Personally what I really can't understand is why they don't list the well known bugs in the known issues section. I mean there's a known issues section in any new release, what's for then ?

  Post edited by Padone on October 2019
• Padone Posts: 3,476

  October 2019

  UPDATE. The daz support says the bug has been reported to the developers. They'll let me know any news.
• nonesuch00 Posts: 17,922

  October 2019

  Richard Haseltine said:

  nonesuch00 said:

  Padone said:

  nonesuch00 said:

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.

  That seems useful to be aware of. Please explain it better or point us to a discussion about it.

  If there are nested groups (example you created groups and named them but as anyone that's bought a lot of DAZ 3D products from their store knows many products have nested groups in them already) and you open an animation you've made on the DS timeline that exceeds 30 frames and then go to the aniMate2 tab and just look around in the GUI on that tab by scrolling the timeline on that tab for example, what happens is the animation you made on the original timeline gets erased. It's still actually there but you have no access to it because the initialization process of transferring animate2 data to the DAZ Studio timeline clobbers it. To recover it you have to quit DAZ Studio without saving the scene and then reopen the scene.

  I remember also in the 4.12.x public beta thread in the DAZ Discussions section of the forum forum user Ivy complained about the same bug towards the being of the introduction of these new features.

  Furthermore, when I say there is a problem with nested grouping I've since discovered another bug in DAZ Studio related to nested grouping but unrelated to animation. If you use the Geometry Editor with nested groups in it to do something like hide toes that are poking through boots in a character that is a child of those nested groups then the geometry you hide (the toes in this example) only stays hidden as long as the geometry editor remains active. If you switch from the geometry editor to the translate gizmo as one example the hidden geometry reappears in the viewport and in any renders.

  In the examples about one nested group was three groups deep and another was four groups deep. The geometry editor bug disappears if the number of nested groups is 0, 1, or (maybe) 2. 

  I've submitted bug reports along with videos and scene duf and the DAZ 3D workers have reproduced both bugs.

  So if you like organizing your scenes by using groups & nesting those groups thematically you can be pretty sure that you are unintentionally causing all sorts of DAZ Studio functionality to not 'quite work as intended'. 

  Here you can see the way I've made my own groups in the attached image. The groups I've created aren't some radical never done before concept. It's expected they'd be used to organize scene data.

  Bug Report 307064

   

  So, I'm not sure if bug reports I file can be read by the public but the two bug reports I speak of are 307064 and 306870. Note that the 306870 bug has been marked as solved but it has not been. The original DAZ worker handed the bug report 306870 over to the DAZ worker handling 307064 for them to handle since it's expected that fixing the messing up 'group' functionality has a good chance of fixing both these bugs (and potentially a lot of other bugs). I'm not sure why they closed it already because although it's a very good guess fixing the group functionality will fix both bugs that's not been actually proven in code and tests yet.

  I think it's fairly normal to close a report that is linked to a different report, it avoids duplication of effort

  nonesuch00 said:

  Since groups are naturally a way to organize and separate objects created via instantiation it's likely that the recent decision to stop multiple instances of the same version of DAZ Studio from running at the same time is related to the two bugs I mentioned above.

  Totally diiferent kinds of instance, so I feel pretty sure I can say there is no connection at all.

  nonesuch00 said:

  Furthermore, I forgot to mention I also filed a bug related to 'duplicating node hierarchy' of the 'Eastern Dragon' that has an IK chain as part of the original product that's for sale in the DAZ 3D Store; well, doing that causes DAZ Studio to crash dump on me when I do it in DAZ Studio 4.12+ Again, this is likely related to group and instance code in DAZ Studio. That bug is 306668.

  Again, I see no connection to application isntances - there was a bug related to IK in legacy figuers, which was fixed in 4.12.1.x - do you still see the crash in the current Public Build?

  nonesuch00 said:

  So there you have it. 3 bugs I've reported in the month after DAZ 3D released the animation improvements with the 4.12.x series that all seem to be different but actually are pointing the finger at group and instance functionality. Those bugs are why after my initial excitement to try out the improved animation capabilities I stopped trying to learn animation in DAZ Studio. While I'm confident DAZ programmers will eventually fix the bugs you have to admit it's a big row to hoe as it's likely a pervasive mistake that requires the code to be meticulously worked through and tested.

  Groups, yes, but nothing there is related to instances - duplication is not instancing, about the only thing they have in common, that I can think of, is creating new nodes in the scene.

  nonesuch00 said:

  Also, a lot of those 'non-reproducible' render bugs we've all encountered in the past at one time or another, whether iRay or 3DL, might be manifestations of incorrect tree traversal because of broken instancing and grouping.

  Again, I am not seeing any connection here. This seems like a case of having a hammer and so everything looks like a nail.

  nonesuch00 said:

  I'm not complaining about the bugs, they happen, especially with such complicated code and algorithms, but I think if you find a bug and have in inkling of how to reproduce the bug you should report it to DAZ 3D as I know from the nature of these 3 bugs these have been around for at least 3 years. I also think you should submit the scene duf used to produce the bug to them and a video of you reproducing the bug, although I didn't actually submit a video until they requested it (because I had to go and download and install the freeware version of Bandicam to do that). 

   

  No, everything doesn't look like a nail I'm afraid. If one creates an instance that has one or more groups in it, than instancing depends on groups and those groups on that instance as well as the original. And nested groups that contain instances? As they're both able to be used in any scene you'd care to make in DAZ you'd be able to knock me other with a feather if those two things having bugs in their implementation don't wind up causing all sorts of problems in the program. The object oriented nesting of groups and instances with all the inheritance that goes on in those scenes means you really have a case of of almost every bug you care to name in DAZ Studio can reverberate in unexpected ways in the inheritance chains depending on how you set up your scene because those properties and such are inherited in different ways depending on how you set up your scene. They've fixed in the past summer two or three cases where that has happened with some properties being inherited incorrectly. At any rate, my opinion is unimportant, they have the design docs and the code and the various bug reports.

  Also, as they've not closed either the aniMate2 bug I reported or the case of duplicating a node hierarchy using the Eastern Dragon I haven't checked to see if they work because their ticketing / bug tracking system tells me those things don't work because the tickets are still open.

  Aso, closing that Geometry Editor bug without it actually being fixed is very inconvenient because how do I know if it gets fixed now? I have to instead watch the aniMate2 bug ticket I wrote and test to see if both of those test case scenarios I submitted are broken.
• Richard Haseltine Posts: 96,712

  October 2019

  nonesuch00 said:

  Richard Haseltine said:

  nonesuch00 said:

  Padone said:

  nonesuch00 said:

  I've also have for over a month a bug report submitted about the initialization of the animation system in DAZ Studio (all versions but 4.12+ is what's going to get fixed). It's a big problem.

  That seems useful to be aware of. Please explain it better or point us to a discussion about it.

  If there are nested groups (example you created groups and named them but as anyone that's bought a lot of DAZ 3D products from their store knows many products have nested groups in them already) and you open an animation you've made on the DS timeline that exceeds 30 frames and then go to the aniMate2 tab and just look around in the GUI on that tab by scrolling the timeline on that tab for example, what happens is the animation you made on the original timeline gets erased. It's still actually there but you have no access to it because the initialization process of transferring animate2 data to the DAZ Studio timeline clobbers it. To recover it you have to quit DAZ Studio without saving the scene and then reopen the scene.

  I remember also in the 4.12.x public beta thread in the DAZ Discussions section of the forum forum user Ivy complained about the same bug towards the being of the introduction of these new features.

  Furthermore, when I say there is a problem with nested grouping I've since discovered another bug in DAZ Studio related to nested grouping but unrelated to animation. If you use the Geometry Editor with nested groups in it to do something like hide toes that are poking through boots in a character that is a child of those nested groups then the geometry you hide (the toes in this example) only stays hidden as long as the geometry editor remains active. If you switch from the geometry editor to the translate gizmo as one example the hidden geometry reappears in the viewport and in any renders.

  In the examples about one nested group was three groups deep and another was four groups deep. The geometry editor bug disappears if the number of nested groups is 0, 1, or (maybe) 2. 

  I've submitted bug reports along with videos and scene duf and the DAZ 3D workers have reproduced both bugs.

  So if you like organizing your scenes by using groups & nesting those groups thematically you can be pretty sure that you are unintentionally causing all sorts of DAZ Studio functionality to not 'quite work as intended'. 

  Here you can see the way I've made my own groups in the attached image. The groups I've created aren't some radical never done before concept. It's expected they'd be used to organize scene data.

  Bug Report 307064

   

  So, I'm not sure if bug reports I file can be read by the public but the two bug reports I speak of are 307064 and 306870. Note that the 306870 bug has been marked as solved but it has not been. The original DAZ worker handed the bug report 306870 over to the DAZ worker handling 307064 for them to handle since it's expected that fixing the messing up 'group' functionality has a good chance of fixing both these bugs (and potentially a lot of other bugs). I'm not sure why they closed it already because although it's a very good guess fixing the group functionality will fix both bugs that's not been actually proven in code and tests yet.

  I think it's fairly normal to close a report that is linked to a different report, it avoids duplication of effort

  nonesuch00 said:

  Since groups are naturally a way to organize and separate objects created via instantiation it's likely that the recent decision to stop multiple instances of the same version of DAZ Studio from running at the same time is related to the two bugs I mentioned above.

  Totally diiferent kinds of instance, so I feel pretty sure I can say there is no connection at all.

  nonesuch00 said:

  Furthermore, I forgot to mention I also filed a bug related to 'duplicating node hierarchy' of the 'Eastern Dragon' that has an IK chain as part of the original product that's for sale in the DAZ 3D Store; well, doing that causes DAZ Studio to crash dump on me when I do it in DAZ Studio 4.12+ Again, this is likely related to group and instance code in DAZ Studio. That bug is 306668.

  Again, I see no connection to application isntances - there was a bug related to IK in legacy figuers, which was fixed in 4.12.1.x - do you still see the crash in the current Public Build?

  nonesuch00 said:

  So there you have it. 3 bugs I've reported in the month after DAZ 3D released the animation improvements with the 4.12.x series that all seem to be different but actually are pointing the finger at group and instance functionality. Those bugs are why after my initial excitement to try out the improved animation capabilities I stopped trying to learn animation in DAZ Studio. While I'm confident DAZ programmers will eventually fix the bugs you have to admit it's a big row to hoe as it's likely a pervasive mistake that requires the code to be meticulously worked through and tested.

  Groups, yes, but nothing there is related to instances - duplication is not instancing, about the only thing they have in common, that I can think of, is creating new nodes in the scene.

  nonesuch00 said:

  Also, a lot of those 'non-reproducible' render bugs we've all encountered in the past at one time or another, whether iRay or 3DL, might be manifestations of incorrect tree traversal because of broken instancing and grouping.

  Again, I am not seeing any connection here. This seems like a case of having a hammer and so everything looks like a nail.

  nonesuch00 said:

  I'm not complaining about the bugs, they happen, especially with such complicated code and algorithms, but I think if you find a bug and have in inkling of how to reproduce the bug you should report it to DAZ 3D as I know from the nature of these 3 bugs these have been around for at least 3 years. I also think you should submit the scene duf used to produce the bug to them and a video of you reproducing the bug, although I didn't actually submit a video until they requested it (because I had to go and download and install the freeware version of Bandicam to do that). 

   

  No, everything doesn't look like a nail I'm afraid. If one creates an instance that has one or more groups in it, than instancing depends on groups and those groups on that instance as well as the original. And nested groups that contain instances? As they're both able to be used in any scene you'd care to make in DAZ you'd be able to knock me other with a feather if those two things having bugs in their implementation don't wind up causing all sorts of problems in the program. The object oriented nesting of groups and instances with all the inheritance that goes on in those scenes means you really have a case of of almost every bug you care to name in DAZ Studio can reverberate in unexpected ways in the inheritance chains depending on how you set up your scene because those properties and such are inherited in different ways depending on how you set up your scene. They've fixed in the past summer two or three cases where that has happened with some properties being inherited incorrectly. At any rate, my opinion is unimportant, they have the design docs and the code and the various bug reports.

  Also, as they've not closed either the aniMate2 bug I reported or the case of duplicating a node hierarchy using the Eastern Dragon I haven't checked to see if they work because their ticketing / bug tracking system tells me those things don't work because the tickets are still open.

  Aso, closing that Geometry Editor bug without it actually being fixed is very inconvenient because how do I know if it gets fixed now? I have to instead watch the aniMate2 bug ticket I wrote and test to see if both of those test case scenarios I submitted are broken.

  Instances of objects in DS have absolutely no connection to running isntances of the application was one of my points. Grouping and instancing (objects) are also not the same thing, or inherently related in any way as far as I know, though instances can be - and often are - grouped.
• Ivy Posts: 7,153

  October 2019 edited October 2019

  Padone said:

  UPDATE. The daz support says the bug has been reported to the developers. They'll let me know any news.

  Thanks @Padone  I've been following your progress with this ik-issues on both your threads I have reported that same issue with the ik-chain slide around with daz 4.12.0.31 . so it something you might try once you get your ik-chain and animation the way you like it bake them into the timeline  it will take the bake fine. and they will save and reload okay,... But the one thing i have notice is on reloading the scene the ik-chain of the character jumps off-set left or right beyond the keyframe. I am not sure whats causing that . but it happens pretty regularly to me. &  i have not upgraded to 4.12.1.16 because of the only 1 instance at a time allowed open issue of that version of beta.  so there would be no sense in me submitting a bug report on the ik-chain slide for daz4.12.0.35. you may want to test it though if you have 4.12.1.16 installed  , I love your details your putting out keep up the good work

  Post edited by Ivy on October 2019
• Padone Posts: 3,476

  October 2019

  Ivy said:

  .. on reloading the scene the ik-chain of the character jumps off-set left or right beyond the keyframe.

  Yes this happens to me too sometime, but I cannot understand what's trigging it. For sure something is lost in the ik chains when saving and reloading the scene. I trust this issue will be fixed in the next release, or the ik chains would be rather unuseful all together.
• PDSmith Posts: 712

  August 2020

  Padone,

  Okay I know this is an old thread, but has anyone heard of the IK Chain fix with the latest version of Studio Beta?  Since 12 came into being this IK chain has borked pretty much anything that uses it. I'd reported it with Studio with in a week of it occuring and heard nothing for weeks. the problem was never resolved on my end, so was it on your end?

    Any legacy figure, any animal or creature of beast that uses the IK Chain is affected by this change.

  Richard,  is there a way to not have Studio load it with the older legacy figures? or lock the ik chains so they have zero effect?  If so, anyone else...please spell it out in the most simple and basic of layman terms. Thank you.

  -P.