3DEE

[Deathbeam]

1DEE and 3DEE Textures (I couldn't resist )
Maybe not many beginners might know, but counter to intuition, OpenGL supports 1D and 3D textures in addition to 2D textures which SFML already exposes through its API. They won't be too useful when sticking to fixed-function 2D rendering, however they might be useful to those that make heavy use of raw OpenGL and shaders.

To demonstrate how a 1D texture might be used (this is still a very synthetic example), I altered the Storm + Blink Effect in the Shader example a bit to add a bit more... "chaotic energy" to it .

1D textures? For what they can be used, becouse from name it seems that they have only 1 dimension, and rendering 1 dimension is not possible. Hmm never heard about 1D textures, what is it and for what it is exactly? Becouse I am not skilled in C++ I can´t check your example to understand it But your 3D extension is epic, I agree that this should be atleast official extension for SFML.

[Lolilolight]

the direction in your class camera, it's the lookat vector

[eXpl0it3r]

1D textures? For what they can be used, becouse from name it seems that they have only 1 dimension, and rendering 1 dimension is not possible. Hmm never heard about 1D textures, what is it and for what it is exactly? Becouse I am not skilled in C++ I can´t check your example to understand it

I bet Google could've explained it to you in an understandable way...

1D textures have a dimension of x*1px. I'm not enough familiar with OpenGL or graphics in general to explain why they exist but I'm sure wikipedia can.

[Laurent]

1D textures can be used for color lookup in pixel shaders (it's basically an efficient way to pass an array, and to get interpolation between values for free). Example: toon shading.

[binary1248]

Major Update
Non-legacy rendering implementation for drawables
As already stated previously, I aimed to (re-)implement SFML's drawable implementation using only the modern, non-legacy OpenGL API. I think I've succeeded at that short of any undiscovered bugs I didn't find during testing. SFML will query OpenGL for the required functionality (shader support obviously, along with a minimum space requirement regarding uniform storage for storing light arrays and a minimum GLSL version of 1.30).

The idea is that the fixed-function pipeline is replicated in a Shader object that the RenderTarget will default to for rendering if the user doesn't specify otherwise. This means that certain attributes need to be sent per drawable to the vertex shader and currently they are hardcoded (position, color, texture coordinate, normal), so if you write your own shaders be sure to make use of them to interact with SFML. To ease the transition from the previous Shader API, I followed the naming scheme of the deprecated/removed built-in OpenGL attributes, e.g. gl_Vertex becomes sf_Vertex, gl_Normal becomes sf_Normal, gl_MultiTexCoord[0] becomes sf_MultiTexCoord0. All of the matrices are also provided as uniforms (model, view, projection, texture, normal). Lighting data is provided in a uniform array of structs as-is straight from Light and is used to compute per-pixel lighting. Maybe some time in the future, there will be a mechanism to choose from per-pixel and per-vertex lighting if the former isn't required.

A full list of uniforms and vertex attributes can be found in the Shader documentation. For anybody who is interested, the hard-coded shader source is inside RenderTarget.cpp.

As the previous posts, this is meant to be drop-in compatible with vanilla SFML. If something breaks that wasn't explicitly mentioned either here or in the documentation, report it as a possible bug. This was something I hacked together in a few days and although I tried to stay as clean as possible, the possibility of bugs slipping in is still there .

In the case that this completely and utterly breaks all of your code and would cost you an enormous amount of time rewriting all of your shaders and what not, there is the SFML_LEGACY_GL option/define in CMake that forces SFML to keep using the legacy pipeline. Be aware that if you use this you might not get to make use of any future additions .

Minor change to Light
I decided that it made little sense to provide a separate color for each component of a light as opposed to a single color and multiple intensities. There aren't many use cases where you would want ambient, diffuse and specular colors of the same light to be different. In the cases where it is required for some reason, one can simply create multiple lights instead. Currently, the specular component doesn't contribute anything. In the future, objects should be able to be assigned materials that provide surface information so that the proper lighting calculations among other effects can be performed.

The changes have all been pushed to GitHub.

With the initial de-deprecation done, this lays a nice foundation to implement other features that are widely used and that SFML still lacks to cater to more experienced 3D programmers. If anybody has ideas/concrete features that they and others might find useful, I'd like to know about them. I can only brainstorm out of my own perspective when it comes to this.

[Grimshaw]

Hey binary! Good job on this library! Looking awesome

I wonder if there are computers around with no shader support.. I keep seeing people trying out for shader support, but I guess its 99.9% of the times a yes Any further information on this topic? =)

[binary1248]

Shaders have been around for a long time (maybe even when 3dfx was still around) but the current incarnation of shaders only came to life when Nvidia/ATI noticed that developers needed more flexibility when transforming vertices and performing shading. GL_NV_vertex_program was probably the first extension that provided the developer a way to send a whole program (still written in assembly ) down to the vertex shader to execute on vertices. That specification was written against the OpenGL 1.2.1 specification, so you can guess how old it is. After that more and more programmability got exposed to the developer and eventually Direct3D's HLSL and OpenGL's GLSL showed up and that is what we are still using today.

The joke is, even now, probably around 14 years later, some "graphics processor manufacturers", yes... graphics processor, not graphics processing unit because they aren't units, still fail to implement the specification that it allegedly follows. If you are lucky, querying the GL capabilities yields that some certain feature isn't supported. Tough luck in that case, but at least you're not in for an adventure. If you are not so lucky, GL tells you that some certain extension is supported, but in reality, either it isn't at all, or that implementation is so buggy that you voluntarily stay away from it.

I listed 3 requirements for non-legacy rendering to be activated.

• Shader support: probably every implementation that came out of manufacturing after OpenGL 2.0 spec was released will claim it supports shaders. Whether the whole spec is implemented word for word, I don't want to find out. But there really isn't much you can screw up by writing an implementation that executes a simple vertex/fragment shader in software for example.
• Uniform storage: this one is a bit trickier. The lighting structures take up a certain amount of uniform space and the number of supported shader lights is based on the value returned from the implementation. This is also where the problem lies. If you query the implementation for the maximum number of uniforms it supports and go about calculating the absolute maximum that will fit into uniform memory, you will notice that the program successfully compiles and links, but when you run it, all hell breaks loose and you get all kinds of strange artefacts and maybe even just a blank screen. I tested on my own AMD card and I had to reduce the maximum number of lights to 50% of the theoretical maximum just so it would run properly and reduce it by another 50% just to have a bit of breathing room left over. This is a discrete GPU (HD5850) and still quite powerful even today. I cannot imagine what would happen on an IGP. It surely has less "uniform memory" if at all, since most of them siphon off system RAM, and how it is implemented, let alone what GL reports back is anybody's guess. I won't be surprised if 3DEE doesn't run properly on certain Intel chips considering how many other problems they seem to have.
• GLSL version: this might not be significant on first thought, since it is only a "programming language specification", but if you consider that some of the newly implemented keywords modify behaviour as well, it isn't just about whether you write out instead of varying for example but actually what happens when you try to trigger certain things through explicit keywords. It would be annoying as hell if some implementation reported that it supported a certain GLSL version, you compile and link it successfully and then notice something isn't right. To add to it all, just like in normal programming languages, vendors can choose to support more or less than what the spec says which is totally fun to write portable code for.

As you can see, testing for support by asking GL nicely is certainly a crazy thing to do since more often than not certain things are more random than one might like. This is probably also the reason why AAA developers tend to look up in hard-coded hardware tables what the capabilities of the underlying hardware allow them to do rather than asking nicely. This also lets them add the "Select best settings for my hardware" feature to their settings screens. If they really probed each and every capability, it would take them more than a few milliseconds to do, and it wouldn't even result in a functioning setup sometimes.

This is also one of the problems that OpenGL opponents (i.e. Direct3D fanboys) love to point out. DirectX has an emulation layer that tries to smooth out the feature landscape of the hardware that it abstracts. It can't make up for every single feature that might be missing, but the more mundane ones that OpenGL would still require a capability lookup for are transparently added via other means so the developer can assume it is present given some other preconditions. I can still remember long ago how Quake Engine based games tended to have more settings than DirectX based games and some of them even crashed and failed to start up without configuration file editing if you accidentally checked a box you weren't supposed to .

[binary1248]

Major Update
Vertex Array Objects
In an attempt to reduce the OpenGL API call overhead, I implemented a way for RenderTargets to batch attribute bindings into vertex array objects when they are supported and the requirements are set. Due to the way SFML goes about with its contexts, I couldn't make it into its own class because VAOs need to be bound to a context due to their inability to be shared between contexts. This means that the RenderTarget has to manage creation and destruction of VAOs on its own using a dynamic aging system, which was also a bit annoying to implement. Right now, each RenderTarget (and their context) has the ability to track up to 10000 VAOs meaning you can draw 10000 distinct drawables per frame before they will be continuously created and destroyed which will likely kill performance. Hopefully 10000 distinct drawables is enough . This is a limitation of SFML's context architecture and might change in the future.

Geometry Shaders
Added support to load in geometry shaders. Geometry shaders are optional so Shader objects can still be used without them. In order to keep the API clean, I chose to support only the core specification of geometry shaders as it doesn't add any new GL functions because all the needed information is encapsulated in the shader source.

Uniform Buffer Objects
Buffer objects (sf::VertexBuffer) can now be used as storage for uniform data in shaders. sf::VertexBuffer already had the option of storing generic (non-vertex) data previously and if you bind it to a uniform block in a shader, you can upload truly huge chunks of data in a single call just by modifying the contents of the buffer and rebinding it. Access to the data is as simple as accessing any other array type in the shader.

Light Optimizations
I moved the light component colour computations out of the shader and into the Light class so it only has to be computed once and can be used for every fragment without taxing the shader needlessly. The attenuation values are also packed into a vec4 now so that the shader compiler has an easier time vectorizing the attenuation computations that are performed inside the shader, and the number of glUniform calls using the non-buffer method is reduced.

General Optimizations
There are also many other optimizations that I implemented that reduce the amount of redundant operations that are performed as well as the number of OpenGL calls per frame. The vanilla shader API wasn't designed for frequent (multiple times per frame) setting of parameters and as one can see below, the call count exploded with the initial implementation.

For comparison, here are the function call lists running the 3d example per frame using CodeXL:
Legacy rendering using minimally modified SFML:


Initial non-legacy rendering:


Optimized non-legacy rendering:


It might look like the legacy rendering is still advantageous over the optimized non-legacy rendering, however keep in mind that glDrawArrays using client-side arrays was transferring huge amounts of data every frame along with having to reset the attribute source in every draw call which might lead to pipeline stalls on the GPU in some cases. In addition to that, the implicit data transfers that take place as part of the fixed-function behaviour would also have an effect but not show up on the list. The performance difference might not be noticeable in this scenario, however, the larger the amount of geometry gets and the more data the GPU has to process each frame, the more the new implementation will gain over the others.

I think the ARB was right when they said that the non-legacy API is designed to be much cleaner . This can easily be seen by the reduction of the number of function types that are called from legacy to non-legacy.

The changes have all been pushed to GitHub.

[BaneTrapper]

Is it possible to use your "Light" engine for 2d world?

[binary1248]

Light is not an engine... it is a class that instructs the rendering pipeline to apply lighting effects to whatever is drawn.

Because shadows aren't cast from lights, it makes little sense to use it for lighting a 2D world. You could easily achieve the same effect by blending a light map on top of your rendered world while saving a lot of GPU resources.

[BaneTrapper]

I aren't really known with the light "class" you have, because i had issues setting up the camera or the objects something was off and i couldn't get stuff on screen.
If i draw everything on 0 and set camera position to 0 i would get image but any attempt to move the camera made screen just black.
Is there a example code? i didn't find any except the sfml one, but that is not using your "camera" which is afaik needed for light.

What i want from light is just to have point and emit light from it for X radius, but be blockable/obstructed by objects/terrain.

[binary1248]

I aren't really known with the light "class" you have, because i had issues setting up the camera or the objects something was off and i couldn't get stuff on screen.
If i draw everything on 0 and set camera position to 0 i would get image but any attempt to move the camera made screen just black.

If you put your camera right in the object you are trying to look at, depending on how big the object is, you will move it out of the view even with small movements of the camera. Not only that, if they both have exactly the same location, and you are literally "inside" the object, you won't see anything because backfaces are culled. If you want to look at a box in real life you also don't put the camera inside of it...

If you post the code you wrote, maybe it might be easier for me to tell what you did wrong...

Is there a example code? i didn't find any except the sfml one, but that is not using your "camera" which is afaik needed for light.

There is a "3d" example in the examples directory, and it uses a camera... along with a few 3D objects and some 2D objects.

What i want from light is just to have point and emit light from it for X radius, but be blockable/obstructed by objects/terrain.

Because shadows aren't cast from lights

Lights do not cast shadows... Things behind other things will be lit up as if nothing was in front of it blocking the light. If you want shadows, you will have to implement it yourself. Don't use the Light class and take the detour into the 3D realm if you just want shadows for your 2D application, that is not what it is meant for. Light is only used to shade 3D objects to give them a sense of depth which you would not perceive without it. It makes little to no sense using it in a truly 2D application (consisting only of 2D geometry).

[cooldog99]

This. is. amazing. EXACTLY what i've been looking for!

I tried to create something like this for myself awhile back... and kinda lost interest since I'm still new-ish to openGL.

I really love how simplistic it is to get a 3d application up and running with a small file.

Thank you so much for this

I AM having one issue though, I can't seem to get anything textured (besides billboard). Does the .setTexture function not work for most of the classes yet? I'm really tired and am probably screwing it up.

When I add something like this to the example... it doesn't seem to work.

Code: [Select]

cube.setTexture(&billboardTexture);

Even when I use your example code for loading .obj files and .setTexture the model class (from example) It gets the texture coordinates right, but doesn't seem to use them?

Like I said, I probably screwed something up... still new-ish to openGL.

Thanks again.