Progress report

[JensAyton]

Now that I’ve hopefully fixed the sound bug¹, I’ve got back to redoing the texture code.

I’ve created a branch (new-texture-model) based on the current trunk and added in my new texturing code from an old local copy. I also found the issue which was causing the font texture to fail to load, and worked around it². It is now possible to play with mip-mapped textures, currently only on the Mac. I should be able to adapt the old SDL loading code.

Asynchronous (threaded) texture loading also works. However, there is unnecessary delay in the process, resulting in objects appearing white for a frame or two, mostly during startup. This can be fixed by a more object-oriented approach to meshes (my next project) and by preloading the font texture at startup.

The “object-oriented approach to meshes” thing will also lead to a situation where textures that aren’t in use can be unloaded, meaning we can put a size cap on the texture cache.

Some of the stuff I want to do for meshes will be lifted from Dry Dock, and I want to improve that code, so I’ll work on Dry Dock for a bit.

[EDIT: Actually, I’ve already done that bit of Dry Dock. Whaddya know. Maybe I ought to fix the one bug that’s stopping me from making a significantly improved new release, though.]

¹ Audio playback units (“channels”) were being detached from the mixer in the CoreAudio rendering thread. This failed if another thread was currently working on the AudioGraph, i.e. another channel was being attached. This was a pure thinko of mine which I caught a couple of weeks ago, but my initial attempts to fix it caused new problems.
² By disabling mipmapping for non-square (but still power-of-two) textures, which is somewhat unfortunate. I have to research the proper procedure here.

[aegidian]

Excellent! When you merge back to the main trunk please make sure it's all somewhat better documented than my code!

[JensAyton]

Before:

After:

Texture used:

Eventually (with certain featuers implemented) the test model will use the same textuere on each panel; where the cross is, it’ll be without mip-mapping, for side-by-side comparison. This will be achieved in shipdata.plist as follows:

Code: Select all

"model-options" = {
    materials = {
        "mipmap-test-not.png" = {
		    "allow mip-mapping" = 0;
			texture = "mipmap-test.png";
		};
    };
};

Other options I’m expecting to implement are “specular color” and “specular exponent”, allowing for shiny surfaces. This will work best on relatively dense smoothed meshes, at least until per-pixel lighting and/or normal mapping is implemented… What other material options would OXP makers like to have?

Thanks to Murgh for the ad droid AI. :-)

[winston]

For those who don't know what mip mapping is, Wikipedia:

http://en.wikipedia.org/wiki/Mip_map

[winston]

It is now possible to play with mip-mapped textures, currently only on the Mac. I should be able to adapt the old SDL loading code.

Perhaps the SDL-OSX build should be revived in GUSTO so you have something to test with. Currently, it's in a bit of a state of disrepair (I never got it to work either - it built OK, but when you ran it it just hung).

[JensAyton]

Either that or I’ll get Linux working under VPC. I’ll focus on reworking model loading for now, though, and roll out the model and material improvements as one thingymajig.

[Murgh]

Thanks to Murgh for the ad droid AI.

you're very welcome. your test subjects flocking around you?

What other material options would OXP makers like to have?

specular powers sounds a cool thing to add. any plans to expose a way to adjust a texture's opacity?

[JensAyton]

Why, you want windows?

(Hmm, I wonder what happens if you give a model texture an alpha channel as it is. If that works, a master alpha component shouldn’t be a problem.)

[Murgh]

Why, you want windows?

(Hmm, I wonder what happens if you give a model texture an alpha channel as it is. If that works, a master alpha component shouldn’t be a problem.)

Why yes, among other things. FI, a racing-spectator-stand-ship would look considerably cooler with a smoked glass sub-entity cover with new texture possibilities behind. Domes on big asteroids etc.
just guessing from how exhaust plumes work that some things could be possible without any idea why..

[JensAyton]

Making things transparent is easy. Making things transparent without it looking shite is not.

Opaque objects are just drawn in any old order and left to the card’s Z buffer to sort out (I’ve seen this cause problems in Oolite, but they’re relatively minor). Transparent objects, however, have to be drawn in strict back – to – front order. This is less of an issue for glowing objects, which can be drawn with additive blending, as long as they’re drawn after all other objects.

[Murgh]

Making things transparent is easy. Making things transparent without it looking shite is not.

I'm sure you're right. are you saying it isn't worhwhile to pursue?

[JensAyton]

No, I’m saying it won’t be in the first batch of material options.

[Murgh]

righto.
you'll surely tell when you're good and ready, but I'm curious (and ignorant) of how these forthcoming features will present themselves. like, will they require additional visuals for blending, or will it be a matter of typing factors into a list, or.. by sliders in a Drydock?

[JensAyton]

I gave an example above of texture replacement and disabling mip-mapping in shipdata.plist. In the same way, you might specify:

Code: Select all

"model-options" = {
    materials = {
        shiny = {
         texture = "metal.png";
         "specular color" = (0.6, 0.4, 0.4); /* Reddish specular highlight */
         "specular power" = 64; /* Moderately diffuse highlight */
         alpha = 0.8; /* Slightly transparent */
      };
    };
};

Specular colour and power maps are possible, but definitely future material. :-)

Oh, I should probably add diffuse colour to the list of first-gen options.

[Flying_Circus]

Parallax mapping for producing the illusion of sustained damage would be good (especially on unshielded items like asteroids) - if it's easily supported, of course . You could have a situation where the asteroid miner's mining laser began blasting off 1 tonne chunks off the asteroid without having to destroy the entire rock; applying a parallax map for the damage sustained and spawning a few splinters would be enough to explain what the player sees. It's always seemed a little odd that Rock Hermits go to all the trouble of setting up home in an asteroid belt, that can be reduced to, perhaps 100 tonnes of mineral, maximum, in about tree minutes time. Mining lasers should be able to carve asteroids up into much more frangible material than that over a much longer period of time.

There's a parallax map plug-in for the Gimp, for those wishing to create parallax mapped damage zones, for their ships. I'm probably thinking way too far ahead, with this, but if a ship picked up "dent" decals, all over them as they went about their daily business (but especially in the vicinity of the fuel scoop intake, methinks) - dents that could only be removed by shipyard maintenence - players might resent the ship overhaul a little less, too .

If that's not easily supported, of course (and I don't think I'd need to be very shrewd, to guess that it's not), forget it. I'll be busy with me normal maps, nohow!

Edited from paragraph 2 onwards: I meant to write: 'there's a parallax-mapped plugin for the Gimp... and everything thereafter (regarding graphics, WRT ships taking a paikin'!). I've edited my original post but highlighted my errors (I had said 'normal mapped, which don't make sense, of course - well, not as much ). I'm still willing to confess I'm thinking too far ahead.