Hey guys, I am running daz 4.15 and am having trouble getting started. I went back to page 24 where Mike the 3d guy entered the fight. I am by no means a pro at daz but very much want this to work on g8f. I understand you need to clone the g8f to g8m but that is where i am having issuses. I have the genesis UV swap and the cross figure resource kit. Every time i use the transfer utility nothing happens or the 2 bodies or become one with deformaties. Once i have the 2 models by themselves i go to the transfer utilities. Sourse is the g8f with item shape selected to default Target is the g8m and item shape is selected to clone g8f. Projection template is selected to none. According to Terry the boxes selected are do I uncheck all the boxes except for morph targets, smart left/right filtering, and concider lines as rigid. Now either nothing happens at all and I still have my 2 models standing there with no changes or if i go to transfer utilities again and leave all the pre checked items i get stuck at 22% just like Mike did! I don't know what I am missing? I've read the post close to 100 times but and still scratching my head.

Just looked at the log.

As far as I can tell it's loading morph deltas then it CTD( crashes to desktop)

Is that what happens?

Are you trying to load G8F and the program suddenly closes and you are back to the desktop?

Where to start---

First up the Duplicate Keys, seen a few reports of these in the past 6 months or so, I suspect that someone at DAZ has changed something in a product, then Connect has had a brain fart when it's seen the changes.

The Duplicate Formula is the standard two products with the same internal asset IDs. Did a search and there are at least three G8F characters called Mercy, two sold here at DAZ and the other over at Renderosity, wouldn't be surprised to find you have two of them or all three.
The problem is poor workflow and bad habits, as a result you have two products with "Mercy Head" and "Mercy Body" as the asset IDs, and thanks to the animated joint centers about 1K+ Duplicate Formula errors in the log.

Richard I think someone should have a word with Zeddicuss, and tell him/her to stop making alias files as he/she is so effing bad at them, first one I've seen with syntax errors, the others I've seen are normally bad ERC pathways.

You have an eyelash morph called "3DA Lashes" that has bad parent data, as a result DS wont load it.

Looks like the character Baila by SASE is having a hard time finding G8F's facial rigging, not sure why as it appears to be looking in the right place.

And a whole stack of vender cock ups and missing dependances to add to the mess.

duckbomb said:

Asari said:

drzap said:

there are at least 2 work-a-rounds for this problem.  What you are experiencing in Maya is the pure basemesh.  You are not comparing apples to apples.  Unless you dial down your viewport in DS, you won't ever see what the basemesh really looks like.  Anyways, here are the workarounds that I use:

 

1. Export a hi-poly OBJ (usually subD4) and bake it as a displacement map to your Maya rig.   I bake vector displacements in Zbrush or Mudbox.  I use this method when I want to use the micro details already on the HD Daz asset (HD morphs).
2.  Export hi-poly OBJ (usually subD2 or 3) and use it as your render mesh.  You can transfer animation by means of UVblendshapes.  I do this when I'm transferring micro-details from other sources or making my own.

There is also a third possible way:  a piece of software published by a friend of mine called Kinetic Motive has a feature that reportedly automatically bakes the HD morph from Daz into your Maya rig.  I haven't tried this feature to confirm it, but you might want to try it out.  Good luck. 

/edit/   I neglected to provide you with links for the tools used in these methods.    SeUVblendshapes plugin is essential to my Maya animation pipeline:  https://scottenglert.com/seuvblendshape/

Kinetic Motive is my pal's facial animation plugin.  Here is his webstore: https://gumroad.com/kineticmotive. ;   He has a website too, but I can't find it at the moment.
And these are some renders of Daz figures using this method in Maya: 

 

https://www.deviantart.com/bad-uncle for more images (figures are unclothed)

I used method #2 in the above examples.  If you have any questions about how to employ some of these techniques, feel free to hit me up on Skype.

Hey drzap,

 

I have seen Kinetic Motive's video on youtube regarding subdivision morphs a long time ago and could never figure out which product is the right product on his gum road.

 

This is the video I'm thinking of:

 

 

I usually use the displacement workflow but I would prefer to start from a subdiv1 mesh in some cases. You also mentioned another workflow that I recently experimented with:

 

1. Import G8 figure

 

2. Subdivide mesh

 

3. Import higher res mesh as obj

 

4. Setup blendshape.

 

This works technically but I noticed the blendshape is losing a lot of details. Given that Maya blendshape are not made to transfer details at higher mesh density levels I guess this is not an error of Maya but simply blendshapes are not made for this.

 

I have purchased the seUVBlendshape plugin but haven't played with it much yet. From the demo video it seems this is more meant to transfer deformations from a low poly mesh to a high poly mesh and not transfer details between 2 high poly meshes.

 

Ever since I saw Kinetic Motive's demo on their product I wanted to test this but what is the product and where can I buy it? Is this integrated into one if the face rig products?

I do have the Kinetic Motive plugin, and I think it works great!  The mesh ends up being really dense and is basically un-poseable once it has gone through the subdivisions, however.  The facial rig and everything works exactly as intended and described, but I think displacement maps are the way to go when dealing with detail because even with my beefy system it really can't handle the high resolution mesh when it comes to animating.

Yes I wouldn't go beyond subdiv1 for a rigged mesh, but going from a smoothed mesh at base resolution wont get you far with displacement maps, because a lot of details wont actually show up. It's fairly ok if you don't do close ups, so if I want to do a cloth simulation or focus on hair movement where the face of the character isn't the focus the base mesh is ok. But for close-ups ... yeah having the face in subdiv1 and start from there helps tremendously.

Currently I'm going with the seUVblendshape workflow and it works to be honest. True the scene is a bit heavier because I have 2 meshes in the scene - one rigged mesh as a driver and the actual mesh which is rendered but it's still tolerable.

DZ_jared said:

After a lot of hard work, long nights, and even longer days by our development team we are happy to announce that Carrara 8.5 is available for purchase in the DAZ 3D store. We would like to thank all of our loyal Carrara customers for their patience and support with this project.

Carrara 8.5 Pro is priced at $285.00 for a limited time. Carrara 8.5 Standard is priced at $149.95.

Current owners of Carrara will receive a 50% discount on either product for a limited time. Platinum Club members get an additional 40% off, which means it's never been a better time to join the Platinum Club.

Carrara 8.5 Pro
Carrara 8.5 Standard

Included in Carrara 8.5 Pro are the Michael 5 and Victoria 5 Pro Bundles and Carrara Shaders - over $250 worth of Genesis content.
Carrara 8.5 standard ships with the Michael 5 and Victoria 5 Starter Bundles and Carrara Shaders - over $140 worth of Genesis content.

Here's a quick look at some of the new features:

Native DSON Importer means seamless integration of:
- TriAx™ Weight Mapped figures (Genesis, G2F, G2M)
- General Weight Mapped figures
- Legacy Parametric Figures (4th Generation and earlier)
- DSON presets
- Scenes
- Scene Subsets
- Wearable(s) Preset
- Character Preset
- Properties Preset
- Shaping Preset
- Pose Preset
- Hierarchical Material(s) Preset
- Material(s) Preset
- Shader Preset (preset must be for a Carrara shader)
- Camera(s) Preset
- Light(s) Preset
- Support for multiple UV sets (through Hierarchical Material(s) Presets and Material(s) Presets)

Native AutoFit functionality means:
- Conversion of legacy parametric clothing to TriAx™ weigh mapped figures
- Automatic Morph Projection quickly gives you the fit you need for your figure's shape.
- Automatic Weight Map Projection allows AutoFit clothing to bend and pose smoothly with the figure.
- Morphs built into clothing are carried through the AutoFit process.

Improved Sequencer, Keyframing and Animation Tools
- New keyboard shortcuts to:
- Play/Stop animation
- Advance the frame
- Preview a frame
- Key Frame Filters
- Sample – Creates a key at every frame of the animation.
- Smooth – Smooth out wild keys to get an even looking animation
- Reduce – Programatically determine which keys are unecessary and eliminate them.
- Graph Editor Box allows for fine tuning of animations
- Easily adjust timing
- Simple yet powerful manipulation of amplitude
- Scale, and translate key frames along the Graph Editor.
- Marquee selection of key frames for Graph Editor.

Smart Content and CMS Integration
- Carrara can now access the CMS database; PostgreSQL or Valentina.
- New smart content pane allows users to browse smart content by:
- File
- Category
- Product
- File view provides selection based filtering so that the user only sees items compatible with the current instance tray selection.
- Double click and drag and drop loading are both supported in Smart Content Tab.

Parameters Actions
- Zero, Memorize and Restore:
- Figure
- Figure Shape
- Figure Pose
- Selection
- Selection Shape
- Selection Pose
- Selection Tree
- Selection Tree Pose
- Selection Tree Shape
- Provides users with powerful tools to reset a pose, shape or both.
- Memorize and Restore allow user to take a snap shot of the model's current pose and/or shape and restore all or part of it.

Improved Fit to Functionality
- Automatic projection and following of morphs for TriAx™ Figures
- No more relying on built in clothing morphs to fit clothing over a figure. Carrara automatically projects any morphs for a TriAx™ figure onto items conformed to the figure.

Improved Viewport Avatars
- Spotlight, Sunlight, Moonlight, Tube Lights and Shape lights have all received a makeover and can easily be identified in the viewport.

yay

8 year anniversary since the last Carrara update. .. seems like only yesterday  

Couple of fixes to try: 
Make sure your character is at world center (0,0,0)
Change Instance Optimization to either Memory or Speed - which one works better seems to be random.
There is a morph for the eye moisture that can also fix it available at ShareCG  (I have this downloaded but I have yet to try it)
 

If you want more info you can read this thread. 

Macislav said:

You need to build a modified version of UE from source code for the "glitch" to go away. (key word: Dual Quaternion Skinning support)

Discussion here: https://www.daz3d.com/forums/discussion/134926/adding-dual-quaternion-support-to-unrealengine4-images-inside/p9

Modified source (most recent one): https://github.com/AlienRenders/UnrealEngine/tree/4.26-mod

For the modified source to be visible you are supposed to link your epic account with your github account:

https://www.epicgames.com/help/en-US/epic-accounts-c74/connect-accounts-c110/how-do-i-link-my-unreal-engine-account-with-my-github-account-a3618

thanks, i do know about the dual quartenion stuff, but i was hopping someone could come with a "alternative way to fix like a sort of "jcm" or corrective morph or anything like that to be usable to fix this glitch or at last make it less bug, my issue is which since the creator don't have time to keep updating the stuff it could ending being troublesome specially if it don't work with "updated versions of the engine like only work on the 4.26 and not 4.26.2 and stuffs like that, if it was actually a full valid plugging for unreal would be better but since you have to build the unreal from the ground using it make things even more troublesome, i means i want to avoid "too much work time wasting", i'm not saying which the mod is not good just is a lot of "extra work" and time which i would love to avoid to loose, then i really want something different another work around would be good. 

Note: If you need a Drago with breast, you can apply a female morph to G8M

Thunderwall said:

It's not quite what the OP is talking about, but I'd like to use dragon grafts on the female figure, to make something like this.

That would be wonderful.  I think part of the reason the female therianthrope characters tend not to sell well is b/c they "monsterfy" the wrong parts, or in such a way that they no longer retain human female characteristics (which is what most people want in a female character).  I have characters who can morph either entirely into a dragon or partially, so a reasonable adaptation would be mostly human, but with things like geograft wings, tails, and claws (hands and/or feet).  Leave the face mostly alone, or only have minor additions like scales away from the main parts of the face, or horns.

No need to go above 3 unless you have an HD morph that requires higher, even then I would never go above 4.

I used free face transfer with this gen 8 build for my own face, you have upto 3 uses before you need to activate the unlimited serial number.

DAZ_sam said:

adploshko said:

Hi, 
I recently upgrade to the 1.3 version and it completely stops exporting morphs for Gensesis 8. When I import into C4D R23, the pose morph tag and all the morph sliders are there, but they don't do anything. The mesh just remains static. This is the last time I ever update DAZ or any corresponding plugins like this one as each update ruins my projects more and more and I end up loseing months of work because of the slew of bugs each update brings. I've had enough. Can someone please post a link to the 1.0 version of the C4D bridge? 
Thanks

I can definitely understand your reasons until the plugin is in a state that you don't run into these problems here is a solution for now.
1.1 Packaged for support for R23
https://github.com/daz3d/DazToC4D/releases/tag/1.1 ;
and original release is here.
https://github.com/daz3d/DazToC4D/tree/5c74e073f2b39086ee0e6d0729f92e17a05b61b0

First link is broken, seems an extra  character got added onto it

https://github.com/daz3d/DazToC4D/releases/tag/1.1

I'm experiencing the same issue with 4.15.  Not really sure what to do. I've just simply dialed the face morph for CO Ichigo and it's deformed. 

Below is an example transfer to Unity with the bridge one of Stonemason sets: https://www.daz3d.com/urban-future-6

together with Daisy HD: https://www.daz3d.com/daisy-hd-for-genesis-81-female

and its render in Unity:

Do you need to activate some sort of serial key for that catalyzer to work, some products like face transfer unlimited or other plugins like some world builders require serial activation for it to work fully,.

Decals usually best done in something like photoshop or substance painter, you can apply shaders and rescale them in DAZ3D but to do good texturing you'll probably need something better at retexturing DDS files and the like. DAZ3D lacks tools like clone brush & other texture tools for images.

The way i would tackle the issue would be use Photoshop with a DDS plugin view the DDS file transfer the decal you want by using clone brush from image you want then you set the bump maps for that by saving the file thats been edited in the DDS format then doing any final displacement detail of the decal if needed using something like mesh grabbber if your good at it in DAZ3D, so say you want to have a patch on some clothing you use mesh grabber to mould the mesh according to the shape of your decal kind of like a sculpter.

Or you could make a layered texture in photoshop place it over the DDS file to transfer the decal image then use displacement pattern shaders in DAZ3D to fit or scale to your needs. 

In daz you could also tie the decal to a shaped mesh apply it like a prop to an outfit part then parent or graft the prop the the part of the body or outfit.

Coral's skin does not seem to be up to the level of specular three-dimensionality established by the other 8.1 females. It looks flat and dry, like Aubrey's and Robyn's. I like her morph though.

I know that personally, I tend to buy just about any female anthro type morph and character I can find. I would love to see female counterparts to male anthros. It can be done using the variety of trans morphs though, it does make transitioning for a sequence a bit more of a pain.

thenoobducky said:

mindsong said:

Richard Haseltine said:

mindsong said:

Richard Haseltine said:

...

Well, if you actually know how to meet the design objectives without the lag on large data sets then you should be able to describe the process without needing acess to the code; if you don't have an actual solution then it is quite possible that you would do no better than the daz developers if you did have access to the code.

wow. just ... wow.

--ms

Please do note that that was in response to ana ssertion that the other poster would be able to write a better system - I don't hold with the "if you can't do better you can't criticise" school, and have previously been careful to say that making a case that the current system is sub-par could be made by pointing to another system that did a similar job with better scalability.

While it appears that the problem being discussed is sluggish figure loading, based on simple to describe, predict, and repeat DS behaviors...

I propose that a parallel issue being discussed here is the audacity of savvy programmer/users that would, without seeing the code (!), speculate as to why this is occurring, and even more irritating, folks that would propose reasons as to why it's still happening after all of these years and suggest (!) possible solutions.

How dare they!

I think the parallel issue being discussed here is more of equating there is a problem to be addressed with program design is bad while offering no plausible alternative solution. The current program has performance issue is not mutually exclusive to the current design is the best that can be done given the requirements. I think every here agrees that Daz have performance issue that the dev should address. 

Saying there is an issue that the dev needs to address is fine by me. Saying the current design is bad because this other solution is much better is fine by me. What I disagree with is saying there is a problem therefore the current design is bad without offering any alternative.

 

This is hardly a new behavior in here, and in-fact it seems to be an open wound that keeps getting (usually inadverdently) poked by rational and frustrated programmer/users who seem to know this business pretty well.

Amidst this bantor, it appears that both sides are arguing about a black box that neither actually knows about with any real certainty, which presents as the recurring position of the frustrated defense: "you're speculating, you can't know that" - and this is true - we certainly can't know what's actually going on without seeing the code.

Yet, does not the DS black box speak to us who choose to listen, and us who know what to listen for?

*Regardless* the details of the code, the behavior in question is consistent and predictable, so perhaps it isn't so presumptuous for some of use who have struggled with this very problem to speculate about what might be going on in that DS black-box. I don't get why that's so taboo in here. It's what we do - how we're wired!

Perhaps there's some code in there that was written a long time ago (DS1.0), by some long-gone coder, at a time when 200meg drive, 256megs of memory and a 1024x768 moniter was hi-end (640K anyone?) and a V4 figure had 150 morphs on a good day. Likely that old code that serves as the foundation to the entire DS code framework. Code that, to fix, would effectively require a full rewrite of the DS code-base and all of the dependent supporting libraries. Darn that sounds like a lot of work, and *very* expensive. I'd probably consider a full re-write (DS5), rather than an expensive repair effort on an EOLife product version (DS4.x).

(yeah, I know, I can't know that, silly me...)

But, i certainly wouldn't castigate those who *would* speculate about such application behaviors, when in general, they're probably more right than wrong - based on both the available evidence and their own experience with one of the most classic of computer-science (and project budget) problems.

I would counter to someone arguing the contrary, yet *also* not having access to the code, that to simply assume that such speculative analysis is without merit is equally speculative, and comes across as, well... comes across as speculative (lets see if i can keep this post from being filtered).

I think the issue here is too much speculating without basing on the available evidence and making grand statements instead of having discussions on the technical details which I think can be much more calmly discussed. Talking on the high level just naturally leads to personal attack instead of discussing the details where technical merit can actually be assessed.

No, the better part of this discussion isn't about big-0 code design algorithms and possible data optimisation opportunities, it's about knowing the unknowable - based on observed and predictable DS behavior, and it's about business decisions in tension with available resources, and technological trade-offs.

This isn't personal, at least not until a viable speculative assertion is met with a 'you simply can't know that' and summarily dismissed without counter-substantiation - even if also speculative.

I have high confidence that if allowed, those who critique and speculate about the situation would be able to *quickly* identify and assess the problem code, and also (but less quickly?) be able to determine the implications and costs of fixing that code, along with the cascading side-effects of those changes, and probably come to a conclusion that would result in the very situation we're seeing now from the DAZ development team.

Just a guess. And I would fall out of my chair if a DAZ-dev chimed in and said something like "the original code is too expensive to fix - wait 'til you see the DS5 re-write!", or "that code could be fixed, but it works well-enough for now, relative to the other tasks we think are more pressing or beneficial to the community/company".

"that code could be fixed, but it works well-enough for now, relative to the other tasks we think are more pressing or beneficial to the community/company" is there I would bet my monkey on. Many people would no doubt be disappointed by it, but DS5 should be lets port the existing code to Qt5 as fast as possible so people can use it, instead of let's rewrite everything.

But, I would also assert that if the code were open-source (it'd be nice, but I have no expectation of such, nor resentment for the lack of), the active and savvy critics like myself and TMitP would walk their talk, and (assuming the code were salvagable) do the required work to upgrade the code and its dependencies, and do it well - regardless how silly that might seem. To assume otherwise, with the available evidence (see TMitP's Sagan and related projects - both the existence of, and the and quality of the code) is irrational and insulting. At least to my eye.

Per the original issue, I don't see the business case for retro-fitting the DS 4.x figure management core with major and likely disruptive fixes when DS 5.x is on the horizon, unless the code can be fixed one-time to work in both. I would be leaving the 4.x legacy app as stable as I could possibly make it pre-update migration.

Given the wide popularity of Gen 8 contents, any fix really needs to work with Gen 8 and not break backward compatibility with DS4. 

That said, we'll certainly be sensitized to this current (big-O) behavior when DS 5.x comes out, and I'm sure we'll form lotsa opinions about the quality of the DS programmers and newly updated system code's (black box) design and architecture when DS 5.x is released.

No pressure, guys.

(And personally, I have nothing but respect for TMitP's walk of his talk, and appreciate that Richard is one of the most consistent, generous, and reliable providers of help and solutions for the wayward, confused, curious, and outright lost DS users that come to these forums for advice and assistance.)

--ms

Let us focus more on what causes the problem, and how to fix it instead of making grand statements that don't benefit anyone.

good feedback/comments, but let me offer that, to anyone in the business of algorithms and coding (as you are), the problems we see in DS may be self-evident (big-O, etc.) enough that saying anything with any more detail is fruitless without actually seeing code. This lack of detail is likely not a function of over-simplifying pie-in-the-sky critique as much as "that problem and its likely cause is clear, why won't the developers address it already?"

You've clearly done some great/real code (thanks), so I imagine you could see this as a possible reason for the high-level tone you describe rather than oversimplifying criticism from the peanut gallery. I don't see it as being that way. In this thread, I know that TMitP does similar and good work, so going into detail at any higher-a-level actually doesn't make much sense without seeing the code. His language and level of critique is appropriate for this context as I see it. I believe emails between him and DAZ_Rawb would have a decidely different level-of-detail.

which comes to our point of agreement, that it's probably not the capacity of the devs, but rather the available resources as allocated. Many of these problems are probably on their lists, but unlikely to ever get done due to the more pressing tasks of the current industry, hardware, and market-place, etc., as is usually determined by 'market research' - which is understandable but sad, and possibly a miscalculation in some cases.

and BTW, my appreciation for the practical situation doesn't at all imply that I would make the same decisions! In fact I sometimes think this place is run by lunatics (been watching to 10-some years now), yet it seems to work for them - who am i to argue with their staying power?

That said, I tend to respect the 'current user' more than the 'future user'. Probably not good business. I don't see this as DAZ's primary paradigm - but - their immediate numbers at any given moment may confirm the 'correctness' of their chosen ethic - whatever it may be (a black box as well). But over the long-term, I believe they pay a heavy price for what I see them doing. (The Debian linux distro is a great example of a solid product that follows the 'slow-stable-steady' philosophy that I like, and is both popular and is forked more than any other distro in its domain.).

I think DAZ mgt and the devs are making a large miscalculation in this specific domain, based on my history of updates, and what I see going on in the DS5 conversations - which has little to do with algorithms and design, and everything to do with that tension between moving into the future at the expense of an installed base. DS5 will certainly work, but will it work with my habits?, content?, and mental paradigm?, or ... will it be re-framed for a new beginner audience, or higher-margin users, or VR or gaming folks, graphic/design, animation?, or ?

And yes, Richard, this *is* both speculation *and* judgement based on that speculation, and anyone with three neurons can see that. What's the big deal? Do you agree? Do you disagree? Come speculate with me/us, but be willing to call it that and it'll be interesting. I'd be very interested (another thread) to hear your honest (non-DAZ-moderator) thoughts on the past and future of DAZ and DS, and how you might drive the operation if you had the reigns. That'd be fascinating - especially over a beer, heh. I'm certain I'd be both surprised and/or confirmed by your insights. I would also think DAZ would be very interested in your thoughts, considering the front-line trenches you know so well. My guess is they wouldn't weigh your opinions as highly as I would. per what I mentioned above.

The Ds/DAZ future is certainly not an easy problem with an obvious answer but the underlying trend that I sense concerns me in my workflow. But it also confirms the wisdom of my current workflow adjustments. "What DAZ mgt should do" is another thread (it'd be lively, I'm sure).

I am hoping for some final animation refinements and fixes in the 'last' of the DS 4.x family, but with my sense of the past as my own guide to the future, I'm resigned to be content with DS 4.11 and my alternate tool-sets - and long morph-lagging figure loads, unless I repackage my oft-used characters and figures with just their essential elements - which is my current solution to the OT of this thread.

best,

--ms

I was wondering if anyone would consider doind a split tail or fork tail geograft for Daz Dragon 3. Something with 2 long tendrils would be nice like the enclosed pic by kaiserflames. Would love this for my dragons. I'd  even pay for the geograft and a morph of this fine dragon!