Interstage Fairing Shaders

[Beale]

Hi, I was wondering if there was some solution to this:

When you have two fairings on an engine, they can look lighter / darker depending on the angle to sunlight, when they should really look like one smooth surface.
It is not very visible head-on.

But when the sun hits from the side, you can see the issue.

The set-up in Unity is nothing special.

 

Thanks for any help  

[landeTLS]

Mirrored uv map causing inverted normalmap direction? not sure. maybe someone else has a better idea. Nice N1 block B btw.

Edited November 20, 2016 by landeTLS

[Beale]

12 hours ago, landeTLS said:

Mirrored uv map causing inverted normalmap direction? not sure. maybe someone else has a better idea. Nice N1 block B btw.

Thanks  

Those two UV maps are mirrored, nice idea. I will give it a try.

Edit: Unfortunately, it does not seem to be that. I wonder if I could have a unified mesh and then disable that and enable two separate meshes on the decouple event.

Edited November 21, 2016 by Beale

[landeTLS]

10 hours ago, Beale said:

Thanks  

Those two UV maps are mirrored, nice idea. I will give it a try.

Edit: Unfortunately, it does not seem to be that. I wonder if I could have a unified mesh and then disable that and enable two separate meshes on the decouple event.

I dont think so with the unified mesh thing. Atleast not with the stock decoupler module.

In any case if its simply a mesh seam issue(doesnt look like it to me tho, but i could be wrong) you could use something like a copy normals procedure to achieve a similar merged mesh effect. 

Something like this in blender:

or:

I couldnt find a method for wings 3D

In any case it should be possible and probably better to fix the root cause if the shading issue.

Im a bit rusty with unity but could it be that the mirrored fairing side obj has a -1 scale etc.? Still just guessing here.

Edited November 21, 2016 by landeTLS

[InsaneDruid]

Like landeTLS said, It's the normals of the vertices on the seam, where the two halves meet. The normals of the vertexes there are perpendicular to the surface. while the vertices on all the other edges of the round shaded hull are shared between two surfaces, and thus have a common normal with angles >90 degrees (90°+360°/number of edges/2) from the adjacent surfaces. On a 24 sided "round" mesh its 97.5° instead of 90. See the image:

Green lines= normals of the shared vertices
Red lines = normals of the vertices on the seam between the halves.

You have to use some sort of manual normal editing to get rid of the problem, just like around holes in the mesh when doing windows. This thread has the answer when using blender.

PS: I just recently fixed the exact same problem on the hard fairings for my proton using the methods I describe in the linked thread.

Edited November 22, 2016 by InsaneDruid

[Beale]

On 21/11/2016 at 8:24 PM, landeTLS said:

I dont think so with the unified mesh thing. Atleast not with the stock decoupler module.

In any case if its simply a mesh seam issue(doesnt look like it to me tho, but i could be wrong) you could use something like a copy normals procedure to achieve a similar merged mesh effect. 

Something like this in blender:

I couldnt find a method for wings 3D

In any case it should be possible and probably better to fix the root cause if the shading issue.

Im a bit rusty with unity but could it be that the mirrored fairing side obj has a -1 scale etc.? Still just guessing here.

11 hours ago, InsaneDruid said:

Like landeTLS said, It's the normals of the vertices on the seam, where the two halves meet. The normals of the vertexes there are perpendicular to the surface. while the vertices on all the other edges of the round shaded hull are shared between two surfaces, and thus have a common normal with angles >90 degrees (90°+360°/number of edges/2) from the adjacent surfaces. On a 24 sided "round" mesh its 97.5° instead of 90. See the image:

Green lines= normals of the shared vertices
Red lines = normals of the vertices on the seam between the halves.

You have to use some sort of manual normal editing to get rid of the problem, just like around holes in the mesh when doing windows. This thread has the answer when using blender.

PS: I just recently fixed the exact same problem on the hard fairings for my proton using the methods I describe in the linked thread.

My old friend surface normals! 

Thanks for the information  I will have a dig into methods and see if I can use Blender as a "quick remedy" to the wings3D produced models.

 

[Beale]

@landeTLS Maybe you are good to ask for this.

I have what looks to be a correct set-up, but when I click "apply" the data transfer modifier dissappears. Any ideas?

 

 

Edited November 22, 2016 by Beale

[Ven]

2 hours ago, Beale said:

@landeTLS Maybe you are good to ask for this.

I have what looks to be a correct set-up, but when I click "apply" the data transfer modifier dissappears. Any ideas?

 

 

Go to Data and then check Auto-Smooth, that'll fix the issue.

[Beale]

19 hours ago, Ven said:

Go to Data and then check Auto-Smooth, that'll fix the issue.

Thanks, I take it that the data modifier is supposed to dissapear after apply?

Unfortunately, I exported to object and into Unity and the problem persists, maybe the format is wrong to use? (But with OBJ I can keep my UV mappings)

It has that issue in Blender too.

It is important to note I am not creating the fairing from scratch in Blender, but I am importing an OBJ made in Wings 3D.

Edited November 23, 2016 by Beale

[landeTLS]

22 hours ago, Beale said:

Thanks, I take it that the data modifier is supposed to dissapear after apply?

Unfortunately, I exported to object and into Unity and the problem persists, maybe the format is wrong to use? (But with OBJ I can keep my UV mappings)

It has that issue in Blender too.

It is important to note I am not creating the fairing from scratch in Blender, but I am importing an OBJ made in Wings 3D.

Try applying the data transfer modifier on both fairing halves(temporarily merged etc.)? also make sure the surrogate/dummy object has smooth nomals/shading applied(not sure if it makes any difference but i havent used blender for years so i dunno)

edit: When applying the modifier in blender it is correct that it should disappear. But i also heard some mods are better left in the stack and then letting the fbx/obj exporter take care of the conversion. but that may just have been in older versions of blender.

Edited November 24, 2016 by landeTLS

[InsaneDruid]

I wrote about it in my tutorial that i linked.

"2.07 Now only one problem remains: the Data Transfer modifier cannot be applied! So exporting to unity removes it. To fix this issue, head over to the DATA tab of the object again. Under Normals, select Auto Smooth and hit the button Add Custom Split Normals Data from the Geometry Section under Geometry Data."

But as landeTLS said you can also just leave the modifier in the stack and have the exporter auto-apply it. I do this lately with all my modifiers. And, if the upper object in your screenshot is your normal source, it has to be smooth! Not having it smooth shaded means the normals point to 90° from their surfaces, and you are transferring data that is as actually identical to what your mesh that should receive the fixed ones already is in the first place.

Edited November 24, 2016 by InsaneDruid

[Beale]

46 minutes ago, landeTLS said:

Try applying the data transfer modifier on both fairing halves(temporarily merged etc.)? also make sure the surrogate/dummy object has smooth nomals/shading applied(not sure if it makes any difference but i havent used blender for years so i dunno)

edit: When applying the modifier in blender it is correct that it should disappear. But i also heard some mods are better left in the stack and then letting the fbx/obj exporter take care of the conversion. but that may just have been in older versions of blender.

23 minutes ago, InsaneDruid said:

I wrote about it in my tutorial that i linked.

"2.07 Now only one problem remains: the Data Transfer modifier cannot be applied! So exporting to unity removes it. To fix this issue, head over to the DATA tab of the object again. Under Normals, select Auto Smooth and hit the button Add Custom Split Normals Data from the Geometry Section under Geometry Data."

But as landeTLS said you can also just leave the modifier in the stack and have the exporter auto-apply it. I do this lately with all my modifiers. And, if the upper object in your screenshot is your normal source, it has to be smooth! Not having it smooth shaded means the normals point to 90° from their surfaces, and you are transferring data that is as actually identical to what your mesh that should receive the fixed ones already is in the first place.

Thanks for the info, I am using the latest version of Blender currently.

I have left the modifier in place, applied the auto smooth + custom split normals check and applied a smooth shader to the source mesh.
Unfortunately it still suffers from the lighting issues. Any ideas?

Here's the blend file.

[InsaneDruid]

You didn't click on the "custom normals" button after enabling the "face corner data" check-mark. The modifier isn't transferring anything yet

[landeTLS]

17 hours ago, Beale said:

Thanks for the info, I am using the latest version of Blender currently.

I have left the modifier in place, applied the auto smooth + custom split normals check and applied a smooth shader to the source mesh.
Unfortunately it still suffers from the lighting issues. Any ideas?

Here's the blend file.

I had a go at it. i had to import it to 3dsmax to do the normal editing since i dont remember much about using blender. but i reimported it to blender and saved it in addition to the fbx file from max.

I dont have unity on this laptop so havent checked it there. but it does look correct to me in max and blender now. btw it seems that mirroring the mesh resets the normals again so i just added a mirrored copy with fixed normals in the model files.

FBX file

Blend file

Edited November 25, 2016 by landeTLS

[Beale]

5 hours ago, landeTLS said:

I had a go at it. i had to import it to 3dsmax to do the normal editing since i dont remember much about using blender. but i reimported it to blender and saved it in addition to the fbx file from max.

I dont have unity on this laptop so havent checked it there. but it does look correct to me in max and blender now. btw it seems that mirroring the mesh resets the normals again so i just added a mirrored copy with fixed normals in the model files.

FBX file

Blend file

Man, that's flawless!

Whatever process you have done in 3DS max, I need to learn it!
Thanks for the example, no if only I can be self sufficient with this procedure.

7 hours ago, InsaneDruid said:

You didn't click on the "custom normals" button after enabling the "face corner data" check-mark. The modifier isn't transferring anything yet

Is this correct? Unfortunately I still cannot get it to work.

 

Edited November 25, 2016 by Beale

[landeTLS]

1 hour ago, Beale said:

Man, that's flawless!

Whatever process you have done in 3DS max, I need to learn it!
Thanks for the example, no if only I can be self sufficient with this procedure.

Is this correct? Unfortunately I still cannot get it to work.

 

I couldnt get it to work fully in blender either,i was getting slightly incorrect normals along the top/bottom rim using the data transfer modifier + vertex groups. But clearing all the normals then doing a bit of manual avaraging+copy/pasting of the vert normals in max(edit normals modifier) did the trick for me. My guess is that something similar can be achieved in blender too but im just a lot more familiear with 3dsmax.

Here are a few resources/discussions about normals editing in practical use:

http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial

Old one from autodesk help files(still applicable)

http://wiki.polycount.com/wiki/VertexNormal

there are plenty more but these where just some i found by looking around a bit.

 

Edited November 25, 2016 by landeTLS

[InsaneDruid]

easy

https://dl.dropboxusercontent.com/u/107802/Fairing.blend

some things to consider when doing this:

A mirror modifier after the data transfer might produce incorrect results (but manually duplicating and mirroring works fine, and moving the mirror above the data transfer in the stack works, too)

Vertex groups to control which vertices should receive the data transfer and which not have to be selected in the data transfer modifier.

Remember that making an edge sharp via the edge split modifier or the auto smooth option under the vertex data tab this ultimately means the vertex gets split! If a vertex is added to a vertex group and then split by the mentioned options, both resulting vertices are in the group (and both receive the data transfer and thus the same normal direction). In short: vertex groups work on vertex levels, not on the face-level of the mesh! So manually split first, so that you can really independently select the correct vertices into the vertex groups that control the data transfer modifier. This is important around the boundaries of your mesh, where the faces that make the depth of the mesh meet the outer skin faces (top and bottom of the mesh, and the faces that meet when the two sides of the fairing are together). Split the vertices via the v command or just select the depth-faces , move them in a separate mesh (p-command), and immediately join them back via the alt-j-command. Do not remove doubles after that!

I have enabled normal display in the file, so you can better see what I meant. Try it out and look what is when you remove doubles, and  also select the contents of the vertex group and see exactly which vertices i selected for them.

Edited November 26, 2016 by InsaneDruid

[Beale]

On 26/11/2016 at 9:55 AM, InsaneDruid said:

easy

https://dl.dropboxusercontent.com/u/107802/Fairing.blend

some things to consider when doing this:

A mirror modifier after the data transfer might produce incorrect results (but manually duplicating and mirroring works fine, and moving the mirror above the data transfer in the stack works, too)

Vertex groups to control which vertices should receive the data transfer and which not have to be selected in the data transfer modifier.

Remember that making an edge sharp via the edge split modifier or the auto smooth option under the vertex data tab this ultimately means the vertex gets split! If a vertex is added to a vertex group and then split by the mentioned options, both resulting vertices are in the group (and both receive the data transfer and thus the same normal direction). In short: vertex groups work on vertex levels, not on the face-level of the mesh! So manually split first, so that you can really independently select the correct vertices into the vertex groups that control the data transfer modifier. This is important around the boundaries of your mesh, where the faces that make the depth of the mesh meet the outer skin faces (top and bottom of the mesh, and the faces that meet when the two sides of the fairing are together). Split the vertices via the v command or just select the depth-faces , move them in a separate mesh (p-command), and immediately join them back via the alt-j-command. Do not remove doubles after that!

I have enabled normal display in the file, so you can better see what I meant. Try it out and look what is when you remove doubles, and  also select the contents of the vertex group and see exactly which vertices i selected for them.

Not so easy!  

I've followed to the best of my ability and the best I can produce is this:

When pressing V, I get the error (cannot rip selected faces).

 

Edit:

I might have fixed it... The "source" mesh required no top or bottom faces. I haven't played with any mirror-modifiers. To be honest I did not understand that part of your post.

 

Thanks!

 

Edited November 27, 2016 by Beale

[InsaneDruid]

The mirror modifier was just mentioned by me for there was just one side in the test file you provided, and so I added a mirror modifier myself to see how both sides looked together. If placed after the data transfer, it wasn't good. So I mentioned just in case.