WHEN... will DAZ3D learn...

TheMysteryIsThePoint

Richard Haseltine said:

For the record, the developers do not agree with the assessment of the relative superiority of "a component architecture". I lack even a fragment of the knowledge requiired to form my own judgement, but your assertion should not go without at least a note that it does not command universal assent.

Neither should it go without a note that those that dissent are the same people that gave us static header files that they can never update in a way that changes the symbols, i.e. just about any change that would make them more useful.

But maybe next time you could ask them to instead of defending themselves, to use the same time to answer some questions in the SDK forum? Just sayin'.

 

Richard Haseltine

TheMysteryIsThePoint said:

Matt_Castle said:

TheMysteryIsThePoint said:

Matt_Castle said:

To say that the current system is bad does not actually mean that a better option is known, or is even possible at this stage.

No, but the design created the situation. And if there is no solution, Richard M. Stallman coined a great phrase: "Broken By Design".

This is pointless. You have yet to propose any alternative solution that meets the design requirements, which can be retrofitted at the current stage, and which hasn't already been tried and proven unsuitable.

With a better design we would never have been "at the current stage". But now we are stuck with it and that offsets in bas relief the importance of a forward thinking design in the first place. My, and presumably the OP's, valid point. An argument based on the fact that an outsider not involved in the product's development at all doesn't have an alternative is an exceedingly weak one. And I still have not heard a convincing argument against the one that says that if the user experience is unsatisfactory, it was a deficiency in the design. And I sincerely doubt I ever will.

If there is no solution, there is nothing for "Daz to learn" as the topic title puts it, because they couldn't have done any better. Sometimes there is no perfect answer. Sometimes there was never one to begin with.

Again, that's "Broken by Design." There are always tradeoffs to be made. That's the process of Engineering in a nutshell. If there is no tradeoff to be made, the design cut off certain avenues to be explored. I have never seen that not to be the case. No one will ever convinve me that when there was ultimate freedom to determine how the framework would work, that the only way to make an extensible framework was to load all the morphs. At some point, that was designed in by a decision that, in retrospect, turned out to be a bad decision. Happens to the best of us.

But again, do you have a better alternative that does what Daz needs it to - something along the lines of provide an extensible architecture for content items that can have new shapes, rigging adjustments, mappings etc. added and removed without requiring special actions (running additoonal utilities, invoking special commands to fiininalise the set up) - with less overhead than the current system?

I'm sure if there was a good solution, Daz would love to hear it, because obviously it's not in their interests to have users getting picky about buying new content because they don't want it to slow down their library.

That's probably the best argument for Open Source-ing DAZ Studio that I've ever heard.