Request Support for other mesh / 3d formats and shaders in current and future versions?

[Coolhand]

Hi guys, i've recently been working on the ingame materials for the XR2 and have been thinking about the shaders that are currently supported in orbiter.

This has lead to a couple of questions.

1, Is there currently any support for a mesh format other than .msh? Would it be possible to load a Direct X format file and use some of the extra shaders/effects that the format supports in orbiter in its current form?

2, If not, will there be support in the future for more advanced shaders or formats with the new plugin graphics modules? Presumably if .msh is still being used then the same limitations on shaders will persist no matter what renderer is being used to draw the screen.

Thanks.

Steve.

 

[James.Denholm]

Maybe an idea will be to have a simple, non-textured .msh used by the Physics engine, and a more detailed, different mesh format for the Graphics engine. I don't know the feasibility, but this has been musing over in my head for a while. Not that I would have a clue on how to do such a thing, though.

 

[dbeachy1]

Maybe an idea will be to have a simple, non-textured .msh used by the Physics engine, and a more detailed, different mesh format for the Graphics engine.

Actually the mesh has no effect on the Orbiter physics engine at all -- the mesh is purely cosmetic. A ship's aerodynamic drag, lift, etc. depend exclusively on the code in the ship's DLL. In other words, we could create a large flying brick that would fly as well as the DeltaGlider. I can see it now: the XR9 Superbrick! :lol:

I have read that X-Plane uses the plane's mesh to determine its flight characteristics. But in 99% of other simulators, Orbiter included, the mesh has no effect on the physics. Which, of course, is just fine with me because it lets the software engineers decide how the ship will fly rather than the 3D artists. (No offense, Steve!) :beach:

 

[James.Denholm]

Oh, ok. So I could theroeticly make a huge Lego brick that has the areodynamics of a rocketship...

 

[tl8]

Oh, ok. So I could theroeticly make a huge Lego brick that has the areodynamics of a rocketship...

Or vice versa

 

[James.Denholm]

Ha! That wouldn't be to hard to get into orbit. Oh, wait, I said huge. Ah well.

 

[spcefrk]

Realflight uses two meshes as was mentioned. There's a graphical mesh which is used to display the RC plane graphically with textures, transparency, and reflections. There's a second much simpler collision mesh which is part of the dynamics of the simulator. Using a collision mesh allows a lot of cool things.

The most fun is that separate parts have separate collision meshes and are chained together such that if I bank while taking off, I can snap a wheel off without losing anything else. Similarly I can snap the wing off and if the wheel was attached to the wing, the wheel stays attached to the now-removed wing.

I would be delighted to see Orbiter go this route. It would allow collisions and specific damage natively. And if that were too much for a beginner to handle, you could simply make a square or cylindrical collision mesh encompassing the whole aircraft and be done with it.

 

[tblaxland]

I would be delighted to see Orbiter go this route. It would allow collisions and specific damage natively. And if that were too much for a beginner to handle, you could simply make a square or cylindrical collision mesh encompassing the whole aircraft and be done with it.

See computerex's handywork in this regard here.

 

[spcefrk]

See computerex's handywork in this regard here.

That's sort of what I was talking about, but collision detection really needs to be innate. The way it's done in RealFlight is pretty brilliant once you figure it out. From what I can tell ComputerEx's work is a step in that direction (and certainly no small cookies) but it's not the full chained collision mesh support I was talking about. The crashes in RealFlight are spectacular (although there's no fire or anything of that nature). And for collisions between two small bodies (like spacecraft) there's a rather nebulous strength modifier. Whichever strength is higher, remains unbroken.

So at most I could see a list of 8 coordinates (simple box), plus a part mass (for transfer of momentum), a strength modifier value, and a list of child collision meshes. If it were standardized as part of the API, it would be very easy for add-on developers to make use of it rather than the other way around which leaves only a few ships supported.

But I'm really just spitballing here as I do so often.

 

[ar81]

Some addons use high poly meshes.
Those are useful for close view.

But for distance, a simplified mesh could be used.
I know that this trick of having several meshes for the same vessel, depending on the distance, is used in gaming to improve performance.

I think Orbiter could support OBJ format.
You may see some description of OBJ format in Mesh Wizard manual.
Materials file documentation is somehow incomplete and limited. I haven-t found everything on MAT files

 

[Urwumpe]

I think Orbiter could support OBJ format.
You may see some description of OBJ format in Mesh Wizard manual.
Materials file documentation is somehow incomplete and limited. I haven-t found everything on MAT files

Veto. OBJ is not really a useful format for computer games. I think it would be better to create a compressed mesh format and maybe also container files for spacecraft and bases, so Orbiter uses internally a virtual file system, instead of a real one. Would make add-on management simpler.

 

[RisingFury]

Actually the mesh has no effect on the Orbiter physics engine at all...

Do you have any idea if there ever will be a system implemented in orbiter that would allow Orbiter to determine the aerodynamics from the mesh... or would such a thing be too slow?

Would get some more realistic aerodynamics that way though...

 

[Urwumpe]

Would get some more realistic aerodynamics that way though...

What do you think, when you read this idea?

Realistic calculations by the meshes is, in Orbiters context, completely useless. I don't know any flight simulator, which does so in every time step, all precalculate the data and there is some CFD software around already, though in beta stage...

A CFD software, covers the full hypersonic range is still expensive and not real time capable at all.

 

[Hielor]

Some addons use high poly meshes.
Those are useful for close view.

But for distance, a simplified mesh could be used.
I know that this trick of having several meshes for the same vessel, depending on the distance, is used in gaming to improve performance.

LOD meshes aren't that hard to implement, and this could allow pretty significant gains in performance, specifically when you have vessels between orbiter's "colored dot" distance and the near, full-detail-needed distance.

 

[Urwumpe]

LOD meshes aren't that hard to implement, and this could allow pretty significant gains in performance, specifically when you have vessels between orbiter's "colored dot" distance and the near, full-detail-needed distance.

Especially, using modern graphic cards and normal mapping, you can save a lot of polys for effects, which can then be done by better textures.

 

[ar81]

I am thinking about convenience for newbie developers. Therefore my suggestion.