Engine design Tracking (nine. 14.2c) Recent minor updates

1. Bump map and Normal map

Yesterday took the Crytek Sponza (http://www.crytek.com/cryengine/cryengine3/downloads) scene test,

The first use of the model here (http://graphics.cs.williams.edu/data/meshes.xml) found the use of the 1-channel BumpMap, but blade shader does not support, If you want to support the addition of materials and shader, so use this hack, just to run this scene.

BumpMap is a single-channel grayscale image, which is actually a height map in which normal disturbances can be obtained based on the height difference of the shader. The normal map is the phasor of the tangent space.

Bump map is the offset and perturbation of normals, while normal map is a complete replacement of normals.

Normal maps can be produced in two ways: high-modulus baking, and second through height graphs. The second way Nvidia's Photoshop plugin is inside (https://developer.nvidia.com/ Nvidia-texture-tools-adobe-photoshop).

The principle is not much to say, here is a link:

Bump mapping (Bump map) implementation principles and differences from normal map (normal map)

Bump map to normal map conversion method from the above link in the shader inside can be seen, that is, the height of the derivative dx, dy to construct the normal. Here is a reference (the original post is the wrong help post, the reply has Sobel filter code snippet):

Https://www.opengl.org/discussion_boards/showthread.php/168864-HeightMap-to-NormalMap

More references are here (GIMP's normal mapping plugin, various, NXN filter):

Https://code.google.com/p/gimp-normalmap/source/browse/trunk/normalmap.c

Currently Blade uses a 3x3 Sobel filter. This conversion is only available for real-time conversions, but in theory the backend tools can also be used directly.

The following is a blade export plug-in exported Cretek Sponza scene, and in the Model Viewer to see the effect of the scene after the rendering effect can be temporarily to test it first :

This scene is more complex, use it to test the Max Export plug-in, also found in the export of tangent space, some bugs, such as the calculation of the tangent space, the triangle two-side vector, is a vector with length, can not be unit , otherwise for the narrow triangle, calculation error will be exposed.

In addition, there are two weird questions unrelated to the topic, with two models (. obj) above in Max: a material sponza_bricks, and its diffuse map and normal map are the same diffuse map: Spona_bricks_ A_DIFF.TGA, but obviously has the corresponding normal map file in Ah, and with this export model, the rendering result is obviously not correct, the damage was pits, and changed to the correct map is good.

And the map clearly contains specular map, but the material is not set specular map, this I also temporarily did not control.

2. Through the above model, several minor bugs of material Lod have also been tested:

A. Although the material of the model system is updated in a single sub-mesh, the sub-mesh is given the world coordinates of the Materiallod updater, which is the coordinates of the parent model, that is, all sub-mesh uses the same coordinates. This way, if a model is too large, the accuracy of the position will be problematic, and now it has been changed to the real world coordinates of the sub-mesh, so that the precision of the material Lod really reaches a single sub-mesh level.

B. Judge the distance of the material Lod, before using the distance between the camera and the center of the object. When the object is very large, the camera is already inside the object, but it is far from the center of the object, causing the LOD to switch out of the problem, which requires a distance minus the radius of the object (although the interface has already defined AABB but it has not been used).

C. Some submesh have multiple parts and are very far apart (such as the two ends of the scene), but they belong to the same submesh (share the same material), resulting in this submesh is very large, the camera has been in its interior. Such material LOD update granularity is too large, resulting in material Lod has no chance to switch. This is to change the export plugin. Because now the export method is divided by the material Submesh, the same material is merged with the object, this need to press material + object to divide the Submesh, the same material object is exported separately and not merged. As long as the material same object is exported, multiple Submesh are separated consecutively, and plotted sequentially at render time. This way, compared to the previous, from a material corresponding to a drawcall, into a material corresponding to multiple consecutive drawcall, the result will be more than a few drawcall, there is no redundant material switching, is an acceptable compromise.

Use the OGL coordinate system for the 3.UV coordinate system.
Because the coordinate system used by blade is the right-hand system, UV uses the DX coordinate system (U right v down), which causes the "default" tangent space to be left-handed, a bit uncomfortable. So it is changed to the OGL coordinate system, that is U right v upward.

So the default tangent space becomes the right hand, but in the actual cutting space is the use of left-handed or right-handed, but also to see what kind of normal map. Most of the game's normal maps under windows are left-handed.

left-handed and right-handed normalmap are not the same, their G-channel is the opposite . Remember to read the comparison of two pictures on the internet, the specific link forgot.

So the palm option is also added to the export plugin. In general, for a project, these parameters (palm and so on) are predetermined specifications, and then according to the specification of the corresponding model and map, this time the Palm option is fixed, not much use.

However, when you want to use 3-party existing models and maps (such as the various models I am currently downloading on the Web), you may need to choose to export the palm of your hand to make the tangent space match the normal map.

And for the above bump map to the normal map, because it is run-time generation, so the export of the tangent space can choose any coordinate system, such as the current export to choose the right-hand system, bump to normal when also using the right-hand system can be.

In addition, blade for UV processing, the previous idea is this: using a fixed UV coordinate system, if the use of UV, or image memory layout (some from the low upward, some from top to bottom) with the rendering API is expected to be different, flip the content of the texture image, so for the various APIs, UV and shader are not changed.
Although this idea is theoretically no problem, it is actually very two: it is too time-consuming to flip the image at run time. The texture coordinates (v-coordinates) of the model are now changed to load, so the most Chinese effect is the same.

Because the UV coordinate system of the OGL requires that the image be stored backwards (the origin is in the lower left corner), if the loaded texture is not this layout (the origin is in the upper left corner), then the V value of the texture coordinates is flipped. For example , the DDS image format, whose origin is in the upper-left corner rather than the lower-left corner.

In the process of using Mfc+gdi to do the editor, learn to GDI bitmap header, or general bitmap header can be based on the image height biheight symbols to dynamically differentiate their storage format http://msdn.microsoft.com/ en-us/library/aa930622.aspx),

In the process of using freeimage, it is found that freeimage loaded bitmaps are vertically inverted, which has a congenital advantage for OGL.

4.threading Utility

Because C++11 already has a simple thread in it, but Blade is written based on c++98/03 and does not use any new features. Because blade internal has used Intel TBB, multithreading this function because it has not been used directly (in addition to their own written Readwritelock used the mutex lock), so did not add. But take into account the possible needs of future users, so first put on.

The original idea is written c++11 compatible interface, so that users can not support the C++11 compiler with the blade to bring the thread, the interface can be consistent, do not change the code.

But found that some of the thread's features use the new syntax of c++11, so this idea is not OK, so the blade current style is simply encapsulated condition variable, mutex, thread, Put it in the Foundation Library. Currently, both Windows and *nix (Pthread) are implemented. The pthread corresponds to the function, but the simple package, Windows under the new version of the CRT also has, but for compatibility, is written by itself.

At present, only to do a simple test, it is estimated that there are more than n bugs, for the time being first, hmm.

5. IK Pre-research

The current references are:

Http://freespace.virgin.net/hugo.elias/models/m_ik.htm

Http://freespace.virgin.net/hugo.elias/models/m_ik2.htm

Http://billbaxter.com/courses/290/html/img0.htm

Http://graphics.ucsd.edu/courses/cse169_w04/welman.pdf

Http://graphics.ucsd.edu/courses/cse169_w05/CSE169_12.ppt

Http://graphics.ucsd.edu/courses/cse169_w05/CSE169_13.ppt

Cyclic coordinate descent (CCD) algorithm for bone animation in the knee and other joints of special treatment very happy to have someone in the country do ^ ^.

There's also DOOM3 source code, which has IK codes.

It is understood that IK is commonly used in the following scenarios: Jacobian transpose, CCD (cyclic coordinate descent), and analytical method.

The first two are the iterative approximation solution, and the CCD is more simple and easy to understand and effective.

Jacobian transpose:http://www.math.ucsd.edu/~sbuss/researchweb/ikmethods/iksurvey.pdf

Ccd:https://sites.google.com/site/auraliusproject/ccd-algorithm

Analytical method:http://www.ryanjuckett.com/programming/analytic-two-bone-ik-in-2d/

The last one is the method of geometrical analysis, which is suitable for simple situations. Now, from the DOOM3 code, it seems to be in this way (seemingly not seeing iterations).

Blade's plan supports leg ik, arm ik, and, if necessary, hair braids, and so on, this is similar to Doom3 's Ik_walk and Ik_reach, but arm ik should be more complex than DOOM3.

Back or continue IK research, work is very busy, first take a look at the Information Bar, progress will be very slow.

Engine design Tracking (nine. 14.2c) Recent minor updates