User talk:Hvengel: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
mNo edit summary
Line 4: Line 4:


[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 09:09, 11 July 2014 (UTC)
[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 09:09, 11 July 2014 (UTC)
Like you I avoid Nasal if there is an XML way to handle things.  With a JSBSim FDM you can do a lot of things in XML that require Nasal in a YASim aircraft and, at least for a JSBSim FDM, you should almost never need Nasal for animations unless they are VERY complex or are not FDM specific (IE. intended for use in any aircraft regardless of FDM).  The K-14A gun sight reticle animations are an example of something complex enough to be beyond doing it with XML only but it is also intended to be FDM independent as well so using JSBSim to drive the animations was not an option. 
Also in JSBSim you can setup XML functions specifically to drive animations.  For example, I do this to throttle the gun animations as frame rates fall below certain thresholds.  But I don't use any JSBSim stuff for the prop animation. When you use XML you are relegating things to either the FDM or to FG itself which will generally be more efficient and "safer" than rolling your own Nasal and much of this will actually happen in C++ space.  Also if you do this using FDM XML you take this out of the main loop which is generally a good thing.
Yesterday evening I pulled the prop disk and a second copy of the spinner into a separate model and did some cleanup on the models (the blades and the disk were not running true so I fixed that issue).  Looks OK.
Right now I only have two stages to the prop animation and I am trying (unsuccessfully) to use a transparency animation on the blades to simulate the blurred blades phase.  In fact I have been unable to get the transparency animation working in a number of contexts with recent versions of FG and I am not sure what the issue really is (probably something I am doing).  I can get things to have a fixed transparency by setting the material to a certain gamma and using a texture with a gamma but I have been unable to change the transparency at run time using the transparency or blend animation.
The other issue here is that in the blurred blade phase the blades should be darker/less transparent closer to the hub/spinner because they are traveling way slower than at the tips of the blades.  A blurred blade phase specific model and texture would probably make this possible. 
At this point I have more important stuff to tackle than the blurred blase phase stuff so it will have to wait until later as the prop animations are "good enough" for now.
[[User:Hvengel|Hvengel]] ([[User talk:Hvengel|talk]]) 16:16, 12 July 2014 (UTC)


== Ubershader Issues ==
== Ubershader Issues ==

Revision as of 16:16, 12 July 2014

Spinner animation

Hi. I've duplicated the spinner for each of the stages of the propeller animation (blades, blurred blades, disk ), as each of these spins at a different rate. It's the cheapest way to solve the issue, and it avoids having extra bits of code laying around (I generally avoid having nasal involved if there's a viable solution without it). Some will argue it's a quick job in 5 lines of nasal, well 5 lines of nasal add up, and can become quite the issue as the extra-500 bears witness (it is unflyable here and elsewhere due to the low fps, as everything is waiting on the nasal scripts).

I4dnf (talk) 09:09, 11 July 2014 (UTC)


Like you I avoid Nasal if there is an XML way to handle things. With a JSBSim FDM you can do a lot of things in XML that require Nasal in a YASim aircraft and, at least for a JSBSim FDM, you should almost never need Nasal for animations unless they are VERY complex or are not FDM specific (IE. intended for use in any aircraft regardless of FDM). The K-14A gun sight reticle animations are an example of something complex enough to be beyond doing it with XML only but it is also intended to be FDM independent as well so using JSBSim to drive the animations was not an option.

Also in JSBSim you can setup XML functions specifically to drive animations. For example, I do this to throttle the gun animations as frame rates fall below certain thresholds. But I don't use any JSBSim stuff for the prop animation. When you use XML you are relegating things to either the FDM or to FG itself which will generally be more efficient and "safer" than rolling your own Nasal and much of this will actually happen in C++ space. Also if you do this using FDM XML you take this out of the main loop which is generally a good thing.

Yesterday evening I pulled the prop disk and a second copy of the spinner into a separate model and did some cleanup on the models (the blades and the disk were not running true so I fixed that issue). Looks OK.

Right now I only have two stages to the prop animation and I am trying (unsuccessfully) to use a transparency animation on the blades to simulate the blurred blades phase. In fact I have been unable to get the transparency animation working in a number of contexts with recent versions of FG and I am not sure what the issue really is (probably something I am doing). I can get things to have a fixed transparency by setting the material to a certain gamma and using a texture with a gamma but I have been unable to change the transparency at run time using the transparency or blend animation.

The other issue here is that in the blurred blade phase the blades should be darker/less transparent closer to the hub/spinner because they are traveling way slower than at the tips of the blades. A blurred blade phase specific model and texture would probably make this possible.

At this point I have more important stuff to tackle than the blurred blase phase stuff so it will have to wait until later as the prop animations are "good enough" for now.

Hvengel (talk) 16:16, 12 July 2014 (UTC)

Ubershader Issues

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)

HTH

I4dnf (talk) 18:11, 3 July 2014 (UTC)

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,...)!
Cheers
--HHS (talk) 19:38, 3 July 2014 (UTC)
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 problematic 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)
UV OK1  
UV OK2  
UV Problem1  
UV Problem2  
I4dnf (talk) 10:44, 4 July 2014 (UTC)

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:

Cowl UVMap
Cowl In Sim Normals Normal
Cowl In Sim Normals Flipped

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.
HTH
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)

Most Likely Fix

Pfewww that was a hard one, and well hidden. The perils of transforming stuff in object mode in blender ;)
All these problem objects have negative scaling on at least one of the axes, and when the export script applies the transform, the normals get flipped. You'll notice it right away if you apply the transform first. Which you should do, to all objects, right away, to avoid this cropping up again. Fuselage isn't affected since it's not scaled. Examples below:
Cowl  
exhaustCoverLeft  
wingFilletLeft  
Fuse  
Btw, a couple of issues that I noticed that will affect performance: all your meshes have double-sided faces in blender, make them single-sided; your textures have the alpha channel left in, this will affect performance with shaders disabled and will cause funny rendering bugs in Rembrandt. Remove the alpha channel for the textures that are applied to opaque objects.
HTH, and cheers,
I4dnf (talk) 16:06, 6 July 2014 (UTC)