Oolite Bulletins

Nic wrote:

@winston: Do you know why on startup the intro/demo screens that show the spinning Cobra and other models aren't looking quite right.

Might be a good one to point at aegidian - the lighting models ARE different. Is this reproducable on different hardware, would be my next step. Not all OpenGL drivers or hardware is created equal!

Hrm. Reminds me. I really must start going through the Red Book again at some stage.

Thanks for that Ryke, but on a scale of my input into this, I am "mostly harmless" you guys, yourself, A_H, Galileo, Selezen, Murgh, Dajit, Nic, TGHC, Winston, and so many others are "Deadly" with your input. Nic knew the answer all along, 'cos he is a wizard, but sometimes, people just need "reminding" of what they do know. If anything, if it does work, its an example of how effective bulletins are. Even the lowliest can contribute.............Oops!! slipped off my soapbox.

By the by, i created, for something to do, an Oolite Logo in Wings 3D,



It has 481 poys, 966v edges, 491 vertices, i can create the .Dat file no probs, but Oolite bombs out whenever it goes to look for this image, deploying a parachute. Is this image too much for Oolite, or should i look for a problem elsewhere?

The poly count and the face/edge count may be exceeding the limits. You might also have dodgy edges or free floating vertices. Do a cleanup on the model and try and take out any non-essential edges. Don't worry about smoothing it - this takes up too many polys and can look a bit naff in Oolite anyway.



Oolite Logo: 950+ polys.
Elite Logo: 10,000+ polys.

The Elite one is converted from a 3DS model, and there are two copies of each poly in many places. The head of the logo is the most polygon packed, and the writing is a joke. I'm in the process of fixing the writing, but I might just delete it.

These were drawn for the Elite Wiki logo.

@winston:

. Is this reproducable on different hardware, would be my next step. Not all OpenGL drivers or hardware is created equal!

Very true! Just tested it on another machine and everything looks great. So all is well. I'll go upload a release.

-Nic

milinks, 'mostly harmless' or not, you *did* point out what a lot of people were overlooking.
(And BTW: I don't know *at all* what this is about, me know nothing wrt Windows stuff beyond troubleshooting other people's computers sometimes, heh)

@ Selezen

Those are amazing! I don't suppose i could be cheeky and ask you to post the logo, if you have the Wings obj file, it would help me a lot. I could look at it and learn from it. I'm looking at incorporating spinning logos on my docked screens OXP. Can you recall on such games as Wing Commander etc when news items etc came up, they had a smal spinning logo in the corner? I'm trying to do something like that. Whats the general thoughts on this?

Heh - yeah, of course. I'll post you the Oolite one, but I'd rather try and fix the numerous problems with the Elite one before posting it anywhere. There's no way in hell that either of them will work in Oolite at the current poly count though - they need to be under 500 polys to work.

Ironically, I do actually have a 3DS object of the Confederation logo from Wing Commander - I used it to make my really crap Wing Commander site about 10 years ago!! If I find it I will convert it to Wings and chuck it at you too.

I'd love to see the Elite logo incorporated into a game the way it was meant to be (at least according to the Imprint novella), as the official symbol of GalCop.

milinks wrote:

By the by, i created, for something to do, an Oolite Logo in Wings 3D

That's the sort of thing the Lave monument OXP needs...

Another minor graphical problem:

Just been trying to get lave.oxp working. It doesn't work currently because lunar.png having 1 plane is causing problems.

In getTextureNameFor in TextureStore.m it will crash on:
With lunar.png, n_planes == 1, and that causes a crash. n_planes == 3 or n_planes == 4 doesn't cause a crash. Loading lunar.png in mspaint and resaving it add means it get saved with 4 planes which allows the OXP to work.

Anyone got any ideas, a workaround etc as to why it might not work? Could it be hardware specific?

-Nic

It was sloppy programming on my part - assuming texture images would be either RGBA or RGB formatted.

I'm working on a fix.

milinks wrote:

It has 481 poys, 966v edges, 491 vertices, i can create the .Dat file no probs, but Oolite bombs out whenever it goes to look for this image, deploying a parachute. Is this image too much for Oolite, or should i look for a problem elsewhere?

Let me just look this up in the new Dry Dock documentation… ;-) Ahh: ”Oolite is incapable of loading models with more than 320 vertices, 512 faces or 8 materials.” A slightly more polite way of telling you when you’ve exceeded the limit might be nice.

Selezen wrote:

Don't worry about smoothing it - this takes up too many polys and can look a bit naff in Oolite anyway.

Smoothing doesn’t use up any polygons, it only affects lighting calculations.

Nic wrote:

Another minor graphical problem:

Just been trying to get lave.oxp working. It doesn't work currently because lunar.png having 1 plane is causing problems.

In getTextureNameFor in TextureStore.m it will crash on:

Code: Select all

if (n_planes == 4)
				glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texture_w, texture_h, 0, GL_RGBA, GL_UNSIGNED_BYTE, texBytes);
			else
				glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texture_w, texture_h, 0, GL_RGB, GL_UNSIGNED_BYTE, texBytes);

With lunar.png, n_planes == 1, and that causes a crash. n_planes == 3 or n_planes == 4 doesn't cause a crash. Loading lunar.png in mspaint and resaving it add means it get saved with 4 planes which allows the OXP to work.

Anyone got any ideas, a workaround etc as to why it might not work? Could it be hardware specific?

-Nic

Frankly, this is down to Oolite’s texture-loading code being really crap. The Cocoa loading code is of a type that comes up on the mac-opengl mailing list from time to time under the heading of “don’t do this”, and the SDL code squeezes sdl_image into the Cocoa code.</flame> New texture loading is one of the things I’m procrastrinating on. I seem to be stuck in an unproductive phase. :-/

Still, the fact that you’re getting n_planes == 1 suggests that this may be the source of some of the problems related to lave.oxp’s moon. It’s happening because the texture is greyscale. Your fix converts it to RGB. (The simplest code fix would probably be to recognise the case of n_planes == 1 and use GL_LUMINANCE instead of GL_RGB/GL_RGBA.)

Committed r306 which should have that texture (and Lave.oxp) working properly.

Ha, Giles managed not one but two replies in the time I was writing mine, as well as a code fix. Maybe I should spend more time coding and less time bitching. :-p

Mmm. But you're right about the texture loading. Now we're on the same page (GUSTO) howzabout fixing my poor old code up?

Right after I rejigger the sound channel queueueing mechanism. And do all my getting-back-on-the-internets-after-a-week-stuff. And finish this gradient backdrop control I’m writing for the Dry Dock inspector.