Is this the future of Studio? Not good.

13

Comments

  • Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Not all software developers are comfortable with making their source code available to someone to enable that person to maintain it after the original developer dies; I know of at least one application in common use that hasn't been updated in over a decade because the creator had a provision in his will that the source be destroyed after his death. And as far as scripts goes, they would need to save two copies to be able to make them available in the event the PA could no longer maintain them; I think this is part of the reason some freebie scripts are distributed as text versions.

     

  • Male-M3diaMale-M3dia Posts: 3,584
    edited March 2018
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

     

     

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Post edited by Male-M3dia on
  • TaozTaoz Posts: 10,264
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

  • Male-M3diaMale-M3dia Posts: 3,584
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

  • TaozTaoz Posts: 10,264
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

  • nemesis10nemesis10 Posts: 3,799
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    How about this other situation: you wish to sell your product at another store...do you allow Daz3d to retain intellectual control after you have left?  Even marriage has a "until death do you part" clause.  Your contract is that your product should work in the current version of software and there is no post death warranty for any piece of software in the world. If I were the survivor and someone came to me to release intellectual rights to something a departed loved one made, I think I would have hard words with them before I got law enforcement involved. Realistically, in everything in life, there is an alloted lifetime; If you get a dog, the dog will pass away and the provider of the dog doesn't have to give you another one.

  • Male-M3diaMale-M3dia Posts: 3,584
    edited March 2018
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    If you don't like the idea, then you sell your products outright before you die or you leave specific instructions. But this isn't the topic that was being discussed, it was that PAs should be required to give encryption keys to the store so when they die the store can use the products they don't actually own. If someone isn't keen on the idea of someone dying and their code not becoming usable, then it's probably best they don't use any indie software. Software offered in the 3D industry is no different than any software industry so the same rules will apply to all.

    Post edited by Male-M3dia on
  • TaozTaoz Posts: 10,264
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    If you don't like the idea, then you sell your products outright before you die or you leave specific instructions. But this isn't the topic that was being discussed, it was that PAs should be required to give encryption keys to the store so when they die the store can use the products they don't actually own. If someone isn't keen on the idea of someone dying and their code not becoming usable, then it's probably best they don't use any indie software. Software offered in the 3D industry is no different than any software industry so the same rules will apply to all.

    No rules are etched in stone, anything is potentially subject to change. And I'm just giving some suggestions that might benefit many without hurting anyone. Anyway, enough said.

  • Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    If you don't like the idea, then you sell your products outright before you die or you leave specific instructions. But this isn't the topic that was being discussed, it was that PAs should be required to give encryption keys to the store so when they die the store can use the products they don't actually own. If someone isn't keen on the idea of someone dying and their code not becoming usable, then it's probably best they don't use any indie software. Software offered in the 3D industry is no different than any software industry so the same rules will apply to all.

    I would like to point out, again, that with respect to scripts, there is no encryption in the sense of the "encrypted DAZ Connect content". Encrypted scripts are simply binary and limited to the minimum version of DAZ Studio that they were saved in; saving an ASCII version of the script can be done as well so it can be updated as needed, or provided to DaZ by the family if the PA wishes this to happen after they die. The same could be done for plug-ins, if desired, by this is ultimately up to the PA.
  • Male-M3diaMale-M3dia Posts: 3,584
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    If you don't like the idea, then you sell your products outright before you die or you leave specific instructions. But this isn't the topic that was being discussed, it was that PAs should be required to give encryption keys to the store so when they die the store can use the products they don't actually own. If someone isn't keen on the idea of someone dying and their code not becoming usable, then it's probably best they don't use any indie software. Software offered in the 3D industry is no different than any software industry so the same rules will apply to all.

     

    I would like to point out, again, that with respect to scripts, there is no encryption in the sense of the "encrypted DAZ Connect content". Encrypted scripts are simply binary and limited to the minimum version of DAZ Studio that they were saved in; saving an ASCII version of the script can be done as well so it can be updated as needed, or provided to DaZ by the family if the PA wishes this to happen after they die. The same could be done for plug-ins, if desired, by this is ultimately up to the PA.

    But that wasn't what was discussed.. what was discussed was a requirement which can't be done. Yes if PA wishes the ownership to be transferred at their death, it's up to them, but it can't be a requirement.

  • kyoto kidkyoto kid Posts: 41,880
    edited March 2018
    kyoto kid said:
    kyoto kid said:

    ...not enough for those stuck with CPU rendering though. Iray is optimised for GPU based rendering. 3DL for CPU rendering which is why I have moved back to the latter.

    I have to disagree with the blanket assertion. I ran a fairly complex scene with things that would grind 3DL to a slow grind and CPU iray ran it faster. Now if you're running fairly simple scenes, there may be a case, but rendering the same complex scenes, even CPU Iray renders it faster.

    ..running Iray to get hte optimal quality takes far too long on the CPU unless have a dual Xeon system (which most of us don't and it still takes longer than on the GPU). I have been rendering complex scenes in 3DL using IBL Master that take less than 15 min.

    I don't have that chip, yet that scene ran in about an hour. My computer is the exact same machine I've been using for 3DL before Iray was released. Again, if you're running things in 15 minutes, they absolutely don't have the things I (and certainly not the lighting quality) mentioned that would grind 3DL to a halt in those scenes so it's not a valid comparison. Before iray, using any SAV hairs was basically a no-no in 3DL... but iray just breezes through those hairs.

    ...this took under 12 minutes to render in 3DL at 1,500 x 1.050 (still a WIP but the latest version).

    Rendered on a 5+ year old system that has an i7 930 2.8 GHz CPU and 12 GB DDR3 1333 three channel memory.

    bus stop Danika rebuild.jpg
    1500 x 1125 - 1M
    Post edited by kyoto kid on
  • Oso3DOso3D Posts: 15,087

    KK: At a glance, it appears to lack SSS, bounce light, has a simple distant light + basic ambient light (maybe some AO).

    So it's essentially stripped down to a basic style of rendering.

    For roughly the same quality of render, you could do it with similar speeds in Iray CPU. Mind you, it wouldn't look the same; trade-offs are a little different in Iray; I expect the lighting would look a little better while it would look a little more grainy.

     

  • nemesis10nemesis10 Posts: 3,799
    kyoto kid said:
    kyoto kid said:
    kyoto kid said:

    ...not enough for those stuck with CPU rendering though. Iray is optimised for GPU based rendering. 3DL for CPU rendering which is why I have moved back to the latter.

    I have to disagree with the blanket assertion. I ran a fairly complex scene with things that would grind 3DL to a slow grind and CPU iray ran it faster. Now if you're running fairly simple scenes, there may be a case, but rendering the same complex scenes, even CPU Iray renders it faster.

    ..running Iray to get hte optimal quality takes far too long on the CPU unless have a dual Xeon system (which most of us don't and it still takes longer than on the GPU). I have been rendering complex scenes in 3DL using IBL Master that take less than 15 min.

    I don't have that chip, yet that scene ran in about an hour. My computer is the exact same machine I've been using for 3DL before Iray was released. Again, if you're running things in 15 minutes, they absolutely don't have the things I (and certainly not the lighting quality) mentioned that would grind 3DL to a halt in those scenes so it's not a valid comparison. Before iray, using any SAV hairs was basically a no-no in 3DL... but iray just breezes through those hairs.

    ...this took under 12 minutes to render in 3DL at 1,500 x 1.050 (still a WIP but the latest version).

    Rendered on a 5+ year old system that has an i7 930 2.8 GHz CPU and 12 GB DDR3 1333 three channel memory.

    I'm jealous... for me, Iray was a godsend becauise all of my 3dl renders took hours and hours...

  • kyoto kidkyoto kid Posts: 41,880
    edited March 2018

    ...if you were using UE, indeed, it crawled about as slow as Iray does on the CPU for me. In the attached pic I used Parris' new IBL Master

    Oso3D said:

    KK: At a glance, it appears to lack SSS, bounce light, has a simple distant light + basic ambient light (maybe some AO).

    So it's essentially stripped down to a basic style of rendering.

    For roughly the same quality of render, you could do it with similar speeds in Iray CPU. Mind you, it wouldn't look the same; trade-offs are a little different in Iray; I expect the lighting would look a little better while it would look a little more grainy.

     

    ...SSS is really only useful for close ups, this is a medium to wide shot.  As I mentioned, this is still a WIP or more correctly an "experiment in progress".

    Graininess is part of what bothers me about Iray . To me a "little more grainy" does not look "better" it looks like you used a low quality film.  

    This is a marked improvement over the original 3DL version I did over two years ago.  I wanted to keep everything in the scene the same as it was in the original for the most part so the characters are still G2 (the older lady, Steph 5 [Genesis "Classic]).  The only major differences is the sky backdrop as it has more depth than the flat photo background, and I used Skin Builder Pro on the three characters.

    Post edited by kyoto kid on
  • nemesis10nemesis10 Posts: 3,799
    kyoto kid said:

    ...if you were using UE, indeed, it crawled about as slow as Iray does on the CPU for me. In the attached pic I used Parris' new IBL Master

    Oso3D said:

    KK: At a glance, it appears to lack SSS, bounce light, has a simple distant light + basic ambient light (maybe some AO).

    So it's essentially stripped down to a basic style of rendering.

    For roughly the same quality of render, you could do it with similar speeds in Iray CPU. Mind you, it wouldn't look the same; trade-offs are a little different in Iray; I expect the lighting would look a little better while it would look a little more grainy.

     

    ...SSS is really only useful for close ups, this is a medium to wide shot.  As I mentioned, this is still a WIP or more correctly an "experiment in progress".

    Graininess is part of what bothers me about Iray . To me a "little more grainy" does not look "better" it looks like you used a low quality film.  

    This is a marked improvement over the original 3DL version I did over two years ago.  I wanted to keep everything in the scene the same as it was in the original for the most part so the characters are still G2 (the older lady, Steph 5 [Genesis "Classic]).  The only major differences is the sky backdrop as it has more depth than the flat photo background, and I used Skin Builder Pro on the three characters.

    At least for my Iray renders, I have been gradually adjusting the mitchell filter so my iray renders are sharper and faster than my 3dl renders ever were.  

  • PadonePadone Posts: 4,019
    edited March 2018

    One question @Padone though: No raytracing? You mean you had ray trace depth at 0?

    I'm not an expert in 3Delight since now I use Cycles most. What I did in my example is to use a key light with shadows set to bitmap (no raytrace) and some point lights with no shadows for rims and fills. Plus a uber environment set to ambience only (no raytrace) for the overall light. That's old school lighting I used for fast rendering back with Lightwave 8 (that had a great raytracer anyway), and it seems it works fine with 3Delight too.

    The advantage of raytrace over PBR is that you have so much control over what lights do so you can fake whatever you need. While with PBR you use "real" lights and cheating is harder or even impossible in some cases. As I said, I believe each engine has its strong and weak points depending on what you need.

     

    EDIT. I included the scene files in my previous post for anyone interested.

    Post edited by Padone on
  • AlienRendersAlienRenders Posts: 794
    edited March 2018
    Still incorrect. Iray runs the same per processor as per CPU.. the difference is that a CPU has 4-12 processors and a GPU has hundreds to thousands, which is why it runs faster. So no it's not optimized for GPU, it just runs faster on a GPU.

    I've been a programmer for longer than I care to admit. I do 3D and GPGPU programming and what you say is factually incorrect. Not every algorithm can be easily parallelised. In fact, multi-core programming is usually avoided if there is no pressing need for it as it is very easy to make a mistake and introduce bugs. On video cards, GPGPU processing is even more difficult because often the time it takes to upload all the resources can outweight the time it would take to just run the algorithm on the CPU. Once you have the data uploaded, you now have the challenge to split up the tasks into kernels that will run on the GPU. Each compute unit (OpenCL) or Streaming Multiprocessor (CUDA) will execute the exact same code and have the same instruction pointer for all the cores in each compute unit or streaming multiprocessor. So the code must be tailored just for GPU. Then you have the various types of memory access that are unique to GPUs that I don't have time to go into here. While you can run OpenCL code on a CPU, the performance will be severely degraded. CUDA (which iRay uses) cannot be run on CPU. So there is different code entirely that runs when you use iRay on CPU.

    In short, to say that iRay is not optimized for GPU is just silly.

     

     

    Please don't pull development rank on me. I've been in IT for over 3 decades including a stint at Intel.

    What I said is correct.  The architecture is the same built by processor; it is faster because GPUs have more processors (IE CUDA) than processor cores on a PC. It is also the reason why GPUs are being snatched up for the crypto currency mining.

    I'm afraid you need to do more research on the topic. I mentioned significant differences. It's not just about more cores. The instruction pointer is IDENTICAL per core group. There is nothing like that on CPU. You need to write code specifically tailored for the GPU. And GPUs aren't used by crypto currency for the most part. They use ASICs because they can do hashing an order of magnitude faster. Not because they have more cores, but because the hardware is specialized. Crypto currency that uses the GPU has an algorithm that has a DAG. This DAG is a large data structure that cannot be used by ASICs. There is a lot more going on than just more cores. The irony of your argument is that the opposite is acutally true. Crypto currencies that use GPUs do so in order to SLOW DOWN the hash rate.

     

    Post edited by AlienRenders on
  • Sven DullahSven Dullah Posts: 7,621
    edited March 2018
    Padone said:

    One question @Padone though: No raytracing? You mean you had ray trace depth at 0?

    I'm not an expert in 3Delight since now I use Cycles most. What I did in my example is to use a key light with shadows set to bitmap (no raytrace) and some point lights with no shadows for rims and fills. Plus a uber environment set to ambience only (no raytrace) for the overall light. That's old school lighting I used for fast rendering back with Lightwave 8 (that had a great raytracer anyway), and it seems it works fine with 3Delight too.

    Ok now I understand what you did=)One can use raytraced shadows or shadowmaps. I thought you rendered with ray trace depth at zero in the render settings. Well I had to try it of course, and fact is that IBLM renders shadows with raytrace depth at 0surprise. That of course means all kinds of other problems with reflective/refractive stuff like eyes and so on, but very interestingblush!

    Padone said:

    The advantage of raytrace over PBR is that you have so much control over what lights do so you can fake whatever you need. While with PBR you use "real" lights and cheating is harder or even impossible in some cases. As I said, I believe each engine has its strong and weak points depending on what you need.

    Agreed! And Petercat, sorry for the long sidenote!

    Post edited by Sven Dullah on
  • Male-M3diaMale-M3dia Posts: 3,584
    kyoto kid said:
    kyoto kid said:
    kyoto kid said:

    ...not enough for those stuck with CPU rendering though. Iray is optimised for GPU based rendering. 3DL for CPU rendering which is why I have moved back to the latter.

    I have to disagree with the blanket assertion. I ran a fairly complex scene with things that would grind 3DL to a slow grind and CPU iray ran it faster. Now if you're running fairly simple scenes, there may be a case, but rendering the same complex scenes, even CPU Iray renders it faster.

    ..running Iray to get hte optimal quality takes far too long on the CPU unless have a dual Xeon system (which most of us don't and it still takes longer than on the GPU). I have been rendering complex scenes in 3DL using IBL Master that take less than 15 min.

    I don't have that chip, yet that scene ran in about an hour. My computer is the exact same machine I've been using for 3DL before Iray was released. Again, if you're running things in 15 minutes, they absolutely don't have the things I (and certainly not the lighting quality) mentioned that would grind 3DL to a halt in those scenes so it's not a valid comparison. Before iray, using any SAV hairs was basically a no-no in 3DL... but iray just breezes through those hairs.

    ...this took under 12 minutes to render in 3DL at 1,500 x 1.050 (still a WIP but the latest version).

    Rendered on a 5+ year old system that has an i7 930 2.8 GHz CPU and 12 GB DDR3 1333 three channel memory.

    You will have to go back to what I said in a previous post. My answer unfortunately has not changed. If you want me to expound on this, you'll have to send me a PM.

  • PetercatPetercat Posts: 2,321
    edited March 2018
    Padone said:

    The advantage of raytrace over PBR is that you have so much control over what lights do so you can fake whatever you need. While with PBR you use "real" lights and cheating is harder or even impossible in some cases. As I said, I believe each engine has its strong and weak points depending on what you need.

    Agreed! And Petercat, sorry for the long sidenote!

    Nah, it's cool. This thread became a spectator sport for me a while ago. What was I talking about in the beginning?
    Oh, yeah. Predatron stuff not working in older Studios. Nevermind.

    Although I'd still like to know why it's only the ground, and was it intentional?
    I wish Predatron would chime in, because if the problem wasn't intentional, maybe
    they could fix it for the stubborn among us.

    Maybe they built it, tested it in 4.10 and said "Good to go!" without even
    realizing that it doesn't work in older versions.
    I have no way of knowing, or asking.

    Post edited by Petercat on
  • TangoAlphaTangoAlpha Posts: 4,587
    Petercat said:
    Padone said:

    The advantage of raytrace over PBR is that you have so much control over what lights do so you can fake whatever you need. While with PBR you use "real" lights and cheating is harder or even impossible in some cases. As I said, I believe each engine has its strong and weak points depending on what you need.

    Agreed! And Petercat, sorry for the long sidenote!

    Nah, it's cool. This thread became a spectator sport for me a while ago. What was I talking about in the beginning?
    Oh, yeah. Predatron stuff not working in older Studios. Nevermind.

    Although I'd still like to know why it's only the ground, and was it intentional?
    I wish Predatron would chime in, because if the problem wasn't intentional, maybe
    they could fix it for the stubborn among us.

    Maybe they built it, tested it in 4.10 and said "Good to go!" without even
    realizing that it doesn't work in older versions.
    I have no way of knowing, or asking.

    One thing I just noticed about your original render - at least the tree & swing set (I don't have the other set), is that there is a central grass bank upon which the tree & bushes sit, and this is missing from your render: the tree is clearly floating above that base level.

  • Male-M3diaMale-M3dia Posts: 3,584
    Still incorrect. Iray runs the same per processor as per CPU.. the difference is that a CPU has 4-12 processors and a GPU has hundreds to thousands, which is why it runs faster. So no it's not optimized for GPU, it just runs faster on a GPU.

    I've been a programmer for longer than I care to admit. I do 3D and GPGPU programming and what you say is factually incorrect. Not every algorithm can be easily parallelised. In fact, multi-core programming is usually avoided if there is no pressing need for it as it is very easy to make a mistake and introduce bugs. On video cards, GPGPU processing is even more difficult because often the time it takes to upload all the resources can outweight the time it would take to just run the algorithm on the CPU. Once you have the data uploaded, you now have the challenge to split up the tasks into kernels that will run on the GPU. Each compute unit (OpenCL) or Streaming Multiprocessor (CUDA) will execute the exact same code and have the same instruction pointer for all the cores in each compute unit or streaming multiprocessor. So the code must be tailored just for GPU. Then you have the various types of memory access that are unique to GPUs that I don't have time to go into here. While you can run OpenCL code on a CPU, the performance will be severely degraded. CUDA (which iRay uses) cannot be run on CPU. So there is different code entirely that runs when you use iRay on CPU.

    In short, to say that iRay is not optimized for GPU is just silly.

     

     

    Please don't pull development rank on me. I've been in IT for over 3 decades including a stint at Intel.

    What I said is correct.  The architecture is the same built by processor; it is faster because GPUs have more processors (IE CUDA) than processor cores on a PC. It is also the reason why GPUs are being snatched up for the crypto currency mining.

    I'm afraid you need to do more research on the topic. I mentioned significant differences. It's not just about more cores. The instruction pointer is IDENTICAL per core group. There is nothing like that on CPU. You need to write code specifically tailored for the GPU. And GPUs aren't used by crypto currency for the most part. They use ASICs because they can do hashing an order of magnitude faster. Not because they have more cores, but because the hardware is specialized. Crypto currency that uses the GPU has an algorithm that has a DAG. This DAG is a large data structure that cannot be used by ASICs. There is a lot more going on than just more cores. The irony of your argument is that the opposite is acutally true. Crypto currencies that use GPUs do so in order to SLOW DOWN the hash rate.

     

    I've done my research, and you didn't understand what I said. That's ok, I'm moving on.

  • PetercatPetercat Posts: 2,321
    Petercat said:
    Padone said:

    The advantage of raytrace over PBR is that you have so much control over what lights do so you can fake whatever you need. While with PBR you use "real" lights and cheating is harder or even impossible in some cases. As I said, I believe each engine has its strong and weak points depending on what you need.

    Agreed! And Petercat, sorry for the long sidenote!

    Nah, it's cool. This thread became a spectator sport for me a while ago. What was I talking about in the beginning?
    Oh, yeah. Predatron stuff not working in older Studios. Nevermind.

    Although I'd still like to know why it's only the ground, and was it intentional?
    I wish Predatron would chime in, because if the problem wasn't intentional, maybe
    they could fix it for the stubborn among us.

    Maybe they built it, tested it in 4.10 and said "Good to go!" without even
    realizing that it doesn't work in older versions.
    I have no way of knowing, or asking.

    One thing I just noticed about your original render - at least the tree & swing set (I don't have the other set), is that there is a central grass bank upon which the tree & bushes sit, and this is missing from your render: the tree is clearly floating above that base level.

    Yeah, I forgot about that. That one grass patch killed the render also, but the other grass didn't.
    That's why I'm wondering if it's unintentional.

    Love your products, BTW. Now create more, I have a sliver of a gift card yet to spend.

  • TangoAlphaTangoAlpha Posts: 4,587
    Petercat said:

    Love your products, BTW. Now create more, I have a sliver of a gift card yet to spend.

    https://www.daz3d.com/forums/discussion/240071/coming-soon-mv-stella-engineering-deck-commercial#latest ;smiley

  • PetercatPetercat Posts: 2,321
    Petercat said:

    Love your products, BTW. Now create more, I have a sliver of a gift card yet to spend.

    https://www.daz3d.com/forums/discussion/240071/coming-soon-mv-stella-engineering-deck-commercial#latest ;smiley

    Your timing is perfect, I will soon need an asteroid mining ship for my webcomic!
    And I'm glad to see walkways and stairs, as my universe has artificial gravity.
    So I'm assuming there will be three modules for sale... will there be an exterior?
    This will be one of the few things that I buy at 30% off.
    (One question - do you intend for it to work in older versions of Studio?)

  • TaozTaoz Posts: 10,264
    nemesis10 said:
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    How about this other situation: you wish to sell your product at another store...do you allow Daz3d to retain intellectual control after you have left?  Even marriage has a "until death do you part" clause.  Your contract is that your product should work in the current version of software and there is no post death warranty for any piece of software in the world. If I were the survivor and someone came to me to release intellectual rights to something a departed loved one made, I think I would have hard words with them before I got law enforcement involved. Realistically, in everything in life, there is an alloted lifetime; If you get a dog, the dog will pass away and the provider of the dog doesn't have to give you another one.

    Well one can imagine all kinds of problem scenarios but my opinion is that a PA must have the right to sign a contract with a company based on whatever terms they might agree on. The PA can then discuss these terms with his/her relatives before signing, if relevant.

    Yes, things generally have an expected lifetime, depending on the context, but many things can actually live a lot longer, if needed (especially if the context is planned obsolescence). Why not extend the lifetime as long as possible if it can benefit someone, within reasonable cost-benefit terms. There are no absolute rules here, anyone can make their own rules if they want.

    As for dogs you normally can't extend their natural lifetime but with software there are no real limitations; as long as it's relevant (someone wants it, necessary hardware etc. is available, cost-benefit allows it) you can extend its lifetime as long as you want. So you can't really compare these two things.

  • kyoto kidkyoto kid Posts: 41,880

    ...oh, and by the way, I am fully aware that the version of 3DL in Daz is not set up for photoreal output like a PBR render engine is.  I'm simply pushing it for all it has to get the best results I can wring out of it.

    It will be interesting to see how much further it can go when Wowie's Ultra Shader system hits the store.

  • nemesis10nemesis10 Posts: 3,799
    Taoz said:
    nemesis10 said:
    Taoz said:
    Taoz said:
    Taoz said:

    The very fact that it does run faster on a GPU than a CPU is evidence that it's optimized for GPU over CPU.

    I mean, dude....

    I assume you're joking here...

     

     

    I can see the why of encrypting scripts, re; don't want someone stealing it - but when an author of a script passes on, or just bails, and that script needs to be updated to work in the latest version, and no one steps up to the plate, then it's a problem for end-users. At one time, Poser had an effective metaball script plugin, but the author bailed and it only works with version 5. We need some sort of contingency plan, like a source code release if said author bails or passes away. Then again we also need some sort of policy regarding abandonware being public domain, so all these ancient and neglected pieces can get new life if the author doesn't see enough $ in doing it themselves. If they don't want to lose it, they have to keep it updated. If you want to run a business, run it like a business.

    Agree. If you're an indie developer make sure that someone else have access to your source code, key generators etc., so your stuff doesn't die with you if you're hit by a truck.

    DAZ could require that PAs give them the encryption keys to their scripts so they can update them if necessary. I would be fine with that myself if I was a PA.

    Again, they can't require PAs to do this. It isn't DAZ's code. You're probably lucky the product doesn't get pulled from the store. I would think it's up to the next of kin to decide what's done with the code.

    Well they probably could if they wanted to, but how the PAs would react I don't know. The vast majority of content is not protected against public abuse/piracy anyway, despite the option of encryption, and with scripts they would still be encrypted publicly.

    The problem for DAZ is that you purchase something in their store and then the next DS update breaks it and there's no way to update it. Not something that makes customers happy.

    Still this is not DAZ's code to change; and code breaking is part of the software cycle not limited to DAZ. I have programs that won't work past a OS version as well that weren't updated. A vendor dying isn't a valid reason for customer to be upset.. it seems to me rather selfish and callous. I can imagine DAZ contacting a grieving person saying "I'm sorry for your loss, but can we get that code because our customers need it?"

    You know how exactly how that conversation will end.

    No one have ever talked about that. If you give a copy of your code to someone (DAZ or whoever relevant) who can utilize it constructively and say "use it as you like when I'm dead", I can't see it can hurt anyone.

    Personally I don't like the idea that people who have purchased my products suddenly can't use them anymore just because I've decided to take my code with me in the grave. So I am taking precautions to avoid that happening (not that I expect do die soon, but some day it will happen, I suppose). I have nothing to lose but my customers may have, and I don't like to see anything get wasted unless there is a good reason for it. So to me it's an obvious and constructive decision.

     

     

     

    How about this other situation: you wish to sell your product at another store...do you allow Daz3d to retain intellectual control after you have left?  Even marriage has a "until death do you part" clause.  Your contract is that your product should work in the current version of software and there is no post death warranty for any piece of software in the world. If I were the survivor and someone came to me to release intellectual rights to something a departed loved one made, I think I would have hard words with them before I got law enforcement involved. Realistically, in everything in life, there is an alloted lifetime; If you get a dog, the dog will pass away and the provider of the dog doesn't have to give you another one.

    Well one can imagine all kinds of problem scenarios but my opinion is that a PA must have the right to sign a contract with a company based on whatever terms they might agree on. The PA can then discuss these terms with his/her relatives before signing, if relevant.

    Yes, things generally have an expected lifetime, depending on the context, but many things can actually live a lot longer, if needed (especially if the context is planned obsolescence). Why not extend the lifetime as long as possible if it can benefit someone, within reasonable cost-benefit terms. There are no absolute rules here, anyone can make their own rules if they want.

    As for dogs you normally can't extend their natural lifetime but with software there are no real limitations; as long as it's relevant (someone wants it, necessary hardware etc. is available, cost-benefit allows it) you can extend its lifetime as long as you want. So you can't really compare these two things.

    I think we agree on some points: "PA must have the right to sign a contract with a company based on whatever terms they might agree on" but I can't imagine how this would benefit either Daz3d or the PA.  Software can have an almost infinite lifetime but the hardware it runs on doesn't.  If one made a script and one (or your descendents) was required to recompile it everytime OS's change for eternity unless you are forced to give up your intellectual propertty seems like a pretty raw deal for a PA.  I would prefer that the PA's be less encumbered so that they can work their creative magic and that Daz3d retain the rights to make and try to sell the products that spark them creatively. No one should be required to endlessly maintain a DOS version  or OS 8 version of a program through decades. Finally, when you purchase  a product, you enter a contract but even marriage contract dissolve on death.

  • cherpenbeckcherpenbeck Posts: 1,416
    edited March 2018

    Marriage, maybe, but if I buy a house, I still own it when the former owner dies, and I can add rooms and such freely.

    The software for DAZ studio instead - I buy a scipt licence, and with the next update of DAZ Studio the script doesn't work any longer, and no one can fix this besides the original PA. If he/she doesn't, that's it.

    Which ends in two ways (if I really loved to work with this software script):

    1. I stay with an older version of DAZ Studio, won't buy newer products from DAZ or that PA, because they don't work with the older Studio versions in the long run.

    2. I'm pissed off that I can't use my sparkling toy any longer, change to the new Studio Version and don't buy from that PA a second time.

    In both version DAZ AND the PA loose sales.

    Post edited by cherpenbeck on
  • TangoAlphaTangoAlpha Posts: 4,587
    Petercat said:
    Petercat said:

    Love your products, BTW. Now create more, I have a sliver of a gift card yet to spend.

    https://www.daz3d.com/forums/discussion/240071/coming-soon-mv-stella-engineering-deck-commercial#latest ;smiley

    Your timing is perfect, I will soon need an asteroid mining ship for my webcomic!
    And I'm glad to see walkways and stairs, as my universe has artificial gravity.
    So I'm assuming there will be three modules for sale... will there be an exterior?
    This will be one of the few things that I buy at 30% off.
    (One question - do you intend for it to work in older versions of Studio?)

    lol, this is basically the asteroid mining ship out of a novel I'm writing. The full set will be 3 interior decks (already out) and an exterior. Haven't started work on that yet.

    I don't really subscribe to artificial gravity of the "magic" sort, favouring gravity through thrust - which doesn't preclude ladders & stairs, it just means more handholds for the times when the engines aren't running. (Centripetal gravity is only for the strong of stomach, imho, since it's known to cause nausea through coreolis effect on the inner ears, unless you have a massive diameter centrifuge, that is.)

    As regards older versions of Studio, I don't honestly know. I don't do anything deliberately to make it not work. But like most people I forget to make a backup of the old DS before it gets overwritten by the new one, and so I only have the current release. I do know that new versions get extra Iray shader parameters (for example) from time to time, and they will be saved in the .duf when you save a file with the new version. But whether an older DS will ignore parameters it doesn't understand, or if it will barf, I don't know.

Sign In or Register to comment.