MBassador PublicationErrorHandler

I was very confused when my thrown events didn't show any results somewhen. And then, I realized I did not pay enough attention, because MBassador was indeed very nice to suggest registering an ErrorHandler for publication failures. The documentaiton is quite sparse about that, it took me some time to figure it out, so with version around 1.2.4, this is the way you can do it:

 IBusConfiguration config = new BusConfiguration()  
  .addFeature(Feature.SyncPubSub.Default())  
  .addFeature(Feature.AsynchronousHandlerInvocation.Default())  
  .addFeature(Feature.AsynchronousMessageDispatch.Default())  
  .addPublicationErrorHandler(error -> {  
    System.out.println(error);  
  });  
 new MBassador(config);  

Swing reload JTree

So many people want to know how a JTree in for example a JScrollPane can be reloaded. To make it short, no revalidating, no repainting by hand - just:

 DefaultTreeModel model = (DefaultTreeModel)getModel();  
 model.reload();  

Call this everytime your underlying data changes and the view will update itself automatically. This is mainly for myself, because I have to look it up again every time I need it...

Bindless texture with LWJGL

The classic bound texture paradigma is so 1990. But getting bindless textures to work is not that easy, especially when you're using something other than C or C++. For all the LWJGL or Java users out there, here are some notes that may help you removing the classic texture pipeline from your engine. I think you can read about the technique in the internet, so I'll keep it mostly short.

First of all, you need a handle (some kind of pointer again, but don't think of it as a pointer, yucks) for a given texture.

 long handle = ARBBindlessTexture.glGetTextureHandleARB(textureID);  

Afterwards, the handle has to be made resident. I think that's something you need for the combination with partially resident textures.

 ARBBindlessTexture.glMakeTextureHandleResidentARB(handle);  

This was the easy part. Now, you have to use the handle in our shaders somehow. The easiest way would be to use it as a uniform.

 ARBBindlessTexture.glUniformHandleui64ARB(location, handle);  

Inside your shader, you have to use the handle. But what datatype should one use? Maybe I missed something elementary, but  there's only one proper way, namely use a datatype made available through an nvidia extension. Since bindless textures are available through an extension as well, here are both calls that you (probably) need:

 #extension GL_NV_gpu_shader5 : enable  
 #extension GL_ARB_bindless_texture : enable  

And now, you can use tha datatype uint64_t. So your uniform would be a uint64_t.

That would work. But most probable, you want to have your data in a uniform or storage buffer, probably together with some other data and datatypes. So here's what I did.

Use a DoubleBuffer (Java native buffer, available via BufferUtils.createDoubleBuffer(int size)) for your data. Since doubles are twice the size of a float, which is 4 byte, we have 8 bytes per texture handle, which is 64 bits, which is the same as a uint64's size, so that's enough. Now one has to take the generated handle's bits and put them into the buffer (for example a ssbo) as they are. This can be done like so:

 GL15.glBufferSubData(GL43.GL_SHADER_STORAGE_BUFFER, offset * primitiveByteSize, values);  

-
Where primitiveByteSize is 8 in this case. Since we use the underlying buffer as a DoubleBuffer, we have to provide a double value for the handle (or use it as a byte buffer, but nevertheless we need the correct bits or bytes). You can convert a Java long to and from a double like this:

 Double.longBitsToDouble(longValue)  

 Double.doubleToLongBits(doubleValue)  

Afterwars, the shader can take the value as a said uint64_t and cast it to a sampler. Sounds ugly, maybe it is.

 color = texture(sampler2D(uint64_t(material.handleDiffuse)), UV);  

That is the whole story, took me a while to figure it out.

Single Pass Omnidirectional Shadow Mapping Evaluation

Layered rendering is possible since geometry shaders entered the OpenGL stage. The rough idea of a good omnidirectional shadow mapping (for example for pointlights) is to render the complete shadow map with a single draw pass, in order to reduce the amount of rendercalls, compared to six-pass rendering with traditional rendering to a cubemap. Therefore, the geometry shader emits a vertex for each incoming vertex of the non-culled scene geometry to a face of the cubemap with something called layered rendering. While the idea is well described all over the internet already, every now and then, there is discussion about the efficiency of this method.

My first idea was to evaluate omnidirectional shadow mapping with dual paraboloid shadow maps since it's the easiest way to achieve pointlight shadow: No viewmatrices, no projectionmatrices, two textures per pointlight, let's go. Without view frustum culling, I draw the complete geometry twice and passed a "backside" flag as a uniform variable for the second rendering. No layered rendering, just two depth buffers and two color attachments (can be ommited if no variance shadow mapping is used) for each pointlight (front and back). It's possible to do dpsm with a single-pass rendering in a single texture - I doubt it to be efficient because you would have to handle the depth buffer somehow. Or it will be efficient, but much more complicated.

Rendering a single (two texture) shadowmap for the famous sponza atrium takes ~1.5 ms on my GTX 770.

Layered rendering however, took me a while for the implementation. Because I use array textures in order to be able to use many shadow mapped lights, I had to fight with the strange array indices for cubemap arrays. For everyone who is interested, here's how you create a cubemap array rendertarget and use it to draw your shadow maps:

 framebufferLocation = GL30.glGenFramebuffers();  
 // Create rendertarget
 GL30.glBindFramebuffer(GL30.GL_FRAMEBUFFER, framebufferLocation);  
 IntBuffer scratchBuffer = BufferUtils.createIntBuffer(colorBufferCount);  
 for (int i = 0; i < colorBufferCount; i++) {  
      GL32.glFramebufferTexture(GL30.GL_FRAMEBUFFER, GL30.GL_COLOR_ATTACHMENT0 + i, cubeMapArrays.get(i).getTextureID(), 0);  
      scratchBuffer.put(i, GL30.GL_COLOR_ATTACHMENT0+i);  
 }  
 // Use glDrawBuffers(GL_NONE) if you don't need color attachments but depth only
 GL20.glDrawBuffers(scratchBuffer);  
 CubeMapArray depthCubeMapArray = new CubeMapArray(AppContext.getInstance().getRenderer(), 1, GL11.GL_LINEAR, GL14.GL_DEPTH_COMPONENT24);  
 int depthCubeMapArrayId = depthCubeMapArray.getTextureID();  
 GL32.glFramebufferTexture(GL30.GL_FRAMEBUFFER, GL30.GL_DEPTH_ATTACHMENT, depthCubeMapArrayId, 0);  

Although some implementations are hidden because of my framework, the idea should be clear. Don't forget to initialize the cubemap array texture correctly or your framebuffer object won't be complete.

Since the geometryshader decides which face to render to, you can pass the pointlight index as a uniform variable. The layer will then be gl_Layer = 6*lightIndex + layer.

The quality is very nice, but unfortunetly, rendering sponza into the cubemap takes ~8.3ms on my GTX 770. The additional color attachment is not responsible for the expensiveness, since I tried to remove it. I'm pretty sure that I didn't do a major mistake in the implementation. It has to be the poor performance of the geometry shader that is responsible for the high amount of time this method takes.

Conclusion

• Dual paraboloid shadow map rendering ~1.5 ms
• Single pass cubemap shadow map rendering ~ 8.3 ms

I used 512*512 per dspm face or cubemap face. Would be nice to hear anyone alse's experience with omnidirectional shadowmapping.

FormGenerator: Automatic html forms from java objects

Purpose

One of Ruby on Rails' features I quite liked but missed in other frameworks, is code generation. The scaffolding produces forms and controllers for a given object automatically and saves the files in appropriate folders. This is mainly convention driven.

With Java, we have a nice type system, so why do I have to write forms over and over again? I used reflection to automatically generate an html form for a given object.

Algorithm

Basically, the FormGenerator gets an arbitrary object attached. On this object, first all fields and inherited fields have to be obtained. Since it would be useless to just process public fields, I had to use a small piece of utility code I found here.

public Iterable<Field> getFieldsUpTo(@Nonnull Class<?> startClass,
                                     @Nullable Class<?> exclusiveParent) {

  List<Field> currentClassFields = Lists.newArrayList(startClass.getDeclaredFields());
  Class<?> parentClass = startClass.getSuperclass();

  if (parentClass != null &&
     (exclusiveParent == null || !(parentClass.equals(exclusiveParent)))) {
    List<Field> parentClassFields =
                (List<Field>) getFieldsUpTo(parentClass, exclusiveParent);
    currentClassFields.addAll(parentClassFields);
  }

  return currentClassFields;
}

After the information about the object is obtained, the form fields are wrapped by a form begin/end pair. The private fields have to be made accassible - note the exception handling.

try {
  field.setAccessible(true);
} catch (SecurityException e) {
  Logger.getGlobal().info(String.format("Field %s can't be accessed, so no input for this field.", field.getName()));
  return result;
}

Depending on the type of the field, inputs should be generated. The types are determined at runtime, so a switch is needed for the value extraction.

if(type.equals(String.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), (String) field.get(object));
} else if(type.equals(Boolean.class)) {
result += generate(formGenerator.getFieldName(field.getName()), (Boolean) field.get(object));
} else if(type.equals(boolean.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), field.getBoolean(object));
} else if(type.equals(Integer.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), (Integer) field.get(object));
} else if(type.equals(int.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), field.getInt(object));
} else if(type.equals(Float.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), (Float) field.get(object));
} else if(type.equals(float.class)) {
  result += generate(formGenerator.getFieldName(field.getName()), field.getFloat(object));
} else if(type.equals(List.class)) {
  result += "<div class=\"well\">" + newLine;
  result += String.format("<div id=\"%s\">%s", formGenerator.getFieldName(field.getName()), newLine);
  result += generate(formGenerator.getFieldName(field.getName()), (List) field.get(object), (ParameterizedType) field.getGenericType());
  result += "</div>" + newLine;
  result += "</div>" + newLine;
}

After all primitive types and lists/collections/iterables or whatever are treated, this method can be called recursively to treat arbitrary classes for fields again. It's probably not the best idea to hardcode css classes into this methods, but for my purposes and right now, bootstrap is the only ui framework I satisfy.

Attention has to be paid for generics. For lists, I implemented a treatment in the following way.

static String generate(String fieldName, List value, ParameterizedType type) {
    StringBuilder builder = new StringBuilder();

    int counter = 0;
    for (Object listItem : value) {
        Class<?> componentClass = (Class<?>) type.getActualTypeArguments()[0];
        String listItemFieldName = fieldName + "_" + counter;
        try {
            Method InputGeneratorMethod = InputGenerator.class.getDeclaredMethod("generate", String.class, componentClass);
            String generatedFormElements = (String) InputGeneratorMethod.invoke(null, listItemFieldName, listItem);
            builder.append(generatedFormElements);
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        counter++;
    }

    return builder.toString();
}

The method invocation can be done via reflection again. With the given type, the correct overloaded method is chosen at runtime. However, this could lead to exceptions that one has to handle properly *cough*.

Results

The following class definition is used in my tests.

class MyClass {
    private String testString = "testStringValue";
    private Boolean testBoolean = true;
    private Boolean testBooleanObject = false;
    private int testInt = 12;
    private Integer testInteger = 14;
    private float testFloat = 12.0f;
    private Float testFloatObject = 14.0f;
    private List<String> testStringList = new ArrayList() {{
        add("a0");
        add("a1");
    }};
    private List<Boolean> testBooleanList = new ArrayList() {{
        add(true);
        add(false);
    }};
}

And the generated form looks like this.

It's just an early version yet, there is plenty of stuff left to do. For example the recursive generation for arbirtary objects. Or an injector for style classes. Or field annotations for named fields and non-exported or disabled fields. After this, I'll try to write a reflective argument extractor for ninja, that is capable of parsing request data from generated forms and propagate it back.

Ninja framework: Argument extractors

The last post introduced a simple way to automatically extract a collection of objects from a form and inject it into a controller's action. However, when classes get more complex, this option is not the best one because of two reasons: Method signatures get bloated and the collections have to somehow get attached to the corresponding object (injected into the action as well) by hand. If one writes a new action and uses the built in functionality, it's possible that he forgets to update one of the instance's fields....saves...and boom: the object's data is gone.

The functionality can be gathered into an argument extractor. Sadly, the official documentation only shows an example where the session is used to extract a simple session cookie. But what if you have to get complex form data? Ideally, one wants a clean action method signature, where the instance is injected correctly. This can be done with simply with an annotation:

public Result saveTrip(Context context, @argumentextractors.Trip Trip trip) {

It's important to note, that you can't use other built-in extractors (Param, Params) any more, after you parsed the request. Additionally, your own extractor has to be the first extracting paramter in the signature.

The marker interface specifies the extractor class:

@WithArgumentExtractor(TripExtractor.class)
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.PARAMETER})
public @interface Trip {
}

The magic then has to be implemented by yourself. Therefore, extend a BodyAsExtractor, where T is the return type you want to extract. There are three methods to be overriden. I don't have a clue what the third one (getFieldName()) does, but the important one is

public Trip extract(Context context) {}

Your form data has to be gathered now. Took me some time to find out how to do this - actually, you can do

String body = "";
while (context.getReader().ready()) {
  body += context.getReader().readLine();
}

and that's it. I was'n able to use the InputStream the context provides directly. Now the ugly part. the params string of the form http://example.org/path/to/file?a=1&b=2&c=3 should result in a list of a=1, b=2, c=3. Since this is a common task, it's implemented in the apache commons htmlUtils - nice wordplay. I extracted some single methods from their library, because I only use a few ones. Now, you have to apply the parsed values by hand. To mention would be, that this can only work, if the keys you use to extract all the stuff don't change between forms. Otherwise, you would have to implement another extractor.

trip.getStops().clear();
for (int x = 2; x < params.size(); x++) {
  trip.getStops().add(params.get(x).getName());
}
return trip;

The nice thing is now, that everyone who uses this object class, can use the extractor and afterwards just has to save the instance regularly in the controller action:

manager.merge(trip);

I'm curious if this is the intended way to extract stuff from forms. It's a pity that such an important requirement isn't documented better.

Ninja framework: collection extration from forms

Ninja quickly became one of my favorite web frameworks. For REST, MVC, dependency injection, database and other basic stuff, it mostly is very convenient. But what about the more complicated things web development often demands? Because documentation is rather sparse for it, here's how you can use built in functionality to extract a collection of objects from a form.

My example has a simple edit form for a trip model.A trip can have multiple stops, for simplicity represented by a String. With a POST route in the TripsController, Ninja can automatically parse the request, extract your form data and inject the Trip instance into the method call - one has to add a Trip reference the controller's signature and it just works, how great is that:

public Result saveTrip(Context context, Trip trip) {

However, the documentation states, that the extraction only works with primitives and arrays of them. This means no other collections, like Lists, can be extracted automatically. But no one uses plain arrays as fields... So, an easy way to circumvent this limitation, is to add the given items within the collection to the form and provide the same name attribute for all of them:

<#list trip.stops as stop>
  <tr>
    <td><input type="text" class="form-control" id="stops[${stop_index}]" name="stops" value="${stop}" ></td>
  </tr>
</#list>

Then, add the String[] stops parameter to your signature and you're done.

public Result saveTrip(Context context, @Params("stops") String[] stops, Trip trip) {

In my case, I updated all of the trip instance's stops with the stops automatically injected and saved the objet. Can't get any easier, I think.

I'm not yet sure if this would work for more complex (means no-primitive type) objects. For this purpose, argument extractors were introduced. The documentation is again a bit sparse about them - a first try seemed that argument extractors that try to parse the request data for object extraction tend to be a bit hacky. Will be continued.

Microbenchmarking Java image loading libraries

During my 3d engine project, the demand to load arbitrary image formats came up. My choice was ImageIO since it's shipped with Java. Short time ago, I realized that there is a cool Apache lib called commons imaging. The main goal would be to speed up the loading processes, so finally I have a reason to do some microbenchmarks, yey.

Since there are only very few tools for micro benchmarking and most of them offer poor features and documentation, I recommend to use JMH. As always, documentation and examples are kind of confusing, so here's the workflow I used.

First of all, you need two dependencies - the jmh core lib and the annotation processor.

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.9.1</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.9.1</version>
</dependency>

The methods you want to benchmark can then be annotated to be automatically registered for measurement.

@Benchmark
    public void commonsImage(){
        MainClass.loadImageCommonsImaging();
    }

Now a piece of software is needed that runs all your annotated methods. This can be done with some command line stuff, I prefer a solution that can be packaged as a jar or directly run from the IDE. Embedding your benchmark config in a class and write a small main method can do the job. The class you pass into the benchmark via the options is scanned for annotated methods.

public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(ImageLoadBenchmark.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }

Run the main method from your IDE or export a package. Note: If you export a jar, you have to provide the dependencies - if you don't want them to reside in your classpath, create a fat jar with the maven-assembly-plugin. Tested it, works fine. Here's the result:

Benchmark         Mode  Cnt   Score   Error  Units
commonsImage  thrpt    20    8,127   0,077  ops/s
imageIOImage    thrpt    20   11,283  0,105  ops/s

So it seems as if imageIO can push more loading jobs per second than commons imaging. Dang it.

This is just a minimal benchmark setup - of course there's a ton of other things you could do with JMH. Have fun.

Simple setup: Spring with Boot, Maven and IntelliJ from scratch

There will never be enough tutorials about how to use Spring with an IDE. Here's another one in case of someone wants to know how to setup a development environment with IntelliJ. Especially the hot reloading features are very important and nobody wants to miss them. Here's how one can do it.

1. Create a new maven project. Don't use archetypes.
2. Edit the pom.xml file to use a parent from Spring Boot that does a lot of configuration for you.
   

      <parent>  
        <groupId>org.springframework.boot</groupId>  
        <artifactId>spring-boot-starter-parent</artifactId>  
        <version>1.1.5.RELEASE</version>  
      </parent>  
   

3. Also, the spring boot dependency has to be added to the pom.xml.
   

      <dependencies>  
        <dependency>  
          <groupId>org.springframework.boot</groupId>  
          <artifactId>spring-boot-starter-web</artifactId>  
        </dependency>  
      </dependencies>  
   

4. The main application class is configured to enable auto configuration. For further information, one should read one of the thousands of Spring tutorials.
   

    @Configuration  
    @ComponentScan  
    @EnableAutoConfiguration  
    public class Application {  
      public static void main(String[] args) {  
        ConfigurableApplicationContext ctx = SpringApplication.run(Application.class, args);  
      }  
    }  
   

5. Now you could add controllers and other stuff. And run the main class from your run configuration. In order to have an executable fat jar, you could use the maven assembly plugin (see one of my other posts). Class reloading with this run configuration should work out of the box.
6. The convention seems to say one should place resources in src/main/resources/static. Placing an index.html in there will make it available via the applications root path. However, if you use src/main/webapp/ as your folder structure, you fulfill standard java web application convention and make Tomcat automatically recognizing your stuff. You then have to access your static content via /static/index.html or similar, or you can reconfigure your routes (not covered here).
7. If you work on your static content, you want it to be reloaded automatically. However, this doesn't happen with the configuration so far. That's because of the fact that your static content will be copied into a working directory - changing the root files doesn't change their copies. There may be other ways, I successfully tried to use spring boot maven plugin.
   

          <plugin>  
            <groupId>org.springframework.boot</groupId>  
            <artifactId>spring-boot-maven-plugin</artifactId>  
            <dependencies>  
              <dependency>  
                <groupId>org.springframework</groupId>  
                <artifactId>springloaded</artifactId>  
                <version>1.2.0.RELEASE</version>  
              </dependency>  
            </dependencies>  
          </plugin>  
   

8. Executing the goal spring-boot:run in your IDE will now launch the application and automatically reload your content. Debugging with breakpoints and hot reloading your classes  seems to not work with this run configuration any more. But if you want to work on the backend of your application, you could run the main class like before.

If anyone knows a better way to setup a development environment, I would be curious about it, just tell me. Especially it would be nice to have only one run config for reloading static content and classes with breakpoints and stuff alltogether.

Declerative Programming in Java With Dagger Dependency Injection

Most web developers got already used to working with Dependency Injection (DI), but other developers tend to avoid this topic in e.g. desktop applications. First of all: dependency injection does only mean that the inversion of control paradigm/pattern is used. As a consequence, domain objects don't get their dependencies (other objects, services etc.) by themselves, but have them injected (at construction time). This isn't necessarily done by a framework, the easiest way is to just have constructor arguments for all object fields. For example this

MyObject object = new MyOject(new Dependency());

class MyOject() {
  private Dependency dependency;
  MyObject(Dependency dependency) {
    this.dependency = dependency;
  }
}

is better than this

MyObject object = new MyOject();

class MyOject() {
  private Dependency dependency;
  MyObject() {
    this.dependency = new Dependency();
  }
}

because of some reasons. The most important reason is, that the second example doesn't support different implementations for the dependency. Imagine you want to do tests and mock a heavy database connection. Using interfaces in those situations and an injected implementation is recommended. Second, if you change something on the dependency class, you have to touch the intrinsics of the object class, which doesn't sound right, because you don't want to touch this class. 

After it's clear to use DI, one can go a step further. Instead of how our dependencies are solved, it would be nice to just say what dependencies we want to have: declerative programming. How they are solved is easy most of the time and handled later, even in a declerative manner.

So for Java SE applications, it's not trivial to chose the right framework for injection. For the platform standard CDI, an implementing library is needed. Other containers, like Google's Guava or Spring are rather heavyweight and provide a rich set of features. However, there's a new shooting star I dove into: Dagger. Promises to be simple and fast, because it's (optional) a compile time thing. And I can confirm that it's easy and nice.

For example how many times have you already used the Singleton pattern? With dagger, you can just annotate your class as a Singleton and the framework does everything else for you.

@Singleton
public class Config {
    public int WIDTH = 1280;
    public int HEIGHT = 720;

    @Inject
    public Config() {}
}

A small configuration for a renderer framework of mine. Can't get any simpler than this - only one odd @Inject constructor annotation I don't understand completely. To obtain the service, you declare the injection in the consuming class. For example a context class of the application.

@Singleton
public class Context {
    @Inject Config config;
}

The context class is not meant to provide access to the configuration. The configuration can be injected directly into all other classes as well.

There is a ton of other features and having some objets wired together automatically is great. But I already found a job that Dagger can not fullfill - something that is called assisted injection. The factory - for example for your game objects - can be injected into the context. You can inject something like a provider as well; this is an object that works like a factory but cannot take your parameters to construct them. While other frameworks may be used for injection of objets with partially managed fields, Dagger can't do it, maye can do it in the future.

Java + Maven: Use local dependencies with maven-assembly-plugin

Every now and then we come across dependencies that can't be found in a repository. While there is a simple way to tell maven how to use a local file as a dependency with there is one major issue. The maven-assembly-plugin will not copy your local libs into your fatjar. I found several ways to somehow tell maven how to handle maven/the maven-assembly-plugin that the provided dependencies should be asembled as well - one looks scarier than the other and none of them did what I wanted. To make it short: After I ripped out my hair several times trying to manage such... screwed needs, the most satisfying answer is probably: don't do it this way.

If there's no way to get your own dependency repo server, where you can put your lib (which should be the case most of the times you program small personal projects), then just place all dependencies somewhere in your repo and let other programmers do the rest for themselves. Sounds lame, can be pretty easy and simple: One should install the local dependency as a local dependency. This is the stadard way maven recommends and it is robust. Can be done with

This installs a given jar into your local maven repo. Minimal pain, minimal effort, works with (probably) all plugins, because it's a simple provided dependency.

Get normal for cubemap texel

Since I came across this problem and wasn't able to find an easy solution on the internet, I decided to write s small recipe to calculate normals when you want to do manual mipmapping/radiance convolution with cubemaps in OpenGL. I use compute shaders, so for geometry/vertex/pixel-pipeline, you could use layered rendering and other stuff.

First of all, the shader needs the current cubemap face index as a uniform variable. I recommend using the standard OpenGL indices (see link below).

Most likely, you are using the standard cubemap layout. If this is not the case, you have to change the vectors in my code. So with a given face index and a given texel position, the problem can be solved:




What happens here is that I calculate the pixel position in texture space with the help of the invoation position. The compute shader is invoked with cubemapfaceResolution.x/16, cubemapfaceResolution.y/16, 1. Knowing which (OpenGL) world axis the view direction of the virtual camera, facing the current cubemap side from the inside (cubemaps origin) is, the other two axis are the two orthogonal axes. These two axes' values grow with the texelcoordinates we already have. But therefore, they have to be remapped from 0 - 1 to -1 - 1. The resulting vector can be used to sample a cubemap as it is. Normalization could be unnecessary.

Using Go with eclipse

I like how different platfoms like Java, C++, build tools like maven, gradle etc. are integrated in eclipse via its extension mechanisms. So the first fight every tool that wants me to use it has to win is its eclipse integration. Because the usage of Google's Go with eclipse isn't a complete no-brainer, I want to share the way I did my setup. So here's a guide how you can setup Go on Windows, with eclipse luna.

1. Install your go distribution
   You can download your distribution from the official download page. The installation is quite easy. After completion, ensure that your environment variable GOROOT points to your Go folder. The variable GOPATH should point to your chosen workspace, in the means of where you want to place your Go projects. Or where you have any libs or other Go code. This sounds like an easy job, but seems to be confusing for half the internet, me included. It turns out that every directory in the go path has to have a well described structure, that you can find here. We will take another look later, when the run configuration in elcipse is confiured. You can check if Go is properly installed via a shell with "go version".
2. Install eclipse integration
   Within eclipse (luna) go to Help -> Install new software and use http://goclipse.github.io/releases/ as path. Chose the GoClipse project and install.
3. Create a Go project
   This is fairly easy: Restart your eclipse, chose File -> new Project -> Go Project . You could check the box for automatic main method generation. Now slow down, first chance to waste time ahead: You should create a subfolder in src because if you just place your first Go file in the source folder and try to execute it, you would get go install: no install location for directory as a response. Also not nice is that eclipse auto generates a main.go file and places it right in the wrong folder...Took me half an hour to figure out that not my Go installation is the cause, but that I placed the source file in the top source folder. Don't do that. Create a Go file, your main function if not already done.
4. Adjust your path
   As said before, the GOPATH variale shows your workspace. If you have several IDEs or several projects, it could be useful to use the run configurations to override the path. Therefore, open Window -> Preferences -> Go. This is where you could set a path for your eclipse executions if your default path is not the right one.
5. Add a debugger
   Probably the most interesting part. Since Go is a compiled language, you have to work with debug symbols. I think Go's compiler is based on the GCC, therefore you can use the GDB. On Windows, you could get trouble finding it, so here is your link. Install wherever you like it and afterwards, go back to your eclipse. Right-click your project and chose Debug Configurations. Select the Debugger tab and tell your IDE where your gdb.exe can be found. Uncheck the box Stop on startup at main because this won't work with your go program and apply the settings. Now you can use eclipse debugging as you know it, with breakpoints and stepping and stuff. Remember that go programs are not fully compatible to gdb, so there will be some issues. Let me correct myself: There will be many issues. Doesn't work very nice at all. But at least you can use it.

Compute shader advices

Recently, I had a lot of pleasure with OpenGL's compute shaders. With this lot of pleasure came a lot of pain because I made some (rookie) mistakes. So I wanted to share my experience and some advices I have, just in case you have troubles too:

• The first thing you should check are your texture formats! No, really, double check it, don't repeat my mistakes. In your compute shaders, you could use your images (not textures) with
  
  
  glBindImageTexture(unit, textureId, 0, false, 0, GL_WRITE_ONLY, GL30.GL_RGBA16F);
  
  
  of OpenGL version 4.2 as an output texture. Of course you could use GL_READ_ONLY or GL_READ_WRITE if you use the texture differently. Also keep in mind that this call binds an image, not a texture. And that's why you have to provide a mipmap level you want to attach. I used the wrong format once, namely rgba32f, which my rendertarget attachments didn't have, and it resulted in non existent output from my compute shader. Very frustrating but correct behaviour.
• Keep in mind that you could use your regular textures via samplers in your compute shaders, too. Simply bind the texture and have a  similar line to this in your shader
  
  
  layout(binding = 1) uniform sampler2D normalMap;
  
  That's helpful if you want to access mip levels easily.
• Since even in the OpenGL super bible is a typo that doesn't help to understand the compute shaders built-ins, I recapture them.
  With dispatchCompute you have to provide three variables that are your group counts. A compute shader pass is done by a large number of threads and defining clever group counts/sizes will help you to process your data. In graphics related cases, mostly you will need compute shaders to render to a texture target. So it would be clever to have a certain, two-dimensional amount of threads, wouldn't it? Define your group sizes corresponding to your image size: a 320*320 image could be devided into 10*10 groups, or tiles - and each will have 32*32 pixels in it. So you should define your group size as 32, 32, 1. Now you can dispatch 320/group size threads, which will be 10 groups, for x and y dimension. In your shader, you will be able to use the built-in gl_WorkGroupSize to have this information in every invocation of your shaders main method. To uniquely identify your invocation, you can use the gl_GlobalInvocationID. If you use your shader like I said in this example, this would contain your texel's position the invocation would have to write. And that's how you can use compute shaders to manipulate your textures. Additionally, there is a gl_WorkGroupID, that identifies your tile/group of the invoation, and gl_LocalInvocationID, that is your pixels position in its tile. Sometimes, it could be useful to use a flattened identifier - for example if you have a task that requires performing an action just 12 times, but has to be done in the compute shader - and therefore you can use gl_LocalInvocationIndex. You can use it as a conditional to limit some code paths like
  
  

  if(gl_LocalInvocationIndex < MAX_ITEMS) { processItem(); }
  
  For a better understanding, have a look at this post, which has a nice picture and another explanation of the group layout.

What else? Compute shaders are awesome! I like how easy it is to invoke them, independent of something like the graphics pipeline. Use compute shaders!

Quick look at my OpenGL engine

I just want to share a small screenshot of my OpenGL rendering project. Includes physical based rendering, a global illumination concept daveloped by myself and realtime (glossy) reflections as you can see on the screenshot. Realtime of course - seen on my GTX 770 in full hd at max 300 fps.

Java 8 default methods for your game engine transformations

Although transformation and class hierarchies in game engines are a topic for itself for sure, I finally arrived at a point where I just want every single of my regular game objects to be a transformable entity. Those objects that don't act as something that can be transformed are outside of my interest, they need some default behaviour I don't care about. I think that is the way the Unity engine took, too. A shared super class might look like a good idea, but we are often warned about such kind of class hierarchies.

While C++ offers multiple inheritance to implement things like this very easily, in languages like Java, you probably have to use composition - which should be favored over inheritance nevertheless. The problem is that sometimes, you get lost in interfaces and class fields... and see yourself write interface implementations again and again while delegating interface calls to field objects.

The last sentence is the catch-word: I tried to learn about Java 8's new stuff and stumbled across default methods. While mainly created to guarantee binary compatibility when changing interfaces, they offer a nice way to implement transformations within one file, without the need of (nearly) no other implementations or stuff. Here's how I did it:

I have a class called Transform. This holds a position, an orientation, a scale and is mostly a data holder. Additionally, I created an interface called Transformable. If this would be a class, I should have implemented the state (which now is in Transform class) in this class. But it's an interface. My gameobjects implement this interface, so I would have to implement all those move(vec3 amount)-etc-methods in this implementation. With default methods, I can now provide implementations on the interface tiself - combined with a pattern I don't know the name for anymore, this could be powerful: methods implemented by the interface can be called by the interface. This means I can use a non-default-implemented method getTransform() on the interface in my default methods.

For all classes that implement Transformable, it's sufficient to provide a transformation, because it needs getTransformation() to be implemented. That's because interfaces are not allowed to have state and one has to add the field to the implementing class.

Where this really shines is in situations where you would use (method)-pointers in C++: When you have an object besides your regular game objects that has to be a transformable, but is attached to another object that controls their transformation, you can implement the getTransform()-method with returning a field object's transform. Best example is for gameobjects that have a physics componentn attached, that should win every transformation war.

Additionally, I made the gameobject interface a subclass of my transformable interface, so that I can have different entity types for game objects, lights, environment probes etc. Some of them are not movable, like a directional light - therefore, I can override the directional light's move-methods to not do anything. And then, the subclass interface can call it's superclass interface's methods, too: For example the default implementation of the game object interface's isDirty()-method uses the superclass interface's hasMoved()- and its own animationHasPlayed()-method, if it's an animated entity.

So for the maximum price of a method call, that the interface has to do on itself when a transformation changes, you can have your transformations interfaced. My experience is, that I have very few problems with undesired class hierarchies in the means of "oh no, now I have to implement x or subclass y, but it's not clean code". As always, I'm still a bit uncertain about if this is good use of default methods. But at least I gave them a try and I don't regret my design descision - let me know why this stuff is bullshit, I'm curious :)

Copy textures in OpenGL

Often, people need to postprocess textures, like with a blur or something. While it's sometimes possible to render to and sample from the same texture in OpenGL, it's not recommended, as long as rendering and sampling uses the same mipmap level. However, some cards and drivers let you do exactly this, but I guess most of the times you want to use kernels, you're screwed, because pixels are processed in parallel.

One common approach is to use somthing that is called ping-ponging. You bind the texture to sample from to a texture unit and render to another texture. However, all other application components have to be aware that your fist texture doesn't contain the result they need, thus have to use the other texture, means the other texture handle id. This is sometimes very inconvenient and I didn't want to clutter my code - so I checked an alternative approach that modern OpenGL provides us: copy textures.

With earlier OpenGL version, you had to do a fullscreen quad render pass or a framebuffer blit to duplicate textures, with version 4.3 you can do the equivalent of a memcopy. I duplicated my texture, set my source texture as a color attachment of a temporary rendertarget and set the duplicated texture to a texture unit for sampling. My method looks like (Java, used lwjgl):


I modified the code so that it doesn't take a texture object but the attributes you know from OpenGL. Copying a 1280, 720-Texture takes around 0.2 ms on my GTX 770. I'm pretty sure it doesn't take much more time for a larger texture, but if you want me to test it, just leave a comment. Or if you need additional explanations. Somewhere I saw people having trouble with this simple functionality and most of the times it was because their textures were incomplete. That's why I added all those filter attributes etc.