HI, I'm the author of the ubershader and accompanying effects. I noticed on the forums that you're having some issues with it.
Could you please paste somewhere the effect file you use?
Also could you check that the respective objects are not parented to some other object (or an empty) from where they could possibly inherit effects/materials?
The flipped normal behaviour is really weird (and would suggest you have inadvertently enabled the <normalmap-dds> flag)
Also, for the uberhsader the relevant documentation is in $FG_DATA/Docs/model-combined.eff/
(If you're gonna ask why it's not on the wiki, you have already hit the main reason, bitrot, and having to duplicate maintenance efforts. And no, I don't think the wiki should be the authoritative source for documentation)
- Hello Hvengel
- I have/had the same problem with the EC135P2 and the Dornier 328 model slow WIP. So far I can remember one thing seems to be is the uvmapping. When two face are overlapped in the :UVmapped it seems to produce this issue. At least it is not a issue with the shader itself. More the way the model is uvmapped.
- Can you send a in-sim screenshot of the faulty part and a image of the the matching uvmapping?
- Btw: the main culprit is not the vertice numbers- but the objects numbers. So a, let's say 7.000.000 vertice aircraft divided into 1000 objects has a much bigger impact
- as a model with twice number of vertices but divided in only 50 objects. Means: combine all meshes into one object in Blender as long you don't need to animate in any way =
- One object + those objects which has to be animated (aileron, flap,...)!
- Yes, the UV coordinates direction needs to be consistent on the same mesh. You can have overlapping faces as long as they don't share an edge in the UV and/or they don't have one of the coordinates flipped. (i would post some screenshots if not for the innane upload wizard :( )
- In the meantime a couple of examples here: http://emilianh.go.ro:6980/flightgear/uv-mapping/
- In the problematic1 example the middle face will be causing issues (it's U coordinates being flipped, and it shares the UV edge with the left face). In the problematic2 example the B1 (right) face will be causing issues, as it's V coordinates are flipped (mirrored)
I have very carefully gone over the three objects to make sure that the UV maps had no overlapping or 0 area faces in the UV map. In the case of the cowl I actually removed parts of it that were not part of the main exterior surface. These consisted of things like the cylindrical surfaces for the air intake holes, the edge and internal surfaces of the exhaust cutout, the internal air intake passages (behind the holes on the side of the cowl) and the front ring that is next to the spinner which are all now separate objects now. The cowl in now much simpler (still a fairly complex shape in the chin scoop area) with no folded over edges or inside surfaces.
So here are some screen shots:
These are high res screen shots (about 4.5 mega pixels each) so you should be able to see all of the necessary details. The background in the UV map screen shot is the actual texture being used. The line and hole detail in the texture was used to create the normal map.
Hvengel (talk) 18:08, 5 July 2014 (UTC) Hal
- Hi, I've moved your message here to have the discussion in one place.
- I took a look at the blender file. Sorry to say this but the mesh is a mess, and I suspect the somewhat flaky blender-2.6+ .ac export script is choking on it and spitting out garbage.
- For example on the cowl object there are 88 n-gons (faces with 5 or more vertices). This can cause issues with the winding order (which determines the respective face/normal orientation), even more so if the script tries to be smart and split those on its own. There is a blender script that's called MeshLint and can help with checking and fixing the meshes. You can find and enable it in the addons tab of the user-settings dialog. Try first manually splitting the n-gons into tris, recalculate normals and then re export the mesh from blender, see if that helps.
- I know working with booleans seems easier, but these are the hidden traps in that style of work, and you end up doing twice the work needed on the mesh to fix it up after the quick&dirty boolean operations.
- And that's a shame given the amount of work you obviously already put into it.
- I4dnf (talk) 19:01, 5 July 2014 (UTC) Hvengel (talk) 08:22, 6 July 2014 (UTC)
- Got the MeshLint add in and went through the three meshes that are having issues and removed all n-gons. Kind of time consuming but no too bad. After all I only have to do one side then mirror it to get the other side. After removing all n-gons I then had Blender recalculate the normals and exported the model. The issue is still there.
As a side note the last objects I discovered that had this issue are the exhaust covers. In these I cut the holes by hand since I couldn't get the boolean operation to work. I also cut the exhaust cutouts in the cowl by hand and at one point these were nice clean looking cutouts. But when i did the boolean operation to do the 32 1 inch holes for the filtered air intake Blender decided to mess with the exhaust cutouts. But at that point I don't think there where any n-gons. But the normals problem was still there even before I tried to clean things up. I spent some time cleaning up the air intake holes and this is where the n-gons came from.
I just had a close look at the exhaust covers and the one I looked at did have two n-gons. I fixed those then flipped back to to normal and recalculated the normals and exported it. Opening the .ac file in FG everything looked sort of OK except the inside of the mesh was bright and reflective. This object has the normals of the front pointing outward and the normals of the back areas are pointing inward and these parts of the object are textured black. But the back was acting like it's normals were flipped (IE. the back was black - showing the texture- on the outside when it should be showing this on the inside). Turns out that this is acting just like the cowl and wing fairings. So is unrelated to using a Boolean operation.
Thinking things through a little it appears that all of the objects that are showing up black in the FGRUN 3D preview when the normals are the correct direction are objects where I did cutouts of some sort either by hand or using a Boolean operation in Blender. For most of these I did NOT use a boolean operation.
The export script definitely has issues but, at least with simpler models, works in most cases. The way it behaves when something is not textured is very flawed in that it just fails with more or less hidden and very cryptic error messages. I do UI work for a living and I would never let something that poorly designed out into the wild. If it has such obvious UI issues who knows what kind of issues exist in the actually functionality.
Hvengel (talk) 08:22, 6 July 2014 (UTC)