CHAPTER 16: The Future of Android: The 64-Bit Android 5.0 OS 595A geometry shader allows an underlying mesh to become more refined, so that 3D models can be
created using “low poly” modeling to save on data footprint (here it is again, this time in the creation
of 3D assets). Geometry shaders allow low-poly meshes to be refined into higher-poly (polygon)
meshes, which are smoothed on the client side using the GPU to apply what is termed tesselation,
or the refinement of the mesh, by adding more vertices. A polygon is made up of vertices (points in
space) connected by edges. A triangular polygon has three vertices and three edges, and a quad
polygon has four vertices and four edges. It is important to note that a quad polygon can be split in
half (diagonally) into two triangle polygons. An example of a quads modeler is the NeverCenter SILO
software, and an example of a triangular modeler is the DAZ Hexagon or Blender software.
The rendering pipeline (a 3D layer stack, if you will) goes from the “Vertex Shader” on the top, or
“skin” of the 3D mesh (model) down through the Tessellation Shader, which provides fine-tuned
tessellation control over how the underlying geometry shader will be tessellated. How this all works
is beyond the scope of an Absolute Beginner programming title, but I wanted to cover it briefly here
so you have an idea of how advanced AEP is.
Finally, ASTC (Adaptive Scalable Texture Compression) is like a more advanced, 3D version of the
WebM and WebP codecs added in Android 4. ASTC is in the full OpenGL 4.4 as well as in OpenGL
ES 3.1, so it is an advanced technology that is used in the most popular 3D video games today.
ASTC allows even better 3D texture map optimization, allowing developers to greatly reduce both
the application data footprint and the amount of memory used for these texture maps to be applied
to the 3D polygonal mesh. As I have been telling you all along, data footprint optimization is the
name of the game these days, which is why I have been including this topic in all of my Android and
Java 8 programming titles.
Z-Order and Z-Layers: The Third Dimension for UI Design
As you learned throughout this book, Android 4.4 and previous versions have a certain amount
of support for the concept of Z-order, as it is necessary for implementing the compositing
engine, which can be implemented using classes such as Android Canvas, View, RelativeLayout,
FrameLayout, LayerDrawable, and PorterDuff. The concept of Z-order, sometimes called Z-index,
can also be found in HTML5 and CSS3, as well as in JavaFX.
Besides using advanced Android classes such as Canvas, Z-index was not explicitly specified
in the classes that used it. For instance, in some ViewGroup layout containers, you can use the
.bringToFront( ) method to change the Z-order of the UI elements (View widgets) inside of the UI
layout container. In Android 5.0, you can control the Z-index of each View widget in your ViewGroup
layout container using a specific numeric value (Z-layer).
These classes, and the concept of Z-order, are also covered in my Pro Android Graphics book from
Apress. Android 5.0 takes this Z-order concept to new heights (no pun intended) by specifically
implementing a UI concept that I like to call Z-layers. Android 5.0 implemented this so that all of the
Android 5.0 UI elements will have a specific Z-order, Z-index, or Z-layer value in the overall scheme
of a now Isometric (2.5D) Android UI design space. This feature makes it easier for developers
to add a 3D look and feel to their UI designs so that users can see things like stacked information
“cards,” as well as UI elements that float above the previously “flat” (2D) UI design paradigm.