Lighting problem with multiple meshes

Picture of problem

How can I avoid this particular issue with the lights. I’d like to have some parts of my game pieced together from different models, these are walls and doors but later I’ll have a few other things added in. The problem is that the lighting should act on the entire row of objects as a whole not each one seperately.

I have a few theories about how to handle this but I’m hoping there is a better one somewhere.

Turn off lighting on the building parts, this is a simple solution but not real great in some regards. Light mapping might be great for this if I understand how it works correctly, it’s just a texture applied to nearby objects to make it look like light, I think that this could be done pretty easy in jME though but I’ve never done lightmapping in any way shape or form so I’m not sure.

Create my walls dynamically, I could make a simple wall from the data available and have less seams and make the problem a lot less obvious, but I don’t want all my walls and doors to look flat and alike so I don’t think this is useful at all but… possibly merging the mesh data together behinds the scenes would work. This is pretty hard for me, especially when it comes time to figure out how to get the texture coordinates and stuff to match up right, but I could probably figure this out or brute force it by creating an actual node and then using getworld coordinates on all the meshes, that’d be slow and I think textures would still give me trouble.

Making each building a complete object in a modelling program… isn’t an option because each building will be player designed from simple parts, and could be damaged individually/modified.

Insert your simple smart easy solution here


It looks to me like you have smoothed normals on your object, this means that the two vertecies next to each other from different objects, will have different normals (in your case, 90 degrees apart), and so the lighting will be very different. If you have non smoothed normals, you will have 3 normals per box section vertex, and any faces facing the same way on consecutive box sections will have the same normal, and the lighting will be nice and smooth.



That sure seems like an easy solution, I did a quick test of telling blender to 'set solid' instead of set smooth (in case it had somehow defaulted to smooth) and it doesn't seem to have changed the end result, so I might have done something stupid in my quick test(I'm at work and can't get into it too much at the moment). Looking at the xml file it does look like the normals are smoothed (they should be at 90 degree angles and they aren't). A look at the xml file it seems like the normals have been smoothed in it so maybe I saved to the wrong folder or something.

I'm not sure how it works, does blender have a jme exporter?, or do you have something else to convert them?

It may be that the importer or exporter can only cope with smothed normals, my ac3d loader can only cope with smoothed ones atm, but thats cause i wrote it and don't need non smothed ones atm :slight_smile:


I had the same problem and after some discussion in #jme I changed my AC3DLoader (btw it's interesting that there are two now) to calculate normals per vertex and non-indexed. This means higher memory consumption and lower performance but it looks much better for non-organic structures (architecture, machines, etc.) and the performance loss is not that big.

The difference now is that there are as many normals per vertex as there are surfaces the vertex is a part of. Before there was one normal for each index entry and that makes smooth normals which is fine for organic structures but looks very bad for buildings.

Especially for AC3D it would be perfect to honor the flat/smooth setting and the grease angle to determine which vertices can be shared and which should be set per surface. I read about that and it's far from easy to implement.

Yup, I had the same issue. The normals can not be indexed in the same way vertecies can. I was hoping there was a way to share the vertex data, with independant normals for each vertex index, but it seems not.