Git Product home page Git Product logo

coregl's Introduction

OpenGL core utilities

Important: toolchains.xml required to build

To build this project you'll need a toolchains.xml file in your Maven directory. This is necessary to support Java 9. Even if you don't plan to use Java 9 right now, you'll still need a toolchains.xml to build.

For details see the end of this readme.

What is this?

Simple utility classes and methods to make life with OpenGL core profile simpler.

  • The classes provided can be used independently from each other. You don't need to learn a complex API.
  • The abstractions provided are rather low level. This is by intention. The library is supposed to be as simple and lightweight as possible.
  • Adapter jars are provided for LWJGL, LWJGL3 and JOGL. If you want you can target both Java OpenGL providers or you can use the implementations directly. You decide.

It's main purpose is to reduce the amount of boilerplate code you would need to write when talking to OpenGL core profile. It's not meant to be anything else.

I've came up with these classes while learning OpenGL core profile. Maybe you can find them useful too.

Maven

CoreGL is available in the Maven central.

LWJGL

<dependency>
  <groupId>com.lessvoid</groupId>
  <artifactId>coregl-utils-lwjgl</artifactId>
  <version>2.0.0</version>
</dependency>

JOGL

<dependency>
  <groupId>com.lessvoid</groupId>
  <artifactId>coregl-utils-jogl</artifactId>
  <version>2.0.0</version>
</dependency>

Example

/**
 * Copyright (c) 2013, Jens Hohmuth
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are
 * met:
 *
 *  * Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *  * Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
 * THE POSSIBILITY OF SUCH DAMAGE.
 */
package com.lessvoid.coregl.examples;

import com.lessvoid.coregl.CoreRender;
import com.lessvoid.coregl.CoreShader;
import com.lessvoid.coregl.CoreVAO;
import com.lessvoid.coregl.CoreVAO.FloatType;
import com.lessvoid.coregl.CoreVBO;
import com.lessvoid.coregl.CoreVBO.DataType;
import com.lessvoid.coregl.CoreVBO.UsageType;
import com.lessvoid.coregl.spi.CoreGL;
import com.lessvoid.coregl.spi.CoreSetup.RenderLoopCallback;

/**
 * The SuperSimpleExampleMain just renders a single quad using a triangle strip
 * with a very basic vertex and fragment shader. It demonstrates the use of the
 * core-utils classes.
 *
 * @author void
 */
public class SuperSimpleExampleMain implements RenderLoopCallback {

  private CoreRender coreRender;

  @Override
  public boolean render(final CoreGL gl, final float deltaTime) {
    // We don't have to use coreRender though but it's kinda easier that way
    coreRender.clearColor(.1f, .1f, .3f, 0.f);
    coreRender.clearColorBuffer();
    coreRender.renderTriangleStrip(4);
    return true;
  }

  @Override
  public boolean endLoop() {
    return false;
  }

  @Override
  public void init(final CoreGL gl) {
    coreRender = CoreRender.createCoreRender(gl);

    final CoreShader shader = CoreShader.createShaderWithVertexAttributes(gl, "vVertex", "vColor");
    shader.vertexShader("super-simple/super-simple.vs");
    shader.fragmentShader("super-simple/super-simple.fs");
    shader.link();

    final CoreVAO vao = CoreVAO.createCoreVAO(gl);
    vao.bind();

    CoreVBO.createCoreVBO(gl,
                          DataType.FLOAT,
                          UsageType.STATIC_DRAW,
                          new Float[] { -0.5f, -0.5f, 1.0f, 0.0f, 0.0f, 1.0f, -0.5f, 0.5f, 0.0f, 1.0f, 0.0f, 1.0f, 0.5f,
                              -0.5f, 0.0f, 0.0f, 1.0f, 1.0f, 0.5f, 0.5f, 1.0f, 1.0f, 1.0f, 1.0f, });

    // parameters are: index, size, stride, offset
    // this will use the currently active VBO to store the VBO in the VAO
    vao.enableVertexAttribute(0);
    vao.vertexAttribPointer(0, 2, FloatType.FLOAT, 6, 0);
    vao.enableVertexAttribute(1);
    vao.vertexAttribPointer(1, 4, FloatType.FLOAT, 6, 2);

    // we only use a single shader and a single vao so we can activate both here
    // and let them stay active the whole time.
    shader.activate();
    vao.bind();
  }

  // pass 'jogl' into program arguments for JOGL backend and 'lwjgl' for LWJGL backend
  public static void main(final String[] args) {
    final RenderLoopCallback superSimpleExample = new SuperSimpleExampleMain();
    CoreExampleMain.runExample(superSimpleExample, args);
  }
}

Maven toolchains.xml support

You'll need to create a toolchains.xml at this location:

  • Linux, OS X: ~/.m2
  • Windows: C:\Documents and Settings{your-username}.m2

Option 1: Compile with Java 8

The idea here is to have only Java 8 in the toolchains.xml.

toolchains.xml:

<toolchains>
  <!-- JDK toolchains -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
      <vendor>oracle</vendor>
    </provides>
    <configuration>
      <jdkHome>/path/to/jdk1.8.0</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Option 2: Compile with Java 9 - the resulting Jar can be used with Java 8 and Java 9

We need both JDKs since for the time being we create backward compatible jars which require both JDKs.

toolchains.xml:

<toolchains>
  <!-- JDK toolchains -->
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>9</version>
      <vendor>oracle</vendor>
    </provides>
    <configuration>
      <jdkHome>/path/to/jdk-9</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
      <vendor>oracle</vendor>
    </provides>
    <configuration>
      <jdkHome>/path/to/jdk1.8.0</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Build

mvn clean install

coregl's People

Contributors

bgroenks96 avatar mkaring avatar void256 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

coregl's Issues

Code-Style

Hey,

I wanted to do some good to the code of CoreGL and I noticed a utter mess when it comes to the style of the code. There are tab indentions, space indentions different sized indentions, different sized line lengths and so on.

We should set one style of code as default. Maybe the same as for Nifty-GUI?

@void256 ?

glCheckError

I know this function has good intentions, but in matters of performance and implementation it is just terrible.

Making it smarter, regarding the detection what really needs to be generated in matters of output (isLoggable -checks) and adding some support for adding variables that are added into the message only if it is required

gl.checkGLError("glSomeFunction({})", param5);

is not that much of a problem. The main issue is that every implementation would require this and this results in us ending up with a lot of duplicated code.

My suggestion would be to use a central logging helper class (fully static) that offers all the functions for logging and the implementations in the provider only have two functions.

int getNextErrorCode();
String getErrorMessage(int errorId);

So logging could look like this:

CoreLogger.checkGLError(gl, "glGetUniformLocation for [{}] failed", uniformName);

What do you think?
This way we get faster error checking/logging and reduced code requirements for the provider implementations.

Add CoreGLES interface

CoreGL needs an ES interface and implementation set. This should be very easy to do with the existing API. The ES-friendly parts of CoreGL just need to be extracted to a parent interface CoreGLES (or something like that). The same thing can be done with the implementations but with subclassing (sorry @void256 it's the best way to do it for this xD). No overrides will be necessary of course.

Memory Leaks in coregl LWJGL examples

There's a HUGE memory leak somewhere in CoreGL noticeable while monitoring the Starfield or ObjectRender LWJGL examples (it probably applies to more of them but those were the only two I've tested so far). After several minutes of usage on my system, the Starfield example peaked at 3.1 GB of memory use, with ObjectRender being even worse at 7-8 GB.

After profiling the VM, the leak appears to be coming from the Mat4 utility class. There's a lot of direct buffer memory that is being allocated and inefficiently released.

See images below for details:

Screenshot of VisualVM memory profiler at ~2:00 uptime
coregl_profile0
Screenshot of SystemMonitor showing process information; CoreGL StarfieldMain process is at the top of the list
coregl_profile2

CoreSetupLwjgl uses hardcoded bit-depth value in DisplayMode matching

This private method:
matchesRequestedMode(final int requestedWidth, final int requestedHeight, final DisplayMode mode)

uses a hardcoded value (32) for bits per pixel. This wasn't compatible with my display, so setup would always crash program with ArrayIndexOutOfBoundsException

Suggestion: use default display's setting for bit-depth or allow setting through API call.

I can make this change in the next commit to my branch if you would like.

move maven repo to sonatype and later to central

After we've successfully got Nifty GUI approved with Sonatypes open source software hosting we should do the same for CoreGL - since sf.net is still acting up at times when deploying artifacts, unfortunately ๐Ÿ˜ž

To do this we'll need a groupId for the Maven project that will be accepted by Sonatype.

Any suggestions where CoreGL should "live" in the future?

Should we move it to an "CoreGL" organisation like we did with Nifty?

@bgroenks96 ?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.