Ortho and Depthbuffer?

Hi,



I was just wondering - what’s the best way to disable the depthbuffer and turn on orthogonal rendering? Is it valid to directly set GL11 settings or is there another way?



And, once that’s done, what’s the draw order? Does it cycle through the root node’s children in order of addition, cycling through their children in order of addition, and so on?



Additionally, can one change which node is considered the root node of the scenegraph? Say, one has several scenes, and wants to switch easily, so does setRootNode(root_node_of_other_scene) or something?



If you haven’t guessed, I’m trying to see how well a 2D port of jME would work. :smiley: I’m new to jME, though, so I don’t get how everything is set up.

For orthogonal rendering you can set the camera in parallel projection mode (cam.setParallelProjection(true)), no need to disable the depth buffer, so everything is sorted like it should.

As a rule of thumb never call directly OpenGL routines directly, it can have bad side effects because the engine takes care of that on it’s own.



For switching the root node, you can can use the viewPort.attachScene, getScene, removeScenes methods.



hope that helps

The problem is that a 2D setup needs the depth buffer to be off. You want the display to be based on draw order instead of depth value. Then, since you can cluster objects into categories with the root node, you can create Layers for objects to be rendered to (a very useful tool with 2D games).



So… is there a way to disable it?

Whats the point of using a 3D engine when you really want this basic 2D drawing?

Basically, some other people and myself recently got together to make games, and when looking for an engine, jME stood out. However, we want to do some games in 2D (at least at first). We still wanted to use jME, so we thought we’d try making a small library on top of the engine to enable 2D development easily.



jME has a lot of features that Slick doesn’t have - filters/shaders, lighting, etc.



Also, I personally think it’d be interesting to see how a simple port would turn out. Why not? :slight_smile:

codebunny said:
Also, I personally think it'd be interesting to see how a simple port would turn out. Why not? :)
I agree! So long as you can do it mostly on your own steam, he he. There's plenty of room for innovation when it comes to merging 2D & 3D rendering techniques, so I hope to see some cool stuff come out of this.

Though it's a long shot, you might wanna try poking @anykeyh for some pointers. He's working on a very promising 2D project with jME2. They also have a Facebook page you can check out.

Actually I wonder what the problem is , basically you only have to use only x and y coordiantes and thats it, I don’t think you need to change anything in the rendering, just use quads or similar. draworder then can be set by useing the z axis? Or am I mising something?

@erlend_sh: Actually, the conversion shouldn’t be that hard if I can manage to get the DepthBuffer off. Most of the features are already there, basically the only work I’d need to do would be to create classes that lock things into a specific plane. I’ve already done some work on a personal 2D game engine with LWJGL (still unfinished, unfortunately), so I have a good idea of what to do.



Hmm, interesting… It’s a shame; they’re not actually using 2D, it looks like they’re just locking the camera and setting up some system for their Spatials, but that does look cool… I’ll check it out. :smiley:



@EmpirePhoenix: You actually do need to change things up a bit if you want 2D to work well.



Firstly, it’s important to switch from perspective to orthogonal rendering. If you don’t, the edges of the view will appear to tilt away from the center. To make the game look like it’s a flat plane, you need to tell the render process to ignore that third dimension.



Secondly, the DepthBuffer should be turned off. 2D graphics work based on draw order, not on z-distance. It’s true, I could work out a rough system for organizing my sprites based on depth, but such a system wouldn’t scale perfectly, would be inefficient to organize, and unnecessary.



Also, a pleasant side effect of no depth buffer is the ability to automatically organize your rendering based on the data structure you store your objects in (why I mentioned implementing Layers earlier). :wink: It may not sound like much, but when you put it into practice you really appreciate it.

Why don’t you take a look at Slick2D then? It does what you need. Interfaces with Nifty (GUI) too, just like JME.

I made a Isometric engine for it before I decided I needed 1st eye perspective and came here. You could of course use a screwdriver as a chisle, but it might object :wink:

:slight_smile:



I’ve suggested it to them, and they wanted to try this first. I figured that we’d find out fairly quickly if a port would work or not.

So… is there a way to turn off depth-buffer? :?

Use AppSettings.setDepthBits(0) to turn off the depth buffer. You can also use a material with RenderState setDepthTest(false)

If you have any alpha blended sprites, make sure to use the transparent render bucket (Spatial.setQueueBucket(Bucket.Transparent))

Thanks.



The closest I could get that would compile was:



[java]settings.putInteger(“DepthBits”, 0);[/java]



in the first line of simpleInitApp(). It runs, but nothing changes about the DepthBuffer. Do I have to do something more?

You have to change the settings before calling start() on the app by using Application.setSettings()

Okay… It’s still not working, and I’m not sure why. I’m trying to modify the HelloAssets tutorial:



[java]

public static void main(String[] args) {

HelloAssets app = new HelloAssets();

app.setupSettings();

app.start();

}



private void setupSettings()

{

AppSettings s = new AppSettings(true);

s.putInteger(“DepthBits”, 0);

setSettings(s);

System.out.println("Depth Bits: " + settings.getDepthBits());

}

[/java]



Can anyone see something wrong with this? It runs, and it prints the DepthBits as 0, but there’s no change in how the game is rendered.