New Orbiter Beta Released (r.13, Mar 7, 2015)

[Gingin]

Thanks for the quick reply Jarmonik.
Looks like you 've done an amazing work and still working on nice features , congrats

Ok for the shaders , but I have really the feeling that with the last D3D9 Beta , the earth is not glowing anymore like with others versions.

In the first picture of my previous post , it's like if Earth was dimmed compared to others pictures with your older plugin or even with the vanilla Orbiter 2015 with Dx7.

Do you have the same feeling than me looking to the picture , or is just my imagination?

Thank again for your nice reply

 

[Felix24]

Also, it would be a good idea to explore a possibilities of pre-computed (baked) lights via light-maps.

The ideas a self-shadowed virtual cockpit has crossed my mind. But I have considered it from a sun light perspective. How would the sun light lit the cockpit when shining through cockpit windows.

These two ideas are the best, I think.

The first idea is simple enough; we can currently produce diffuse textures with the shadows baked in, and without too much fuss we can make a separate texture map containing just shadows and apply it to the diffuse texture using the shader. Maybe someday there can be different shadow maps for when the sun is coming in from different directions, to better emulate a raytraced cockpit, but that's only an idea.

The second idea would be more involved. I know the D3D11 client has self-shadowing with the sun, and I don't know how much harder it would be to do it with D3D9. Self-shadowing is basically the last big visual effect I'm hoping the D3D9 client will get.

 

[jarmonik]

I think the vessel self-shadowing is the next big feature in line. But there are so many "Monday" problems as well as the cloud shadows and atmospheric rendering issues, that it may take some time to get there.

 

[Felix24]

Martins, what do you think about having the un-lit labels painted on the base texture (like the Atlantis VC), and only using the light map for illuminating the labels? In other words, is there a reason you are using the label texture both for diffuse and illumination?

 

[jarmonik]

I am not exactly sure if I understand the question. But from my point it would be logical to have the labels in a diffuse texture that would determinate the appearance of the labels when the back-lights are turned off. And when the back-lights are switched on an emission map which would also contain the labels would be added. Also, it might be good idea to modulate the emission map color via material color to provide on/off/color toggle options.

Of course, it might be easier for developers only to have the labels in one texture. But then, how to switch the rendering behavior of the texture (i.e. day time/night time mode). Also, one issues is that the D3D9Client already has a system to load an additional texture maps. Do we need an other parallel system to match the inline engine ? (-just thinking aloud-)

 

[Chuckosan]

Just because I can't find this anywhere else, but I saw that Martin said 2015 at the earliest. I will be very sad, but very understanding, if this slips for a long time. Any guestimate on completion?

My kids and I love this, Martin. Thanks for your efforts.

 

[martins]

Martins, what do you think about having the un-lit labels painted on the base texture (like the Atlantis VC), and only using the light map for illuminating the labels? In other words, is there a reason you are using the label texture both for diffuse and illumination?

Both methods have their merits. I chose this because it was easier to implement, and requires a lot less texture real-estate (all the labels can be squeezed together without gaps, and the underlying panel texture is just a generic 256x256 DXT1), but painting the labels on the panel backgrounds works equally well. Pick whatever you prefer.

Maybe things will become clearer when the next beta is submitted. I wanted to finish the DG VC for that, but I could probably also upload a work in progress.

 

[Bibi Uncle]

Will VESSEL::MeshgroupTransform be implementable in graphic clients in the next version ? Without this method, manipulating meshes is a pain...

 

[martins]

Will VESSEL::MeshgroupTransform be implementable in graphic clients in the next version ? Without this method, manipulating meshes is a pain...

Ah yes, good point. I'll have to think about this one. The inline client implements this by directly editing the vertices. But for other clients this may not be feasible or expensive, if the vertices live only in graphics memory. So it may be necessary to keep the transformation matrix stored with the mesh groups, to be applied to the world matrix before rendering the group. This may require an extension to the mesh group definitions.

On the other hand, maybe the simplest solution would be to just pass the MeshgroupTransform call through to the client, and leave it to the client how to actually implement it.

 

[martins]

Orbiter Beta SVN commit #11

A new beta (r.11) has been uploaded to the SVN repository.

This concerns mostly the DeltaGlider VC redesign. Note that this is still a work in progress. I mainly uploaded it for testing against external clients, and because there was interest in implementation details.

Other than that, there is only a small change in rendering planet water surfaces (altitude-dependent fog density).

Compatible OVP (r.29) has also been committed.

 

[Bibi Uncle]

On the other hand, maybe the simplest solution would be to just pass the MeshgroupTransform call through to the client, and leave it to the client how to actually implement it.

That's probably the best solution. Graphics clients would simply implement their own matrices and apply it before rendering the meshgroup.

 

[dgatsoulis]

A new beta (r.11) has been uploaded to the SVN repository.

This concerns mostly the DeltaGlider VC redesign. Note that this is still a work in progress. I mainly uploaded it for testing against against external clients, and because there was interest in implementation details.

Other than that, there is only a small change in rendering planet water surfaces (altitude-dependent fog density).

Compatible OVP (r.29) has also been committed.

WOW! I love the way the new VC looks, works and feels. Thank you very much for all the new features. I can't decide what's best; Red flood lights without the instrument lights, or the other way around! Both look fantastic.:thumbup:

Also... landing freaking lights!? I am not sure if they were there on rev.10, I just noticed them! AWESOME!

I do have one feature to ask, if it's not too much trouble for you Martin.
I've always hated the "nose down" reentry of the DG. Do you think you can add a switch or lever in the VC that puts it in "reentry" mode, by shifting the CoG? (well, actually by moving the hwing center of pressure a little bit forward with EditAirfoil).

Again, thanks for all your hard work.

 

[C3PO]

:crystalball: I do see my TrackIR getting a workout in the future.

I do have one feature to ask, if it's not too much trouble for you Martin.
I've always hated the "nose down" reentry of the DG. Do you think you can add a switch or lever in the VC that puts it in "reentry" mode, by shifting the CoG? (well, actually by moving the hwing center of pressure a little bit forward with EditAirfoil).

The STS orbiters had a narrow stable area at around 40° AoA at hypersonic speed. Would it be possible to add a force(torque?) to simulate that stability? A +/- 5° band where the force is just strong enough to counter the aerodynamic stability, but if you venture too far the "normal" stability takes over. Maybe it could be tuned so that if you reenter too steep the force isn't strong enough to keep the nose from dropping.

Speaking of dropping, I need to go look for my jaw. Fantastic view! :thumbup:

 

[Felix24]

Both methods have their merits. I chose this because it was easier to implement, and requires a lot less texture real-estate (all the labels can be squeezed together

without gaps, and the underlying panel texture is just a generic 256x256 DXT1), but painting the labels on the panel backgrounds works equally well. Pick whatever you prefer.

I would pick painting the labels on the panel backgrounds and illuminating them separately as the standard method, for the following reasons:
- Having a larger total texture size is worth the trouble for a virtual cockpit, because the textures get seen a lot and the increase in detail lends itself to better immersion.
- The VC is more customizable. Labels can be enlarged or moved without having to re-map the texture and rebuild the model.
- Label lights can be colored within the texture, allowing for better realism.
- It keeps a standard rendering method for the DG and everything else.

It would basically be the rendering method used for the old DG VC, with some modifications.

The new VC seems to render okay in the D3D9 client. However, in both the inline client and D3D9, I noticed that during daylight, turning on the instrument lights and then cranking down the brightness results in darker labels than if the instrument lights are off. When the lights are off, the labels are light gray, but when the lights are on, the labels become dark green. Instead, the labels should become only a slight bit lighter. Drawing from real-world experience, when you're in a car during the daytime and you turn on the panel lights, the added light is practically invisible, because of ambient light levels. This can be simulated in Orbiter by multiplying the label lights by (1 - ambient). This reduces the lighting effect during the day, but makes it clearly visible in the dark.

 

[luki1997a]

Is there any way to download previous betas?

 

[Face]

Is there any way to download previous betas?

Just checkout an older version from the repository.

 

[Zach121k]

I don't know if this has been answered yet, but I have a few questions.

1: Will the MSS be retracted in the future? (I assume it is)
2: Will there be a fix of the slight Lat/Long adjustment from 06/10. As in will mods from 06 be adjusted to the correct position on the globe. (IE Pads being in the right place... etc.)

 

[orbitingpluto]

2: Will there be a fix of the slight Lat/Long adjustment from 06/10. As in will mods from 06 be adjusted to the correct position on the globe. (IE Pads being in the right place... etc.)

It's not really Martin's place to update all the mods out there, and I'm certain applying a fix like that shouldn't be something that is handled by the core. You could make a request thread to ask for a simple calculator that knows what offset to apply to place things as they were intended, maybe relying on the user to update the scenario and config files by hand, or automatically patching files you tell it to. I'm not sure what form that kind of thingy would take, but it seems possible and should get it's own thread.

 

[Zach121k]

I agree, it's annoying going into every CFG file.

 

[romanasul]

I finally tried the Orbiter Beta and I am absolutely amazed. I can't go back to Orbiter 2010 after this.