full GLSL implementation in Blender?Calling GE developers

Hi all, just a question… now that Zaghagi has made the custom filter nodes the use GLSL funtions like this…

  • bgl_RenderedTexture[LIST]
  • usage: uniform sampler2D bgl_RenderedTexture;
  • bgl_TextureCoordinateOffset
  • usage: uniform vec2 bgl_TextureCoordinateOffset[9];
  • bgl_TextureWidth
  • usage: uniform float bgl_TextureWidth;
  • bgl_TextureHeight
  • usage: uniform float bgl_TextureHeight; [/LIST]
    Does this mean we can use them in our own GLSL shaders… that are not attached to the custom filter actuator?

Also can we now use multiple passes and render to texture in our GLSL shaders too? If the answer is yes then we can finally make reflective water and real-time shadows… possibly?

If the answer is NO…

I would like to kindly propose/ask iether Zaghagi, Ben2610, Ovidui to fix the game engine so it can support the left out GLSL functions that Snailrose never got round to implementing. I might be right in assuming that doing this won’t be very hard or take too long… pls. correct me if I’m wrong here.

It would a an awesome quick fix to the BGE allowing for some sweet GLSL shaders. What do you think guys?

I am for it too :). But some documentation of this feature would be nice too ;).

There is a common misunderstanding around here of a “full GLSL implementation”. There is no such thing. GLSL is either implemented or not implemented and multipass has nothing to do with GLSL what so ever. Plus the render to texture thing is just a sampler and samplers can be used in any GLSL shader if they are bound in the program.

And the answer to your question is no.

It would be difficult to make multipass accessable to everyone since it would either need a complex GUI or multipass material support in blender. It might be a bit tricky code wise too. Not as tricky as qui wise though… The best solution would probably be python controllable multi pass.

The render to texture is not bound through the rendering of normal objects so you cant use the render to texture in normal shaders. It would slow down the engine too much if it would be bound for every rendered object.

yeah that’s what I suggesting…

The best solution would probably be python controllable multi pass.

yeah I definitely wouldn’t be wanting render to texture for all objects… so I’m suggesting being able to use multiple passes and render to texture via python… no complicated interface to bother designing etc.

I was of the understanding that currently in blender we can’t use the render to texture type samplers… so would it be hard to get this working via python?

The render to texture is just a normal texture, so basically the devs just have to make a some kind of flag that idicates that the object uses the render to texture, and it gets bound for usage in the shader.

As for multipass, that requires a bit more work…

thanks for the info… :wink: how’s your project coming?

Hi, guys.

What exactly is possible to do with the custom 2D filter feature? I have seen some predefined things like blur, sobel, etc., which blurred the scene or were changing screen colors. Is there something else it can do? Can it be used only on some scene objects, because it really slows the games down?

Thanks for reply :).

Post processing is done on the whole scene, not on individual objects so the time it takes only depends on the complexity of the GLSL shader that does the post processing (or possibly any openGL code that does the post processing).

With the custom 2d filter feature you can use a GLSL shader to change the color data of the rendered scene. Imagine that the scene is a picture. You get access to the color data of the whole picture and you can change it at will.

Oh, I see. So it is working like filters in console emulators. Thanks, toonist .

the only reason why your game is slowing down is because you are constantly activating it, try doing this instead:

this executes it only once, and can be done with any other sensor.

Thanks, nicolasbrown, I know about it :slight_smile: - but in complicated scenes it is a significant slowdown.

But we should go back to topic.

I have found some articles and GLSL examples. I have seen some particle effects, realtime water, reflections, bumpmaps, … . These functions looks really “tasty” :).

If it is hard to implement GLSL in BGE, it is possible to make some python classes or functions, which will mimic these features? (Please correct me if I am talking silly things.)

I would appreciate, if I could apply motion blur only on some object in game.

you can apply motion blur on individual objects right now by using the motion blur filter… it’s one of the choices under the filter actuator…

Are talking about motion blur 2D filter actuator? If yes, so if you apply this, it appears on every object in the scene, which is moving. As toonist said it works with whole rendered scene as an image. I just tried to be sure :).

I thought, if there could be a way to make some python commands, which would apply that filters only on some objects (this could reduce the memory or cpu these filters uses).

oh … I never tested it out… wasn’t sure how it worked… I assumed incorrectly it was on a per object basis. Yeah being able to do it on single objects would be sweet… properly a bit complex to get working… but they could easily get the render to texture sampler up and going so we could use it in our GLSL shaders… using python of course…

In this thread, there is a blend file with cel shading effect on material. It can be used on chosen scene objects and uses GLSL vertex and fragment shaders.

I am not a GLSL specialist, but your own shaders could be used this way too, or not? I am very curious what else can be done with GLS language in BGE. Is there any documentation on these functions? Or docs about Zaghaghis 2Dfilters?

I think if you search the forums you will find several examples of GLSL shader usage.

Reiko… Zhaghagis’s docs… about the filters

Cool examples of filters made by mpan3

the official wiki about GLSL

the official GLSL forum where you can ask questions and get answers that are so technical they sometime leave you more confused than before… :wink:

Thanks, kirado :).