Digital Art Zone

 
     
Normals Flipped On Save to Library
Posted: 20 November 2012 03:45 PM   [ Ignore ]
Addict
Avatar
RankRankRankRank
Total Posts:  5211
Joined  2008-03-06

Mine and Fuseling’s current project has a scarf with a fringe.  I export the scarf from blender with normals pointed out.  I use transfer utility to copy rigging from Blender.  I test-render.  The normals are stll facing the right way.  Then I save to library.  When I reload from library the normals are flipped so that the fringe renders black under UE lights. 


If I try flipping the normals before I export, they don’t flip back to normal on save, they stay wrong.


If I just flip one set of them before I export, they all flip to wrong again.  Studio stubbornly refuses to save the normals pointed forward away from Genesis.


Is there a fix for this that won’t require me to bork the vert order?  The morphs are already done.

 Signature 

My store at DAZ.

My Deviantart gallery.

Profile
 
 
Posted: 20 November 2012 04:19 PM   [ Ignore ]   [ # 1 ]
Addict
Avatar
RankRankRankRank
Total Posts:  4545
Joined  2007-09-13
SickleYield - 20 November 2012 03:45 PM

Mine and Fuseling’s current project has a scarf with a fringe.  I export the scarf from blender with normals pointed out.  I use transfer utility to copy rigging from Blender.  I test-render.  The normals are stll facing the right way.  Then I save to library.  When I reload from library the normals are flipped so that the fringe renders black under UE lights. 


If I try flipping the normals before I export, they don’t flip back to normal on save, they stay wrong.


If I just flip one set of them before I export, they all flip to wrong again.  Studio stubbornly refuses to save the normals pointed forward away from Genesis.


Is there a fix for this that won’t require me to bork the vert order?  The morphs are already done.

Is the item in DS format or is is it an OBj, when the normals are getting flipped? 

Would you be willing to post a wireframe screenie of the fringe area?  I’m wondering if there is something in that area that’s causing this…

One of the few times I’ve had something like that, I had a ‘double extrusion’ and ended up extruding ‘inside out’. (it was on a mushroom stem, that I ultimately scrapped and started over)

If they are flipped in the obj then try PropViewer to flip them (it’s not a very complex program and doesn’t do much, but it can orient normals, fairly efficiently).

 Signature 

1432 old posts

My ShareCG gallery.

Just because something costs a lot, doesn’t mean it’s the best…

It just means it’s expensive.

Profile
 
 
Posted: 20 November 2012 04:25 PM   [ Ignore ]   [ # 2 ]
Addict
Avatar
RankRankRankRank
Total Posts:  5211
Joined  2008-03-06

No.  The obj is fine.  The initial rig is fine.  It flips the normals ONLY when saved to library and reloaded.  I know this because not only can I manually check normals in Blender, but I put on UE lights and rendered it both before and after rigging and saving.


It is not a double extrusion.  I can count every single vert in that geometry area.


Duplicating the small planes that constitute the fringe, translating slightly on the y axis (or z in DS4 terms), and flipping normals fixes it.  DS4.5 stops flipping the normals the wrong way on save when there are two proximate identical planes with opposite-facing normals.  Apparently DS4.5 just can’t handle a single sheet of polys stacked in front of another single sheet with both having normals face the same way.  I still have to redo all the morphs, but it’s faster than a redo from scratch because I can just do the same dup on each morph obj.


I may file a bug report on this one.  This is an unacceptable loss of productivity when I’ve got this may projects going at once. :p

 Signature 

My store at DAZ.

My Deviantart gallery.

Profile
 
 
Posted: 20 November 2012 04:35 PM   [ Ignore ]   [ # 3 ]
Addict
Avatar
RankRankRankRank
Total Posts:  4545
Joined  2007-09-13
SickleYield - 20 November 2012 04:25 PM

Apparently DS4.5 just can’t handle a single sheet of polys stacked in front of another single sheet with both having normals face the same way.  I still have to redo all the morphs, but it’s faster than a redo from scratch because I can just do the same dup on each morph obj.


I may file a bug report on this one.  This is an unacceptable loss of productivity when I’ve got this may projects going at once. :p

I wonder if it’s somehow related to the way DS is now treating normals, over all…because it’s actually conforming more to how 3Delight handles them, than it did in the past…but it should still handle the single sheets as two separate things and handle each one separately…

I wonder…smoothing/collision…could DS be counting both sheets as ‘one’ because of that?

If you turn off smoothing, does it still do it?

 Signature 

1432 old posts

My ShareCG gallery.

Just because something costs a lot, doesn’t mean it’s the best…

It just means it’s expensive.

Profile
 
 
Posted: 20 November 2012 04:44 PM   [ Ignore ]   [ # 4 ]
Addict
Avatar
RankRankRankRank
Total Posts:  5211
Joined  2008-03-06

HA


I could kiss you.  Now I don’t have to redo all the morphs.


If smoothing is turned off before saving to library, the issue does not occur.  If smoothing is turned on, normals are borked.


I can still have smoothing by reloading from library, adding the modifier, and saving to library again, as once the .duf is created it doesn’t appear to create the issue again on re-save.

 Signature 

My store at DAZ.

My Deviantart gallery.

Profile
 
 
Posted: 20 November 2012 05:05 PM   [ Ignore ]   [ # 5 ]
Addict
Avatar
RankRankRankRank
Total Posts:  4545
Joined  2007-09-13

Now to figure out if it is collision or smoothing and if the values can be tweaked.

 Signature 

1432 old posts

My ShareCG gallery.

Just because something costs a lot, doesn’t mean it’s the best…

It just means it’s expensive.

Profile