Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I think it would occur in any application, Daz Studio included. It's just that the artist who made the model is a Daz Studio artist ensures that the base rez model, once subdivided, looks more "correct" in Daz Studio; If you think the base rez looks correct, then the subdivided model will look shrunk around conves curves. If you think the subdivided model looks correct, then the base rez model will looks bloated around the same regions. The model can't be correct for both because meshes and subd cages are just two different things but Daz only provides one for both purposes. I searched through the SDK for several days for this thing called a "subd cage" until I came to the conclusion that there wasn't one.
Thanks for the explanation.
Here's a better comparison of the application of subdivision between DS and Blender than I did earlier, using an 8-sided cylinder instead of a sphere.
The turquoise blue object was exported from DS with subdivision level 1. The purple one was created in Blender and has a subdivision surface modifier at level 1.
Bit of an extreme example - very low poly - and the sharp corners show the most difference, so only of limited relevance on a Daz human figure, but interesting nonetheless.
What I don't like (at all) is the Proportional Edit. (i.e. soft select) What a disappointment from Hex (or from Maya, I hear) that is! Only being able to adjust the size during edit, and not actually higlighting the affected vertices, is really a pain. The "circle" it shows looked like it was going to affect 1/2 the model, and it was only affecting a small area...I guess based on how I had the model rotated. Is there a way to higlight the affected vertices that I am missing?
I don't believe there is. Of all the tutorials I've ever watched where they used it, not once did I see any highlighted verts. Only the big circle :(
Laurie
Proportional edit was one of the concepts that stopped me in my tracks doing tutorials a while back. I figured if I couldn't think of a use case where I'd need to use it then I'd never model anything of any account anyway.
OK, so I am stuck. I made a shirt in blender, exported and imported into DS, but the outside of the shirt is black, and the inside of the shirt accept the iRAY textures.
Can someone point me in the right direction on what I am doing wrong?
I would assume that your face normals are inside out (although, the outcome is a little odd, as my experience is that DS doesn't much differentiate between front and back faces). Try either Recalculate Normals (normally shortcutted to Ctrl-N), or Flip Normals (via the Space menu)
Your normals might be reversed. In blender you can flip the direction of the normals to make sure they're facing out.
Sounds like flipped normals to me as well
I was thinking that, but it really looks like they are all facing out...unless these blue hairs pointing out, means they are facing in
OK, I recaculated normals inside and then outside again, and re-exported and it worked. Something didn't "take" the first time I guess. Thanks!
I always select the area I want to for instance, scale, and start with the fallofff tight around the area, start to scale it and then use my scroll wheel to expand to farll off. This allows me to better control the effect. Also, try the different types of falloff to finetune how the falloff affects the result.
Control-N to reverse the normals
It's not the normals, per se, but the vertex order. I think one app wants clockwise, and the other wants counter clockwise. So when each calculates a normal vector by the vector cross product using two edges, the calculated vector is of the same magnitude but opposite orientation of what it should be because in Linear Algebra U x V = - ( V x U ). It's the same thing with Alembic; it wants the opposite of what Wavefront OBJs want.
Why would this issue only be affecting one person then? I have sent literally hundreds of things I created in Blender to DAZ Studio and they all import fine.
I think that when 3DOutlaw made the shirt they extruded something somewhere without paying attention to which way the normals were pointing and then just continued the process without noticing until they got to DS.
Who knows? It was a possibility and just to share my experience with the different ways formats treat normals, in a searchable forum.
Sometimes even that doesn't work, and I have to Reset Vectors, under the same option.
Yeah, I second Mythic3D's question (with my over two decades experience) -- I have been reading this thread everyday, and finally I have to step in to say WTF are you talking about, donalddade?
Are you trying to reference Vertex Normals (otherwise known as shading normals)?
Because, Facet Normals are cut-n-dry -- They are either forward/backward - front/back -- There is no magic to them, and yes, winding (vertex) order does constitute which way a facet normal is facing.
There has never been any need other than to reverse (flip) normals under any context for facet normals if your normal is invisible (inside out/facing backwards/inside mesh).
3dOutlaw : I know you are not a noob at this, but this (and Blender) are possibly new territories for you. What software did you create your great Anime Head kit in?
First, and foremost, I try to show and reiterate this everytime I show something I have worked on -- Turn on Backface Culling in Blender (under Shading Parameters) while you create your model -- It will defaultly show if you have any inverted normals in viewport, selected, or not - An added benefit, if your mesh is selected, it will show all backfacing normals as a highlighted wire-frame (regardless if show wires is selected for mesh, or not).
DAZ Studio, unlike Poser (or Blender's ability to utilize), does not have backface culling, and that has always been a problem for people creating models for it when it comes to polygon normals facing outside correctly. Now, you know, but this is more for any newbies trying their hand at this who are reading...
Regarding the image you showed of your shirt with the facet normal projection lines -- For Daz sakes, man... If you want to use those as your normals checker - turn them down (0.01 - 0.1 should be good) -- That is a cluster**** to look at and try to discern what is what. Also, make sure see-through culling is not turned on (mesh should be solid - can't see wires through your mesh). It is great for modeling selections when needed, but not great for viewing correct normals.
Looking at that image of the normals and they way they are pointing, I'd be turning them down to a few milimetres to be sure they were pointing the correct way. I've had it look good until then before realising they were poking through from another face and giving the illusion of being correct.
I've also accidentally duplicated a mesh and had it facing the correct way, with the original facing the other - been a good long while since that happened though. :)
You can also in Blender 2.8 (and maybe also in previous versions?) select to view 'Face oreintation' with blue being front side and red being back side. Than will affect everything in viewport.
felis : That is new to the 2.8x series - I mentioned it in another thread recently...
So, now we have three ways to check for correct normals, and I do appreciate that they added that new way - I'm sure some people will make it their default checker.
Corrections for my previous post -- The facet normal projection lines default to 0.10, so 0.01 - 0.05 will yield better results. And, the viewport occlusion turned off doesn't matter if viewing from backside faces - only occludes front faces (still a good idea to have off to help with viewing).
Also, I was mistaken to believe B2.80 carried on with previous builds viewport usage (one more dissapointing things with the new series). The 2.79 default viewport with backface culling on and a selected object showing lit backface wires does not carry on into 2.80 'Workbench' (non-render) viewport.
Blender 2.80 default viewport (no face culling - same as DAZ Studio) :
Blender 2.80 culling on (Workbench [non-render basic OpenGL]) :
Blender 2.80 - turn on backface culling :
Blender 2.80 backface culling selected (needs 'Wireframe' selected for backface lit wires) :
Blender 2.79 backface culling (not selected/selected) :
What I am talking about is that if you reckon the vertices from 0 to 3, like Daz, Blender, and Alembic, the normals will point one way. If you reckon them from 3 - 0, like Wavefront OBJs do, the normals will point in the opposite direction. This is important because OBJs don't represent facet normals, and I was hypothesizing that Blender was calculating them based on some function of the vertex normals, which OBJs do represent.
What turns out to actually have been the problem is always among all the things that COULD have been happening, so it seemed helpful to point out some wierdness that I've experienced and eventually figured out, whether it was the problerm or not. Sorry if that upset you enough to drop an F bomb. Maybe you should consider going back to lurking if you can't observe the same basic etiquette that every one else kind of grasps implicitly, i.e don't curse at strangers. Who knew that vectors stirred such passion.
I must warn and remind everyone to remember to address the topic and not each other.
Sorry, Cris, I forgot about sensibilites on the net - guess I upset him...
Please, don't hold it against him, his response was fair - that was my bad. I should have kept that thought only a thought...
I will go back to my stoic, anaylitcal ways - only the facts - so much for trying to introduce some whimsical color into my posts, but I digest...
donalddade :
My apologies...
And, thank you, for clarifying you were talking about Vertex (Shading) Normals, as I suspected. I am currently working with them for OBJ imports into a fantastic Unity 3D game, and still trying to work out best practices without being privy to the underlining import, or shader coding.
Looks like Blender 2.80 adopted some of the great Vertex Normals add-ons, and has produced quite a nice custom normals panel now.
Just curious if you are creating custom normals for a game engine, something like Second-Life, or for meshes you are using in DAZ Studio.
If it is DS, can you provide any screenshots showing the differences, and to which renderer are you utilizing them for?
@DaremoK3 - It's all good. We're on an imperfect medium.
I'm subjecting myself to all this because I have not found a fool-proof way to get characters out of Daz and in to Blender. Every method as a gotcha that makes it less than optimal for a certain reason. I've found that the Alembic file format is closest to "it just works, so now you can think about creative things instead of technical issues", with the only problem that the offical Daz exporter has a few beyond-annoying quirks, and it produces huge files. The latter can be fixed by just buying a bigger hard drive, and the former by just writing an exporter that works.
I did that latter, and that's why I know more about normals in Daz/Wavefront/Alembic than I actually cared to. What was happening is that Cycles apparently uses the normals from the OBJ file to render, but the sim engine calculated them on the fly using the vertices from Alembic's cache and, you guessed it, they reckon in exactly the opposite ways. My renders came out perfect, so I can't "show" the differences, but all the cloth sim would quickly bunch up inside of the character's limbs and disappear.
That was such an insidious bug/feature that I thought I would mention it, even though Mystic3D immediately pointed out that it could not be the issue in OP's case.
I started using Blender while the transition to 2.80 had already begun, so unlike you I don't know what the normal tools were like before :) I just know that they're pretty nice now and I've never come across anything that I couldn't fix.
I have zero experience with Unity; how has your experience with it been? I stopped by the Unity booth at SIGGRAPH, no, pavillion really, and my impression was that everything here may be NVidia this and Unreal that, but Unity ain't nothin' to sneeze at, either... they had some really nice tools from the looks of it.
So I tried using the DazToBlender8 script, and it gets stuck in a loop once it hits head.(insert expression here) and keeps going like that forever.
i tried uninstalling the expressions in question, but that didn't work.
Heeeeeeeelp me please D;
That is a paid addon for Blender, isn't it? So you should get the best support for it from the author. They will probably appreciate the chance to improve their product, since that sounds like a bug.
Yeah, I guess I should do that. Thing is, English is not their first language, so I'd probably have to have a friend translate it to Japanese for me (I don't trust Google translate, tbh), because that'd be the only way I could get a good answer. I was just hoping maybe someone else /w the plugin who's experienced the same issues could help. :T
Somehow, it didn't do it for Genesis 8 Male, though. It looked like it was going to, but it didn't. Now getting G8M to actually import into Blender, though... *sigh*