Add Yokes

[xcvb85]

Add textured 3D-model of the yokes.

[HHS81]

[xcvb85]

cool 👍

[HHS81]

Tiller, Pedals, and Yokes modelled and uvmapped. Only the center pedestal is missing yet....

The whole flightdeck without Overheadpanel as .ac-model is currently about 3,6Mb large.

[xcvb85]

This looks really promising! I wasn't lazy either (not yet finished):

This was really annoying and when finished there is also a prop-version... Thanks for the picture btw.

[HHS81]

Wow, great work! How much difference is between the prop and jet version of the fuse panel? I'm still thinking how we proceed regarding OVH-Panel. Center pedestal is only marginal and could be easily solved by a select animation. The OVH-Panel has also marginal difference (Fuel system and Engine system) which I could solve the same way. Hmm...

[xcvb85]

About 80% is the same (rough guess) so the prop version will not be the big problem. I could finish the OHP texture and modelling (I shifted some buttons) for the prop version first because I guess you are already busy with the rest of the cockpit. Then we can see how to proceed. I'm not sure about the ALS shadows. Maybe it is possible to use .ac includes in xml-files as long as there are no further transformations. Then a select animation would not be required. Regarding OHP animations: I would prefer to create them in X/Y-plane first and to do the transformation afterwards.

[HHS81]

Maybe it is possible to use .ac includes in xml-files as long as there are no further transformations. Then a select animation would not be required. Regarding OHP animations: I would prefer to create them in X/Y-plane first and to do the transformation afterwards.

As I understood ALS-Shadows all objects has to be in the same space position. So an object with Position (0/0/0) can't be included and transfered via xml to, let's say Position (10/0/2). That's the big problem with the ALS shader and FGFS as well, that makes modelling and developing aircraft so difficult and challenging compared with other sims.

[xcvb85]

Maybe this is ok:

  <model>
    <path>ohp.ac</path>
  </model>

but this is not:

  <model>
    <path>ohp.ac</path>
    <offsets>
      <x-m>  -8.27159 </x-m>
      <y-m> 0.0 </y-m>
      <z-m>  2.61106 </z-m>
      <pitch-deg>-13.35</pitch-deg>
    </offsets>
  </model>

Then we wouldn't need a select animation. We must check. Nevertheless we can start with the animations in x/y-plane and transform them later e.g. in this way (just a quick and dirty C++/Qt program, maybe wrong):

#include <QMatrix4x4>

int main()
{
    // inputs
    QVector3D position(-0.123, -0.061, 0.0);
    QVector3D orientation(0.0, 0.0, -1.0);

    // calculation
    QMatrix4x4 rot;
    QMatrix4x4 trans;
    rot.setToIdentity();
    trans.setToIdentity();
    trans.translate(-8.27, 0, 2.61);
    rot.rotate(-13.35, 0, 1, 0);
    trans = rot * trans;

    // outputs
    qDebug() << trans * position;
    qDebug() << rot * orientation;
    return 0;
}

Output is new position and new orientation of the knob:

QVector3D(-8.76885, -0.061, 0.601537) QVector3D(0.230899, 0, -0.972978)

[xcvb85]

Finally I finished the two circuit breaker texts versions. It was some detective work since none of the templates was free of errors but I hope it should be ok now. The final result will look better than I expected:

But first I will upload a version without ambient occlusion shadows because they must be re-baked when all positions are fixed.

[HHS81]

@xcvb85 Well, I introduced some misunderstandings here

1.) ALS Interior Shadows

For this, as you said, `

ohp.ac

will work. The c172p guys figured out that

ohp.ac

<offsets>
  <x-m>  -8.27159 </x-m>
  <y-m> 0.0 </y-m>
  <z-m>  2.61106 </z-m>

...` won't work, as the shadows will be mismatched. That means we have to save the OHP.ac at exactly the position where we need it later. So your procedure with transforming the animation sounds good.

But regarding the select animation, that has a completly different reason:

2.) 80% commonalities vs. other shader effects

We have only 20% difference in the OHPanel and on the Center Pedestal. Everything else in the cockpit is absolutely the same. So it doesn't make sense to have two completely cockpit files, with 80% of them are doubled .ac-models, doubled texturefiles, doubled lightmaps and other stuff.

I had uvmapped the OVHPanel in a way, that there is still enough place for uvmapping the different sub-panels (engine/ icing, etc...) and parts of the fusepanel. We don't should forget that the buttons also have text. This image explains what I mean: This part in the red circle was on the same uvmap like the ovh. I took it now away and uvmapped it on the cockpit-map. So the free space on the ovh-map can be used for the sub-panels which are different and fuse panels which are different.

Do you think this will be possible, that those parts of the fuse panel which are different can be mapped elsewhere, so the fuse models can be selected by different type (jet vs prop)?

3.) Occlusion shadows

Forget about them. They are unrealistic, and ugly.

I have used a better and faster method on the Cessna 182 S, but this should really come at very, very last when everything is in place. Actually we can get something like that: : Render to texture ;-)

[xcvb85]

1./2.) Something like this is what I had in mind:

  <model>
    <path>cockpit.ac</path> <!-- without pedestial and overhead panel -->
  </model>
  <model>
    <path>pedestialProp.ac</path>
  </model>
  <model>
    <path>ohpProp.ac</path>
  </model>

In any case the pedestial and the ohp cannot be joined with the cockpit object because hinding with select wouldn't work either. In a development branch we could use the following (animations only in X-/Y-plane):

  <model>
    <path>ohpProp.ac</path>
    <offsets>
      <x-m>  -8.27159 </x-m>
      <y-m> 0.0 </y-m>
      <z-m>  2.61106 </z-m>
      <pitch-deg>-13.35</pitch-deg>
    </offsets>
  </model>

When we finished all animations it is not that much effort to calculate the new positions with the transformation program. Otherwise it is very annoying to determine the exact position of the switches if the ohp is rotated.

3.) OK, if you know how this works we can do this ;-)

[xcvb85]

Q: Do you think this will be possible, that those parts of the fuse panel which are different can be mapped elsewhere, so the fuse models can be selected by different type (jet vs prop)?

A: I wouldn't make it too complicated and I guess this will be bad for the frame-rate. Many polygons are not the big problem but high resolution textures are frame-rate eaters. So I would prefer one texture for prop and one for jet. Maybe this will increase the installation size a little bit but only one version will be loaded at runtime.

[HHS81]

@xcvb85 actually you should use less textures as possible. High-resolution texture are not frame-rate eaters, they might eat RAM with lots of vertices, but not frame-rate.

Please see: http://wiki.flightgear.org/Modelling_guidelines I followed it with the c182S, and I have 1/3 better frame rates than the similar c172p

[HHS81]

@xcvb85

In any case the pedestial and the ohp cannot be joined with the cockpit object because hinding with select wouldn't work either.

What do you mean with hinding? I don't know this word

[xcvb85]

Sorry typo: I wanted to write hiding.

Nevertheless, what is your problem with this approach:

  <model>
    <path>cockpit.ac</path> <!-- without pedestial and overhead panel -->
  </model>
  <model>
    <path>pedestialProp.ac</path>
  </model>
  <model>
    <path>ohpProp.ac</path>
  </model>

[HHS81]

increase of number of texture files. we would need now: 1 prop-pedestal 1 jet-pedestal 1 prop-ovh 1 jet-ovh 1 prop-pedestal-lightmap 1 jet-pedestal-lightmap 1 prop-ovh-lightmap 1 jet-ovh-lightmap

And just because of less than 20% difference. And if we want (I don't consider it at the moment) normal and specular maps, the number increases a lot more

[xcvb85]

You don't need different texture files for different ac files. In case of the ohp there are so many differences that it doesn't make sense to use a common texture but in case of the pedestal this should be possible.

[HHS81]

Hmmm...according the guidelines it is recommended to have a different texture file per different .ac-file. ("Do not use different parts of a single texture for different models. Split the texture into smaller parts then.")

I can agree to a different OHPanel, if there is so much difference. But on the pedestal it doesn't make sense

[xcvb85]

Too bad that they didn't explain the background of this recommendation. This would help to decide which is the better solution (hiding with select or using different models). I could imagine the reason is that the texture will be loaded twice. Otherwise both models will be loaded at same time. Both approaches are not perfect but I'm not sure which is the bigger problem.

[xcvb85]

Texture pushed to Issue73 branch. I will add the adjusted model in the next days. Still much to do.

[HHS81]

@xcvb85 Looks cool! Since we have more space, should we re-align the uvmap, so the text will get sharper with?

[xcvb85]

Actually there is not that much space left. Left and right from the panel there are two parts which also belong to the OHP model. Besides the work on the circuit breakers I also shifted some buttons (you will notice this if you compare it with Test.png texture from Issue37 branch) and added e.g. the temperature scale. This will look ugly if you resize it because I made it with gimp (I don't like Inkscape that much). Finally we also need the different button icons for activaded and deactivated which are missing at the moment.

[HHS81]

@xcvb85

Left and right from the panel there are two parts which also belong to the OHP model.

No, I shifted this parts to the cockpit as I said yesterday. When we move the Firebuttons we might could enlarge the whole panel on the map. But is is just a suggestion. We can fill the space of the now shifted parts with the texture of the button icons.

[xcvb85]

I just tried what happens if the texture gets resized and the result was ok. We can do this if you like.

[HHS81]

It is just a suggestion, as I think the text will get a bit sharper maybe. But if we loose space for the button icons I can absolutely go with the current way.

[xcvb85]

I don't really know how many different icons are required but I guess if we leave one stripe on the left with the with of one button this will be sufficient. I will check.

[HHS81]

@xcvb85

Too bad that they didn't explain the background of this recommendation.

An explanation is that:

Objects: ... The net effect is that it is far faster to render a million vertices in one draw than in thousand draws a thousand vertices each. Due to the limitations of the AC3D model format used by FlightGear, different parts of an object cannot be assigned to different texture sheets, thus for each extra texture sheet there will be an extra object and ultimately an extra draw call, having as a result that four 1k texture sheets are less efficient than the same data on a single 2k texture sheet because there's 4x less draw calls. Note  Anything that can be combined into one object also should be combined into one object, and the number of texture sheets used should be as low as possible.

You can easily group two or more objects together, each of them animated by a select animation. As said above Grouping objects has the same effect like joining to objects, just that you can animate both objects separatly. Disadvantage is, that opening the file in Blender can be difficult.

I did so on the EC135 P2- advantage: good framerates, quick livery change

[HHS81]

But I'm fine with the solution we have now on the OVH! 👍

[xcvb85]

You can easily group two or more objects together, each of them animated by a select animation. As said above Grouping objects has the same effect like joining to objects, just that you can animate both objects separatly. Disadvantage is, that opening the file in Blender can be difficult.

OK, something like this is what I expected. I wonder if the following could be a solution:

1 common-pedestal 1 common-pedestal-lightmap 1 prop-ovh 1 jet-ovh 1 prop-ovh-lightmap 1 jet-ovh-lightmap

[HHS81]

I have to see if I can combine common-pedestal into a 4096px (or 2048px) texture file together with the ones form the cockpit, but yes, that would it be.

Throsten Renks doubts, that grouping in Blender has the same effect like joining. But my experience is taht liveries are loaded much faster.