SSU Development Thread (2.0 to 3.0)

[GLS]

Remember the little "glassy windows" in front of the landing gear talkbacks and push buttons? Given my recent success in editing the VC mesh, I decided to see if I could do anything about them before moving on to other areas. I already can hear you thinking: "oh no, he's at it again! :uhh:" :lol:
In my view there are 2 options: change the material/texture of those mesh groups so they display a texture that we can modify from the code (to do talkbacks and lights), or delete those groups.
Since I know nothing about the first option, I tried the second one and deleted those 10 groups... and it works! The glass parts are gone and the talkbacks and lights are now more visible (result in attached image).
Now, while this is a solution for me, those groups might be needed in the future, (and it's another VC mesh edit), so once again I have to rely on the better judgement of the experts in the graphics department. So, what's the verdict on this?

 

[Urwumpe]

Modify from the code...if you mean slow painting of textures with it, please take a strong veto from my side. If we don't really need to paint on textures (for example by having the option to use a static texture in GPU memory and just modifying the texture coordinates of the groups for displaying different texture states), we should avoid it.

It is slow, annoys the rendering clients and is hardly reusable for other such elements in the panels (Since the drawing must match the texture scale)

I know we have lots of this in legacy code, but its evil. We should not do it in the future and maybe even remove such technical debts eventually.

 

[Donamy]

Breaking up the VC, would certainly make it easier to modify.

 

[GLS]

Modify from the code...if you mean slow painting of textures with it, please take a strong veto from my side. If we don't really need to paint on textures (for example by having the option to use a static texture in GPU memory and just modifying the texture coordinates of the groups for displaying different texture states), we should avoid it.

It is slow, annoys the rendering clients and is hardly reusable for other such elements in the panels (Since the drawing must match the texture scale)

I know we have lots of this in legacy code, but its evil. We should not do it in the future and maybe even remove such technical debts eventually.

Let me see if I understand this correctly: AFAIK, for both talkbacks and lights, we take a bitmap and paint part of it over the specific texture used in the area of interest. And if I'm not mistaken, that's how we are doing it everywhere... so in SSU it's not "legacy" but "the norm" (albeit a bad one).
I don't know how your other method would work in practice, but I think it would require each light, button with light, LED and talkback to have its own mesh group, right?
If so then I better bin the latest changes. :facepalm: At least it didn't take much of my time.

 

[Urwumpe]

Let me see if I understand this correctly: AFAIK, for both talkbacks and lights, we take a bitmap and paint part of it over the specific texture used in the area of interest. And if I'm not mistaken, that's how we are doing it everywhere... so in SSU it's not "legacy" but "the norm" (albeit a bad one).

Its legacy. Yes we did it that way in the past. No, we know that there are many good reasons why painting on a 2048 x 1024 texture is stupid, especially in Orbiter.

I am aware that it won't be easy to replace the old code without messing with the VC, so I don't want to touch it before we have the capacity to really mess around with the VC.

But for new things, we should do it properly by architecture. Maybe the code must initially not be the fastest and most optimized (no optimization first approach, please), but we should handle the big picture properly. And thats not that hard.

I don't know how your other method would work in practice, but I think it would require each light, button with light, LED and talkback to have its own mesh group, right?
If so then I better bin the latest changes. :facepalm: At least it didn't take much of my time.

Yes. Exactly that. Triangles are cheap with DX9/DX11, so we have nothing to fear there. And for DX7, a slightly higher triangle count is even more faster than painting textures.

I have not been aware that you also plan such a modification, otherwise I would have objected earlier. :blush:

 

[GLS]

I have not been aware that you also plan such a modification, otherwise I would have objected earlier. :blush:

I'm not sure what you mean... are you talking about my suggestion to delete the glass parts?

 

[Urwumpe]

I'm not sure what you mean... are you talking about my suggestion to delete the glass parts?

No, about removing the buttons and indicators and paint them on the texture.

 

[DaveS]

No, about removing the buttons and indicators and paint them on the texture.

Could you provide a sample so we others can study it and learn the appropriate techniques?

 

[Urwumpe]

Could you provide a sample so we others can study it and learn the appropriate techniques?

Sure, what kind of sample do you need?

 

[GLS]

No, about removing the buttons and indicators and paint them on the texture.

I don't think I ever said that... looks like there's some miscomunication going on.
What I've suggested was to delete those glass parts in front of the texture, so we can see better those areas, where the talkbacks and button lights are painted. But, if "your method" is to go forward (and if it is better I'm all for it), then we might need those groups there so we can do that texture "trick", thus
my idea to delete those groups is no longer positive.

 

[DaveS]

Sure, what kind of sample do you need?

Well, mesh(es)/texture(s) that shows just how things should be done vs the way they currently are done.

 

[Urwumpe]

Well, mesh(es)/texture(s) that shows just how things should be done vs the way they currently are done.

Give me some moment, I can do this.

 

[Donamy]

Could make them like this.

 

[Urwumpe]

Could make them like this.

Thats almost like how I would love them. Just the corners could be a lot sharper, so that the surfaces are more flat.

Here you can see some of the switch guards will in 3D (but no color)

 

[GLS]

Could make them like this.

If the window had just a little opacity it would look nice, but not too much or it becomes what we have now (too much). A more metalic tone would also be nice. Also the handle should be as big, in the vertical, as the cover. I can post some photos if you want.

---------- Post added at 09:45 PM ---------- Previous post was at 09:36 PM ----------

Very interesting image Urwumpe. Looking at panel C2 I thought that couldn't be Discovery, because the timer wheels are different. But then I confirmed it is in fact OV-103 as the stains on panel C3 match a photo I have from 2000, but the wheels are like we have in SSU. I wonder when they changed that part. After MEDS, at least 102 and 104 had "our" wheels.

 

[Urwumpe]

I wonder when they changed that part. After MEDS, at least 102 and 104 had "our" wheels.

The wheels had been the original interface to the timers, you can see them in many pictures that also show the old CRT displays.

On the newer pictures, the push-button timer interface is shown.

I can confirm that Atlantis still had the wheels on STS-135, but Discovery and Endeavour had push buttons.

 

[Donamy]

Thats almost like how I would love them. Just the corners could be a lot sharper, so that the surfaces are more flat.

Flatter and sharper edges is easy.

If the window had just a little opacity it would look nice, but not too much or it becomes what we have now (too much). A more metalic tone would also be nice. Also the handle should be as big, in the vertical, as the cover. I can post some photos if you want.

Covers with windows adds another mesh group for each cover, metalic is only accomplished with shading or textures.

 

[Urwumpe]

Covers with windows adds another mesh group for each cover, metalic is only accomplished with shading or textures.

Animating two groups would not be that much harder for the covers, but it Orbiter and transparency is a long topic. I could do without any glass windows there.

 

[GLS]

The wheels had been the original interface to the timers, you can see them in many pictures that also show the old CRT displays.

On the newer pictures, the push-button timer interface is shown.

I can confirm that Atlantis still had the wheels on STS-135, but Discovery and Endeavour had push buttons.

So my quick search shows only OV-103 and 105 had that change to buttons. The other 2 had the wheels.
This is good, it puts more value on us having separate panels in the VC so we can simulate the differences between the OVs. :thumbup:

 

[Urwumpe]

So my quick search shows only OV-103 and 105 had that change to buttons. The other 2 had the wheels.
This is good, it puts more value on us having separate panels in the VC so we can simulate the differences between the OVs. :thumbup:

Maybe we could also easier switch to the classic CRT cockpit then one day. Later. but thats not that urgent. But I think we two agree that splitting up the VC mesh would be a good requirement to be implemented in the next version to come then?