Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Fewes

Pages: [1] 2
I am drawing the same thing, the black part is bigger because the sRGB conversion seemingly happens twice. Once when the texture is loaded and once when drawing to the RenderTexture. Disabling sRGB conversion on the texture fixes this, but I'm not sure if this is intended behaviour or not.

Showing the results of #1093

Hi there! I was very excited to see that support for native sRGB handling was added to the repo a few weeks back. After doing some testing however I noticed that if you use sf::RenderTexture to draw anything anywhere between sampling the texture and drawing to the window, you get terrible color banding.

Here are three images rendered with different setups to illustrate the problem. The texture drawn is a simple 8 bits/channel gradient.

1. Texture is drawn to the RenderTexture via a Sprite, then the RenderTexture is drawn to the window via a Sprite.
ContextSettings.sRgbCapable is set to false and Texture.setSrgb is set to false.

2. Texture is drawn directly to the window via a Sprite.
ContextSettings.sRgbCapable is set to true and Texture.setSrgb is set to true.

3. Texture is drawn to the RenderTexture via a Sprite, then the RenderTexture is drawn to the window via a Sprite.
ContextSettings.sRgbCapable is set to true and Texture.setSrgb is set to true.

As you can see the result suffers from banded colors, as expected of when storing gamma decoded values improperly.

I'm not that high on color space but it seems there is something missing where the RenderTexture should convert the input and output when rendering, just like the window does. I'm not sure if it can be remedied somehow, but I thought I should bring it to light.

Here's the code for the program shown above. Change the boolean at the top to toggle between using sRGB conversion or not.

#include <SFML/Graphics.hpp>

int main()
        bool srgb = true;

        sf::RenderWindow window;
        sf::VideoMode videoMode;
        videoMode.width = 720;
        videoMode.height = 405;
        sf::ContextSettings contextSettings;
        contextSettings.sRgbCapable = srgb;

        window.create(videoMode, "Linear Color Space Testing", sf::Style::Default, contextSettings);

        sf::Texture texture;

        sf::Sprite sprite;

        // Make sure the sprite fills the screen
        float scale_x = (float)videoMode.width / (float)texture.getSize().x;
        float scale_y = (float)videoMode.width / (float)texture.getSize().y;
        sprite.setScale(scale_x, scale_y);

        sf::RenderTexture renderTexture;
        renderTexture.create(videoMode.width, videoMode.height);

        sf::Sprite renderTextureDrawable;

        while (window.isOpen())
                // Poll events
        sf::Event event;
        while (window.pollEvent(event))
            // Window closed
            if (event.type == sf::Event::Closed || (event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Key::Escape))

                // Clear render texture
                renderTexture.clear(sf::Color(0, 0, 0, 255));
                // Draw gradient sprite
                // Finished drawing to render texture

                // Clear window
                window.clear(sf::Color(0, 0, 0, 255));
                // Draw render texture drawable
                // Finished drawing to the window


    return 0;

And here's the gradient texture:

SFML projects / Re: Screenshot Thread
« on: March 28, 2016, 08:58:16 pm »
Very good stuff as usual ;) Don't you think your project would deserve its own thread?

Thanks! I considered making a thread a while ago but figured I should get further along before I did. I'll take your post as a sign I've gotten far enough to make one now  ;)

SFML projects / Re: Screenshot Thread
« on: March 28, 2016, 07:26:26 pm »
I gave creating a velocity buffer / motion blur shader a go.

Video of it in action

SFML projects / Re: Screenshot Thread
« on: March 11, 2016, 02:06:39 pm »
Damn, that's really impressive. Love the things you can do in shaders, especially with stuff like lighting.
Can you give a little insight how you created the normal maps? Did you use some normal mapper or did you have them drawn by hand? Only asking this because they are extraordinary clean.

Thanks! They are actually created by baking 3D models down to textures:

SFML projects / Re: Screenshot Thread
« on: March 11, 2016, 09:37:02 am »
Fewes, wow, this is pretty good! Can you give us more details about what you did to make it so good? Shaders? Lots of layers?

Glad you like it! Really at the center of the renderer is the z info each object writes to a RenderTexture (which is also used for view transformation). There's several other buffers containing info used for the lighting as well as about 30 shaders doing various things; some small and some big.  :)

Here's a small breakdown of the buffers (just recently added normal mapped lighting):

Final scene:

Click for bigger image


Click for bigger image

Buffers (albedo, normals, depth, specular mask, gloss mask):

SFML projects / Re: Screenshot Thread
« on: February 25, 2016, 04:28:25 pm »
Been working on some lighting and effects for my engine recently. Decided to test it out with a foliage scene:

(Click for bigger image)

Video of it in action.

SFML projects / Re: Screenshot Thread
« on: January 11, 2016, 03:47:36 am »
Thanks for the kind words guys, I'm glad you like it!  ;D
Small update as well, I just added vertex coordinates to the OBJ loader (textured meshes ahoy):

Short video:

It's obvious that your "slicer" creates new topology when slicing. Even, in fact, new vertices at the slicing position. This seems to only be from the object's original vertices though as slicing through a slice seems to only be able to use the existing slice's vertices rather than creating new ones. This can be seen when slicing multiple times and at right angles where the slices that go through the previous ones don't line up as a straight line up as the slice would.

A very keen observation, however it is actually caused by something else! The slicing is actually fully dynamic and will create new vertices exactly where the "slice line" provided intersects the mesh but what you are seeing in the video is how the line, or rather I should say lines are constructed from the mouse position.

There are several lines trailing the mouse that go between the current mouse position and the mouse position some frames ago. When slicing the system checks the longest of these lines until it finds one that can perform a cut (at least two intersections points and it did not start from within the mesh) and then performs it.
The angle of these slice lines are compared to the smallest line (going from mouse position this frame to mouse position last frame) every frame and if there's too big a difference (think I have it set to 15° in the video) they are removed.

The higher the angle allowed the easier it is to do long cuts (especially with a mouse) but if the user makes a sharp turn with the cursor bits that are close together are often cut with different lines which becomes noticeable like you managed to spot in the video.  :)

SFML projects / Re: Screenshot Thread
« on: January 10, 2016, 05:17:01 pm »
Here's a little polygon slicing system I've been working on. It's capable of slicing any complex polygon without holes and can handle multiple cuts at the same time. It's also generating a 2D mesh for every new shape that's cut off.

Here's a video of it in action:

SFML projects / Re: Screenshot Thread
« on: June 06, 2015, 09:11:12 am »
That transition effect looks really cool, awesome how it works without any extra work  ;D

After implementing depth values for sprites I've been experimenting some with a fake 3D perspective effect (and order-independent draw sorting):

Short video:

Still needs a bit of work but it's surprisingly stable for how simple it is  :) (just a scale and position offset based on the depth value)

Graphics / Re: Storing data in RenderTexture alpha channel
« on: June 05, 2015, 04:41:05 pm »
That was indeed it! Setting the blend mode to None does exactly what I was looking for. Many thanks! :)

Graphics / Storing data in RenderTexture alpha channel
« on: June 05, 2015, 12:49:24 pm »

I've got some code set up for drawing to a RenderTexture instead of directly to the window to be able to run screen based shaders over the "world". This RenderTexture could be thought of as a scene buffer and in my case I do not need it to be transparent since all I do is draw it to the window in the end. This frees up the alpha channel of the RenderTexture which is great because I can use that to store a depth buffer in the same draw call, or so I thought.

Turns out that it doesn't behave the way you would expect, and somehow when I supply the RenderTexture to a shader the alpha channel is completely white and the alpha I set when drawing to it seems to be taken into account when sampling the RGB channels.

Here's the shader I use to write sprites to the buffer:
uniform sampler2D texture;     // Sprite texture
uniform sampler2D rt_scene;    // Scene render texture, which is what the shader is drawing to. I pass this in here so I can mix without setting the alpha
uniform float r_depth;         // Fixed depth value for every sprite
void main()
    vec4 color = texture2D( texture, gl_TexCoord[0].xy );
    vec4 sceneBuffer = texture2D( rt_scene, gl_TexCoord[0].zw ); // gl_TexCoord[0].zw are screen space texture coords
    gl_FragColor.rgb = mix( sceneBuffer.rgb, color.rgb, color.a );
    gl_FragColor.a = mix( sceneBuffer.a, r_depth, color.a );

Then when I draw the Render Texture to the window I also have a custom shader and do:
vec3 color = texture2D( texture, gl_TexCoord[0].xy ).rgb;
gl_FragColor.rgb = color;
gl_FragColor.a = 1;

And here's an image that shows the problem (the contents of the RenderTexture):

I've done some testing and it'd be my guess that the problem lies outside of the GLSL code but I'm not very familiar with things like OpenGL flags and the like, so I come here hoping someone might have an idea of what to do. Fixing this would bring about a pretty significant performance boost (and order-independent draw sorting(!)) so I would certainly appreciate it!


SFML projects / Re: Screenshot Thread
« on: May 06, 2015, 11:07:05 am »
Thanks guys :D

How does depth calculation work? Do you set a depth per layer or similar?

The way it works currently is I simply draw each sprite I want to have shadows/rim lighting on to a RenderTexture mask with the channels being used for different things. Areas that are not drawn to the mask are considered to be "in the background" and lights can be toggled between being in front or the middle of the two layers which toggles some effects inside the shader. It'd be quite easy to change the setup to write an actual depth buffer with this method which is something I'm planning on doing to see if I can move the shader to work on a more general setup instead of what is basically a 1-bit mask. If I manage to do so then having sprites inherit the depth of the layer they reside in would allow for some pretty cool things like being able to freely adjust the entire layer depth and have (hopefully) shadows and the like be updated in real time.

SFML projects / Re: Screenshot Thread
« on: May 05, 2015, 06:32:43 pm »
I'm working on a fully dynamic lighting system with the idea of it running without any extra textures such as normal maps and the like. After getting some help hunting down a performance hog I was able to optimize it and now my PC easily handles a ton of lights and sprites all being shaded with smooth framerates.

Currently it's just a test environment so I suppose the next step is start working on an actual game ;D

Pages: [1] 2