LWJGL Orthographic projection render order based on Z

Newbie & Debugging Questions
#1

My problem is that everything renders in order: newest vertices appear on top of older ones. I want vertices with that are pointing out of the screen (Z negative?) to be rendered on top of vertices that are into the screen (Z positive?)

Atm I’m using glOrtho from GL11 class.


		glMatrixMode(GL_PROJECTION);
		glOrtho(0, Display.getWidth(), Display.getHeight(), 0, -1, 1);

Here is my vertex shader.


#version 120

attribute vec3 a_position;
attribute vec4 a_color;
attribute vec2 a_texCoord;

varying vec4 v_color;
varying vec2 v_texCoords;


void main() {
	vec4 pos = vec4(a_position, 1);
	
	v_color = a_color;
	v_texCoords = a_texCoord;
	
	mat4 proj = gl_ProjectionMatrix;
	gl_Position = proj*pos;
}

Here is the image i’m getting.

Here is how I want it to look after changing Z values (I changed render order)

I think this is a problem with projection matrix.
Here is my spritebatcher, I hope I didn’t make silly mistake when implementing Z axis…
http://www.java-gaming.org/?action=pastebin&id=892

It has few bugs, but they don’t bother me. (Not flushing when spritesheet is different and some others maybe) and also it is not very efficient, but I don’t really need efficiency here.
For now I just want to resolve the Z axis.

#2

Hmmmmmmmmm. I think glEnable(GL_DEPTH_TEST) solved the problem…

#3

I just added some alpha to my images.

Turns out that alpha blending doesn’t work well with GL_DEPTH_TEST.

If anyone knows how to fix my problem in some other way, would be really nice, because I’m sick of drawing objects in correct order…

#4

Have all renderable objects hold a Z-Index field.

Sort the array using that field, then happily draw.

No idea how much stuff you are having on the screen but this is always how I do it, if you have an array with 1000’s of objects that can be rendered, then you might have some issues when sorting.

If your iterating through an array, it renders in order from 0 > size.

EDIT: Just re-read your post, my suggestion is probably useless.

#5

You generally don’t want to use depth testing with 2D due to the transparency problem. The most common solution for rendering transparent stuff with a depth buffer (regardless of 2D or 3D) is to disable depth writes and sort your objects. If you only need additive blending you don’t need to sort your objects, but this is rarely the case.

Concerning sorting performance, I wouldn’t worry that much. The order of your objects will not change much between frames, so I’d strongly recommend implementing a simple insertion sort. Insertion sort has the advantage of being O(n) if the list is already sorted and requires no temporary memory. Since we can assume that the order does not change much from frame to frame insertion sort will be extremely fast (except for the first frame when your objects are completely unsorted).

#6 

import java.util.Comparator;

public class InsertionSort {
	
	public static <T> void sort(T[] array, int start, int end, Comparator<T> comparator){
		
		for(int i = start + 1; i < end; i++){

			T current = array[i];
			
			int j = i-1;
			while(j >= start && comparator.compare(array[j], current) < 0){
				array[j+1] = array[j];
				j--;
			}
			array[j+1] = current;
		}
		
	}
	
}

Sorting 1 000 objects

[quote]Insertion sort unsorted: 0.275 ms
Insertion sort sorted: 0.003 ms
Java sort unsorted: 0.083 ms
Java sort sorted: 0.002 ms
Java parallel sort unsorted: 0.084 ms
Java parallel sort sorted: 0.002 ms
First elements: 19369, 19369, 19369
[/quote]
Sorting 10 000 objects

Sorting 100 000 objects

As you can see, insertion sort scales horribly with the number of objects when they are unsorted, but linearly when they are already sorted. Although Java’s Arrays.sort() method is faster in all cases, it generates a large amount of garbage which may cause problems with garbage collection pauses.

#7

The performance isn’t the issue for me… Its the messiness of the code… I just implemented something like you said (I had done in the past), but I’m not content with the results. Since I’m using shaders and sprite batch, I still need to keep the order of the drawing, even though I implemented this, since you sometimes need to flush more than once per frame, like changing projection/modelview matrix.

#8

What if I have two seperate lists:

  1. Sprites that only have pixels with alpha 1 or alpha 0 or Sprites that are supposed to be rendered with additive blending,
  2. Sprites that have pixels with other alpha values between 1 and 0.

Now, all sprites have some kind of “layer” variable, or in other words: A Z-position.
I don’t need to sort list 1. I can simply render it non-sorted with additive blending, alpha test and depth testing enabled.
I sort list 2, then render it with normal blending and depth testing disabled.

Transparency should work and everything should be faster, no? :slight_smile:

#9

The problem with this approach is that usually you’d want blending on all your sprites to get nice and smooth edges as alpha testing leads to clearly visible aliasing. You could enable multisampling and alpha-to-coverage to improve that, but that’d make the second pass do blending into a multisampled buffer which is significantly slower.

#10

Funny enough, I was messing around with GLSL yesterday and I found an interesting little tweak. If you set gl_Position.z to equal 0.1f then you get all the vertices rendering, retaining perspetive. I would think that this would create some sort of flat shader, but now that i think of it, it makes perfect sense. This may or may not relate to what you were asking, I just thought I’d put it out there ::slight_smile: