[RFE] LWJGL 3.0

[Umami]

Ya, it makes absolutely sense. As said, I am an OpenGL noob(ie) and afterwards searched for the error elsewhere, which won't happen again.

I had another look at your code and decided to download Scala and try it out. Another bug I found was the order of calls in your render loop. You're effectively rendering your model, then calling glClear, then glfwSwapBuffers, which means you're always going to get an empty framebuffer.

Wow, how nice of you. Thanks! I redownloaded my old example but... I did it like this there

while (glfwWindowShouldClose(id) == GL_FALSE)
    {
      // Render
      renderer.prepare()
      // Swap the color buffers
      glfwSwapBuffers(id)
      // Poll for window events (key callback is only invoked here)
      glfwPollEvents()

      renderer.render(model)
    }

In prepare() of the renderer I clear the color. That's the first thing you want to do in each frame, is it not?

Then I swap the buffers and then I render the model. Not sure what's wrong here, because that's not the order you stated. (Or I am misunderstanding you)

As for the rest: I'll try, but it will take some time.

[spasi]

while (glfwWindowShouldClose(id) == GL_FALSE)
    {
      // Render
      renderer.prepare()
      // Swap the color buffers
      glfwSwapBuffers(id)
      // Poll for window events (key callback is only invoked here)
      glfwPollEvents()

      renderer.render(model)
    }

In prepare() of the renderer I clear the color. That's the first thing you want to do in each frame, is it not?

Then I swap the buffers and then I render the model. Not sure what's wrong here, because that's not the order you stated. (Or I am misunderstanding you)

Note that I said "effectively". It's not the order of the code in the loop, but it's the actual order of rendering. Here's what happens:

1) You clear the backbuffer.
2) You swap buffers, the current back buffer (which is empty) becomes the front and the front becomes the back for subsequent rendering operations.
3) You render the model into the back buffer.
4) go to 1)

So, the front buffer, the one you see on the screen, is always empty.

Since this is all very basic stuff when it comes to rendering with OpenGL (or any other rendering API) and have nothing to do with LWJGL, could you please start a new thread if you have any more questions? This forum has plenty of people who would be glad to help. I'd like to keep this thread focused on discussing the evolution of LWJGL 3 and for reporting issues/crashes/etc. If, for example, you have more info on the ffi_closure_free crash (the one you reported on your first post), please reply here.

[kappa]

Running latest LWJGL nightlies on OS X in which -XstartOnFirstThread is now mandated. Noted that touching any AWT seems to cause an instant application lockup on the AWT call. I was using java.awt.Font to load fonts in the app.

I managed to workaround the lockup using -Djava.awt.headless=true

It does throw the message:
"java[30916:1884135] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode." but otherwise works as expected.

[spasi]

Yes, this is the expected behavior, GLFW and AWT cannot work together. When AWT is initialized it tries to start its event loop in the first thread, but that thread is already occupied by GLFW (and the user's main thread).

It's actually great that it works with java.awt.headless, I hadn't tried that. Is there any difference if you init AWT first and GLFW later?

[SHC]

Thanks for your observation @kappa, it actually works, confirmed on Mac OS X Yosemite, however I'm also getting the same message that you got.

2015-01-02 12:44:59.969 java[1291:10205] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.

Just ignoring this, is working, thanks again for spotting it.

@spasi

I tried initializing AWT first by creating an instance of Toolkit with Toolkit.getDefaultToolkit(); When I create this before launching GLFW, GLFW asks me to use -XstartOnFirstThread, even though I was having that flag enabled. The solution for now is to use the headless mode, but initialize GLFW before any AWT things.

[kappa]

yeh, doesn't work when AWT is run before GLFW as LWJGL throws the exception "Please run the JVM with -XstartOnFirstThread."

Fonts/Text is one of the big hurdles of using OpenGL & Java (especially now without AWT), bitmap fonts can only go so far and are starting to show their limitations, with the advances in high resolutions and use of unicode (massive amount of glyph sets) the font glyph data is getting more and more essential. Maybe in future we could look at the option for a binding to the FreeType library, its small, fast and has a good licence. Should remove one of the big pain points for end users.

[Cornix]

I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.

[kappa]

I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.

Once there is an easy way to access/read font glyph data the rest could be left to the users since there are so many different ways to draw fonts in OpenGL, e.g. see freetype-gl, very efficient implementation of fonts in OpenGL using freetype which could potentially be ported to Java/LWJGL.

[Umami]

Since this is all very basic stuff when it comes to rendering with OpenGL (or any other rendering API) and have nothing to do with LWJGL, could you please start a new thread if you have any more questions? This forum has plenty of people who would be glad to help. I'd like to keep this thread focused on discussing the evolution of LWJGL 3 and for reporting issues/crashes/etc. If, for example, you have more info on the ffi_closure_free crash (the one you reported on your first post), please reply here.

Of course, I'm sorry.
Regarding the crash: I'm not sure what a more basic version than the one you provide on your website could look like. The example from the website (getting started) crashes for me, if I try to close the window with either escape-key or the window's "close button"

[abcdef]

I would support the addition of a font rendering library. Its a pain having to use AWT just for the font support.

Once there is an easy way to access/read font glyph data the rest could be left to the users since there are so many different ways to draw fonts in OpenGL, e.g. see freetype-gl, very efficient implementation of fonts in OpenGL using freetype which could potentially be ported to Java/LWJGL.

I'd second a way to get easy access to font glyphs, the other good thing about awt.Font is it allows you generate a texture for your chosen font (not completely but enough for you to create a ByteBuffer yourself), so something to help out to create bitmap glyphs would be good too. The freetype-gl seems to do this and more so would be good.

[kappa]

Freetype can create bitmaps too (including with antialiasing if needed).

Having a look at the current available Freetype options for Java, came across two:

Firstly LibGDX has a freetype binding, at a glance it seems to be pretty tightly coupled with LibGDX's internals, so not sure how easy it is to use with a non LibGDX project.

Secondly found MatthiasMann's implementation of freetype, seems to be using JNA and the implementation looks clean and straightforward (6 classes), however now sure how complete it is or if its still maintained (last change seems to be 3 years ago).

Other than that haven't found any other useful Freetype java libraries (although internally I think AWT also uses Freetype now).

[SHC]

I found this, opentype.js, but it is a JavaScript based font loader that has the option to create a path from glyphs, it also loads kerning information. I doubt whether it can be ported to Java.

[abcdef]

a long long time ago the developers of freetype offered up some help in creating JNI wrappers for freetype for someone. I wonder if, when LWJGL3 goes fully live, that we could ask them for help in creating some bindings.

Also...I haven't had time recently to look at how to add new bindings to LWJGL, if there was a wiki "how to" page for adding new binding then maybe some of us can help create one.

Libgdx was mentioned but it would be good to have something standalone

[spasi]

Thanks for your observation @kappa, it actually works, confirmed on Mac OS X Yosemite, however I'm also getting the same message that you got.

2015-01-02 12:44:59.969 java[1291:10205] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.

Just ignoring this, is working, thanks again for spotting it.

@spasi

I tried initializing AWT first by creating an instance of Toolkit with Toolkit.getDefaultToolkit(); When I create this before launching GLFW, GLFW asks me to use -XstartOnFirstThread, even though I was having that flag enabled. The solution for now is to use the headless mode, but initialize GLFW before any AWT things.

I spent a few hours trying to figure out what exactly is going on.

- With -Djava.awt.headless=true, AWT after GLFW works, but there's the warning message.

- With -Djava.awt.headless=true, AWT before GLFW does not work for two reasons:

    a) The JVM sets the JAVA_STARTED_ON_FIRST_THREAD_<pid> environment variable when -XstartOnFirstThread is specified. AWT then detects it, sets an internal flag and removes the environment variable. When LWJGL checks it (on glfwInit), it's already gone. I think I can replace this check with an alternative implementation.

    b) With the check removed, glfwInit fails with "No monitors found".

- Without -Djava.awt.headless, AWT after GLFW does not work. AWT initialization hangs because isRunning returns NO (for reasons I don't understand).

- Without -Djava.awt.headless, AWT before GLFW does not work because AWT goes into embedded mode (calls it "SWT or SWT/WebStart mode") and when that happens it calls NSApplicationLoad(). SWT knows about this and somehow injects its NSApplication implementation, so everything's fine. GLFW obviously fails to initialize properly.

- Without -Djava.awt.headless and with a very small fix inside GLFW, AWT before GLFW works perfectly. I could even have a GLFW window side-by-side a JFrame. Only limitation: any AWT windows must be disposed before GLFW, otherwise the AWT windows hang without an event loop.

Anyway, it's a freaking mess, I don't know why I'm still wasting time on this. This can only reliably work if we make changes to GLFW to work more like SWT.

On freetype, I had a quick look and it seems straightforward. It's a simple C API with great documentation. On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.

[Cornix]

On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.

This does only work if you know all Font's you are going to use in advance. If you want to give your user the possibility to use any .ttf font and have them select it you will be in trouble.
Right now I use AWT to build my own Glyph-Textures and then I render them with a VBO. But it is a lot of work and a lot of code and it would be nice if there was a helpful utility library available.

But I can understand if this is low priority right now.