Frinkky said:

Oso3D said:

One of the upsides of morph vs. bones is that you can be a LOT more individually precise. I'm trying to refurbish an old figure and at first I'm like 'ugh, the mouth opening and other stuff is all morphs, this sucks!'

But then I realized that it would take a few extra bones and LOADS of JCMs to capture the same effect, and people are extremely unlikely to care (in this instance).

So at one point I thought morphs for things like mouth opening and whatnot were old and dumb vs. brilliant new tech we have now, but now I've grown to appreciate that every tool has a situation and place.

 

 Morphs would only make sense if the movement is linear. As an example, a door opening is not linear - a morph would work only in the open and closed positions, but an intermediate position would be distorted (I suppose you could create morphs for 10 degree increments, but then may as well rig the damned thing). A drawer opening could be achieved with a morph, as could some resizing of elements, as well as via rigging.

 

I found that one out the hard way, when I made some morphs to open some hinged boxes lol. I thought I was seeing things at first, that the box lid only looked like it was changing size in the betweens. Then I used a primitive to measure it, and sure enough, it was scaling.

acecombs_b317c01b8d said:

Richard Haseltine said:

acecombs_b317c01b8d said:

Richard Haseltine said:

One potential issue with AutoSave is that it needs to have stable data, so either it has to lock editing, make a copy of the data (and given how long a morph-heavy figure takes to load that may take a while - during which editing would have to be locked,) or queue any chnages the user made until saving was complete. I can see all of those being a pain for the user, and the second and third might well introduce new stability issues. I'm not anti-autosave, for what little that is worth, but I'm not sure how practical it would be in this case; most of the other applications, even the other 3D ones, are likely to have much simpler data structures than DS.

If a user saves every ten minutes, doesn't that do exactly the same thing as an autosave would every ten minutes? I'm not sure how auto-save differs from save, except that it's automatic. When programs with autosave operate, there isn't any time difference and, I'm fairly sure, no data difference from a manual save. Wouldn't manual saving introduce the same stability issues as an autosave which is just a timed or iterative save? I have several programs where the saves do take a while, but not nearly as long as it would take me to reconstruct the work from a crash--that split second of pain from being interrupted quickly passes and I'm grateful when I think about the fact that I'll never lose more than 15 minutes of work. There are also autosaves that do incremental and background saves, so time isn't necessarily a constraint. I'm not a software engineer, but it seems odd that a full-featured program like Maya, with its vast array of options, contextual menus, and far more robust rendering engine has a simpler data structure than Daz.

How long do thos application take to do a save, compared to Daz Studio? I would suspect that DS is unusual in the extent to which it uses disparae external assets, with many relationships between them. Still, I wasn't saying Autosave wouldn't work - just pointing out something that may well make implementation challenging, and might possibly be severe enough to be a block on a useable autosave..

I take it then that the issue isn't so much with autosave, per se, as it is with the long save times in DS, which is I think the root of the problem.

I don't know, I'm not a developer. I was merely pointing out a way in which DS may differ from the other applications you cite.

In the cases of most 3D programs, since I am not doing animation but rather 2D finish, save time seems to depend mostly on one factor--polycount. This is controllable to a certain extent--you can reference, remesh, reduce, retopologize, defer, hide, instance, convert to static mesh, etc to reduce polycount. So you have some control over save times in most 3D programs---animation and render times are a whole other kettle of sharks. Zbrush seems to be able to handle massive poly counts with ease, others do not. I'm not sure what leads to the long save times in Daz, but as I understand it, Daz loads a character with all of its possible morphs, materials, etc. and references those during the save process. I find the actual file sizes and polycounts in DS are very small compared to files in other 3D programs. I'm not real clear on the mechanics of this, but it seems that there is a lot of extra work being done by DS that has no bearing on the finished process. What I don't get is why that's necessary. Is there a way to simply make the program stop referring to those resources once you're satisfied with a character or to just load the resources you request?

Yes, though it would be a lot of work, would not be sharable, would not be extensible with new content, and would not benefit from any updates or bug fixes to the original content used.

Greetings! I'm looking to commission a morph of a certain heavily muscled male character. I'm not sure where to reach out, so, I'm starting here. Any suggestions would be greatly appreciated. Thanks!

If you have used DIM/Daz Central/manual installation with your assets, you can get the visemes back if you follow this;

Making the G8 base expressions (and any expressions that are using them) work on G8.1 requires removing dummy/placeholder expressions that are installed to G8.1 morph folders - These dummy/placeholder expression files have no other function than to prevent the base G8 expressions from loading. 

The dummy/placeholder files are located in;

...\Data\DAZ 3D\Genesis 8\Female 8_1\Morphs\Daz 3D\Base Pose Head\ (255 files)
...\Data\DAZ 3D\Genesis 8\Female 8_1\Morphs\Daz 3D\Expressions\ (24 files)
...\Data\DAZ 3D\Genesis 8\Male 8_1\Morphs\Daz 3D\Base Pose Head\ (255 files)
...\Data\DAZ 3D\Genesis 8\Male 8_1\Morphs\Daz 3D\Expressions\ (24 files)

Please make sure you are removing the files from G8.1 morph folders and not G8 morph folders.

Hi guys so i made a preset when i was working with a G8 figure with Visemes to export. Then i tried loading a G8.1 character and seeing if i could export her with the same viseme preset, turns out many of the morphs appeared except the Angry HD, Happy HD, Scared HD, etc those didn't appear and None of the Visemese appeared, then i looked in the character TREE in the left column in Daz tto Unit morph thing and there is no VISEME listning at all. SO Genesis 8.1 has no visemes?

Richard Haseltine said:

acecombs_b317c01b8d said:

Richard Haseltine said:

One potential issue with AutoSave is that it needs to have stable data, so either it has to lock editing, make a copy of the data (and given how long a morph-heavy figure takes to load that may take a while - during which editing would have to be locked,) or queue any chnages the user made until saving was complete. I can see all of those being a pain for the user, and the second and third might well introduce new stability issues. I'm not anti-autosave, for what little that is worth, but I'm not sure how practical it would be in this case; most of the other applications, even the other 3D ones, are likely to have much simpler data structures than DS.

If a user saves every ten minutes, doesn't that do exactly the same thing as an autosave would every ten minutes? I'm not sure how auto-save differs from save, except that it's automatic. When programs with autosave operate, there isn't any time difference and, I'm fairly sure, no data difference from a manual save. Wouldn't manual saving introduce the same stability issues as an autosave which is just a timed or iterative save? I have several programs where the saves do take a while, but not nearly as long as it would take me to reconstruct the work from a crash--that split second of pain from being interrupted quickly passes and I'm grateful when I think about the fact that I'll never lose more than 15 minutes of work. There are also autosaves that do incremental and background saves, so time isn't necessarily a constraint. I'm not a software engineer, but it seems odd that a full-featured program like Maya, with its vast array of options, contextual menus, and far more robust rendering engine has a simpler data structure than Daz.

How long do thos application take to do a save, compared to Daz Studio? I would suspect that DS is unusual in the extent to which it uses disparae external assets, with many relationships between them. Still, I wasn't saying Autosave wouldn't work - just pointing out something that may well make implementation challenging, and might possibly be severe enough to be a block on a useable autosave..

I take it then that the issue isn't so much with autosave, per se, as it is with the long save times in DS, which is I think the root of the problem. In the cases of most 3D programs, since I am not doing animation but rather 2D finish, save time seems to depend mostly on one factor--polycount. This is controllable to a certain extent--you can reference, remesh, reduce, retopologize, defer, hide, instance, convert to static mesh, etc to reduce polycount. So you have some control over save times in most 3D programs---animation and render times are a whole other kettle of sharks. Zbrush seems to be able to handle massive poly counts with ease, others do not. I'm not sure what leads to the long save times in Daz, but as I understand it, Daz loads a character with all of its possible morphs, materials, etc. and references those during the save process. I find the actual file sizes and polycounts in DS are very small compared to files in other 3D programs. I'm not real clear on the mechanics of this, but it seems that there is a lot of extra work being done by DS that has no bearing on the finished process. What I don't get is why that's necessary. Is there a way to simply make the program stop referring to those resources once you're satisfied with a character or to just load the resources you request?

Leana said:

Pitmatic said:

It would imply by supports answer that this outfit ONLY works with these characters

Not exactly. It's more like “we can guarantee it works with the supported characters, results may vary with other characters".

Or "Welcome back to V4 era...", clothes do not fit unless there is a corresponding morph supplied with the clothing, or the clothing has been tagged with dForce and looks like a potato sack without simulation. 

acecombs_b317c01b8d said:

Richard Haseltine said:

One potential issue with AutoSave is that it needs to have stable data, so either it has to lock editing, make a copy of the data (and given how long a morph-heavy figure takes to load that may take a while - during which editing would have to be locked,) or queue any chnages the user made until saving was complete. I can see all of those being a pain for the user, and the second and third might well introduce new stability issues. I'm not anti-autosave, for what little that is worth, but I'm not sure how practical it would be in this case; most of the other applications, even the other 3D ones, are likely to have much simpler data structures than DS.

If a user saves every ten minutes, doesn't that do exactly the same thing as an autosave would every ten minutes? I'm not sure how auto-save differs from save, except that it's automatic. When programs with autosave operate, there isn't any time difference and, I'm fairly sure, no data difference from a manual save. Wouldn't manual saving introduce the same stability issues as an autosave which is just a timed or iterative save? I have several programs where the saves do take a while, but not nearly as long as it would take me to reconstruct the work from a crash--that split second of pain from being interrupted quickly passes and I'm grateful when I think about the fact that I'll never lose more than 15 minutes of work. There are also autosaves that do incremental and background saves, so time isn't necessarily a constraint. I'm not a software engineer, but it seems odd that a full-featured program like Maya, with its vast array of options, contextual menus, and far more robust rendering engine has a simpler data structure than Daz.

How long do thos application take to do a save, compared to Daz Studio? I would suspect that DS is unusual in the extent to which it uses disparae external assets, with many relationships between them. Still, I wasn't saying Autosave wouldn't work - just pointing out something that may well make implementation challenging, and might possibly be severe enough to be a block on a useable autosave..

TheMysteryIsThePoint said:

Richard Haseltine said:

Speaking of engineers, you cannae change the laws of physics (or coding). Not evey problem has an ideal solution, this may well be one where there are trade-offs and it isn't clear that the needs of those of us with large libraries should trump the needs of those who want convenient access.to their morphs (to the extent that the groups don't overlap anyway).

I'm not sure what you mean by "The Laws of Coding", but I really hope you meant Complexity and/or Algorithmic Analysis. I hope so, because then we can have an objective discussion. But then, we can only come to the conclusion that it's a bad architecture. Any rational discussion is going to somehow come back to that.

Yes, that is what I meant. Before calling ti bad architecture you need to offer, by your own design or by pointing to another application, a system that would satisfy what we know of the design specs in a "better" way (and you need to explain what better is, and why any downside is the lesser evil). You keep asserting that it's bad design and that the developers should fix the problem, but that is begging the question of whether the basic logic (ability to add new morphs, ability to access morphs in a conveinent manner) can be implemented in a way that is better; proof of possibility comes before finding fault.

I'll go one step further and say that no non-trivial problem has an ideal solution, and there are always tradeoffs to be made, the most obvious being between time and space. And generally, the more complex the system, the more opportunites there are to work tradeoffs. It should never be the case where a system performs well under a certain set of conditions, and dismally in the others. If it does, bad architectural design choices have been made.

This is all assertion, though.

But I'm willing to suppose that the Daz devs are good at what they do. This is not an ad hominem attack. That's why I distinguish between a bad architecture and an architecture that is simply encountering unforeseen conditions that were not part of the initial system level requirements, and under which it doesn't perform well. You see this sort of thing all the time, and its a much more viable explanation than that Daz meant it to take 5-30 minutes to load a scene and thought that people would be happy with that.

Yes, it is indeed possible that there is more genesis 8 content than the original designers were expecting due to its unusually long lifetime, and i'm sure they are looking at future development in light of this. But we do need to remember that this is not Daz' first morph management system, as I'm sure I have pointed out before, there was morph injection in the third generation figures and ExP in the fourth - the daz team has much experience in thif field, and much feedback from users at all levels (not just those of us with large content sets).

A perfect example: years ago, around the 2.2 series, the Linux had always had O(log n) complexity scheduler. It worked like a champ when Linux ran on desktops with a relatively small number of runnable processes at any given time. But when Linux started to move into the enterprise space, it could spend more time trying to choose the next process to run than it did... running the next process. So they developed an O(1) scheduler because the O(log n) scheduler was written by Linus himself when Linux was his small, pet project and he had never dreamed of Linux even having a GUI one day, much less run mainframes with thousands of processes. Note that the Linux developers did not keep trying to explain to their users why Linux scaled so poorly, they ripped out the scheduler and wrote a new one more appropriate to the space in which Linux was now operating.

Would you agree that all the above is reasonably objective?

I have to point out that the daz developers do not keep trying to explain anything - I keep trying to explain why it is not clear that their implementation is significantly sub-optimal given its objectives, and that there is no guarantee that it can be greatly improved, and that asserting that it just needs fixing is making unwarranted assumptions. I certainly hope that they are working on the issue, and that they can come up with a system that will make life easier for those of us with large cointent libraries; I am not making assumptions about their abilities, or about how any shortfall in the current or future systems may relfect on their skills or judgement.

Oso3D said:

One of the upsides of morph vs. bones is that you can be a LOT more individually precise. I'm trying to refurbish an old figure and at first I'm like 'ugh, the mouth opening and other stuff is all morphs, this sucks!'

But then I realized that it would take a few extra bones and LOADS of JCMs to capture the same effect, and people are extremely unlikely to care (in this instance).

So at one point I thought morphs for things like mouth opening and whatnot were old and dumb vs. brilliant new tech we have now, but now I've grown to appreciate that every tool has a situation and place.

 

 Morphs would only make sense if the movement is linear. As an example, a door opening is not linear - a morph would work only in the open and closed positions, but an intermediate position would be distorted (I suppose you could create morphs for 10 degree increments, but then may as well rig the damned thing). A drawer opening could be achieved with a morph, as could some resizing of elements, as well as via rigging.

Hi,

I have not used the DaztoBlender, so do not know what scale/rotation it is using. I would suggest using a different workflow when creating props to send to DS.

In DS, load the figure.

With figure selected (Make mesh resolution "Base") "File > Export" as Wavefront .obj. Set scale to 1 unit = 1 meter (1%).

In Blender "File > Import > Wavefront(.obj) Select the figure. The default import options are OK (-Z forward / Y up) (optional: In geometry dropdown menu, select "Keep Vert Order". That is not needed for what you are doing, but it is a good option to always use. It is needed if creating morphs and sending them back to DS).

You can then create the prop on the model.

To export Prop from Blender.

Select only the prop, then "File > Export > Wavefront(.obj)". In export window options, select "Selection Only"

(Note:  this is only needed if exporting a morph but good to get into the habit of, is in Geometry dropdown, select "Keep Vertex Order"

 

To import into DS.

"File > import" select the prop. In import option set scale to 1 unit = 1Meter (10000%)

 

 

 

 

Oso3D said:

One of the upsides of morph vs. bones is that you can be a LOT more individually precise. I'm trying to refurbish an old figure and at first I'm like 'ugh, the mouth opening and other stuff is all morphs, this sucks!'

But then I realized that it would take a few extra bones and LOADS of JCMs to capture the same effect, and people are extremely unlikely to care (in this instance).

So at one point I thought morphs for things like mouth opening and whatnot were old and dumb vs. brilliant new tech we have now, but now I've grown to appreciate that every tool has a situation and place.

 

They're great for making things simple. If I'm modeling a ship with multiple hatches on the hull and they're all supposed to open simultaneously then I'm not going to be placing a bone for each hatch. Even making each part separate and changing the origin point would be too messy - now a ship hull ends with dozens of identical clutter attached. It'd be one mess of the scene.

sandmanmax said:

richardandtracy said:

That looks really magnificent. I do have a problem though - it involves the word 'Plug-in'. I have discovered that manual downloads are impossible on plug-ins, and with an Android tablet as my internet connection, that's all I can do. DAZ's policy of making DIM/DAZ Central the only download method puts plug-ins out of reach for me. It's a shame, as the backgrounds look as fantastic as every other US component.

Is getting a used laptop in the realm of possibility for you?  That's what I did and it's my dedicated DIM device. DIM downloads a zip file and then I can copy it on to a flash drive to transfer it to my desktop.  And the manual install process isn't complicated.

Ideally yes. In practice...I really don't need or want another computer at home. A low spec laptop would drive me up the wall. It would only be used to download plugins. A tablet, in contrast to a low spec laptop, is fast to turn on, doesn't have MS Teams (or MS anything) to foul it up, doesn't have manufacturers bloatware introducing security holes, or anything like that. Then, the Laptop being used so rarely would spend a majority of its time downloading updates, and being a low spec thing would be virtually unable to respond to a cursor move until the updates were done - and experience suggests that would be hours after starting. My kids have had updates kill the battery management on their laptops (making them only work when plugged in) and every removed update gets reinstated next time -it makes you at the mercy of poor quality MS updates. It's needless agro I don't want. All in all, a desperately unattractive alternative, or maybe an alternative of desperation. Just not for me.

Matt_Castle said:

The main things with G8.1 are that the default subdivision for the figures is 2 scene/3 render (rather than the 1/2 used for G8.0), that a new material zone has been added for the back of the head and neck (meaning an extra set of textures for it), and potentially that the PBRSkin shader includes additional options for maps, like Ambient Occlusion.

The new UVs are a mixed bag. Theoretically good if you're seeing the top or back of the head, but if it's being hidden by hair, it's arguably worse than the G8.0 UVs because of the additional texture load as well as introducing a seam at the neck, which is often much more visible than one running down the back of the jaw.

As far as trimming things down, in theory, you can drop the subdivision down, and bake the "Head" and "Body" textures back to the old G8.0 "Torso" UVs using Map Transfer so that the same texture maps can be reused on both surfaces (it only loads the textures once if they're used by multiple surfaces.

Genesis 8/8.1 have next-to-no texture load time. If you do a dev load--which has no textures--it loads as quick as a Genesis 8 with textures. The Genesis 8/8.1 lag is just geometry/morph loading.

EDIT:

I didn't read close enough, I thought you were talking about load times.

When it comes to memory load, the figure's geometry only takes up about 50 megabytes, IIRC. Aside from textures, most of the memory is eaten up by SubD as Matt_Castle mentioned, which quadruples the geometry with every tick. Unfortunately, SubD is necessary for HD morphs to work. If you're doing a close-up glamour shot and need HD morphs and crisp textures, then you'll need to bite the bullet and use 3-5GB. But if the character is far-ish away from the camera, you can drop the SubD to 1.0 and maybe run the textures through Scene Optimizer (or do it yourself with GIMP), and it'll drop the memory usage to manageable levels. You really can't tell if the textures have been reduced 2x or 4x unless they're really close to the camera.

Richard Haseltine said:

One potential issue with AutoSave is that it needs to have stable data, so either it has to lock editing, make a copy of the data (and given how long a morph-heavy figure takes to load that may take a while - during which editing would have to be locked,) or queue any chnages the user made until saving was complete. I can see all of those being a pain for the user, and the second and third might well introduce new stability issues. I'm not anti-autosave, for what little that is worth, but I'm not sure how practical it would be in this case; most of the other applications, even the other 3D ones, are likely to have much simpler data structures than DS.

If a user saves every ten minutes, doesn't that do exactly the same thing as an autosave would every ten minutes? I'm not sure how auto-save differs from save, except that it's automatic. When programs with autosave operate, there isn't any time difference and, I'm fairly sure, no data difference from a manual save. Wouldn't manual saving introduce the same stability issues as an autosave which is just a timed or iterative save? I have several programs where the saves do take a while, but not nearly as long as it would take me to reconstruct the work from a crash--that split second of pain from being interrupted quickly passes and I'm grateful when I think about the fact that I'll never lose more than 15 minutes of work. There are also autosaves that do incremental and background saves, so time isn't necessarily a constraint. I'm not a software engineer, but it seems odd that a full-featured program like Maya, with its vast array of options, contextual menus, and far more robust rendering engine has a simpler data structure than Daz.

One of the upsides of morph vs. bones is that you can be a LOT more individually precise. I'm trying to refurbish an old figure and at first I'm like 'ugh, the mouth opening and other stuff is all morphs, this sucks!'

But then I realized that it would take a few extra bones and LOADS of JCMs to capture the same effect, and people are extremely unlikely to care (in this instance).

So at one point I thought morphs for things like mouth opening and whatnot were old and dumb vs. brilliant new tech we have now, but now I've grown to appreciate that every tool has a situation and place.

 

magikhs said:

Render-Farmer said:

Kinda fiddled with this Barbara Palvin look-a-like for months. Higher res picture is avaible on my DA https://www.deviantart.com/render-farmer/art/Character-study-PBR-detail-textures-886951780

Nice work! ;)

To me, Sky HD by Mousso, makes the best template for a Barbara Palvin. Gorgeous model, too! 
 

 

In my first iterations I actually used "Eichorn art's" Palmira HD for g3f/g8f, since she really looks like a younger her. https://www.daz3d.com/palmira-for-genesis-3-and-8-female But for this newer one I used Facegen for textures and its base morph at 30%, then EJFM's facial morph sliders and genesis 8 female head hd morphs. For the body figure I used Victoria 8.1 with some genesis 8 hd body morphs.

TheMysteryIsThePoint said:

thenoobducky said:

TheMysteryIsThePoint said:

I mean exactly what I wrote. As for destroying characters, a morph that I did not apply, that I hadn't even known existed, suddenly and silently gets applied to my character. I didn't discover it until after an overnight render that I had to do again. As for installing unrelated morphs, I recently had to re-install everything for an unrelated reason. While loading up my main protagonist, it prompted me to install several assets that the character does not use, and did not even exist when I created the character. Things that I bought, installed, decided that I didn't really like, and that are not displayed on the "Currently Used" tab.

That is more of a problem with Daz QA. Daz definitely should do a better job at QA stuff they sell to make sure broken stuff doesn't get released. But the program's perspective, it is really hard to figure out what is broken. It can't read your mind and figure out what you think is broken. Although what would be useful is some tools for power users to make fixing stuff easier.

I disagree. It is not a job for a human being.

What you are saying is hard to do is only hard to do because there is no framework in place that could detect and prevent a large number of these mistakes. Consider this: if the product pages were automatically generated from some template, and everything else is created from that master template, the framework could automatically check to see that all the morphs included on the product page were actually in the asset pack. It could force them to be placed in the correct and consistent file locations. If it were an HD addon, it could enforce the name to be the original name with "HD" appended to the end, and make the product page always say so.

There is even a markup language called SGML that was designed to automatically create documents in a structured manner so that references, figures, footnotes, technical drawings, etc... always match up correctly no matter what is changed.

Daz needs to fix this. Period. But I do not have super high hopes, because Daz also made an "architecture" that allows PAs to mess up metadata and poorly name things...

Aside from speed, which as you say may involve tradeoffs, I'm not sure what core-feature issues there are (as opposed to errors in specific products).

I would certainly consider the issues I just described as core features. I repeat that an architecture that requires DS to evaluate all the morphs that are installed globally and not just the number of morphs actually deforming a mesh is just a bad architecture. Full stop. There is no way to explain this one away with technical sounding terms that don't help scenes load any faster by writing them in a forum.

This goes to the above point. Daz loads every morph related to the figure in the base directories you have added. Even if it might not do something now, the user might want to use the morph later. For example, I have asked people if they prefer no expressions in the posing panel and have the figure load faster or the current situation and many people I have talked to said they preferred having expression sliders. To make it beginner-friendly, Daz loads all expressions when you load the figure so that the user can just go to an expression slider and use it to apply the expression.

Even if I accepted that as a good idea, there should be a much lighter-weight method for doing that, that does not cause such strident complaints about the terrible user experience because of it. These are software engineers. They should engineer it. An explanation/justification of why my user experience is so bad is not what I want. I want a better user experience.

Speaking of engineers, you cannae change the laws of physics (or coding). Not evey problem has an ideal solution, this may well be one where there are trade-offs and it isn't clear that the needs of those of us with large libraries should trump the needs of those who want convenient access.to their morphs (to the extent that the groups don't overlap anyway).

Like @charles said, I don't see how this can not be affecting Daz's bottom line, what with the number of people complaining about the user experience. I am just hoping that v5 rectifies as much technical debt as possible... if they're going to break binary compatibility, then let them fricking break binary compatibility and implement as many long-standing and invasive fixes as possible in one shot, as opposed to subjecting the userbase to these bugs for even longer, just to have to break it again later anyway.

I'll be the first one to profess my affection for Genesis as a framework and the incredible PAs that make it shine. I really, really want Daz to continue to succeed. I am actually as content giving Daz and the PAs my money as I am the Blender Foundation. But things like this really make me worry about its viability in the future.

Definitely agree that Daz should fix this. But disagree that they should fix this before releasing DS5. It is better to release a few features early than waiting forever for all features to finish. The fact is currently DS4 is broken for many users and DS5 is being released to fix that. Unless they already implemented a fix for character loading and are just waiting for a binary break, they should release DS5 and then work on a fix and release it later.

Fair enough, I see your point. Here is mine: as a plugin writer, I would prefer to be adding the new features that the people who use the plugin have asked for instead of re-reverse engineering the changes that Daz made and are no doubt not going to document. That sucks more than having a tooth pulled because the pain lasts longer. I'd like to do it as few times as possible.

 

One potential issue with AutoSave is that it needs to have stable data, so either it has to lock editing, make a copy of the data (and given how long a morph-heavy figure takes to load that may take a while - during which editing would have to be locked,) or queue any chnages the user made until saving was complete. I can see all of those being a pain for the user, and the second and third might well introduce new stability issues. I'm not anti-autosave, for what little that is worth, but I'm not sure how practical it would be in this case; most of the other applications, even the other 3D ones, are likely to have much simpler data structures than DS.

charles said:

Silver Dolphin said:

You could have a full body 3D scan made of you but that is expensive but if you want to be the hero of your story it might be worth it. Just do a search online to see if there is a company near you. 

You can also just take photos of yourself in various angles and use Blender to take Genesis model and turn him into yourself. I should point out that unless you get permission from Daz the company you cant use this Daz model for commercial purposes with out a licence from them. If you use Blender there is a freeware MakeHuman that works great with Blender and that can be your freeware solution to your new 3D self. I comes with clothes and hair. http://www.makehumancommunity.org/content/downloads.html

Are you saying it falls out of the general license as described here https://helpdaz.zendesk.com/hc/en-us/articles/207532343-What-can-I-use-Daz-3D-figures-for-legally-

There is no license which allows you to share or sell Daz content as content, directly or as a derivative. You may, however, share or sell morphs that are all your own work (not incorporating other morph sets in the final baked shape) or settings for other morph sets (presets, or a master controller that sets the morphs - as long as the user has to have the morph sets to use the sahpe it is probably OK under the license).