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 ?

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.

Is this possible or should I look elsewhere, if not is there any software that can do what I need.?

Actually it wont matter what  external program you use to create Character animation with IK (Autodesk MOBU,Reallusion 3DX,Mixamo etc)

The IK solving wont transfer to Daz studio correctly  to G3/8 even  as baked FK.

I have told people about this for the past year
to no avail.

Apparently there is a third party Houdini Character motion transfer plugin
in the works, so that may have a solution at some point
assuming you want to acquire&learn SideFX Houdini

The bridges exist for people who actually plan to render Genesis
figures in EXTERNAL programs where the native IK system of those other
progams can be applied.

If you plan to render in Daz studio you really need to animate your figures in Daz studio as best you can, 

SebastianMichaelis said:

One can also use the transfer utility

I'm not sure I remember all the steps for a 100% perfect transfer, but.

• Load up G3F and M
• Select the character you're transferring from, In this example, lets say G3M, Favorite the morphs you want transferred in the parameters panel and dial in either the G3F clone or if you have the Cross Figure Resource kit The "Transfer to" morph from that (you will need to turn on show hidden in the parameters panel to find them) Dial out any othe morphs that may be applied, you want just the clone morph
• go to edit>object>transfer utility
• For source select the figure with the morphs you want transferred, in this instance G3M, set item shape to "Current" (this way the clone you dialed in will be taken into account)
• For target figure set the figure you want the morphs transferred to, in this instance G3F leave the item shape alone.
• click show options, there's a lot of stuff there, but we won't be using most of it.
• have checked only:
  • "Smart left/right filtering"
  • "closest vertex first" (this one is new to the latest beta, but will make the areas around the eyes transfer a bit better, but isn'r 100% necessary if you don't want to use the beta)
  • "Morph targets"
    • Click morph targets to see the extended options, set the source to "favorites" and unclick "from projection template"
•  everything else should be unclicked, we dont want weight maps or to fit one figure to another.

 

• Hit accept, your morphs should transfer pretty nicely!
• You will need to save your morphs as anyother morph under save as > support asset > morph asset

one note transferring morphs does not do things like transferring changes to rigging, so if you have a moprh that drastically alters the proportions of the figure (like changes to height,) things will look weird when you pose the figure, but that is beyond the scope of this tutorial

 

 

This works wonderfully for Genesis 8 Figures. Thank you.

this worked over the other one by sickle yield. quick easy to read and worked. sorry to necro but this thread should never die.

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).

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.