I looked it up and DirectX 9 has a maximum texture limit of 4096x4096. Isn't OgreEE based on version 9?

The original EECH was based on DirectX 7, so the texture limit was 2048 x 2048.

I think I made some bigger textures to test what's even possible. I really don't know it anymore

There were so many things the last two years, I really couldn't remember what exactly I did for the KA-50 project, sorry!

I hope this time with the MI-28, I don't have to halt the work before I'm completely finished with the things I'm able to do. But at least that's sadly not always my decision, that's the way life is (at least how my own life was the last 20 years - it's also the reason my homepit project never finished until now - started with it in 1998!)

I really would like to do the complete work for a helicopter by my own, so noone must deal with the things I made (sometimes certainly not really accurate), but sadly I'm not able to do any coding, which is absolutely required to get any instruments or other things running. I also considered to learn coding, so that I'm able to make all those things too, but I simply haven't enough time for it, even though it seems that I will have more time now than the last years of my life.

If I start to learn coding also, the hompit project is on hold for minimum the next two years again. And the way my life is, I try to use the time it seems that nothing new unexpected will happen, to finish the dream of my last over twenty years. The last twenty years sadly it never worked for me, so I hope this time it will, but who knows?

All I can do is helping with 3D models of cockpits or helicopters. Even the animations are something I could not realize at the moment, but I think this is something I'm at least able to learn.

That's also the reason I try to make as much as possible if I have the time for it, cause I never know what comes next. Sadly I'm no "robocop".

I'm almost done with the needles. But the calculations to work out the rotation of the needle has me stumped. I've got it to almost match the texture scale, but not quite. Also, I was using the speed shown on the hud as a guide. But it turns out the speed on the hud was the wrong value. It showed world z velocity, so basically how fast an object is moving through the 3d world, unaffected by air, or any other physics. Once I changed that to use indicated airspeed, I got further.

I'll need a maths guru to help understand, or try and work out what the calculation is doing. I read this guide, and it helped a bit.

https://www.s-cool.co.uk/a-level/ph...ns-and-angular-speed-versus-linear-speed

Hmm, what about simply change the texture of the instrument, to make it work linear. I know that isn't realistic, cause some instruments in the KA-50 aren't linear, but if it's possible to adjust the texture to a linear one, it could be a workarround until we know more about the code that stands behind it.

If we are able to make it the right way, it's no big deal to change the textures again. Don't know if it is even possible, because of the scaling needed to show the whole indicating range, but if, this could be a solution for now, for sure not for ever. Better a working instrument than nothing

Found a video about this, but it's a description to program it for x-plane. Don't know if it helps cause I have no coding experience, but what I've always heard is that many things are work relatively similar in different coding languages.

https://www.youtube.com/watch?v=gfABSyd5KsA

Don't blame me if I'm wrong

what about simply change the texture.
+1 the same i thought. No make sense waste time.
Thank you Javelin for info.

Another one I found using XML for the gauge calculation. It's for the MSFS.

http://www.kgz.shawbiz.ca/tutorials/xml/backup_attitude_gauge.html

If I change the texture, I'd still have to match the rotation to the markings on the texture, so I'd still need to know how the calculation works.

That mean Houston,we have problem

Is there a way to "borrow" some gauges from another helo? Maybe the Hind or even from a US chopper? I could retexture the instrument, so that it looks like a russian one.

I checked the Hind, but it has a different scale for speed. Just related to that though, the Hind does have a few instruments I'd like to reuse - the Main ADI is more like the one in the Blackshark, also the Engine temperature gauges, the clock, the rotor blade pitch, and the fuel gauge (I have the fuel needle working, but I want to check how it is done in the Hind code, as I'm not sure I have the right calculation).

The youtube video uses an existing function (img_rotate) in his code (I might check out the xplane source code and see what that function does), so he's just feeding it values. In our code, the angle to rotate (theta) is calculated, and then passed to "something" that rotates the object by that amount. There's some conversion from degrees to radians, and radians to degrees going on, and I need to work out how the linear value is translated to rotation using the functions. In the past, I used existing code, or trial and error to get it to work. But I want to try and figure it out, and then document it. It might take a little longer, but it'll be better in the long run to know these things and have them in the wiki.

Yes, I know what you mean. I also think in the end it's better do understand how things are working instead of copy and paste. It might be sometimes faster, but if you want to be more prepared for future things, it's better to understand what it really does.

I had also the vision back those days that if we really understood how the whole instrumentation is working, it might be possible to configure some standard instruments with a simple textfile, you write in the coordinates, the scale and kind of the gauge or MFD you like to display in 3D. Thought this could eventually be done with variables in the code, but I can really imagine that this would be a hard coding work and sadly I'm not able to help with something like this, of course I really would.

I looked at the sourcecode back those days and I even could not follow the whole structure at all. So many different parts which are all dependent from each other and you have to jump from here to there. If you already have problems to understand the coding itself this makes the whole attempt to recognize only a small part of it totally impossible.

I really admire the hard work you and Javelin have done to realize many things, that without you never could have been possible.

Please if you do such GREAT cockpit,think about add manual contrast for tv view. If not for all helos,only for blackshark. Now is really hard see anything,because no flir in blackshark. Contrast i think greatly help .

Well, if I upgrade the external model to the one that Viper did, it has FLIR, so I could change the TV to have that as well as DTV.

that would be fantastic now is extremely hard find targets.

OK, I can see you need some help Messyhead. Which gauge are you working on that has you stumped? Show me the gauge face with the multiple-ranges, tell me where the needle starts out in the 3D object file, and I'll set up the logic for it in a way that you can understand it and use it for any gauge out there. Just give me a day or two to answer, because I'm on 12 hour days until Friday.

I took a look at the Mi-28 Havoc Altimeter as an example. The texture is wrong by the way, the 30 on the gauge should be a 40.

The gauge moves 45 degrees for every 20 meters of altitude all the way up to 100 meters. From 0 up to 100 meters is 5 x 45 = 225 degrees.

From 100 meters up to 300 meters the gauge moves 45 degrees for every 100 meters of altitude.

if (altitude < 100) angle = rad ((altitude/100)*225);
// altitude/100 is the percentage the gauge has moved of the first 100 meters, the fraction of 225 degrees the gauge has rotated.

else angle = rad(225 + (altitude - 100)*45/100);

// now we start new at 100 meters. The first 100m adds 225 degrees. Then Alt-100 gives us the alt that we've gone past 100m.
// divide it by 100 m to get the fraction of 100's and multiply by 45 degrees for every 100, and you get the degrees needed to rotate the needle.
// All the rad() function does is convert degrees to radians. The rotate function for the object wants radians.

Does that help at all?

Now let's say the instead of pointing straight up, the needle object is pointing to the left, 90 degrees to the left of vertical.

We now need to add in 90 degrees just to get the needle to point at 0 on the Altimeter gauge. The new equations become the following:

if (altitude < 100) angle = rad ( 90 + altitude*225/100 );
else angle = rad ( 90 + 225 + (altitude -100)*45/100 );

Clear as mud?

Javelin, you have no idea how much that has helped! Thank you so much.

I understand now how the figures all link together. I think trying to look at existing code, and work it out, for me, wasn't helping.

The only tricky part is working out the angles for each mark. The Mi28 clearly has markers at 45deg, but other ones are more of less. I can judge it roughly, then tweak it till it's matching up.

Rocket science