Normals calculation for terrain ignores scaling

[Rulatir]

Yes this function in the CTerrainSceneNode.cpp file in the Irrlicht Source code and rebuilding it to produce your own DLL.

Unfortunately modifying Irrlicht is not an option in my case. I must live with what there is, and so I must keep appealing to the developers' common sense in the hope that they will fix the problem.

This isn't a bug. Perhaps it isn't the behavior you want, but it is consistent behavior and it can be very useful.

The behavior I want is the behavior pretty much everyone will want, and the current behavior is inconsistent with common sense. Normals should just plain obey, period. I add geometry with transformations that are claimed to be supported by the engine, and I want normals to reflect this actual geometry, not something that the loading routine sees fit to generate, ignoring parameters passed to it! This is a reasonable expectation. It is unreasonable to expect the opposite. Not recalculating normals on a transformation (which would have to be done once anyway, not every frame) is not an optimization because optimizations must still yield correct results, and here the result is incorrect. Barring special effects, it just never makes sense for normals not to reflect the final geometry. You can of course try to convince me otherwise.

[Munger]

Can you suggest an example of its usefulness?

Special effects on a game character - they go through a teleporter and shrink along the width and depth, but not along their height. If you modified the normals to match the model, it would look dark.

It actually looks really cool to flatten a model in one dimension. Try it out. It's the same affect you'd get with a normal map, but you're doing it with geometry.

Anyway, the point is that the transformation shouldn't affect your normals. I don't think you'd be too happy if rotating a mesh changed your normals would you?

Going back to this code for a moment:

Code: Select all

IMeshManipulator *meshManip = sceneManager->getMeshManipulator();
meshManip->scaleMesh(terrainSceneNode->getMesh(), vector3df(1.0f, 0.00001f, 1.0f));
meshManip->recalculateNormals(terrainSceneNode->getMesh());

I suspect (once again, without looking at the code) that the terrain node doesn't like you fiddling with it after the LOD has been calculated. Maybe you should try a different type of node. ISceneManager::addTerrainMesh can give you a mesh that you can pass to ISceneManager::addAnimatedMeshSceneNode to create your node. Now you can use the mesh manipulator to generate normals. I hear you saying 'that's just the same thing!', but notice that addTerrainMesh accepts a maxHeight parameter. That looks like it can scale the mesh to your liking before you generate your normals.

[hybrid]

I think that there are some bugs - or at least unexpected behavior - in the terrain node due to it's breaks with the usual scene node interfaces. The terrain ignored most transformations in the beginning, and also the detailmap material was not accepting dynamic lighting some versions ago. So let's just clean up the code and get it working in all situations (as long as the performance hit is neglectable )

[Rulatir]

Can you suggest an example of its usefulness?

Special effects on a game character - they go through a teleporter and shrink along the width and depth, but not along their height. If you modified the normals to match the model, it would look dark.

Precisely: special effects. It is reasonable to expect the user to go to some lengths to achieve special effects. It is not reasonable to expect someone who doesn't do special effects to go to lengths in order to support the potential possibility of special effects. At least I believe this to be against Irrlicht philosophy of providing Sensible Defaults. I firmly believe that automatic recalculation of normals for scaled terrain is a sensible default.

Anyway, the point is that the transformation shouldn't affect your normals. I don't think you'd be too happy if rotating a mesh changed your normals would you?

I invite you to advance one tiny abstraction level up. Normals are used to represent face orientations for the purpose of lighting, right? If you rotate a mesh, the orientation of faces changes, right? It isn't a matter of my being happy with it or not. It is a matter of fact. The library should do whatever it takes to provide an API that models this reality, and to abstract away details of representation.

[Dorth]

If you just read above your post, it seems hybrid already agrees with you, so relax. I think it should be like you say too, but anyway other better terrain nodes exist on the forum AND fixing this one shouldn't be too much of an incredible task either.

[Rulatir]

1.6 still has the same bug. It appears nothing has been done about it.

I want to load terrain with non-1.0f vertical scaling and expect the resulting meshes' normals to reflect the actual scaled geometry which I am going to render, NOT!!! the original unscaled geometry as stored in the height map file. Am I demanding a star off the sky or what?

[CuteAlien]

Just 2 notes - sometimes things get unfortunately forgotten, especially if they are not on the bugtracker. Adding a bugtracker entry always makes problems more visible to us than forum messages.

And also you can add own SceneNodes to Irrlicht without changing anything within the engine. So as a workaround you can use a modified terrainnode in your code.

[Rulatir]

Just 2 notes - sometimes things get unfortunately forgotten, especially if they are not on the bugtracker. Adding a bugtracker entry always makes problems more visible to us than forum messages.

Hmm... I was under the impression that this forum was the preferred channel for bug reports. Perhaps it was so in the past? Anyway, of course I'll make use of the bugtracker.

And also you can add own SceneNodes to Irrlicht without changing anything within the engine. So as a workaround you can use a modified terrainnode in your code.

Writing a modified terrainnode is a big task, and from what I've seen, the alternatives announced on the forums tend to require changes to Irrlicht (e.g. to store more data in vertices).

[hybrid]

No, finxing the normals simply requires you to fix the normals calculation code. You could copy and rename the terrain node, fix the normals code, post it here, and use it while we didn't add this to the engine.
Providing fixes together with the bug ticket will significantly decrease the time until we can fix this in the engine!