mrinal said:

mrinal said:

Richard Haseltine said:

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Most of which, even if I agree to accept them as criticisms, have nothing to do with optimisation - and even the ones that might be affected by optimisation don't prove that that is the case. I've not run into the docking issue, and the timeline sounds like an issue with the filtering settings or not looking at the correct node.

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

As other users have observed and reported in other threads, character loading happens in a single thread which is a clear and indisputable indication of inefficiency.

Only if you know of a way to load the properties across multiple threads, given that the non-linear aspect is - as far as I am aware - created by the need to check relationships with the other available properties. If you are just assuming that single-threading is bad then you are not advancing a valid argument. As i said above, we need to stop pronouncing on how the process is deficient unless we actually understand how it is implemented and what other options there may be, with what consequences.

I am not willilng to rule out the necessity for more RAM just to present character morph dials as options. 16GB seems sufficient to load a character when there are only 5-10 characters in the library. But that memory tends to peak out when I have more than 300+ characteres in the library. As others with 64 GBRAM have reported acceptable loading times with library of 300+ characters which makes me doubt the scalability of the memory consumption. Is that 64 GB going to remain sufficient when one's character library increases to 600+ or 900+ in the next few years?

There may be other factors in play - I don't believe that character loading makes that heavy a demand on memory. I just loaded my standard Genesis 8 Female clothes horse figure i use for testing; I have over 600 entries in Smart Content>Products for figures with the G8f selected, plus sundry moprh packs, and the total memory usuage incerased byt a little under 5GB going from an empty scene to the full figure, so unless it was heavily loaded with other activity i'd expect even a 16GB system to cope (8GB might have trouble).

Often times one doesn't need to examine the food for staleness when the stench itself could indicate the symptoms. Not disagreeing to the requirements that people have wanted all morph sets to be made available upfront. That requires the skill of managing conflicting requirements. But the cost of supporting that requirement is not scalable, or has not been implementsed in a scalable way, to say the least. Algorithms are just tools or methods that can only provide benefits when applied to address the appropriate requirements under the right context. It is not justified to blame the efficiency of an existing algorithm, when alternate options/methods are available and more suited to address the task (context). Though I have observed an alarmingly common pattern for people in this industry to blame the limitations of their tools to cover for their lack of resourcefulness in exploring alternate methods.

 

mrinal said:

Richard Haseltine said:

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Most of which, even if I agree to accept them as criticisms, have nothing to do with optimisation - and even the ones that might be affected by optimisation don't prove that that is the case. I've not run into the docking issue, and the timeline sounds like an issue with the filtering settings or not looking at the correct node.

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

As other users have observed and reported in other threads, character loading happens in a single thread which is a clear and indisputable indication of inefficiency. I am not willilng to rule out the necessity for more RAM just to present character morph dials as options. 16GB seems sufficient to load a character when there are only 5-10 characters in the library. But that memory tends to peak out when I have more than 300+ characteres in the library. As others with 64 GBRAM have reported acceptable loading times with library of 300+ characters which makes me doubt the scalability of the memory consumption. Is that 64 GB going to remain sufficient when one's character library increases to 600+ or 900+ in the next few years?

Often times one doesn't need to examine the food for staleness when the stench itself could indicate the symptoms. Not disagreeing to the requirements that people have wanted all morph sets to be made available upfront. That requires the skill of managing conflicting requirements. But the cost of supporting that requirement is not scalable, or has not been implementsed in a scalable way, to say the least. Algorithms are just tools or methods that can only provide benefits when applied to address the appropriate requirements under the right context. It is not justified to blame the efficiency of an existing algorithm, when alternate options/methods are available and more suited to address the task (context). Though I have observed an alarmingly common pattern for people in this industry to blame the limitations of their tools to cover for their lack of resourcefulness in exploring alternate methods.

I know Padone was able to get the diffeomorphic method to work with simple IK, but for the life of me following every direction on the Diffeo site to the T as well as the other link Padone sent regarding the ticket that was set up in another thread, I just could never get it work. I don't know what exactly the step I'm missing is considering I've tried it at least a dozen times going exactly step by step to no avail in Blender multiple versions of Blender. I was able to get the keyframes to transfer using the MHX rig and then the transfer that they lay out how to do, but you can't transfer IK with that. So it's possible if you don't want IK, but if you're doing pull ups and such, you're going to want that. 

I wish there was a way that worked flawlessly, that would be so awesome. 

Richard Haseltine said:

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Most of which, even if I agree to accept them as criticisms, have nothing to do with optimisation - and even the ones that might be affected by optimisation don't prove that that is the case. I've not run into the docking issue, and the timeline sounds like an issue with the filtering settings or not looking at the correct node.

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

Often times one doesn't need to examine the food for staleness when the stench itself could indicate the symptoms. Not disagreeing to the requirements that people have wanted morph sets to be made available. That requires the skill of managing conflicting requirements. But the cost supporting that requirement is not scalable, or has not been implementsed in a scalable way, to say the least. Algorithms are just tools or methods that can only provide benefit when applied to address the appropriate requirements under the right context. It is not justified to blame the efficiency of an existing algorithm, when alternate options/methods are available and more suited to address the task (context).

Richard Haseltine said:

This is a known issue with the current version of DS - it will be fixed in a forthcoming version. In the emantime you might need to work via OBJ, at least for sending to ZBrush - use the modo preset in the export duialogue and don't forget to hide attachmanets and set the resolution to base.

 When I export in Zbrush, what setting should I use for Morph Loader Pro or Importing OBJ? Because importing as Daz Studio or Poser, makes the OBJ very very tiny. I have to scale it to about 4000% scale to get it back to normal.

I'm trying to Mirror this morph to the other Eye.

I'm trying to create a eJMC for Genesis 8 eyelashes. I got one side looking good. For Eyes Closed Left. I want to mirror this. I used Morph Loader Pro. When I Mirror... It applies to both the left AND to the right Eye lashes instead of mirroring. What am I doing wrong? Also its distoring the morph all weird and looks horrible.

@Anfy

@Ruthven

Il libro (in formato digitale e in inglese) lo trovate qui: https://www.packtpub.com/product/the-complete-guide-to-daz-studio-4/9781849694087 

Sul sito stanno anche facendo 2 promo:

• 7 giorni accesso a tutta la libreria gratis (come prova)
• 5 mesi di accesso a 5 €

Il libro non ve lo consiglio perchè è del 2013 e ha 348 pagine di cui più della metà parlano di cose che voi già sapete fare (mettere vestiti, aggiungere oggettti alla scena, ecc..)

Inoltre se vi leggete l'indice troverete argomenti come LuxRender (ormai superato) e modellare un vestito con Modo (software 3D non così diffuso). Non c'è Iray e non va mai a fondo su questioni tipo i morph, o il Transfer Utility o ERC Freeze.

Potete sempre provarlo per 7 giorni gratis se volete.

Purtroppo i libri sui programmi 3D (in generale, non solo DAZ) stanno scomparendo, siccome ogni anno escono le versioni nuove dei vari programmi, i libri già dopo 1 o 2 anni sono obsoleti e non tengono il passo coi corsi dei vari Gnomon, Pluralsight, Lynda, Udemy ....e perfino quelli gratis su Youtube. Se poi qualche software house cambia l'interfaccia è un macello... è un trend che sta andando avanti da prima della pandemia. 

Per quanto riguarda le mie conoscenze io sono un hobbista e dunque gioco con DAZ nel tempo libero (infatti posto sempre durante le pause o la sera dopo cena). Molte cose le ho imparate  perchè sto cercando di creare contenuti per DAZ. Finora ho fatto dei morph (ancora da migliorare) e sto cercando di convertire oggetti 3D (scaricati da sketchfab, turbosquid, ecc..) in vestiti per DAZ. Pertanto sbatto la testa con queste cose.
All'utente medio non interessano questi argomenti (prende un character, 3-4 vestiti e uno sfondo e addirittura dei settaggi pronti) per cui la DAZ non ha interesse a fare guide specifiche su tali argomenti, infatti molta roba la trovo sui forum o addirittura sulla vecchia guida online (che è molto tecnica).

Cmq nel tempo, mi sono creato una mia guida in word su come funzionano alcune cose (molto spesso se vado a memoria me le dimentico, così le ritrovo scritte) scritte però in formato appunti (dunque con termini non proprio italici). Però mi aiuta quando magari devo ricontrolalre qualche parametro o settaggio.

@Anfy

sottoscrivo quanto detto da Imago per la scheda Shaping... purtroppo ogni PA della DAZ fa a modo sui e dunque capita spesso che dentro a quella scheda non trovi solo i morph ma anche delle pose o altre cose che non centrano nulla (la scheda non è altro che il contenuto che trovi nel gruppo Actor nella Parameter TAB dei vari G/G2/G3/G8)  

Hi,

  The G8 geoshell presets to do not transfer to G8.1 Torso. A lot of vendors are selling products using the geoshells and a lot of customers want to

update their purchases to G8.1 geoshells.

As a vendor I have a lot of G8 products that are for geoshells that do not work with G8.1.

Also Customers are contacting me how to use them on G8.1.

Is there a script that would change the torso to head, body so I could batch convert all of my G8 products to work with G8.1.

Even if I knew how to replace the torso text with head, body text it would be a great help for batch conversion.

Any help or advice would be greatly appreciated.

Cheerio

lululee

Psyckosama said:

Zaciszna Dolina said:

In the styles of Pacfic Rim, Robotech and Battletech/Mechwarrior and of course pilot outfits as well.

Thinking more along the lines of more realistic style rather than anima style.

Supporting buildings, space craft and vehicles would be cool as well.

Honestly your best option would be to go to one of the Patreon fed figure conversion guys and ask them to start porting over models from MWO/MW5/Battletech and other games such as the failed Heavy Gear game that no longer works but is still for sale on steam.

Their comission prices aren't that bad an compared to creating a new character morph and making the clothing work, rigging a giant stompy robot wouldn't be that pricy.

As for the Heavy Gear style, Heavy Gear Blitz is a complete failure of a game that doesn't work but the models look good and I actually have extracted the game assets. I need to learn rigging one of these days...

Actually, that hadn't really occured to me to try that. Thanks for the suggestion!

alainmerigot said:

Richard Haseltine said:

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

...

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

That is exactly what I said "unless the DB has been refreshed". OS give no portable (nor efficient) means to determine if a subtree of the file system has been modified, but knowing when the DB is refreshed is trivial (even if UI management is in another part of the software). Daz would introduce a modification saying "To reduce the char loading time, the char morph content will be read only once. If you want changes to be taken into account for the newly loaded chars, perform a DB refresh", I am certain that ALL users would be VERY pleased. And even without knowing Daz Studio source code, I know that some modifications are complex and can break code functionality, while others (like this one) are rather simple.

Maybe, but running the utility to update the ExP files for the fourth generation Daz figures was pretty simple but caused many people problems.

Frinkky said:

 Patronise much? You're clearly in a bad mood...

The specific smiles Rarestone tends to use in their promos are not just dial spun/powerpose but involve custom morphs to accentuate certain shapes,folds and creases. Sometimes these are included in their character products. Were this character still available you'd see that.

If it's a morph for this character's face morph, it probably wouldn't be sold separately.

Anyway, if you want to know what's in the product, check the product page:

http://docs.daz3d.com/doku.php/public/read_me/index/82031/start

• data/DAZ 3D/Genesis 8/Female 8_1/Morphs/Rarestone/RNMinto8.1/PBMRNMintoFaceStrcutrueRRebuilt.dsf

• /data/DAZ 3D/Genesis 8/Female 8_1/Morphs/Rarestone/RNMinto8.1/PBMRNMintoFaceStrcutrueYoung.dsf

• /data/DAZ 3D/Genesis 8/Female 8_1/Morphs/Rarestone/RNMinto8.1/PBMRNMintoFaceStrcutrueYoung2.dsf

• /data/DAZ 3D/Genesis 8/Female 8_1/Morphs/Rarestone/RNMinto8.1/RS Minto 8.1 Simle Expression HD.dhdm

• /data/DAZ 3D/Genesis 8/Female 8_1/Morphs/Rarestone/RNMinto8.1/RS Minto 8.1 Simle Expression HD.dsf

Given all the misspellings in the files, the product might've just launched broken and Daz told them to tidy it up.

Ascania said:

Terms of Use. Two Dimensional Works. Subject to the terms and conditions of this Agreement, User may (i) access, use, copy and modify the Content in the creation and presentation of two-dimensional animations and renderings, (ii) incorporate two dimensional images (including two dimensional images that simulate motion of three dimensional objects) derived by User from the Content in User's other works, and (iii) publish, market, distribute, transfer, sell or sublicense User's two-dimensional animations, renderings and other works; provided that User may not in any case publish, market, distribute, transfer, sell or sublicense any renderings, animations, software applications, data or any other product from which any Content, or any part thereof, or any substantially similar version of the Content can be separately exported, extracted or de-compiled into any re-distributable form or format.

The EULA is really not that hard to understand.

LOL, expect that kind of reception when you publish your novel.

Richard Haseltine said:

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

...

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

That is exactly what I said "unless the DB has been refreshed". OS give no portable (nor efficient) means to determine if a subtree of the file system has been modified, but knowing when the DB is refreshed is trivial (even if UI management is in another part of the software). Daz would introduce a modification saying "To reduce the char loading time, the char morph content will be read only once. If you want changes to be taken into account for the newly loaded chars, perform a DB refresh", I am certain that ALL users would be VERY pleased. And even without knowing Daz Studio source code, I know that some modifications are complex and can break code functionality, while others (like this one) are rather simple.

Anfy said:

Non buttarti così giù, io non sono messa molto meglio di te; per imparare ad usare Daz bene ci vuole tempo da dedicare a studiarselo a fondo e fare tante prove... 

A mero titolo di esempio mi è del tutto sconosciuta la ragion d'essere del tab "Shaping" tra Parameters e Posing: dentro ci trovo un po' di tutto, ma non riesco a individuare una funzione logica che ne giustifichi l'esistenza... 

Serve ad avere sotto mano tutti i morph di una figura, separati da altri parametri come posizione, dimensioni, rotazione o morph che non rientrano in quelle liste predefinite.
Io preferisco usare il tab Parameters per avere tutto sotto controllo quando faccio i mix dei morphs ma il tab Shaping può tornare utile per avere una lista "pulita" per creare un personaggio.

mrinal said:

frank0314 said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Do you have enough system RAM and a big enough GPU? I'm not having any of those problems regardless of how big my scene it. Obviously if you have the Iray shader turned on in a huge scene you'll have a bit of a lag but that really the only time I get them.

System RAM and GPU limitations are not the main bottleneck here. DS works fine when there are fewer characters and morphs assets in the content library. The problem is the scalability factor which does not seem to have been addressed in the software. With every new character or morph asset added to library, the resource cost increases at a much higher rate than the perceivable benefit it adds. For example, when I use a character in my scene, I only use a combination 2-3 other character morph dials beside a few other generic morphs. But to provide those 2-3 character morph options DS has to pre-load hundreds of character dials to make them available as option in parameters. Almost all of this preloading is unwarranted and unnecessarily draining system resources and load time when the user uses less than 1% of it in any given scene. This is entirely going against to some software design best practices and patterns like YAGNI (you aren't gonna need it).
 
The user should not be forced to upgrade the system RAM just to accommodate the option of making the new characters available as morph option in a given scene. The system RAM could be a limiting factor for the size and complexity of the scene NOT a limiting factor for the size of the entire content library.
 
Content sets do not address this problem since they render the excluded content totally inaccessible without restarting DS.

Then tell that to every software manufacturer out there. Each and every program out there requires more RAM, processing and VRAM with ever new version, with the exception of a very few. Especially in this industry.

alainmerigot said:

mrinal said:

Richard Haseltine said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Most of which, even if I agree to accept them as criticisms, have nothing to do with optimisation - and even the ones that might be affected by optimisation don't prove that that is the case. I've not run into the docking issue, and the timeline sounds like an issue with the filtering settings or not looking at the correct node.

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Please stop the assumptions about how the code is inefficient or not optimised - we don't havea ccess to the code to judge.

It's true that loading can be very slow - though memory is not the issue, so I don't think this si forcing people to upgrade - but there does need to be a recognition that people have wanted to have multiple morph sets available, and to be able to add 9or remove) sets and characters easily (which is why loading a second figure again does the property reading). I'm sure Daz is aware of the issue, but they are still bound by the laws of algorithmics and the need to maintain compatibility. We will have to see if daz Studio 5 offers an alternative (and if it does, whether it requires new content to use it).

Hi. Don't think morph packages like these will require any updates for DS5, mainly script based products.

mrinal said:

Richard Haseltine said:

margrave said:

Based on: it takes whole minutes to load a figure and even longer to start a new scene if you have a figure in memory; Daz's IK is riddled with lag but exported figures in Blender aren't; the timeline is a confusing mess with keyframes that disappear yet still affect your scene; docking UI panes is an exercise in frustration and can sometimes get panels stuck so they can't be removed without resetting the layout.

There's probably more, but those are the ones that came to mind as giving me the most grief.

Most of which, even if I agree to accept them as criticisms, have nothing to do with optimisation - and even the ones that might be affected by optimisation don't prove that that is the case. I've not run into the docking issue, and the timeline sounds like an issue with the filtering settings or not looking at the correct node.

Optimisation or not, the problem lies within the concern that the DS's architecture/design and morph loading approach has not evolved to support the size of the content library that users have today. When it comes to supporting larger asset library, DS still uses that archaic method of loading assets that was deemed sufficient a decade ago when the users content library wasn't that vast. There are software design issues that can no longer be swept under the rug (without buying a larger rug, of course).

An architecture rethink would abviously be required, but there is also a problem of basic code optimization. Even with this archaic method, it could be easily possible to have much faster loading times. If I load 2 g8F, I can understand that the first one takes a lot of time to load all the morphs. But what about the second g8F? Why is the full morph directory (re)scanning required? Loading should resuse the results of the first scan, unless the DB has been refreshed. So just one full scan per char family per session and the second load should be almost instant. (and it is not alas what I see...)

It could also be possible to scan all the figures directories for their content in another thread while the user is idle. Many (simple) optimizations are possible and not done.

Maybe it's possible to uncover the cup and there's a perfect boba tea morph under that cover :D ?