oolite elite---->frontier---->first encounters

[dajt]

I've been playing with getting Orbiter models to display in my OpenGL ship display program. The only ones I've managed to get going so far are the Orbiter version of the Cobra Mk3, and a simple X-Wing model.

The problem is how I'm displaying things I think - basically I read a .dat (Oolite) or .msh (Orbiter) file and create a C function from it that creates a display list. For Oolite models this works great because they're so small in terms of vertexs and triangles.

The Orbiter models have many more triangles and the source file created for most of them is around 10MB and takes longer to compile than I care to wait.

If I wrote a program to just read the Orbiter mesh and create vertexs on the fly it would probably go much better, but I don't think it is worth it because the models are way more complex than Oolite would allow in game.

Would there be a really bad effect if the allowable complexity of models in Oolite was increased? Some of the Orbiter things are really nice... and the authors may give permission to convert them.

They also often use multiple textures... can Oolite handle that at present?

[Draco_Caeles]

In a message to me, Aegidian wrote:

Code: Select all

MAX_VERTICES_PER_ENTITY   320
MAX_FACES_PER_ENTITY   512
MAX_TEXTURES_PER_ENTITY   8
MAX_VERTICES_PER_FACE   16

It's hard-coded into Oolite, to limit the polycount. You can get around it with sub-entities; however, it's a question of weighing up the hit in game speed that you'll get with all those high-poly ships floating around.

I can understand the reasoning behind the (comparatively low) poly limit: it does make for a lovely swift game.

[JensAyton]

The problem is how I'm displaying things I think - basically I read a .dat (Oolite) or .msh (Orbiter) file and create a C function from it that creates a display list. For Oolite models this works great because they're so small in terms of vertexs and triangles.

That’s a really horrible thing to do. :-) The “normal” way to do it is to load the data and create a display list directly; creating a C file sounds like unnecessary added complexity to me. Of course, these days vertex buffer objects are preferred to using immediate-mode (glBegin(),glVertex()...,glEnd()) rendering, too.

They also often use multiple textures... can Oolite handle that at present?

Depends what you mean. Oolite doesn’t handle multi-texturing, i.e. multiple textures on a single polygon. It does handle multiple textures per model, in the sense that each polygon can have its own texture if you want.

[dajt]

I know this is a cheap and nasty thing to do - all my coding is done that way... Just look at the SDL code someday

Edit
I've had a couple of ideas that I think will solve the problem. The most obvious being to convert the Orbiter .msh file to a .obj file. I just tried removing the vn entries from a simple .obj file (which I assume are the vertex normals) and it imported okay so that's encouraging. The .mtl file seems simple enough too, so I'm going to try a .msh -> .obj/.mtl converter.

The other thing would be to go straight to the .dat format, again as long as it doesn't need normals. I think I saw something in the .dat loading code that could calculate the normals but I'll have to check to be sure.

Many Orbiter models use material settings rather than textures which would mean going to Wings format would be better because then I can use it to create a texture image.

Another thing that occured to me last night was that the Orbiter models look bigger than they are because of the way they're stored - I think there are many common verticies in there that would be defined multiple times. The number of triangles is still pretty huge by Oolite standards though.

Good news re the textures. Orbiter doesn't use multiple textures per triangle, just multiple textures per model so that should be fine.

In other news, there have already been successful attempts to get Orbiter going in multiplayer - using Orbiter itself as the display and input engine only. There also seems to be some fancy way of doing "payloads" which sounds damned cool for cargo handling.

I am a bit surprised some FE2/FFE fan isn't hacking away using this thing. It actually looks like a lot of fun. But I hated FE2/FFE so it won't be me (although I *love* the idea of using known stars in a 3D starmap with real system sizes...!) I reckon John Jordan and the FE2 OpenGL guy are wasting their time and talent on the original code. But it is their time and talent to waste.

[JensAyton]

OBJ vn lines are indeed vector normals. The python obj2dat converter ignores them and calculates new face vertices, I believe after triangulating the polygons. (This is suboptimal; triangles from the same polygon can end up with different normals despite being in the same plane.) Dry Dock averages vertex normal together and provides the option of recalculating normals.

The code for recalculating normals in Oolite is for objects with the isSmooth tag. DAT files require normals, one per face. (A face line is: r, g, b, nx, ny, nz, count, [vertex index]*, where r,g,b are ignored and nx,ny,nz are the face normal.)

I'm still working on rewriting Oolite’s mesh loading. It’s going slowly, because the mesh handling code is so strongly tied to Entity; I think I’ll have to start again with a mesh class based on the current code in entity. When I’ve got a refactored version working with DATs, I’ll start on a new, more flexible format. What sort of “material settings” should such a format have?

My current feature list for the new format, for reference, is:

• Pure one-sided triangles, always. Oolite seems to draw every object double-sided twice, which is a waste of resources. The disadvantage of one-sided triangles is that objects with the wrong “winding order” will appear inside-out. I intend to hack a copy of Oolite down into a simple model viewer so people on any platform will be able to test this. It will probalby also be able to flip the winding direction of a file directly, and possibly do other minor edits.
• A material concept; rather than specifying a texture map per face, it will specify a material per face. The material will have properties such as:
  • Diffuse colour
  • Diffuse map (the current texture map)
  • Specular colour
  •  Possibly an optional specular map
  • Optional normal map (a form of bump-map)
  • Your ideas here
• Per-vertex normals; this allows a model to use smooth shading but also have hard edges.
• Stuff I don’t remember.

Technical stuff that’s even less interesting: I’ll initally prototype the functionality with a plist-based format. After that a more specific format will be used; Giles and Winston will probably make me use a text-based format, even though the idea sucks for reasons I’ll argue for when it becomes relevant. ;-)

[dajt]

Well, I've found and converted a couple of small Orbiter meshes - the Eagle cockpit and the Shuttle AB, which are both well within Oolite's standard limits for vertexes and faces.

I copied the shipdata.plist entry for the viper interceptor and changed it's name, role, and model values. I figured that would be enough.

As soon as it tries to show either of them it crashes with an out of virtual memory error.

A bit disappointed, but as I said above most of the Orbiter models are way too complex for Oolite anyway. This is not having a go at Oolite - the models all have tons of tiny triangles to do little cylinders smoothly, etc. which wouldn't be necessary at the scale of Oolite.

[JensAyton]

Out of virtual memory for in-limits DATs? That shouldn’t be happening. Could you e-mail me the bad files? I’d like to work out what’s causing it, even if I can’t necessarily fix it. :-) (E-mail link at bottom of message.)

[CWolf]

Just back on the original topic, or at least part of it...

I LOVE the non-player centric game. I love the fact that npcs call for you to help them out, I love seeing a battle and getting the sensation that they are others fighting for survival. The whole thing makes it all so much more realistic. It is annoying in other games to see police ships ignore guy shooting at you!

As for the "Foolite" idea, as far as I can tell all the best bits of FE2 and FFE are already in Oolite - passengers and the ability to change ships. There is so much more that Oolite has that neither of the others have. Only thing missing is planetary landings, and that is no big loss.

I like it as it is and I like the way Oolite is evolving. The Strict classic mode is nice to have, I am glad it is an option and not a rule though.

[Ironlion45]

First off, Hi! I'm Ironlion45. Long-time Elite player- Like most here. Also I occasionally post on EBBS. Once In a blue moon, I go to AFE. I have been Elite in at least 5 different incarnations of the game (PC, ARC, TNK, FE2, FFE; and I am working on Oolite).

Introductions aside...

For me, having played Elite extensively, Oolite is the game that I wanted Elite 2 to be. I don't say that lightly; this game, not frontier, is the true spiritual sucessor to Elite.

It takes all the best of new elements from Fe2 and FFE, but preserves the integrity of the original's feel.

It is too bad that Leaving the trade lane also leaves encounters, though- Flying to the sun is a pretty safe bet in Oolite. But beyond that small issue, I have few complaints with Oolite.

In terms of development, I think Giles' current strategy is definately the best one-- take everything thats worth taking from the Frontier games, and leave them alone. I definately would hate to see newtonian physics! If you want that, play Terminus (or FFE).

And you know, when Braben gets around to actually making this game, it will probably be more of the Frontier-ilk than ELITE.