Recent Posts

Hmm, slightly cross at the response the OP got on #lwjgl though. Is there a transcript and can the transgressors be hung by the toenails until sorry?

Cas

Transcript at 21:43, no surprise at who the perpetrator was.

If I was to guess I'd say its a nvidia driver bug, anyway tried here but can't reproduce it on my nvidia card (although using latest stable nvidia driver as opposed to experimental). Anyway there was a change in the way xrandr 1.4 parses display settings recently, so maybe OP might have some luck with the latest nightly build of LWJGL.

The only way to do shininess with the fixed functionality is to render one face at a time, switching the shininess between (it makes no sense to do it per vertex, that's why it's a uniform). If you are using your own shaders however, you could make a custom attribute variable  and add the data to your vbo, or potentially even better - use the alpha channel of your colour as a shininess. This also works if you are using textures provided that you aren't using the alpha channel.

As for the individual texture for each face, I think you might be confused because it really makes no difference whether you are in immediate mode or are using vbos.

Hmm, slightly cross at the response the OP got on #lwjgl though. Is there a transcript and can the transgressors be hung by the toenails until sorry?

Cas

The clamping needs a little work, sometimes you're seeing angles on the composites that make for awkward visuals. Particularly, it seems that at the 45 degree pitch and 45 degree yaw position you see the top or bottom part. This is probably because the clamping for each dimension doesn't depend on the value of the other dimension (giving the space you see the 'top' a square shape rather than a round one like it should have.) i.e

Code:

float fudge_factor = .4;
int direction = 0;

if(n.x < -fudge_factor) {
   direction | back_bit;
} else if (n.x > fudge_factor) {
   direction | front_bit;
}

if(n.y < -fudge_factor) {
  direction | right_bit;
} else if (n.y > fudge_factor) {
  direction | left_bit;
}

if(n.z < -fudge_factor) {
  direction | bottom_bit;
} else if (n.z > fudge_factor) {
  direction | top_bit;
}

return direction;

This gives you any of 26 possible directions; Seems the eye expects the top images to show up later at 45-degree angles than this simple clamping gives me. Another possibility is I need another layer of angled images closer to the top view, which isn't my favored solution but might be the way to getting the sprites to have a production quality appearance from all directions.

Additionally, I've noticed when the sprites are at the edges of a perspective view, some skew needs to be applied to the quads or the parts look disjointed. I'll have to look into how to get the right amount of skew...

I Just found the function glColorPointer() , so I can do colors.

Still have no idea on shininess.

How would you go about allowing each vertex / face on a VBO have its own color, shininess, ect?

Also, is there a better way to use a custom texture for each vertex / face in a VBO's than GL_TEXTUREX?
This page showed a way to do it using immediate mode, but it was a little confusing and I'm not sure how it would translate to VBOs.
http://lwjgl.org/wiki/index.php?title=Multi-Texturing_with_GLSL

Got an issue report for libgdx the other day, see http://www.badlogicgames.com/forum/viewtopic.php?f=11&t=9042 for full details.

Basic setup: user runs app in fullscreen mode. Execution fails running the app a seccond time, on Ubuntu 12.04, using an NVIDIA GTS 540 with experimental drivers. Any idea what could cause this? I'm having difficulties reproducing this myself, maybe someone else encountered it as well.

Near the end of your world update call there is

cur.model.texture.release();

. This is destroying the texture, I looked it up and it's an interface but presumably the implementation would call glDeleteTextures. This means that next time you bind the texture, it is like you are simply binding a non-texture.

This was the problem. Not only was I calling this every update, but I called it immediately after loading the texture, which is kind of not good. I thought this method just allowed other textures to take its place of something. Thanks so much for all of your help. I can't thank you enough.

Near the end of your world update call there is

cur.model.texture.release();

. This is destroying the texture, I looked it up and it's an interface but presumably the implementation would call glDeleteTextures. This means that next time you bind the texture, it is like you are simply binding a non-texture.

Your whole rendering code is wrong though. The idea of vbos is that you send the data to OpenGL when you create them, then each frame all you have to do is setup the pointers and call the draw functions. You are resending the data every frame which would be intensely slow I should imagine.

I for one would be quite interested to see how it turns out so...