views:

65

answers:

1

Hey all, I'm writing a little 3D engine for android to better learn the platform and opengl. I hope to eventually use it as a base for little 3D games.

I'm trying to implement lighting right now, and generally following the NeHe opengl android port tutorials. I have a simple spinning cube and 1 light that should not change position. Upon rendering my scene on a device the light appears to "dim" and re-lighten as cube rotates.

This is a swf video of the behavior: http://drop.io/obzfq4g

The code for my "engine" is located here: http://github.com/mlasky/Smashout-Android-3D-Engine/

The relevant bits are:

http://github.com/mlasky/Smashout-Android-3D-Engine/blob/master/src/com/supernovamobile/smashout/SmashoutGLRenderer.java
this is where I'm initializing opengl and setting up my scene.

and

http://github.com/mlasky/Smashout-Android-3D-Engine/blob/master/src/com/supernovamobile/smashout/SMMesh.java this is the code for actually rotating / drawing the cube mesh.

I wish I could formulate a better question; but I'm very stuck/confused and can't even think of an intelligent question to ask besides "does anyone know what might cause the kind of behavior I'm seeing?"

Thanks for any help you can provide.

Edit: Also the slowness / choppyness of the animation in the video is a result of the screencap software. It's smooth throughout the whole rotation on the emu.

+1  A: 

From the video it looks like your normals are incorrect.

For an axis-aligned cube the normals in cube.xml seem off. They should be axis-aligned, not whatever they are. Where did you get the model?

This answer may also be related if mVNormalsBuffer is empty.

genpfault
Thanks for the answer,I'm going to look into this now. The model came from blender, it's just the initial cube converted to triangles and textured. It's exported with a script I wrote: http://github.com/mlasky/Smashout-Android-3D-Engine/blob/master/superexport.py So there could very easily be a problem with the normals.
Electronic Zebra
hey, I just reread your comment. I might be really dumb, but shouldn't vertex normals *not* be axis aligned on a cube? I'd assume only surface normals would be axis aligned.
Electronic Zebra
@Electronic Zebra: See my second listing [here](http://stackoverflow.com/questions/312124/opengl-how-to-avoid-texture-scaling/354140#354140) on how I expect the normals to be for a cube. You can [average](http://www.xmission.com/~nate/smooth.html) your normals to get a smooth-ish cube, which is maybe what Blender was doing. Otherwise for an axis-aligned cube, all your normals are going to be axis-aligned.
genpfault
I haven't figured it out yet but i think you're correct about it being a normals issue. I'll mark the answer tonight after I do a bit more investigating (unless I drink, then I'll just make an ass of myself in public and mark your answer correct tomorrow)
Electronic Zebra