Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
So if I ever used that script if I had installed via Connect & DIM simultaneously would the script still work?
I think, IIRC the script was originally agnostic about where the material was installed, but it very well may not work on properly installed connect morphs.
I'm not sure about this, as I don't use Connect, and don't want to just make a toy. That said, there are two factors. A, the script doesn't actually care what figure you start with. It will attept to copy morphs from there to Genesis 8. Originally, it would attempt to copy the full path, meaning if X was stored in connect, it would try to use that path. This ended up overwriting someone's files, because of the differences in how Connect paths are named.
To avoid this happeneing, the script was modified so it always writes to the primary library unless for some reason that library is Connect. It should always fail to write to Connect libraries.
B) is trickier. Connect content is encrypted and is opened by studio at runtime. I don't know if the script IDE counts as runtime for this purpose, so the script may not actually be able to read Connect files to begin with. Because of this point, I never intended to support Connect to begin, though the code was able to access that library, on the off chance it would work. Generally, I don't expect it to, and it is the main thing I don't intend to support. As noted, you fiddle around by using Dim or manual install to transfer most connect content, so that only leaves the stuff that Daz has on the one year embargo out of the transfer. I'm, personally, fine with that, as I don't want to mess with Daz's general plan. After all, the output of the script is not encrypted, and this tool is not intended as a decryption source.
My tip would be to get comfy with modifying you content library list. Basically, create a new library, then disconnect it from Daz. When you have connect based content you want to transfer, manual install it to this new disconnected lib. Open the lib manager, and disable Connect. Enable the new lib, and load G3. Run script.. Disable the new lib, enable connect, and restart studio. Seems less trouble, IMO, than removing specific items from Connect, and you can just browse to the folder where this spare libray is and delete all of its content whenever you finish.
TBH, you probably will. The script has limitations. Most of my custom work has been further customized since transfer, but I'm a tweeker, at heart. At this point none of the G8 versions actuall match the G3 versions they started from. But as accurate as the script is meant to be, it definitely adds small differences. Most notably around the arms, though it take fairly exteme morphs to see them (not the shoulder distortion that comes from the manual methods).
I'm glad it worked for you, and I hope it's not too much work to fix. If you are shooting for exact accuracy, tho, the biggest issue you'll see is around the eyes. The transfered eyeballs are good enough for governement work, but the differences in the meshes (G8 being watertight, G3 being not) means the results are a bit off. Also, I thin the UV differences make for a slightly different look. The UVs are close, but not quite the same.
That is not an accurate description of Daz Connect. Daz Connect can install both unencrypted and encrypted products. Only encrypted products are in an encrypted state within the Daz Connect library. Very few products in the Daz Store were ever encrypted, and almost all (if not all) of those have been made available in unencrypted format after a year. I have many hundreds of products in my Daz Connect library, and not a one of them is encrypted.
I believe problem with your script and Daz Connect is that Daz Connect installs each product into its own folder in the "cloud" directory in the Daz Connect library. The file folder structure does not match the file folder structure expected by your script. This is not a problem unique to your script. Many script product in the Daz Store suffer from the same type of problem, especially those written before Daz Connect was released.
Don't take this wrong - I think your script is great! It just doesn't work with Daz Connect installed morphs. The workaround for me is to uninstall with Daz Connect, Install with DIM, run the script, (optionally uninstall with DIM and reinstall with Daz Connect).
Again, this is pretty much by choice. Encrypted content exists, which is one reason. The folders are different, and while I could reverse engineer the structure from the sripts that filled out the basis of my script, I can't test it, because I refuse to use connect. So trying to support connect would result in variable results for limited pay off.
Oddly, the structure of the connect library doesn't really enter into it. The script simply doesn't care as far as that is concerned. It's actually down to the data in the files themselves, because as far as my userstanding of the commands in script goes, if it can open the files, it will transfer them, and it does not hard code the location of the files, at all. It gets that data from the App Manager. Of course, I may have eliminated the ability to access Connect and forgot I did that, but, again, one of the first users ended up with overwritten connect files that were broken due to the simple fact that the script is case sensitive and overwrites agressively, and thus the original redirect that took the base file path and rewrote it for Genesis 8 failed due to Connect using "genesis" rather than "Genesis". This was actually repaired in the next release, and was the event that inspired the warning about risk inherent with connect.
So, unless I forgot I disabled that (I maight have. I didn't like the kludge I used to solve that, even though it was probably the smarter way to do it. Maybe I was sore at not having thought of it from the beginning), the script actually can read and write out from Connect. Some of the Connect files may have statements in them that reference the Connect file path convention and that might cause those files to fail to load. Some other effect might cause them to fail to load. But given the fact that some connect files are encrypted, there are some Connect items that it will always fail, and I don't have any Connect product to test.
Given that, I just don't see a good reason to support Connect. Nobody's paying me to. And frankly, they'd have to pay a lot. I do understand that people want one click solutions, but that kind of thing is beyond my skills. Really. (The one click method would hijack Transfer Utility to make the conversion, but I just use a brute force method. Using TU would be WAAAAAAY faster, but I have no idea how invoke it from a script). I'm a creative little prick, and a decent hacker, but not a code monkey or programmer. A hacker hacks things together, which is what I do. A programmer or code monkey will tend know and understand the general case of how and why stuff works. (You will find most great hackers are also people who fully understand the machine, and always get Randal Munroe's jokes.) I just know the general case of why computers work, and can eventually parse most code if I stare at it long enough (And do better than average at getting Munroe's humor). After that, it's hack, hack, hack, why in Dog's name isn't that working? Supporting Studio features I don't use seems a bridge too far. Hell, I'm too lazy to account for non standard file structures in the base library structure. I've thought of a way to do it, but it's such a small fration of what I do, I can hack around it faster. It's like that XKCD comic (if you allude to Munroe three time, he will appear) about how often you do a thing combined how long it takes to do each time defining the amount of time you can spend trying to automate it before you're spending more time preparing to automate than just doing.
I found your scripts very usefull but wish it could go the other way too as I am not as into genesis 8 as much as genesis 3 even though they finally released a lot of animations and mocaps for it 3 is easier for me to adapt other sources to and can be fixed for Carrara easier too.
I do want to do this, but I never find the time to finish. One day, perhaps. It's not technically impossible or anything, but it is more involved than just running the script backward. The translation method has to be rebuilt. Right now, I'm still in the process of finishing the morphs needed to run the script that make the translation. then I'd have to write the translation. THEN write the two scripts.
Which isn't entirely true. I'm actually in the process of making the morph I'd need to add fingernail support to G8F. It's just that morph is mosly like the one I'd need for making the changes morph to go from G8F to G3F. The Male version of the morph is already in that state, but it's still going to a process of manually positioning something like 3000 verticies.
Tedious.
you might want to submit that one to DAZ 3D for sale then as with all that work an ensured monetary return would be well deserved.
I honestly don't feel I can add enough value or reliability to make vaiable product out of it.
See my comments on being a hacker. I know the modern idea of a hacker is coolness, super skill and danger (while most modern hackers are probably either script kiddies or intelligence employees) but I'm just a guy who hacks stuff together. Which is pretty much all I tend to do.
Even now, my sanity hobby project has a habit of straigh crashing Studio because I'm asking it do things it doesn't really want to (though the root cause here was actually a 3rd party morph which I ended up deleting, because it didn't really do anything important, but it was still only an issue because I overtax the system).
I wouldn't mind developing a real product, but not this. This is free for freeness sake. I can't imagine this script, even if it were product ready, would generate enough revenue to pay for the time I still need to sink into it, or even provide a nice level of play money. If anyone wants to give hard numbers on similar products that don't have legs, I'll be willing to adjust my thinking. Of course, if anyone feels it needs to happen faster than I will do it, they are free to extend it themselves. Which is not me being pissy. I've explained the methods behind it more than once, here, and I'm more than happy to answer questions, though I'd prbably be slow on that, too. Over all, if one wanted to make this thing happen, the key is just creating that really long list of function calls in the middle of the script, and while it's a tedious job to do, one doesn't really need to understand code to do it. My total code experience previous to this was basic BASIC and beating website scripts into submission.
It might be worth the time of those who just can't to try and convince someone like Mork to take it up, since those folks are much better at this nuts and bolts stuff than I am.
There is a well received pose converter in the store that only adjusts four joints. I am willing to bet a morph converter would sell way better.
However I understand being reluctant to sell hobby stuff.
I have to agree, it is already working very well and it would be on my top list of must have products for Daz.
If I now only could figure out this:
"I have a weird problem that I hope someone knows an awnser to. I tried to save a figure as character present with a transfered morp, but when I load the saved figure the morph is not showing until I move a slider to the character. Example: I transfered Bethany 7 mophs and applied it to G8F and saved as character present. but when loading the new character it shows up without the Bethany 7 morph showing.If I do any change to any slider though like Y Rotate slider the morphs suddenly shows on the character."
Same here. This was 100%, competition blown out of the water, my top most useful product of 2017.
Thank you.
I see your point, but if I may be so bold, your "world's greates pose converter" is, indeed the best of all pose converters. Hands down. Between it, and one from shareCG to deal with poses built on pose controls, nothing else is really needed. It is, I believe the appropriate term is, "fantabulous."
All of which is me begging the question.
Thank you, really. I'm really happy that people find this thing useful.
I forgot about your question when I popped back in and saw it because, frankly, I'm stumped. I couldn't think of a reason a morph would not update right away, or wait until you did something else, at least not one based on the DSON mechanism. It sounds like a draw error in the display engine, but every one of those I know of is fatal. Crashes studio. That said, I don't know of any means to detect a draw error except to see it listed in the crash report.
One of the things I do hack is DSON, because you can get things to work right when you do. A rolling issue I've had is when you have n G8F figures loaded, where n is greater than 1, hierachical materials presets will only laod on the first figure. This is because the Hmat/Hpose format specifies the figure by ID. I feel like Studio should know that Genesis*Fremale_6856 is still a Genesis figure, but mine doesn't seem to.
But with the power of find and replace, I can change that specification to @selection and it works just fine (slightly more complicated thna that, but just slightly). I say all this unrelated stuff to kinda build cred that I sorta know what's up when I say, a DSON file should just have code the translates to "set the Bethany 7 property value to n" and then the software should apply that. The only thing I can imagine causing that not to happen is some other thing erroring out at load, and then updating when you force the first figure draw/morph update.
That would imply a different morph in your preset is causing the issue. As a means of trouble shooting, save a preset that is nothing but Bethany 7 Body and another that is just head, then new scene, and load each character preset as a separate figure and see if the problem persists.
If it doesn't then there might be an explanation for why the particular preset you made is failing in the log. If it does, I'm still stumped.
I could have sold it, it was sellable, and I knew it, but I made it on purpose to give back to a community that has already given a hell of a lot to me. This is why I undersand the reluctance to go to market with something made just for the love of it. Trust me, though, the doubts that you have about your converter being an incomplete product are not doubts most people have.
Ironically, if I did sell it the reach might have been wider. (I did hit a thousand combined downloads, though, woo!)
Someone, and I have forgotten who (sorry. I should look it up when I have time) asked me about converting animations, in general. I did look into it, and start working, but (and correct me if I'm wrong) your converter makes that redundant. G3 animations should run on G8 if your converter is active, right?
This, btw, is what I mean about best of all possible converters. So simple, yet so powerful, and easy. And with option to limit the parts and strength of the effect as a set of pose controls, it's just stupendous. Possibly other words ending in "ous."
I realize the execution isn't necessary uber complex, but considering everything, it seems like it must have been some sort of investment to make it (BTW, if you change the figure references to G3 and reverse the sign of delta values and copy it to G3, it works, converting G8 Poses for G3. That I made this hack means I'm not just saying the previous, I looked at the files in detail to do that). I apreciate that it's free, but I would have paid for it just on the strength of the description. It's like an iPhone. Obvious that it ought to have been made, in hindsight, but not so obvious until you did it.
I get the impression people see my script the way I see this converter. I guess I just can't unsee the rough edges. But, I look at it like this. The script is dead simple. The real "Intellectual property" is the translation matrix. So, if the script is fully polished and "professional" before Genesis 9, well, I'll have a G9 product if I can develop a matrix.
(I probably just sowed the seeds of Daz making it harder to make that matrix, but what's life without challenge, eh?)
They sure do!
I really appreciate these comments. And that's clever reversing the deltas to go backwards. The idea kicked around in the back of my head for a while but I never tried.
If previous release schedule is followed, I expect G9 in about a year and a half. So here's hoping you get all kinds of time to polish the script, and that when the figures launch developing the translation matrix isn't too bad. I think with the loss of the GenX creator the market will really be hurting then.
Thank you for your very thorough awnser, that is very much appriciated.
So I did the only head and only body morph test, with render subD level being the only other thing showed in currently used, but the issue presisted.
But the draw error you explained could be the reason, becuse when I did a test render the morph showed up on the render and after closing the render the morph was showing in viewport as well without any crashing or fatal error.
I guess some kind of action (movement, render or morph) is needed for viewport to update and show the transfered morphs when saved as a character present (other morphs does work fine though).
Once again thank you for your help. I do not know how to fix this yet but now with your help I atleast I know why it is happining. Time to rack my brain and see if I can figure out a way to work around this :-)
I upgraded to 4.10 a coule of days ago, because I was having an issue with a geograft I'm working on (I hurd I liked geografts, so I made a geograft for my geograft). Studio get's annoyed when you graft grafts, though it works. But a morph on the first graft was causing an access violation when projected into the second, and I couln't figure this out to save my life. I knew projection was at issue, but I'd turn of a morph, and thing would work, then stop working. I eventually found the suspect morph (it was hidden) tested it and noted that it did almost nothing, so removed it entirely, and now all is well.
But something I noticed after the upgrade, changing things, like hiding the main figure but not hiding the figure grafted to it, will cause the viewport to stop drawing subd.But then, move a slider, and subd comes back. In 4.9, sometimes subd would fail to draw, and when that happened, you had to restart studio to get it back, but here, this new behavior is happening. Maybe that's related to your issue.
It also might be something in the way the script writes out the DSF file. Sometimes it ends up with dangling tab characters, and I've not yet thought of a safe way to clean that up. most of the time, nothing seems to happen due to this, but every once in a while, things conspire to cause the morph not to load at all. Maybe this issue is an inbetween case, where studio burps while trying to parse the string, but is able to get there, in the end. I dunno.
I figure someone will work something out, eventually. I know there is at least on other thing out there that automates the drudge work in Redz's tutorial, I guess, since it creates an obj file for you to import as a morph. Of course, mine is the only one the focuses on retaining the ERC as far as I'm aware.
I think what I really want to do is come up with a method that is more generic than what I have, since this one is exploiting the fact that most of G8 is G3, but in a different pose. If I hit on an idea to do that, I might turn it around and act sooner, just because the resulting tool would be a genuine GenX replacement.
Oh my.
Perhaps I spoke too soon, vis-a-vis not making a saleable product.
Anyone out there willing to give a short explanation of the whole Daz widget scheme? Cuz I just dicovered something wonderful in documentation.
(*resolves never to complain about the docs again)
I haven't used your script(s) yet but likely will as I doubt Toon Generations 2 and Morpheus are coming to Genesis 8.
For a example code more so than a tutorial overview check out this Sun-Sky Clock Setter Widget I think would meet your example needs requirement:
https://www.daz3d.com/forums/discussion/210121/sun-sky-time-for-iray-script
If not the LAMH plugin has quite an involved UI and maybe if you are lucky the LAMH UI scripts are unencrypted (the LAMH part though is dll files). It does things like open an external window and plag a wireframe mesh of the model that is being LAMH edited along with that models surfaces. Not to copy directly but to see how to invoke the DAZ UI API (which is probably just a scripted wrapper around the QT UI for the most part I've never looked at it).
Probably you could design a Morph Selection Transfer UI that highlighted areas of a model appropriately effected by a morph by have a volume represented by the original unmorphed surface area and than a ghosty opaque colored volume shown over the original volume of what the morph looks like completely dialed in. Keep thing though is the DAZ SDK going to be even capable of such UI fluidity. e.g. Petite button nose on a fairy morphed to a big hooked nose of a wicked witch as a general example the fairy nose is drawn normally but the witch nose is like a color clear overlay showing what the selected morph to transfer does.
I'd probably buy your product, especially if provided a visual way to select morphs to transfer.
I am also a (rusty) programmer so if you want help let me know. Certainly can help you test if you like, just PM me.
Examples are right up my alley. I do like to figure out what the heck I'm doing by trying to break things. I'm not sure why. I guess I desire frustrations :D
Thanks!
I make no promises on a time frame, but if I understood what I just found correctly, the script is about to get very extremely strong. Indeed, the power to destroy a planet would be insignificant next to the power of the script.
Progress is made by pushing the breaking point further and further
I've never heard of a "Daz widget". Do you mean plugin?
The reasonable mind seeks accomodation with reality, therefore all progress depends on the unreasonable mind?
I'm not sure if this is quite that progressive. It's just that there are few new toys to play with, now. I'm being cagey right now, because letting slip at this point is just begging someone to beat me to it. But if I find I can't get there, I'll definitely explain why I'm not really pushing the boudaries that far.
I think the specific term is DzWidget. It's a method (object) in DazScript. It's what defines a script User Interface, if a script has one. I'm not sure how far I want to push that, as the important thing is a script that does the thing, rather than one that looks pretty, but the sheer scope of what's now possible is going to require some kind of UI, and I've tended to avoid that bit.
Because, to repeat myself, I see the background bit as most important. Still, having the most informative possible UI is probably a good thing.
And just to explain what I mean by "sheer scope." This thing I found isn't going to be a just a more slick or more effective method of making transfers. Rather, it is going promote this script to a real replacement for GenX2. Unless I fail. And even then, the method is certain to work for all current Genesis figures.
Sounds cool to me!
Well, I'm in no hurry to compete with you although I've been considering taking your script(s), pasting a UI on it, and releasing that result on shareCG. However, truthfully I'd be better off writing on my game UI since I intend to use the same UI for all my games.
Haha, back when I did OpenWindows (and others too) there was always these neat little UI generators that generated these UI forms and the UI developer would always have the false sense of security they were finished. They never were because in those days initialization routines in OSes and API libraries were much less stringent and the developer would invariably have a mostly managable mess to debug although sometimes the bugs would come from deep in the OS or the API libraries and they'd have to try & kludge a workawork.
I'd have no issue if you did that. THat version of the script is, by definition, creative commons.
Technically, this new idea would be different script entirely, though it uses some of the same core ideas. So, I'm fine with whatever happens to the current script.
I need to sleep, but I'm just so jazzed by this. It's exciting.
Look forward to it then when it is ready.