Normal Pass for Custom GLSL Filters

Is there a way to make the BGE renderer perform a normal pass for use with custom 2D filters? And if it already does, what is the name of the sampler? I tried the following as a test, and it simply makes everything appear white:

uniform sampler2D bgl_NormalTexture;

void main()
{
    gl_FragColor = texture2D(bgl_NormalTexture, gl_TexCoord[0].xy);
}

It’s odd, because no error shows up in the Blender console. Also, if anyone knows of a place where a list of all the BGE sampler names is, I would love to see it. Thanks!

I think there’s not actually any sampler that allow you to get the normal pass, but I think you can calculate the normals using the depth buffer, martinsh made an example some time ago, but I don’t know where is it.

Really? I see. I figured it might be possible to calculate the normals from the depth buffer, but to my knowledge, it’s slower and slightly less accurate… Shame. :confused:

I’ll look into using that method, but if anyone has any other information, I would appreciate it. I was also considering it might be possible to make an environment map to simulate a normal pass, but I don’t know of any way to make it render everything that way programmatically…

Can you mix GSL with Nodes? (game nodes)

if so you could always apply your code, and then get the normal pass from a node setup?

You can get the normals via vertex shader. Will post code when I’m home.
Carlo, the normal buffer you’re talking about is for 2d filters.
BPR, Nodes are GLSL :wink:

Sorry, I actually am talking about 2D filters. :stuck_out_tongue:

Still, I’m glad you said that, because I just realized I might be able to cycle through all the objects and temporarily apply a GLSL shader that just renders normals. That could work, right?

Oh! Here’s a deferred shading example by martinsh that icludes a void calculating normals.

Ah, I think I remember seeing this now. And yeah, as I thought, that approach has a number of shortcomings and is pretty slow. I believe this was one of the things that Kupoman wanted to fix with Harmony. It’s a shame that the BGE seems to be a bit of a low priority in development… :frowning:

He said in another thread he is still trying to figure out a way to include harmony, that was less hacky then harmony.

I think its in Agooses hive thread.

Actually I like them, and I like python.

I think they really needs some improvements though.

#1 accept a property as a input in fields

#2 Color coding in logic editor, for noodles and for boxes - along with ‘hide all bricks by color’

#3 SetProperty on sensor True

RaySetProperty(target=hitobject)------and------Steer to target

It just needs some serious love.

also, “leave last highlighted noodle on top”

or even 'Light wave down noodle"

Think of the logic bricks like possibly threaded electronics

and the noodles as wires. We need better electrician tools,

imagine being a electrician and all wires were black :frowning:

I think the more like making a game is like playing one the better.

Oh, I totally agree. I never said I dislike the logic bricks themselves. Just because of the odd terminology used, it’s fairly clear that the system was designed with little knowledge as to how a game engine works. For example, the “near” and “radar” nonsense. There are a lot of redundant nodes that all do minor variations of the same thing. It just feels like it’s severely lacking in certain important sensors and actuators, and it doesn’t feel quite like it was designed with games in mind, but rather something more like computer simulations.

it seems to me the idea was to export to something like a rasberry py,

but none of the tech existed

it also looks like it was designed to be threaded and never was.