Oolite Bulletins

ramon wrote:

@Eric. Do I need to redo the Anaconda (at some point) with less Vertices, or add a 'requires.plist'?

I'm not Eric, but i'd say it depends on what you have in mind. If your Anaconda should be compatible to the last stable release (1.65) then you have to change it. But I wouldn't care so much about this version anymore, because the dev-team has already stated a few times that they are going for a new stable release. But in all cases a requires.plist is a good choice.

btw: Looks great .-)

I've added a 'Transporter' (not yet included in Dizzy's all-in-1 bundle)

i've tried a different way of blinking the lights in this oxp as i noticed the shuttle animated lights didn't seem to be appearing in a_c's screenshots.
The shuttle uses a 2 frame animated sequence for it's lightmap (frame 1 has lights, frame 2 has none) and some stuff in the vertex shader to swap between frames, maybe this is too complex for some vidcard vertex shaders?
The transporter shader uses a sin value of the game clock and a 'if.. then' check on the value to only draw the lights when the value is >0.5, seems to be OK for a 2 frame sequence, and is being done in the fragment shader - don't know if this is a bad thing to do, are 'if.. then..' bits of code best avoided in fragment shaders?
edit: changed the fragment shader to use Ahrumans suggested method for animating the glowmap (see posts below)

Griff wrote:

I've added a 'Transporter' (not yet included in Dizzy's all-in-1 bundle)

I like a lot! (fixed your img link...)

thanks D_H!

Very very nice

Griff wrote:

The transporter shader uses a sin value of the game clock and a 'if.. then' check on the value to only draw the lights when the value is >0.5, seems to be OK for a 2 frame sequence, and is being done in the fragment shader - don't know if this is a bad thing to do, are 'if.. then..' bit's of code best avoided in fragment shaders? *lights Ahruman signal*

“If” is indeed best avoided. However, GLSL provides a lot of ways to avoid it, like mix(), step(), smoothstep(), clamp() and of course min() and max(). In this case, step() is probably what you want – step(0.0, sin_term) will give you even intervals, step(0.5, sin_term) will be 1.0 about 1/3 of the time (i.e., the portion of time sin(x) > 0.5).

Thanks A, i'll update the shader. y'know i'm sure you've told me this before, i might even remember it one day
edit: awesome, it also works for that flickery blink on/off thing the shaders do on the lights when the ship is nearly dead, well, that's my weekend sorted, going back through all the ship shaders and making the code change, woo!

Another one crossed off the list.

Thanks Griff... it looks really good.

Griff

You’re aware of the problems I’ve had with the latest ATI drivers. Been testing using 10.1 again.

The Cargo Cannister, the Anaconda, the Escape Capsule and the Transporter appear to look as they should.
Very strange… all the other ships are still bare of colours and decals, but the above four all look right.
Are they using less shaders or anything different? They are the newer additions, aren’t they.

<edit: the Thargoids look okay as well, now. (Not sure about the Orbital Shuttle… I’ll do some more testing).>

Any thoughts…

hmm, well i tweaked the anaconda recently to fix some bad things i was doing in the shader but i haven't really touched the other oxp's for ages.

i've just this minute re-uploaded a new version of the orbital shuttle to change the code used to animated the lightmap to the same method as the transporter, it should hopefully make the effect more compatible with more video cards as i notice the effect was missing when a_c posted that series of lovely screenshots of it a while back

i usually always try to remember to run the final png's through the pngcrush program using these settings
that wouldn't strip out any information from the png that might cause ati cards some problems do you think?

As soon as you start talking 'code' I'm lost. Sorry.
About to test the new Orbital Shuttle now.

The Orbital Shuttle looks fine as well now... great.

Griff wrote:

i usually always try to remember to run the final png's through the pngcrush program using these settings

Code: Select all

pngcrush -rem cHRM -rem gAMA -rem iCCP -rem sRGB

that wouldn't strip out any information from the png that might cause ati cards some problems do you think?

No, I don’t. :-) The card’s drivers never see this stuff, they just see the uncompressed image. (Getting rid of them is a good idea anyway, for size reasons.)

Who's this handsome devil?
well, you would not believe how hard i found it trying to get the black bits in the decal to show up in the final texture, my brain is melting! hopefully my foolhardy idea to get custom player decals on the ships might just work (except on the moray - there's no spare decal texture available because of the frothy texture thing it has going on)

Oh that's lovely... I've already got my decal lined up. Black and white as well.