Genesis 3 Ear Issue (17k Base) Needs Help and Fixing

We are using the Genesis 3 Male and Female for game use. I personally switched over from Genesis 1 because I really like the Genesis 3 models for game use. The figures looks great in game and we only are setting up 1 LOD with an in game utility (we are using Unity 5.4). The figures are very well optimized for real time animations and bending.

While looking closer at our character tools we noticed that the ears were blocky. I did some searching and testing and found that indeed the Base Resolution Level of the Genesis 3 models are this way. So I made and OBJ export and did some mesh smoothing in Blender to see if I can fix this. It worked but also smoothed out the rest of the body. This worked almost exactly as applying the Smoothing Modifier on the body mesh right within DAZ. So the smoothing was Apples to Apples. Same effect.

I then did a Decimator Test on the Base Resolution Level by setting the Ear Weight to 100 (No Decimation). Decimator worked just like it is supposed to and did not do any poly reduction on the ears.

So this leads me to believe that when the Base Resolution Level model was made that all the weights were set to 1 which universally poly reduced the entire model. I may be wrong of course but this is what the 17k version Base Model is pointing to in issue. This Base Resolution Level of the model(s) needs to be remade. I can do it but I cannot find anywhere how to remove this Base. Also tied to this is when I set High Resolution in the Parameters Tab then prepare to Decimate, Decimator is automatically selecting the Base Resolution Level. So I cannot do a decimation on the High Resolution version.

For our character budget anywhere between 15-32k is perfectly acceptable. The 17k G3 is perfect....except the ears.

Screen pics attached to show what is happening.

Help would be very much appreciated.

Cheers, Olander

 

G3F Head 68k.png
1033 x 910 - 320K
G3F Ear Issue Base 17k.png
1433 x 912 - 408K
G3F Ear Issue Setting Weights in Decimator A.png
388 x 535 - 15K
G3F Ear Issue Setting Weights in Decimator B.png
1920 x 1040 - 364K

Comments

  • Richard HaseltineRichard Haseltine Posts: 101,011

    The base mesh is a SubD cage, not the final model. You can of course use it as a model for your game, but in that case you need to make any adjustments to the mesh - or soemone else does and share them as a morph asset which could then be used by all game makers.

  • dandersonrudandersonru Posts: 19

    Thank you for the answer but it was not quite what was asked. Sorry. We are successfully using the 17k Base 'version' right now with all the morphs in sliders. All of that works. There is no issue there. In fact the only issue with Genesis 3 are the ears. There needs to be a solution to this. I do not know how the Genesis 3 models are created but are simply using what DAZ has created to make a fabulous character creator software as our workflow.

    DAZ G3 Option 1 : Use Decimator on the 68k Hi-Rez to generate a New Genesis 3 Resolution Level that is selectable from the drop down. I already have proper weight settings from my experience in making Genesis 1 32k versions. Genesis 1 does not have the issue I am seeing in Genesis 3. The issue here is DAZ Studio with the Decimator tool will not allow Decimation on the Hi-Rez model. It Auto Selects the Base Resolution Level to begin Decimating from. The ears on Genesis 3 are already not suitable at this stage.

    DAZ G3 Option 2 : Somehow export the 68k G3 models then bring them back into DAZ as simply the High Resolution Level and transfer all the rigging and morphs into this cleaned out version. Now a new Base Resolution Level could be made with proper Decimator weight settings. I have no idea how to do this properly.

     

    Everything with Genesis 3 works perfectly. In any case this is our characters that we shall be using. Bad ears or not. haha!! If it can be done we would really like to be able to export Genesis 3 Male and Female driectly from DAZ Studio as we are doing now and have the ears be 'Not So Bad/Flat/Rough'....whatever you want to call it. The rest of the model is absolutely perfect. I have been a DAZ customer for a long time now and will be for a long time to come. So not trying to bash G3 at all. Just try ing to sort out why the ears are so poor.

    Assitance would be appreciated.

    Cheers

  • JD_MortalJD_Mortal Posts: 760
    edited May 2016

    The ears sort-of depend on "bumps" and "normals" and "sub-d". (Agreed, they don't have enough forced detail in that area.)

    The only way to counter this, is to add the required detail with editing.

    Bump-maps only imply curves, while normal-maps actually alter the sub-division surface and also imply additional curves, if there is sub-d to alter. (Thus, gaining back the detail that is not actually there.) I believe that is how it was explained, for the way the two are used. (Bump being a totally fake shader, with normal containing sub-surface deform information and also that fake shade data, where the surface can not actually be altered more than the sub-d polygons. Thus, more sub-d equals more curvature and bump details, in physical reality, as opposed to the fake-bumps. {fake = just shaded, not actually relocated, as one would naturally assume. Bump on a sphere will still look like a sphere at the edges. Normals on a sphere, will actually deform the edges of the sphere to a physical new shape.})

    I would suggest using the high-detail sub-d, then decimator, if it works that way. Otherwise you are decimating something that is already decimated. As opposed to decimating the "desired curves", down to softer curves. You are turning sharp-edges into lower-poly sharper edges.

    Image below is a depiction of "Bump", vs "Normals", which normals use displacement to alter the form, not just fake the look of bumps. However, without a "micro surface" (sub-d), to alter... both will look like the first image, not the latter. (Bump-maps could look like the later, but for compatibility, I believe they chose not to use displacement on the "bumps".)

    Bump_vs_displacement.JPG
    651 x 345 - 26K
    Post edited by JD_Mortal on
  • nicsttnicstt Posts: 11,715

    Displacement and Normals were different I thought; displacement is expensive at render time, whereas normals are much less so, again that is my understand.

  • Richard HaseltineRichard Haseltine Posts: 101,011

    Thank you for the answer but it was not quite what was asked. Sorry. We are successfully using the 17k Base 'version' right now with all the morphs in sliders. All of that works. There is no issue there. In fact the only issue with Genesis 3 are the ears. There needs to be a solution to this. I do not know how the Genesis 3 models are created but are simply using what DAZ has created to make a fabulous character creator software as our workflow.

    DAZ G3 Option 1 : Use Decimator on the 68k Hi-Rez to generate a New Genesis 3 Resolution Level that is selectable from the drop down. I already have proper weight settings from my experience in making Genesis 1 32k versions. Genesis 1 does not have the issue I am seeing in Genesis 3. The issue here is DAZ Studio with the Decimator tool will not allow Decimation on the Hi-Rez model. It Auto Selects the Base Resolution Level to begin Decimating from. The ears on Genesis 3 are already not suitable at this stage.

    DAZ G3 Option 2 : Somehow export the 68k G3 models then bring them back into DAZ as simply the High Resolution Level and transfer all the rigging and morphs into this cleaned out version. Now a new Base Resolution Level could be made with proper Decimator weight settings. I have no idea how to do this properly.

     

    Everything with Genesis 3 works perfectly. In any case this is our characters that we shall be using. Bad ears or not. haha!! If it can be done we would really like to be able to export Genesis 3 Male and Female driectly from DAZ Studio as we are doing now and have the ears be 'Not So Bad/Flat/Rough'....whatever you want to call it. The rest of the model is absolutely perfect. I have been a DAZ customer for a long time now and will be for a long time to come. So not trying to bash G3 at all. Just try ing to sort out why the ears are so poor.

    Assitance would be appreciated.

    Cheers

    The 17K mesh is the base mesh, the HD version is a dynamically sub-divided model from the posed 17K cage. The ears are shaped the way they are so that they look correct with SubD applied. You cannot select a 64K mesh to decimate as, without exporting the reinporting, there is no 64K mesh - and if you do export, import and rig then the result will not be the same as the standard Genesis 3 as the SubD is frozen from a particular pose (and shape). If you want to work directly with a version of the base mesh then create a new morph for the ears that makes them look the way you want, set the mesh Resolution to base, and work from there.

  • dandersonrudandersonru Posts: 19

    @JD_Mortal   Displacement mapping is very expensive in real time rendering, as in a game engine. This is not really a solution for the tops of the ears in any case since the displacement map would need to be applied to the entire body texture. Thank you for the information though.

    Thank you for the better explanation Mr. Haseltine. Appreciated. I now understand more about the High Resolution Level.

    I did a test on the ears in MayaLT and was able to correct them enough to make at least some difference. This will have to do. Moving the vertices and squishing the ear is really tough with the texture. Too much and the UVs really show the fix. So only a slight movement down and in was possible with very careful shaping. Very touchy but does work in the end. This does add a level of error though. Since the mesh and skeleton are being processed and change within another software which makes transitioning blendshapes (morphs) more troublesome. We may end up simply leaving the ears as is since the workflow directly from DAZ Studio with Genesis 1/2/3 is so fluid for us now.

    Answers have been most appreciative. Thank You.

    Cheers

Sign In or Register to comment.