Orbiter Public BETA 080514: Bugs and Comments

[Tschachim]

Hi All,

after messing up Martin's compiler thread I decided to move my test results of the new Beta version to a new thread. I'm also reporting changes, which are no bugs, but can cause some work for add-on developers to adapt their add-ons.

BUG: "Transparent surface meshes are rendered non-transparent"

The bug was already reported for an ealier beta version last year and is explained here: http://orbit.m6.net/Forum/default.aspx?g=posts&t=14619 (second screenshot). Basically opacity as set in the material definition is ignored for surface meshes, vessel meshes are fine. I'd classify that as a severe bug, which should really be fixed before release.

CHANGE: "New KSC launch pad and VAB positions"

The attached screenshot explains the change well, I hope. I'm quite sure this is no bug, but it can cause some work (in the case of NASSP a lot of work) to change all positions according to the new tiles.

CHANGE: "PARTICLESTREAMSPEC::ATM_PLOG behaves differently"

After some tests it looks like this setting has no effect in the currect release version (i.e. is the same like PARTICLESTREAMSPEC::ATM_FLAT, 1.0, 1.0) and in the beta this fixed now, which is fine, of course. But if you have rather extrem settings in your add-on, be prepared to revise these settings.

REMARK: "OrbiterSound 3.5 isn't working"

... with the new beta. Obviously this is no issue related to Orbiter itself, but given the importance of OrbiterSound from a developers point of view it would be better to test both Orbiter and OrbiterSound together in order to avoid "integration problems"...

Testing continues...

Cheers
Tschachim

 

[Tschachim]

QUESTION: "STATICMESH support"

By the way, does the new beta (using the "build-in" graphics client) and so will the new release support the STATICMESH resp. STATIC flags in the mesh file, or to put it differently, will we be able to take advantage of the stuff we figured out last year here: http://orbit.m6.net/Forum/default.aspx?g=posts&t=13884

Cheers
Tschachim

 

[martins]

The mesh parser is in the orbiter core, so is shared between all graphics clients, including the inline client, and the STATIC and STATICMESH flags should be respected.

However, I haven't done anything with respect to rearranging the mesh groups to reduce the number of vertex buffers. I think you did some work on this. If you can remind me what was required, I could try to incorporate this into the next beta.

 

[martins]

BUG: "Transparent surface meshes are rendered non-transparent"

Yes, sorry I forgot about this. I'll switch on alpha blending for the surface tile rendering.

CHANGE: "New KSC launch pad and VAB positions"

This is a bug fix rather than a bug. I realise that the updated positions may cause problems for some addons, but at least it should eliminate the discrepancies between the orbiter core and some KSC addons which are already using correct positions.
Incidently, could somebody check that the new KSC pad positions in the beta are really correct now? I would like to avoid having to move them again in the future.

CHANGE: "PARTICLESTREAMSPEC::ATM_PLOG behaves differently"

Interesting. I wasn't aware that anything had changed here (or I fixed it so long ago that I have forgotten about it).

REMARK: "OrbiterSound 3.5 isn't working"

Hopefully Dan will provide an update for the sound package. I think I recall that it uses some calls to very ancient station-related API functions that have been obsolete for nearly as long as Orbiter exists. I did take the liberty to finally remove these functions from the API to fix at least the worst clutter. So maybe this is a good spot for a friendly warning to developers: use obsolete functions at your own risk! Anything that has been marked obsolete for more than five years is fair game ).

 

[Tschachim]

Hi Martin,

The mesh parser is in the orbiter core, so is shared between all graphics clients, including the inline client, and the STATIC and STATICMESH flags should be respected.

Thanks, that's good to know.

However, I haven't done anything with respect to rearranging the mesh groups to reduce the number of vertex buffers. I think you did some work on this. If you can remind me what was required, I could try to incorporate this into the next beta.

Yeah, that would be the D3D7 Client "Big Buffer Edition" , last post of the thread I linked. Basically I changed the D3D7Mesh class, so that all static mesh groups are loaded in one big buffer the mesh class has itself and all static groups only store an index of that buffer in their group struct. Non-static groups still use their own buffer.

Unfortunately I did the change based on a now-outdated mesh.h/cpp version, I attached a zip file with both the new and the "originally based on" versions of the mesh.h/cpp files for easier "diffing". The changes in the .h file are small, D3D7Mesh now has a LPDIRECT3DVERTEXBUFFER7 VtxBuf (the "big buffer") and GROUPREC has a new DWORD VtxBufIdx (the buffer start index of the group in the big buffer). In the .cpp file there are more changes, in both constructors either a buffer for a non-static group is created (as before) or the index in the big buffer is stored in the group and the group vertexes are copied in the big buffer. The RenderGroup function is changed according to that, i.e. render the (complete) group buffer or the part of the big buffer, beginning at the index of the group. I hope this isn't too confusing, I think you can see all that better in the code, I'm happy to help with the details. I also should mention that this is a rather "quick and dirty" implementation in order to test that than a good designed piece of code.

This is a bug fix rather than a bug. I realise that the updated positions may cause problems for some addons, but at least it should eliminate the discrepancies between the orbiter core and some KSC addons which are already using correct positions.
Incidently, could somebody check that the new KSC pad positions in the beta are really correct now? I would like to avoid having to move them again in the future.

Yes, I already thought that this is a bug fix, of course using the correct positions is the way to go. Checking would be a good thing, too, I also want to move all that stuff only once.

Cheers
Tschachim

 

[Glider]

Hi All,
I have two questions about the 080516 beta and the new L14 textures support in it.
Is it possible to make L14 Earth texture for a very big area (North America, Europe) that will work with this beta ? I know that such texture will have huge size ( few gigabytes ) but I see that the new beta loads texture parts dynamically on-the-fly and I also see not great usage of RAM by the new beta (only 272mb at my system with 1.06 Gb in the Textures2 folder). So,
1.Is there any limit of RAM or video memory to make big L14 texture ?
2.What source was used to make L14 Florida ?

 

[martins]

1.Is there any limit of RAM or video memory to make big L14 texture ?

There is no explicit limit, but L-14 support is brand new, and no such large areas have been tested to date. It may work, but there are no guarantees.

2.What source was used to make L14 Florida ?

The Florida area is derived from (heavily modified) Zoomit! Florida 1-m images, which according to the World Wind page ( http://www.worldwindcentral.com/wiki/Add-on:ZoomIt%21 ) don't have a copyright attached. I think the original data come from USGS aerial photographs. In fact, if somebody knows a better source for global or local high resolution public domain imagery, please let me know.

 

[n0mad23]

Are STATIC and STATICMESH flags only applicable to the next version, or are they incorporated into the 2006 release as well?

Following the above m6 thread, I've gone into the meshes in this version and for the life of me can find none of these flags.

 

[Tschachim]

Are STATIC and STATICMESH flags only applicable to the next version, or are they incorporated into the 2006 release as well?

As far as I know next version only.

Cheers
Tschachim

 

[martins]

Those flags have been supported since the 061101 beta version, so they are not present in the current release version - sorry ...

 

[n0mad23]

Well that answers that. I thought maybe I was losing my mind or something.

Oh well, it's something I'll certainly keep in mind for future revisions of the current project. The nice thing here is it won't take that much work to modify existing meshes to incorporate this feature.

Thanks guys.

 

[agentgonzo]

The new star brightness is great. However, it doesn't allow you to put negative numbers into the EditBox.

 

[Glider]

The Florida area is derived from (heavily modified) Zoomit!

May I ask you where it was downloaded from ?
I've tried to find any source of Zoomit! images but I found only that Zoomit is included in NASA World Wind. But World Wind creates many 512x512 images that would be difficult to assemble in one big. :huh:So, may be there is another source of big and easy downloadable Zoomit! images?

 

[martins]

The new star brightness is great. However, it doesn't allow you to put negative numbers into the EditBox.

Ah, good catch. Apparently the concept of negative numbers is new to Windows - well maybe by servicepack 5 ...

 

[Voyager_VI]

Where is beta 080514 available at?

When I go to the beta page http://download.orbit.m6.net/betaNG/orbiter_beta.html the last update I see is 070927.zip...I've refreshed the page, so that's not the problem...

 

[computerex]

Where is beta 080514 available at?

When I go to the beta page http://download.orbit.m6.net/betaNG/orbiter_beta.html the last update I see is 070927.zip...I've refreshed the page, so that's not the problem...

http://orbitervis.wiki.sourceforge.net/OrbiterPublicBeta

 

[Voyager_VI]

Thanks computerex, don't know how did I miss that one....

 

[Poscik]

Can I compile D3D9 client by the same way as for D3D7 client?

 

[computerex]

CHANGE: "New KSC launch pad and VAB positions"
The attached screenshot explains the change well, I hope. I'm quite sure this is no bug, but it can cause some work (in the case of NASSP a lot of work) to change all positions according to the new tiles.

That's troublesome, because most add-ons use the pre-calculated (Checklist\quickstart) coordinates to place their vessels on say the runway 33, which means that people will start finding their vessels in the middle of nowhere(still on KSC of course). But we can use this to our advantage, see the attachment.

 

[zippy]

I get a CTD every time it tries to load a scenario.