Oolite Bulletins

Quick test:
fixed the shaders in Vector 1.3 OXP (see Griff's post about "Ahruman's later shaders" and now they seem to work, clean Latest.log and now I can see the ship.

Griff wrote:

The shaders below set up a varying vec2 called vTexCoord to pass texture coordinates from the vertex to the fragment shader, texture coords are now set up using gl_MultiTexCoord0.st instead of gl_TexCoord[0].st, this seems to be more AMD friendly

Gracias Griff.

Griff wrote:

important note: if you copy and paste the above into your shaders, make sure you check for blank spaces after the \ at the end of every line in the light macro in the fragment shader (lines 74 - 79) - there musn't be any, if there are, your shader won't run and you'll have a whole load of errors in your log - basically nearly almost everyline in the shader will be flagged up as having an error in it

I strongly recommend not using macros like that. Since 1.73, the default shader uses two functions – CalcDiffuseLight() and CalcSpecularLight() – instead.

Could someone give me a redirect to a howto for normal maps?
I've been looking, but not very successfully. thanks:)

Arexack_Heretic wrote:

Could someone give me a redirect to a howto for normal maps?
I've been looking, but not very successfully. thanks:)

Closest to what you want is here, but its quite technical. Ahruman wrote it!

Yeah, thanks. I've 'read' that dissertation, without understanding much of it... the technical talk was actually less confusing than visual examples. hehehe
I'm more looking for a tutorial like step-by-step overview of how to create a simple (! I'm not planning on doing anything complex...yet.) normal map.
Or bumpmap for that matter.

I'll just muddle on a bit. :p

Arexack_Heretic wrote:

Yeah, thanks. I've 'read' that dissertation, without understanding much of it... the technical talk was actually less confusing than visual examples. hehehe
I'm more looking for a tutorial like step-by-step overview of how to create a simple (! I'm not planning on doing anything complex...yet.) normal map.
Or bumpmap for that matter.

I'll just muddle on a bit. :p

I think Griff has done one, or has previously linked to one done by somebody else.

See if there's still a demo version of CrazyBump out there - or get the normal map plug in for GIMP, that will help you make normal maps - but how to get them in to the model...

Say Griff,

would it be a bad idea to give my cargopods normal mapping etc,
system-resourcewise?

I had intentionally left them fairly simple, so that clouds of them would not lead to any slowdown problems,
but with the all the glowing debris clouds etc that are now possible, this concern seems a bit superceded by progress.

Arexack_Heretic wrote:

Say Griff,

would it be a bad idea to give my cargopods normal mapping etc,
system-resourcewise?

I had intentionally left them fairly simple, so that clouds of them would not lead to any slowdown problems,
but with the all the glowing debris clouds etc that are now possible, this concern seems a bit superceded by progress.

There are several different costs to consider in this sort of question: texture storage, drawing set-up costs, per-vertex costs, and per fragment costs.

If there are many objects with the same normal map, they’ll share the same texture storage; a cloud of objects is no different from a single object.

Set-up cost is slightly higher with the extra texture map, but this should be quite small. Using the standard shader, vertex cost is the same regardless of what material effects are used.

Fragment costs are proportional to the number of pixels covered by your objects in any given frame. Having lots of small cargo pods contributing a few fragments each is much cheaper than having a single object with many fragments. Fragment count will go up when a cargo pod is near the camera, but that’s when you want time to be spent making it look pretty, so that’s all right.

In short: as long as you don’t go overboard on texture resolution, it should be fine.

Arexack_Heretic wrote:

I'm more looking for a tutorial like step-by-step overview of how to create a simple (! I'm not planning on doing anything complex...yet.) normal map.
Or bumpmap for that matter.
I'll just muddle on a bit. :p

There must be some more in-depth posts about making normal maps somewhere on the boards, i've only managed to dig this one up though:
https://bb.oolite.space/viewtopic.php?t= ... &start=273
I've been making my normal maps using the Nvidia plugin for Photoshop on this page, http://developer.nvidia.com/object/nv_t ... tools.html - it's listed as "Adobe Photoshop Normal Map and DDS Authoring Plug-ins" - there's a link to a similar plugin for Gimp at the bottom of the page too.
I basically use the selection tools and the flood fill tool to paint out a greyscale height map on a set of layers above the usual colour texture layer, once i've completed that i just run it through the normal map generating plugin, see how it looks, if there's anything wrongjust step back a bit in the document history in photoshop, tweaks , adjust brightness & contrast etc then run it through the normal map plugin again.
The oolite bit of actually applying the normal map to the model has become a whole lot easier these days, you no longer need to write custom shaders (although oolite's shaders setting will need to set to full *i think* in order to see the actual normal map effect in game), it's all available using materials in the shipdata.plist for your ship, see this page on the wiki:
http://wiki.alioth.net/index.php/Materials_in_Oolite

and here's the example at the bottom of that page, modded a bit to have a normal map specified

Griff wrote:

The oolite bit of actually applying the normal map to the model has become a whole lot easier these days, you no longer need to write custom shaders

There has never been a released version where you could apply normal maps with custom shaders but not the material model.

Griff wrote:

(although oolite's shaders setting will need to set to full *i think* in order to see the actual normal map effect in game)

It works in simple mode too.

Moderator: this and the following two posts were copied from here.

That new Coriolis is just fkn outstanding.

can we (I!) have a ture on how the shaders do the running lights in the docking bay please? i love that, like the swirly Thargoid lights. and i want to nick it

@KW
It's not a very complex effect, i'm just not going to explain it very well and make it all seem a lot harder than it is! - it's done by scrolling a lamp intensity (or 'brightness' )texture and using a 'mask' texture to control where the lights appear.
Here's a copy of the effects texture used in the coriolis docking bay, in this example i've faded in the 'skin' texture a bit to help show how the effects map fits in place, also the UV borders are visible as light grey lines too, in the actual effects map the background needs to be completely black.

So basically what's happening is that the green pattern is the light intensity map and it constantly scrolls along from left to right, where it passes over a red dot a glow appears in the texture so you need to be careful how you lay out your Texture UV's - any part you want the lights to scroll over have to be laid out in straight line either horizontally or vertically in the UV map, this is probably the most important bit to keep in mind, if you get stuck on any of the shader code just post on here on in the shaders outpost thread and we can work on adding this effects into your usual shader code.

Right, we need a set of scrolling texture co-ordinates for the green channel and a set of static co-ordinates for the red channel (as we don't want the mask map to scroll along with the intensity map), we already have a set of static texture co-ordinates passed to us from the vertex shader… ….so we just need a modified set of coordinates for the green channel, we'll set up a repeating counter stored as a floating point number and add this to the texture co-ordinate for the green channel, this will give us our scrolling effect (it's the same as using the 'offset' filter in photoshop)

OK, first we need to specify that the effects texture ‘tiles’ itself horizontally otherwise it will scroll past once and that’s it, so we need to set repeating edges to on to ensure that what scrolls off one side reappears on the opposite side (we’re only going to scroll the texture sideways so we just need to switch on repeat for the texture 's' co-ordinate – more on texture co-ordinates later). We specify texture tiling in shipdata.plist, in the 'texture' section in 'shaders': Next we need access to the game clock, it'll be the basis for our counter, in shipdata.plist alongside our texture uniforms we'll also set up an uniform called 'uTime' and link it to the 'universalTime' data from Oolite's game engine http://wiki.alioth.net/index.php/Shader ... :_uniforms in the shader we need to call in this uniform, just setting it up in shipdata.plist isn't enough, so up near the start of the shader code you list your uniforms, i'll just do the uTime one here to keep things simple Great, now we have access to a timer we can run it through a mod command to get a repeating set of numbers we can use to offset the texture co-ordinates by - my grasp of maths is total crap, i don't really know what ‘mod’ does - hovering the mouse pointer over it in rendermonkey gives the following tool tip pop-up…

mod(x,y) Modulus. Returns x - y * floor (x/y)

…i don't know if that means anything to you but it certainly sails over the top of my head, all i know is that instead of just using the game time to offset the texture by (which would be a number that started at 0 and kept counting up and up and up) using mod on the game timer gives you a smaller set of numbers that start somewhere around 0.0, count up for a bit then return back to roughly 0.0, perfect for what we need, here’s the code in the shader (I just noticed the code in the shader in the coriolis oxp is over fiddly and can be simplified, I’ll carry on here using the simplified code and update the oxp to match a bit later) uTime counts up a bit too quick making the lights scroll by too fast, so multiplying it by 0.25 slows it down to quarter speed which looks a lot nicer, I think the 1.0 sets the upper limit on the numbers so this bit of code gives floating point numbers in the range of 0.000000 to 1.000000 which is perfect for us as it matches UV texture space exactly.

now that we have our texture offset counter, lets set up our scrolling 'lamp intensity' map, we’re only using 1 channel for it (the green channel) so we can store it in a floating point number

We want the texture to scroll from left to right so we only need to manipulate the ‘s’ texture co-ordinate (s,t,p,q are used when referring to textures coordinates in openGl, we’re only using 2D textures here so we only need to deal with the ‘s’ and ‘t’ co-ordinates , ‘t’ is the vertical co-ordinate)
we’re storing the green channel (the .g at the end of the line) from the uEffectsMap texture as a floating point number called ‘ScrollingIllumMap’ and we’re subtracting our counter value from its ‘s’ (horizontal) texture co-ordinate… …to scroll it along left to right (you could add the counter value to the s coordinate if you want the texture to scroll in the opposite direction) leaving the t (vertical texture co-ordinate) untouched

OK, we’ve got our scrolling map, so now we just need our static 'mask map' to let us control light placement, we’ll use the red channel and leave its texture co-ordinates unmodified, we’ll store it all in a float called ScrollingIllumMapmask Nearly done now, we’ll need a lamp colour for our lights so we’ll use a vec3 to store the colour in (we use a vec3 because we need red green and blue values to describe a colour), we'll call it called ScrollingLampColour All we need to do now is add these elements into the final colour
First multiply the scrolling green channel (ScrollingIllumMap) by the static red channel (ScrollingIllumMapmask) to calculate the light brightness (multiplying by the red channel means that anywhere in the map that there isn’t a red pixel returns a 0 for the light brightness so we can control where the lights will appear by only putting red dots where we want lights) Next we just multiply our light brightness value by our Lamp Colour to get the final result The line in full looks like this ‘color’ has already been calculated further up in the shader using the ‘skin’ texture maps and lighting information, we’re just adding the light maps in at this point and it’s important that this is done after the lighting from the system ‘sun’ has been calculated otherwise you get shadowing on your glow maps which spoils the effect that they are emitting light

many thanks Griff, gonna save that off and have a play. i'm working on two new stations for an OXwhatever and would love to get an effect like that working.

If I use this code in the shipdata with these shaders:
ahruman-generic-accipiter.vertex (a renamed version of the ahruman-generic.vertex used in the griff rocket)
accipiter-effects.fragment (a renamed version of griff-rocket shader)
will it work?