Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Antialiased rendering to Framebuffer object  (Read 4584 times)
0 Members and 1 Guest are viewing this topic.
Offline mmx358

Senior Newbie


Exp: 3 years



« Posted 2018-01-20 17:40:35 »

Hi there!

I'm trying to incorporate a post processing shader in my first project. So I set up a FrameBuffer, drawing onto it, and then drawing a texture from it onto screen.

But when I render directly on screen, I get this:


When I render using FrameBuffer, I get this:


Notice how different edges of bricks look. As far as I understand, in the second case there is no texture filtering? Or what is causing this is more tricky?

I'm using LibGdx.

Textures are loaded like this:
1  
brickTexture = new Texture(Gdx.files.internal(BRICK));


FrameBuffer setup:
1  
2  
3  
4  
5  
        frameBuffer = FrameBuffer.createFrameBuffer(
                Pixmap.Format.RGBA8888,
                Gdx.graphics.getWidth(),
                Gdx.graphics.getHeight(),
                false);


And my render() method:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
    @Override
    public void render(float delta) {
        camera.update();

        if (paused) {
            menu.act(delta);
        } else {
            game.act(delta);
        }

        frameBuffer.begin();

        Gdx.gl.glClearColor(0, 0, 0, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

        if (paused) {
            menu.draw();
        } else {
            batch.begin();
            game.draw(batch);
            batch.end();
        }

        frameBuffer.end();
       
        viewport.apply();

        Gdx.gl.glClearColor(0, 0, 0, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

        batch.begin();
        batch.draw(frameBuffer.getColorBufferTexture(), 0, WORLD_HEIGHT, WORLD_WIDTH, -WORLD_HEIGHT);
        batch.end();
    }
Offline mmx358

Senior Newbie


Exp: 3 years



« Reply #1 - Posted 2018-03-17 11:50:55 »

Okay, maybe my question is incorrect...

Ho do i render to FBO with multisampling?
Offline mmx358

Senior Newbie


Exp: 3 years



« Reply #2 - Posted 2018-03-22 19:30:33 »

Ok, guys, according to the link below AND official documentation for OpenGL 4.6, antialiasing is disabled by default for Framebuffer objects (i.e. created by user).
http://www.java-gaming.org/topics/libgdx-draw-with-anti-aliasing-to-a-non-default-framebuffer/36141/view.html

But is it possible to enable it via standard libGDX api? Or do I really need to somehow enable it manually for a FBO I created? I just can't get it because when I create libGDX FBO, it is created without multisampling, right? So I can't modify parameters of an already created FBO... And does this in turn mean that I should create an FBO manually, using Gdx.gl API calls? If yes, then it seems that I can't, because both GL20 and GL30 classes does not contain functions mentioned in the example here: https://www.khronos.org/opengl/wiki/Multisampling

So how do I do this "simple" thing?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 520



« Reply #3 - Posted 2018-03-22 19:45:03 »

Have you had a look at their GitHub issues page?
MSAA for FBOs is an open feature request.
It looks like, since libGDX's GL abstraction/interface does not yet expose OpenGL 3.2, your only option is to go directly down to LWJGL's classes and static methods, such as org.lwjgl.opengl.GL32. Doing this will of course bind you to Desktop-only, and will not work on Android or the Web.
Offline theagentd
« Reply #4 - Posted 2018-03-23 11:51:53 »

To add a bit, MSAA is not something that you just "enable" on a framebuffer. MSAA requires storing multiple samples for each pixel, meaning it needs more memory. A framebuffer object does not contain any actual data; it just renders to textures. If you attach an MSAA texture to the FBO, rendering to it will happen with MSAA. To actually display an MSAA image, you need to resolve it, which usually means averaging the samples of each pixel together. All of this happens automatically when you request an MSAA default framebuffer but needs to be manually taken care of when using FBOs.

Myomyomyo.
Offline mmx358

Senior Newbie


Exp: 3 years



« Reply #5 - Posted 2018-03-24 08:47:49 »

KaiHH, yes, after my last post I found that information. I also had read it before, but something just didn't switch in my had. I also had found out that GL32 class of lwjgl contains required constants. But then goes next question.
If GL ES is a subset of GL, then I can use functions from GL if I know which ones exactly are supported by specific version of GL ES running on my current device (most likely mobile). Right? E.g.: my game knows that current backend is GL ES 3.1, so it can use some specific functions from GL32 which definitely are included in GL ES 3.1. Is this assumption correct?

theagentd, so MSAA depends on the texture bound to FBO, not FBO itself, nor textures (sprites) being rendered to the texture?
Offline KaiHH

JGO Kernel


Medals: 520



« Reply #6 - Posted 2018-03-24 11:31:28 »

If GL ES is a subset of GL, then I can use functions from GL if I know which ones exactly are supported by specific version of GL ES running on my current device (most likely mobile). Right? E.g.: my game knows that current backend is GL ES 3.1, so it can use some specific functions from GL32 which definitely are included in GL ES 3.1. Is this assumption correct?
No.
Like I said, when you use LWJGL, your application will ONLY work on Desktop.
This is the reason why libGDX has its own GL interface/API to be able to route the GL calls to different underlying implementations (LWJGL on Desktop, WebGL on Web, Android GL ES on Android).
Again, once you use LWJGL classes/methods directly, libGDX has no way of routing the GL calls to Android GL ES anymore and your application WILL NOT work on the Web or Android anymore. There is no way around this without hacking libGDX itself.
Offline mmx358

Senior Newbie


Exp: 3 years



« Reply #7 - Posted 2018-03-25 07:24:54 »

Like I said, when you use LWJGL, your application will ONLY work on Desktop.
This is the reason why libGDX has its own GL interface/API to be able to route the GL calls to different underlying implementations (LWJGL on Desktop, WebGL on Web, Android GL ES on Android).
Oh, sorry for not understanding it for the first time.

Again, once you use LWJGL classes/methods directly, libGDX has no way of routing the GL calls to Android GL ES anymore and your application WILL NOT work on the Web or Android anymore. There is no way around this without hacking libGDX itself.
And there is no library like lwjgl for GL ES? I mean, if lwjgl is used for Desktop, so then which library is used for Android?
Pages: [1]
  ignore  |  Print  
 
 

 
DesertCoockie (52 views)
2018-05-13 18:23:11

nelsongames (83 views)
2018-04-24 18:15:36

nelsongames (74 views)
2018-04-24 18:14:32

ivj94 (759 views)
2018-03-24 14:47:39

ivj94 (87 views)
2018-03-24 14:46:31

ivj94 (643 views)
2018-03-24 14:43:53

Solater (102 views)
2018-03-17 05:04:08

nelsongames (184 views)
2018-03-05 17:56:34

Gornova (426 views)
2018-03-02 22:15:33

buddyBro (1086 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!