Shaders’ Outpost
Moderators: winston, another_commander
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.
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.
...and keep it under lightspeed!
Friendliest Meteor Police that side of Riedquat
Far Arm ships
Z-ships
Baakili Far Trader
Tin of SPAM
Friendliest Meteor Police that side of Riedquat
Far Arm ships
Z-ships
Baakili Far Trader
Tin of SPAM
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
I strongly recommend not using macros like that. Since 1.73, the default shader uses two functions – CalcDiffuseLight() and CalcSpecularLight() – instead.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
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
- JazHaz
- ---- E L I T E ----
- Posts: 2991
- Joined: Tue Sep 22, 2009 11:07 am
- Location: Enfield, Middlesex
- Contact:
Closest to what you want is here, but its quite technical. Ahruman wrote it!Arexack_Heretic wrote:Could someone give me a redirect to a howto for normal maps?
I've been looking, but not very successfully. thanks:)
JazHaz
Thanks to Gimi, I got an eBook in my inbox tonight (31st May 2014 - Release of Elite Reclamation)!Gimi wrote:Maybe you could start a Kickstarter Campaign to found your £4500 pledge.drew wrote:£4,500 though! <Faints>
Cheers,
Drew.
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
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'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
Riding the Rocket!
- DaddyHoggy
- Intergalactic Spam Assassin
- Posts: 8515
- Joined: Tue Dec 05, 2006 9:43 pm
- Location: Newbury, UK
- Contact:
I think Griff has done one, or has previously linked to one done by somebody else.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
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...
Oolite Life is now revealed hereSelezen wrote:Apparently I was having a DaddyHoggy moment.
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
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.
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.
Riding the Rocket!
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.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.
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.
E-mail: [email protected]
- Griff
- Oolite 2 Art Director
- Posts: 2482
- Joined: Fri Jul 14, 2006 12:29 pm
- Location: Probably hugging his Air Fryer
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: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
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
Code: Select all
materials =
{
"myship_diffuse_texture.png" =
{
normal_map = "myship_normal_map_texture.png";
emission_and_illumination_map = "myship_glow_map_texture.png";
emission_modulate_color = (160, 255, 160);
illumination_modulate_color = (180, 180, 200);
};
};
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
There has never been a released version where you could apply normal maps with custom shaders but not the material model.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
It works in simple mode too.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)
E-mail: [email protected]
- Killer Wolf
- ---- E L I T E ----
- Posts: 2278
- Joined: Tue Jan 02, 2007 12:38 pm
Re: Griff's normalmapped ship remakes
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
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
- Griff
- Oolite 2 Art Director
- Posts: 2482
- Joined: Fri Jul 14, 2006 12:29 pm
- Location: Probably hugging his Air Fryer
Re: Griff's normalmapped ship remakes
@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
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…
Code: Select all
varying vec2 vTexCoord;
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':
Code: Select all
textures =
(
"griff_coriolis_dock_diffuse.png",
"griff_coriolis_dock_normal.png",
{name = "griff_coriolis_dock_effects.png"; repeat_s = "yes";}
);
Code: Select all
uniforms =
{
uColorMap = { type = texture; value = 0; };
uNormalMap = { type = texture; value = 1; };
uEffectsMap = { type = texture; value = 2; };
uTime = "universalTime";
};
Code: Select all
// Uniforms from Oolite
uniform float uTime;
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)
Code: Select all
// Set up a float to add to the texture coords in order to scroll them
float counter = mod(uTime * 0.25, 1.0);
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)
Code: Select all
// set up the scrolling light map
float ScrollingIllumMap = texture2D(uEffectsMap, vec2(vTexCoord.s - counter, vTexCoord.t)).g;
Code: Select all
vTexCoord.s - counter
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
Code: Select all
float ScrollingIllumMapmask = texture2D(uEffectsMap, vTexCoord).r;
Code: Select all
vec3 ScrollingLampColour = vec3(0.7368, 1.0, 0.4736);
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)
Code: Select all
(ScrollingIllumMap * ScrollingIllumMapmask)
Code: Select all
* ScrollingLampColour
Code: Select all
color += (ScrollingIllumMap * ScrollingIllumMapmask) * ScrollingLampColour;
Last edited by Griff on Wed Apr 27, 2011 7:00 pm, edited 2 times in total.
Wiki homepage for my OXP: http://wiki.alioth.net/index.php/Griff_Industries
- Killer Wolf
- ---- E L I T E ----
- Posts: 2278
- Joined: Tue Jan 02, 2007 12:38 pm
Re: Griff's normalmapped ship remakes
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.
- Staer9
- ---- E L I T E ----
- Posts: 570
- Joined: Fri Feb 18, 2011 4:53 pm
- Location: Hatfield, Hertfordshire (poor industrial)
Re: Shaders’ Outpost
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?
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?
Code: Select all
materials =
{
"accipiter_no_shaders.png" =
{
diffuse_map = "accipiter_diffuse.png";
emission_map = "accipiter_lights.png";
effects_map = "accipiter_effects.png";
};
vertex_shader = ahruman-generic-accipiter.vertex;
fragment_shader = accipiter-effects.fragment;
};