Correct me if I'm wrong, but I thought the userData was mostly for collision info with contactlisteners. I think your original method was fine.

I added both of those methods to my initialisation and the texture is still rendered with a white background.

At the end of nineties, C/C++ fans gave the same kind of arguments to explain that as Java is written in C (Jikes was written in C++), it can't outperform C which is wrong. One of my teacher wrote a program that converted Java (1.3) to C code during his thesis and he only obtained a very small gain (less than 5%) after years of work. Brian Goetz explained that memory allocation and method calls are between 2 and 4 times faster in Java. I really think that almost no human being is able to write a better machine code or assembler code that a compiler like GCC except in particular cases on a small piece of source code and if you really believe you can be more efficient than the JVM, don't use Java. I'm sad to see these kinds of prejudices about Java even here on JGO.

Ok actually the soft lights are the best option, but that doesn't matter now.

I thought about modding Box2DLights so that the shadows are not rendered over the Body.
I don't really understand the code, probably because I only know ridiculously small parts of OpenGL, but I thought I don't need this much OpenGL to do the kind of change that I want:

It looks like the shadows are drawn from the first collision of a light ray with a Box2D Body into infinity. I'd like to change this to the second collision, so it's the collision of the light ray with the other side of the Body. This way, the shadow would begin on the farer away side of the Body (seen from the light position) and not be drawn over it. Hopefully I made my idea clear enough.

Instead of replacing the current way it's done, wouldn't it be possible to add Light#setShadowBehindBody(boolean shadowBehindBody) or something similar?
I don't want to put extra work on you, but is this as simple as it seems to me in theory? I don't even find the place where the collisions of rays and Bodies are calculated...

You can optimize it even further by exploiting bilinear filtering to get a correctly weighted average of two texels per texture sample. You can achieve a 9x9 gaussian blur using only 5+5 texture samples, which means you'll go from 81 samples down to 10. Another trick is that you can do a 3x3 gaussian blur using only 4 texture samples and a single pass.

Nice tutorials, thanks.

It seems really slow to use multiple fbo's just for a little blur .

Box2dLights, for instance.

Games build with Lwjgl
Games build with LibGdx

i don't want to be childish (even if i am  ) but, let's be honest here, for a newbie game developers, seeing what people has achived with the current language,engines,framework,library or any development tools, will give him a big push up and huge motivation to keep working with that tool, and just like what most of you said (except libGdx extremist fans  )
a noob developer should just stick with what ever he saw "easy" to work with, i don't regret starting this topic cause i really was scared that i will spend months learning lwjgl without being able to finish ANY project, even a little one, so i wanted to ask, and now am sure that i will keep learning lwjgl for 2 simple reason :
1- i like the way i pronounce "lwjgl" 
2- it has a very good wiki to start with   

Learning how to use LWJGL and writing boilerplate code is portrayed to be way harder than it really is.

@pitbuller: That's probably it!

I used 3 unsigned bytes for coords + 2 unsigned bytes for texture coords.

I just changed vec3 to vec4 and added one dummy value + changed UV to unsigned shorts. So they are all now 4-byte aligned and it went to 300 fps on ATI card.

Thanks!

How could I have missed that best-practices page.

Just added frustum culling but finding using the distance formula better...

As anybody else implemented frustum culling in their voxel project and how does it fair over
doing a distance check?

I think I will use frustum culling for other objects in my project, not for the voxels, will stick with distance formula.

I don't think the bottle neck is the ArrayList, more to do with my distance formula, I've now got this:

         int deltax=(int)x - c.getX() * 32;
         int deltaz=(int)z - c.getZ() * 32;
         int deltay = 1;
         int distance2=deltax*deltax+deltay*deltay+deltaz*deltaz;
                   int radius2 = (Chunk.CHUNK_SIZE * 8)
                        radius2*=radius2;//precalculate this
         if(distance2 < radius2)
         {
            c.render();
         }

Resizing the texture on the screen isn't the problem. TextureRegion using the textures native resolution is my problem.

Let's say I have a texture that's 100x100 but I need it to be 50x50 for use with TextureRegion. I need to resize the native resolution to 50x50 before sending it to be cut into pieces by TextureRegion.

For further clarification I'm splitting up a single picture into many little pictures that make up the main picture. I'm making a puzzle type game.

The pictures all need to be a certain resolution for the game to work correctly.

Oh well, that's great to hear then! we just go ahead and try to use it then! Thanks a lot!

First i read through the code of box2light I was a bit worried that it uses a physics engine to do a calculations, and I thought it might be slow, but yeah if you say it's not then it's great news.

I hope it is possible to use it with Stage class right?

So, that means that even if I do not need "more dynamic" system, box2dlight is still better in performance then the fake dynamic overlaying to buffer approach?