Lighting and Flickering objects

And I’ll ask again more directly, where did these meshes come from that do not have their normals?

I know for sure that Blender doesn’t export normals by default if using OBJ format. You have to tick a checkbox for that to happen.

@Momoko_Fan

blender 2.5 or 2.49?

I’m guessing 2.49?

pspeed said:
And I'll ask again more directly, where did these meshes come from that do not have their normals?

These meshes come from old .jme (jMonkeyEngine 2) Node/Geometries containing a TriMesh, from an older version of the project. missingno and I were tasked with porting the project to jME3, so I wrote a script to dump all buffers of the TriMesh and imported that back into a jME3 Mesh, but none of the .jme TriMeshes had a normal or binormal buffer.

The port is done now, so we're focusing on adding the new cool stuff that jME3 allows now. One of those cool things is lighting, which the old version didn't have, hence the lack of normal buffer on those .jme files.

The .jme files themselves were made from various programs over the years. In order to convert them to .jme, an application was written which, I am guessing, didn't copy the normal buffer. We still have the source (some are Blender files, some are from 3DS Max, some are from MilkShape 3D, some are from Maya, some are just .obj's) for some of them but not all, hence the need to be able to generate them somehow.

Which is probably impossible to do automatically. I’m not trying to be discouraging but I suspect way too much information has been lost.



For example, when you need a cube where each side is flat, in modern OpenGL where everything is per-vertex then you need four vertexes per face and cannot share them. Each will face will need its own vertexes so that they can have the same normal vector as the face. In the old days, there was bind per primitive which allowed the whole face to have the same normal. So there it’s possible that old meshes share vertexes and its impossible to generate good normals…



In that case, hard edges would look like rounded edges unless you break apart the vertexes and you have no idea if you can… because maybe those edges really were supposed to be round.



The other issue is texture coordinates. If you assume that shared vertexes should be rounded then you may come across non-shared vertexes where different texture coordinates were needed… but really should be rounded.



If you can make assumptions about your meshes that all surfaces should be flat or something then it might be possible to write a utility. Otherwise, I suspect that your only option is to somehow dump them in a format that can be loaded into an app like blender, use its tools to automatically attempt normal generation, and then painstakingly hand-tweak things until they look right.

You can generate normals but for some types of models you get incorrect ones and you have to fix them manually. So I would so Paul you’re not really correct. I had encountered many models online that had incorrect normals and the work in fixing them was too tedious so I had to discard them.

About the OBJ issue: I believe that by the spec, OBJ exporters are not required to export normals even if the model has lighting enabled. By default that checkbox is disabled in all versions of blender including 2.5x. You simply have to remember to check it if exporting for jME3.



jME2 had a NormalGenerator class, that I actually started porting to jME3 but stopped because it required copying attributes which wasn’t exactly easy. However in your case it will work since you have the originals from jME2 which did not have worry about other attributes.

There’s been huge progress when it comes to lighting, but we are still encountering small quirks.

As for now, if we use a texture on the NormalMap parameter of the Lighting material, it will sometime create jagged effect on some GPUs.



For example, the problem occurs on an ATI Radeon HD 4550:

If an ambient light and a directional light are present, the jaggedness is barely present:

http://i.imgur.com/EjM8q.jpg



If we remove the directional light, then the problem is clearly present:

http://i.imgur.com/eP1QL.png



But if we remove the the NormalMap texture, then the jagged shadows disappear:

http://i.imgur.com/oon7f.jpg



For some reason however, even though there is no directional light and no NormalMap texture, the upper torso of the player model is more lit than the lower part of the body. This is strange considering AmbientLight supposedly applies the same light intensity everywhere.



Anyways, the problem doesn’t seem to occur on the Nvidia cards we tested. Also, the TangentBionormalGenerator is called on every mesh.

Any idea what is causing this?

I assume you have set the shininess parameter for all materials in the scene? Is there a way you can make a test case for this? Does it happen only with your models or with jME3’s shapes as well?

Indeed, the shininess parameter is set for all materials in the scene.

This problem appears, to different degrees, on all models which have a texture applied to the NormalMap parameter. (although we do not use any of jME3’s basic shapes)



I’m still don’t know if it is related, but even without a NormalMap, the lighting seems uneven on the models even if there is only an ambient light. (see 3rd pic)

Yes I understand. This is why I asked to test this on one of the jME3 shapes, that way we can find out if the issue is with the model or with something else

It does work fine on jME3 shapes, so the issue is with the model.

In other words, you replaced the models in your application with jME3 shapes (probably by changing assetManager.loadModel() to creating the shape) and then you saw a correct result.



By process of elimination it is possible to deduce that the issue can’t be with the position, texture coordinate or index buffers because the model looks fine (shape wise) and the texture is applied correctly. Then it must be either the material or the normals on the model.

Although I agree with your reasoning, there are inconsistencies which I can’t wrap my head around.


  1. Almost all models have normal data which was exported directly using blender or using the normal data from the previous .jme file. Yet, the staggered shadow appear on them as well.
  2. The material is the basic lighting.j3md.
  3. The shadow problem only occurs when a texture is applied on 'NormalMap" parameter of the material. Shadows look fine when we only use the “DiffuseMap” parameter.
  4. The problem only seems to be present on ATI card.
  5. Again, and I’m not sure if it’s related, but shadows seem to be cast even when there’s only an ambientLight, which goes against the definition of the class itself. (http://i.imgur.com/oon7f.jpg)

It sounds to me like bad tangent vectors… given that they are only used for normal maps and bump maps and the default behavior for no tangents looks much better on nVidia. Maybe bad tangents do too.



Though mostly I think this because you’ve eliminated everything else.

Tangent vectors are created using TangentBinormalGenerator right? Or are they part of the mesh themselves in the same way normals are?

I don’t think they’d be a part of the mesh and if you are using the generator then they’d be replaced anyway.



…but I’ve never really understood how that can work in all cases. I can pretty easily imagine situations where a generator would construct bad tangents depending on the mesh data.



Edit: but I’ll admit to not know how it works… I just know it’s not an easy problem.

Thank you for your answer, I if we ever stumble across a solution we’ll make it known.

If you know anyone who does have deeper knowledge of the inner workings of light and shadow or already came across this issue, let them know about us :P.

Would it be possible for you to provide one of your j3o files (preferably simplest one) with the issue?

Sure,

The j3o:

http://upload.gaiatools.com/files/redpathmuseum_0.j3o



The texture:

http://upload.gaiatools.com/files/redpathmuseum512_0.png



The normal map:

http://upload.gaiatools.com/files/redpathmuseum512.normal_0.png



Hope this helps :slight_smile:

I have tried it on my ATI and NVIDIA cards. I cannot reproduce the issue

Here’s the code I used to load the model

[java]Spatial model = assetManager.loadModel(“model.j3o”);

TangentBinormalGenerator.generate(model);

AmbientLight al = new AmbientLight();

rootNode.addLight(al);

DirectionalLight dl = new DirectionalLight();

dl.setDirection(new Vector3f(-1, -1, -1).normalizeLocal());

rootNode.addLight(dl);

Material mat = new Material(assetManager, “Common/MatDefs/Light/Lighting.j3md”);

mat.setTexture(“DiffuseMap”, assetManager.loadTexture(“diffuse.png”));

mat.setTexture(“NormalMap”, assetManager.loadTexture(“normal.png”));

model.setMaterial(mat);

rootNode.attachChild(model);[/java]

Screenshot of model on ATI Radeon HD 5770