Geometry and Appearances
This tutorial will teach you about the Geometry & Appearances system available with the Primitive API. This is an advanced topic for extending CesiumJS with custom meshes, shapes, volumes, and appearances and is not geared towards the typical Cesium user. If you are interested in learning how to draw various shapes and volumes on the globe, check out the Creating Entities tutorial.
CesiumJS can create different geometry types using entities, such as polygons and ellipsoids. For example, copy and paste the following into the Hello World Sandcastle Example to create a rectangle on the globe with a dot pattern:
In this tutorial, we go under the hood and look at the
Appearance types that form them. A geometry defines the primitive’s structure, i.e., the triangles, lines, or points that compose the primitive. An appearance defines the primitive’s shading, including its full GLSL vertex and fragment shaders, and render state.
The benefits of using geometries and appearances are:
- Performance - When drawing a large number of static primitives (such as polygon for each zip code in the United States), using geometries directly allows us to combine them into a single geometry to reduce CPU overhead and better utilize the GPU. Combining primitives is done on a web worker to keep the UI responsive.
- Flexibility - Primitives combine geometry and appearance. By decoupling them, we can modify each independently. We can add new geometries that are compatible with many different appearances and vice-versa.
Low-level access - Appearances provide close-to-the-metal access to rendering without having to worry about all the details of using the
Rendererdirectly. Appearances make it easy to:
- Write full GLSL vertex and fragment shaders.
- Use custom render state.
There are also some downsides:
- Using geometries and appearances directly requires more code and a deeper understanding of graphics. Entities are at the level of abstraction appropriate for mapping apps; geometries and appearances have a level of abstraction closer to a traditional 3D engine.
- Combining geometries is effective for static data, not necessarily for dynamic data.
Let’s rewrite the initial code example using geometries and appearances:
Instead of using a rectangle entity, we used the generic
Primitive, which combines the geometry instance and appearance. For now, we will not differentiate between a
Geometry and a
GeometryInstance other than an instance is a container for a geometry.
To create the geometry for the rectangle, i.e., the triangles covering the rectangular region and that fit the curvature of the globe, we create an
Since it is on the surface, we can use the
EllipsoidSurfaceAppearance. This saves memory by making assumptions based on the fact that the geometry is on the surface or at a constant height above the ellipsoid.
CesiumJS supports the following geometries:
||A circle or extruded circle|
||A polyline normal to the surface with a width in meters and optional extruded height|
||A cylinder, cone, or truncated cone|
||An ellipse or extruded ellipse|
||An rectangle or extruded rectangle|
||A polygon with optional holes or extruded polygon|
||A collection of line segments with a width in pixels|
||A 2D shape extruded along a polyline|
||A wall perpendicular to the globe|
We see a performance benefit when we use one primitive to draw multiple static geometries. For example, draw two rectangles in one primitive.
We created another instance with a different rectangle, and then provided both instances to the primitive. This draws both both instances with the same appearance.
Some appearances allow each instance to provide unique attributes. For example, we can use
PerInstanceColorAppearance to shade each instance with a different color.
Each instance has a
Color attribute. The primitive is constructed with a
PerInstanceColorAppearance, which uses each instance’s color attribute to determine shading.
Combining geometries allows CesiumJS to efficiently draw A LOT of geometries. The following example draws 2,592 uniquely colored rectangles.
Instances are independently accessible after they are combined. Assign an
id to an instance and use it to determine if the instance is picked with
The following example creates an instance with a
id, and writes a message to the console when it is clicked.
id avoids keeping a reference to the full instance, including the geometry, in memory after the primitive is constructed.
Instances can be used to position, scale, and rotate the same geometry in different parts of the scene. This is possible because multiple instances can reference the same
Geometry, and each instance can have a different
modelMatrix. This allows us to only compute the geometry once and reuse it many times.
The following example creates one
EllipsoidGeometry and two instances. Each instance references the same ellipsoid geometry, but places it using a different
modelMatrix resulting in one ellipsoid being on top of the other.
Updating per-instance attributes
Update the per-instance attributes of the geometries after they are added to the primitive to change the visualization. Per-instance attributes include:
- Color : A
ColorGeometryInstanceAttributedetermining the color of the instance. The primitive must have a
- Show : A boolean determining the visibility of the instance. Available for any instance.
This example shows how to change the color of the geometry instance:
The attributes of the geometry instance can be retrieved from the primitive using
primitive.getGeometryInstanceAttributes. The properties of the
attributes can be changed directly.
Geometry defines structure. The other key property of a primitive,
appearance, defines the primitive’s shading, i.e., how individual pixels are colored. A primitive can have many geometry instances, but it can only have one appearance. Depending on the type of appearance, an appearance will have a
material that defines the bulk of the shading.
CesiumJS has the following appearances:
||An appearance that works with all geometry types and supports materials to describe shading.|
||A version of
||Uses per-instance color to shade each instance.|
||Supports materials to shade a Polyline.|
||Uses either per-vertex or per-segment coloring to shade a Polyline.|
Appearances define the full GLSL vertex and fragment shaders that execute on the GPU when the primitive is drawn. Appearances also define the full render state, which controls the GPU’s state when the primitive is drawn. We can define the render state directly or use higher-level properties like
translucent, which the appearance will convert into render state. For example:
We can’t change its
renderState property once an appearance is created, but we can change its
material. We can also change a primitive’s
flat- Flat shading. Do not take lighting into account.
faceForward- When lighting, flip the normal so it is always facing the viewer. The avoids black areas on back-faces, e.g., the inside of a wall.
|flat : true||faceForward : false||faceForward : true|
Geometry and appearance compatibility
Not all appearances work with all geometries. For example,
EllipsoidSurfaceAppearance is not appropriate for
WallGeometry since a wall is not on the surface of the globe.
For an appearance to be compatible with a geometry, they must have matching vertex formats, which means the geometry must have the data that the appearance expects as input. A
VertexFormat can be provided when creating a geometry.
vertexFormat determines if it can be combined with another geometry. Two geometries do not have to be the same type, but they need matching vertex formats.
In the reference documentation, see:
For more on materials, see Fabric .
For future plans, see the Geometry and Appearances Roadmap .