Introduction to 3D Plotting with Matplotlib: A Practical, Deep-Dive Guide

A few months ago, I was helping a teammate debug sensor drift in a robotics prototype. We had columns of numbers in a CSV file and clean 2D charts, but we still missed one key pattern: a curved error band that only appeared when time, temperature, and distance were viewed together. The moment we switched to a 3D plot, the issue became obvious.

That is why I still reach for Matplotlib 3D plotting, even in 2026 with many newer visualization tools around us. You can quickly inspect relationships among three variables, test hypotheses, and communicate findings to teammates who are not living in your notebook all day.

I will walk you through the exact path I recommend when you are getting started: create a blank 3D canvas, plot a line, combine it with a scatter layer, render surfaces from grid data, and control camera/view settings so your chart tells a clear story. I will also show where people usually get stuck, how to avoid performance pain on larger datasets, and when you should skip 3D entirely and choose a better chart form.

Why 3D plots still matter in day-to-day Python work

When you first open Matplotlib 3D, it can feel like a demo feature. In practice, it solves very real problems:

• You have three continuous variables and need to inspect their relationship quickly.
• You are validating simulation output where geometry matters.
• You are comparing measured vs expected behavior over time, with an extra factor like load, speed, or altitude.
• You need a visual sanity check before fitting a model.

I think about 3D plotting as a fast diagnostic lens. It is not always the chart you publish, but it is often the chart that helps you discover what is really happening.

A useful mental model is this: 2D plotting maps values on a page; 3D plotting places points in a room. In 2D, overlapping points hide each other. In 3D, rotation reveals structure. The downside is cognitive load. If you add too much styling or too many points, readers get lost quickly.

So I follow a simple rule when teaching teams: use 3D to detect patterns, not to decorate reports.

Environment setup you should use

For most projects, this stack works well:

• Python 3.10+
• NumPy for array operations
• Matplotlib 3.8+ (3.9/3.10 are common in 2026 environments)
• Jupyter or VS Code notebooks for interactive rotation

Install once:

pip install matplotlib numpy

If you are running in a notebook, I recommend an interactive backend so you can rotate the chart with your mouse and inspect depth. A static screenshot often hides the key signal.

In Jupyter, these options are the ones I use most often:

• %matplotlib inline for static output in reports
• %matplotlib notebook for basic interactivity
• %matplotlib widget for richer controls (if ipympl is installed)

For scripts (not notebooks), I usually separate two modes:

• Exploration mode: local run with interactive window
• Export mode: deterministic PNG/SVG generation for docs and CI artifacts

That split sounds simple, but it prevents many reproducibility issues later.

Your first blank 3D canvas

Before plotting real data, I want you to understand the smallest possible 3D setup. This is the foundation for every other pattern.

import matplotlib.pyplot as plt

# Create an empty figure object

fig = plt.figure(figsize=(7, 5))

# Add one 3D axis to the figure

ax = fig.add_subplot(111, projection=‘3d‘)

# Optional labels make orientation easier

ax.set_xlabel(‘X axis‘)

ax.set_ylabel(‘Y axis‘)

ax.set_zlabel(‘Z axis‘)

ax.set_title(‘Empty 3D canvas‘)

plt.show()

What is happening here:

• fig = plt.figure(...) creates the drawing surface.
• add_subplot(..., projection=‘3d‘) creates a 3D axis object.
• All 3D methods (plot3D, scatter3D, plot_surface, and others) are called on that axis.

You might still see old examples using fig.gca(projection=‘3d‘). They can work, but I recommend add_subplot because it is explicit, clearer in multi-plot layouts, and easier to maintain in team code.

If your plot appears blank, check these first:

• Did you call plt.show()?
• Are you plotting values that are all identical (flat line or single point)?
• Did you accidentally overwrite ax with another object?
• Did your notebook backend reset and stop rendering interactive figures?

Lines and scatter: the fastest way to understand 3D coordinates

The next step is combining a line with points. This pattern is great for trajectory data, growth over time, and any sequence where order matters.

import numpy as np

import matplotlib.pyplot as plt

# Synthetic sample data: a curved path in 3D

x = np.arange(0, 7)

y = x 2

z = x 2

fig = plt.figure(figsize=(8, 6))

ax = fig.add_subplot(111, projection=‘3d‘)

# 3D line path

ax.plot3D(x, y, z, color=‘red‘, linewidth=2, label=‘Trajectory‘)

# Scatter points colored by z value

scatter = ax.scatter3D(x, y, z, c=z, cmap=‘cividis‘, s=60, depthshade=True)

ax.set_xlabel(‘X‘)

ax.set_ylabel(‘Y‘)

ax.set_zlabel(‘Z‘)

ax.set_title(‘Line + scatter in 3D‘)

ax.legend(loc=‘upper left‘)

fig.colorbar(scatter, ax=ax, pad=0.1, label=‘Z value‘)

plt.show()

Why this works well for learning:

• The line gives structure and order.
• Scatter points show exact sampled values.
• Color mapping adds a fourth channel (value intensity) without cluttering the geometry.

In real projects, I often map color to residual error or confidence score. That way, I can inspect both geometry and data quality in one view.

A practical tip on color maps

Pick perceptually balanced maps (viridis, cividis, plasma) unless you have a domain reason to do otherwise. Rainbow maps can produce false visual boundaries.

A practical tip on scale

If one axis is much larger than others, your shape gets visually distorted. Either normalize your data before plotting or set axis limits consciously.

I also like to print quick stats before plotting:

print(‘x:‘, float(np.min(x)), float(np.max(x)))

print(‘y:‘, float(np.min(y)), float(np.max(y)))

print(‘z:‘, float(np.min(z)), float(np.max(z)))

That tiny check catches many axis mistakes early.

Surface plots from grid data (sine and cosine example)

Once you are comfortable with points and lines, surfaces are the next major step. A surface plot is perfect when your z value depends on x and y, like elevation, heat maps in space, or model response surfaces.

import numpy as np

import matplotlib.pyplot as plt

# Coarse grid

x = np.arange(-5, 5, 1.0)

y = np.arange(-5, 5, 1.0)

X, Y = np.meshgrid(x, y)

Z = np.sin(X * np.pi / 2)

# Finer grid for a second surface

x2 = np.arange(-5, 5, 0.6)

y2 = np.arange(-5, 5, 0.6)

X2, Y2 = np.meshgrid(x2, y2)

Z2 = np.cos(X2 * np.pi / 2)

fig = plt.figure(figsize=(10, 7))

ax = fig.add_subplot(111, projection=‘3d‘)

surf1 = ax.plot_surface(X, Y, Z, cmap=‘viridis‘, alpha=0.75, linewidth=0)

surf2 = ax.plot_surface(X2, Y2, Z2, cmap=‘magma‘, alpha=0.45, linewidth=0)

ax.set_xlabel(‘X‘)

ax.set_ylabel(‘Y‘)

ax.set_zlabel(‘Z‘)

ax.set_title(‘Sine and cosine surfaces in 3D‘)

fig.colorbar(surf1, ax=ax, shrink=0.55, pad=0.1, label=‘sin surface‘)

plt.show()

Core ideas you should keep in mind:

• meshgrid turns 1D coordinate ranges into 2D coordinate matrices.
• plot_surface expects X, Y, and Z with matching 2D shapes.
• Finer grids look smoother but cost more memory and render time.

A useful analogy: think of meshgrid as laying graph paper on a table. Every paper intersection gets an (x, y) pair, and your formula gives the height z at that spot.

If you get shape errors, print dimensions:

print(X.shape, Y.shape, Z.shape)

They must line up.

Camera, perspective, and readable storytelling

A good 3D chart is rarely about more data. It is about the right view angle and restraint.

I almost always tune the view before sharing a screenshot:

ax.view_init(elev=25, azim=35)

• elev changes the vertical angle.
• azim rotates around the vertical axis.

Try 4-5 view settings and pick the one where depth relationships are obvious.

Other settings that improve readability:

• ax.setboxaspect((1, 1, 0.7)) for balanced proportions.
• Light alpha (0.5 to 0.8) on surfaces so overlap is visible.
• Fewer ticks when the audience is non-technical.
• Clear axis labels with units (Temperature (C), Time (s)).

I also recommend this workflow when presenting:

• Start with a static 2D projection for context.
• Show the 3D figure to explain spatial structure.
• Return to 2D slices for precise numerical discussion.

This prevents the common problem where 3D looks impressive but hides exact comparisons.

Traditional vs modern plotting workflow (2026)

I still see teams copy old snippets and fight unnecessary friction. Here is the approach I recommend now.

Area

Older pattern

Current pattern I recommend —

—

— Axis creation

fig.gca(projection=‘3d‘)

fig.add_subplot(111, projection=‘3d‘) Data prep

Python lists assembled manually

NumPy arrays and vectorized expressions Iteration loop

Re-run full script repeatedly

Notebook cells + interactive rotation Style tuning

Hard-coded colors everywhere

Named colormaps + small shared style helper Debugging

Visual guesswork

Check array shapes + min/max + axis ranges Team workflow

One-off local script

Notebook + saved script + CI screenshot check

On modern teams, I often pair Matplotlib with AI-assisted coding in the editor. It helps generate boilerplate quickly, but I still manually review axis scale, color semantics, and label clarity. Those decisions are domain decisions, not autocomplete decisions.

Performance patterns when your data gets bigger

3D plotting can get heavy fast. The issue is not only CPU; it is also visual overload.

Here is how I keep plots responsive and readable:

1) Reduce point count for exploration

For raw point clouds in the millions, downsample first.

import numpy as np

# Keep about 50k points for quick visual inspection

sample_idx = np.random.choice(len(x), size=min(50000, len(x)), replace=False)

xs, ys, zs = x[sampleidx], y[sampleidx], z[sample_idx]

In my experience, interactive exploration stays smooth at tens of thousands of points on normal laptops, while full millions can become sluggish.

2) Use smaller markers and no edge stroke

For scatter:

ax.scatter3D(xs, ys, zs, s=2, alpha=0.6, linewidth=0, c=zs, cmap=‘viridis‘)

This reduces rendering overhead and makes dense regions easier to read.

3) Control grid resolution for surfaces

A 200 x 200 grid already means 40,000 faces. Start coarse (50 x 50 or 80 x 80) and increase only if the surface still looks jagged.

4) Split tasks: explore first, render final later

I use quick, low-resolution settings for analysis sessions and a higher quality render only when exporting for docs or slides.

5) Prefer 2D slices for exact communication

If your audience needs exact numeric comparison, a cross-section or contour plot is usually easier to read than a dense 3D surface.

Common mistakes I fix in code reviews

I review a lot of plotting notebooks. These are the recurring issues I see, plus what you should do instead.

Mistake 1: Mixing incompatible shapes

Symptom: ValueError around broadcasting or shape mismatch.

Fix: Ensure X, Y, Z all share the same 2D shape for surfaces.

Mistake 2: Forgetting units and labels

Symptom: Pretty plot, unclear meaning.

Fix: Add units to axis labels and title with context. Future you will thank present you.

Mistake 3: Color map does not match meaning

Symptom: High values look random or misleading.

Fix: Use consistent colormap semantics across related plots and include a color bar label.

Mistake 4: 3D used where 2D is better

Symptom: Reader cannot compare values because of perspective distortion.

Fix: Use 3D for structure discovery; use 2D for precise comparison.

Mistake 5: Rendering every raw point

Symptom: Laggy notebook and unreadable cloud.

Fix: Downsample or aggregate, then inspect region-of-interest slices.

Mistake 6: Relying on one camera angle

Symptom: Hidden clusters or false overlap.

Fix: Check multiple elevations/azimuths before drawing conclusions.

Data preparation patterns that make 3D plots trustworthy

Most 3D plotting problems are really data preparation problems. If your arrays are noisy, inconsistent, or misaligned, no camera angle can save the chart.

I use this prep checklist before I trust a figure:

• Confirm dtypes are numeric (float32 or float64 for most workflows).
• Remove or impute missing values consistently across all three axes.
• Verify ordering (especially if one axis is time).
• Standardize units (mixing meters and millimeters is a silent failure).
• Confirm equal-length arrays after filtering.

A compact prep function I reuse:

import numpy as np

def clean_xyz(x, y, z):

x = np.asarray(x, dtype=float)

y = np.asarray(y, dtype=float)

z = np.asarray(z, dtype=float)

mask = np.isfinite(x) & np.isfinite(y) & np.isfinite(z)

return x[mask], y[mask], z[mask]

Why this matters: it removes NaN and inf points in one place, so downstream plotting code stays predictable.

For time-dependent trajectories, one more guardrail helps a lot:

# Ensure monotonic time before plotting sequential path

order = np.argsort(t)

t, x, y, z = t[order], x[order], y[order], z[order]

A surprising number of zig-zag artifacts come from unsorted time indices.

Beyond basic primitives: wireframe, contour projections, trisurf, and quiver

Once line/scatter/surface feel familiar, these plot types add practical depth.

Wireframe for structure without heavy shading

plotwireframe is lighter than plotsurface and is often easier to read during analysis.

ax.plot_wireframe(X, Y, Z, rstride=2, cstride=2, color=‘gray‘, linewidth=0.6)

I prefer wireframes when I only need topology, not polished visuals.

Contour projections to reduce ambiguity

One challenge in 3D is depth ambiguity. Projected contours help.

ax.contour(X, Y, Z, zdir=‘z‘, offset=np.min(Z)-0.2, cmap=‘viridis‘)

This places a 2D contour map at a fixed Z offset. Readers get both the 3D shape and a clean footprint.

Triangulated surfaces for irregular points

Grid surfaces assume data lies on a regular matrix. Real data often does not. For scattered points, triangulated surfaces can work better.

ax.plot_trisurf(x, y, z, cmap=‘viridis‘, linewidth=0.1, antialiased=True)

I use this for sampled terrain, scan data, and any non-grid measurement system.

Quiver for vector fields

If each point has direction (wind, flow, force), 3D arrows (quiver) can communicate dynamics.

ax.quiver(x, y, z, u, v, w, length=0.1, normalize=True)

Tip: keep arrow counts low. Dense quivers quickly become unreadable.

Edge cases: what breaks and how I handle it

Edge case 1: Extreme outliers flatten everything else

When one or two points are far from the main cloud, the axis range expands and structure disappears.

My fix:

• Inspect percentile ranges (p1 to p99).
• Plot clipped view for exploration.
• Keep a separate outlier chart for integrity.

Edge case 2: Duplicate points hide density

If many points share nearly identical coordinates, you see sparse dots instead of dense clusters.

My fix:

• Add alpha transparency.
• Reduce marker size.
• Consider binning and plotting voxel-like summaries.

Edge case 3: Near-planar data looks falsely curved

Perspective can trick the eye. Something almost planar can look bent from certain angles.

My fix:

• Rotate to orthogonal views.
• Fit a reference plane and visualize residuals.
• Pair with 2D residual histogram.

Edge case 4: Missing chunks in surfaces

If grid generation skips ranges, surfaces can look torn.

My fix:

• Validate grid coverage.
• Mark missing regions explicitly.
• Use masked arrays so gaps are intentional, not accidental.

Edge case 5: Mixed sampling rates

In sensor systems, one variable may be sampled faster than others.

My fix:

• Resample to common timestamps.
• Document interpolation method.
• Show raw vs resampled comparison once.

Practical scenarios: when 3D adds value fast

Scenario A: Robotics drift triage

Axes:

• X: time
• Y: temperature
• Z: position error

Goal: detect temperature-linked drift over time. A rising curved ridge usually appears faster in 3D than in separate 2D plots.

Scenario B: Model response surface sanity check

Axes:

• X/Y: two hyperparameters
• Z: validation metric

Goal: verify whether optimum is a stable basin or a narrow spike. This helps choose robust settings, not just peak settings.

Scenario C: Manufacturing process window

Axes:

• X: pressure
• Y: speed
• Z: defect rate

Goal: find safe operating region. 3D surface plus contour projection can highlight process windows clearly.

Scenario D: Geospatial altitude patterns

Axes:

• X/Y: location coordinates
• Z: measured value (pollution, moisture, temperature)

Goal: inspect how value changes across terrain. I usually pair this with 2D maps for reporting.

Alternative approaches and when I switch

3D Matplotlib is great for quick diagnostics, but it is not always the final answer. Here is how I decide.

Need

Better choice

Why —

—

— Interactive web sharing

Plotly

Built-in browser interactivity and hover details Very large point clouds

Datashader-based stack

Better aggregation for massive data Mesh-heavy scientific visualization

PyVista/VTK

More advanced 3D rendering capabilities Precise comparison in reports

2D contour/heatmap/small multiples

Less perspective distortion Team notebooks with standard Python stack

Matplotlib

Ubiquitous and easy to integrate

I still start with Matplotlib most of the time because it is dependable, scriptable, and already present in many environments.

Performance expectations in practice (ranges, not hard promises)

On typical developer laptops, here is what I see during exploratory work:

• ~10k points: usually smooth rotation
• ~50k points: generally usable with small markers
• ~100k+ points: often lag appears, depends on backend and hardware
• Surface grids around 50 x 50 to 100 x 100: usually fine
• Surface grids around 200 x 200 and above: can feel heavy, especially with overlays

These are rough ranges, not guarantees. Backend choice, GPU drivers, and notebook environment all matter.

My optimization order is always:

• Reduce data volume.
• Simplify styling.
• Lower surface resolution.
• Split one heavy figure into multiple focused figures.

That order usually gives the biggest gains quickly.

Reproducible, team-friendly plotting workflow

If you work in a team, plots are part of the product, not just personal scratch work. I standardize these pieces early:

• One plotting utility module for style defaults.
• A deterministic seed for synthetic examples.
• Explicit figure sizes and DPI.
• A save function for named artifacts.
• A tiny smoke test that runs plotting code headlessly.

Example export helper:

from pathlib import Path

def savefigure(fig, name, outdir=‘artifacts/plots‘, dpi=160):

out = Path(out_dir)

out.mkdir(parents=True, exist_ok=True)

fig.savefig(out / f‘{name}.png‘, dpi=dpi, bbox_inches=‘tight‘)

This avoids the classic ‘works on my notebook‘ trap and makes review much easier.

AI-assisted workflow that actually helps

I use AI tools to speed up repetitive plotting tasks, but I keep a human checklist for visual integrity.

What I delegate well:

• Boilerplate axis setup
• Reusable helper functions
• Initial drafts for style presets
• Transforming one plot type into another skeleton

What I never skip reviewing manually:

• Axis units and scaling
• Color semantics and legends
• Statistical meaning of overlays
• Whether 3D is the right chart at all

A practical prompt pattern I use in editors:

• Ask for a minimal plotting function with typed inputs
• Request handling for NaN and shape checks
• Ask for one quick test call with synthetic data

This gives me speed without sacrificing trust.

Accessibility and communication in 3D visuals

3D charts can be hard for some audiences, especially in static documents. I apply these guardrails:

• Use high-contrast palettes.
• Avoid encoding meaning with color alone.
• Add captions that state the key pattern in words.
• Provide a 2D companion chart when precision matters.
• Keep labels readable at export size.

A 3D plot should never force readers to guess the takeaway.

When I submit reports, I often include:

• One interactive notebook view for analysts.
• One static 3D image for overview.
• One or two 2D projections for exact comparisons.

That combination serves both technical and non-technical readers.

A full runnable mini-project you can adapt

This example combines line, scatter, and a reference surface in one figure. I use this structure in exploratory notebooks all the time.

import numpy as np

import matplotlib.pyplot as plt

# Reproducibility for demo data

rng = np.random.default_rng(42)

# Simulated trajectory

t = np.linspace(0, 10, 300)

x = np.cos(t) (1 + 0.05 t)

y = np.sin(t) (1 + 0.05 t)

z = 0.3 t + 0.4 np.sin(2 * t)

# Add small noise to mimic sensor measurements

x_noisy = x + rng.normal(0, 0.03, size=t.size)

y_noisy = y + rng.normal(0, 0.03, size=t.size)

z_noisy = z + rng.normal(0, 0.04, size=t.size)

fig = plt.figure(figsize=(11, 8))

ax = fig.add_subplot(111, projection=‘3d‘)

# Smooth reference path

ax.plot3D(x, y, z, color=‘black‘, linewidth=2, label=‘Reference path‘)

# Measured points with color by time

pts = ax.scatter3D(

xnoisy, ynoisy, z_noisy,

c=t, cmap=‘plasma‘, s=12, alpha=0.85, linewidth=0,

label=‘Measured points‘

)

# Optional guide surface: z as a function of x and y (toy example)

gx = np.linspace(xnoisy.min() – 0.5, xnoisy.max() + 0.5, 40)

gy = np.linspace(ynoisy.min() – 0.5, ynoisy.max() + 0.5, 40)

GX, GY = np.meshgrid(gx, gy)

GZ = 0.4 GX – 0.2 GY

ax.plot_surface(GX, GY, GZ, alpha=0.2, cmap=‘Greys‘, linewidth=0)

ax.set_title(‘3D trajectory with measured scatter and guide plane‘)

ax.set_xlabel(‘X position (m)‘)

ax.set_ylabel(‘Y position (m)‘)

ax.set_zlabel(‘Z position (m)‘)

ax.view_init(elev=24, azim=38)

ax.setboxaspect((1, 1, 0.8))

fig.colorbar(pts, ax=ax, pad=0.08, shrink=0.7, label=‘Time (s)‘)

ax.legend(loc=‘upper left‘)

plt.tight_layout()

plt.show()

How you can adapt it right away:

• Replace simulated trajectory arrays with your own telemetry columns.
• Map color to a quality signal (temperature, error, confidence).
• Save snapshots from multiple camera angles for code reviews.
• Add a second panel with 2D residuals for precise interpretation.

A second, more realistic example: measured vs predicted surface

I often need to compare measured values against a model in one visual workflow. Here is a pattern that scales well from notebooks to team analysis.

import numpy as np

import matplotlib.pyplot as plt

rng = np.random.default_rng(7)

# Synthetic process variables

pressure = np.linspace(10, 60, 45)

speed = np.linspace(100, 700, 50)

P, S = np.meshgrid(pressure, speed)

# Predicted defect rate surface

Z_pred = 0.015 (P – 35)2 + 0.00002 (S – 420)2 + 1.8

# Measured data sampled at random points

n = 900

p_m = rng.uniform(10, 60, n)

s_m = rng.uniform(100, 700, n)

ztrue = 0.015 (pm – 35)2 + 0.00002 (s_m – 420)2 + 1.8

zmeas = ztrue + rng.normal(0, 0.15, n)

fig = plt.figure(figsize=(12, 8))

ax = fig.add_subplot(111, projection=‘3d‘)

# Model surface

surf = ax.plotsurface(P, S, Zpred, cmap=‘viridis‘, alpha=0.55, linewidth=0)

# Measurement points

pts = ax.scatter3D(pm, sm, zmeas, c=zmeas, cmap=‘plasma‘, s=8, alpha=0.75, linewidth=0)

ax.set_xlabel(‘Pressure (bar)‘)

ax.set_ylabel(‘Speed (rpm)‘)

ax.set_zlabel(‘Defect rate (%)‘)

ax.set_title(‘Measured vs predicted process behavior‘)

ax.view_init(elev=28, azim=140)

fig.colorbar(surf, ax=ax, pad=0.02, shrink=0.6, label=‘Predicted defect rate‘)

fig.colorbar(pts, ax=ax, pad=0.10, shrink=0.6, label=‘Measured defect rate‘)

plt.tight_layout()

plt.show()

What I look for in this chart:

• Regions where measurements consistently sit above the model surface.
• Clusters of high residuals near process boundaries.
• Whether the optimum basin is broad enough for stable operation.

This is where 3D earns its keep before I move to formal residual analysis.

Debug checklist I run before trusting a conclusion

When a 3D figure suggests a strong pattern, I verify it with this quick checklist:

• Re-plot from at least three camera angles.
• Confirm axis limits are not hiding edge behavior.
• Check whether downsampling changed the pattern.
• Verify no unit mismatch between variables.
• Compare with one 2D projection and one contour plot.
• Confirm the same insight appears on fresh data slices.

If a pattern survives that checklist, it is usually real.

What I want you to do next

If you are learning this for real project work, do not stop at a toy curve. Open one of your production-like datasets and run a focused 30-minute plotting pass:

• Build the empty 3D axis from scratch.
• Add one line layer and one scatter layer.
• Color points by a meaningful metric, not random color.
• Rotate the camera until hidden structure appears.
• Export one image for your team and note one actionable insight.

Then do one extra step that most people skip: make a companion 2D chart that validates the same insight. If both views agree, your confidence jumps.

That single exercise usually changes how people think about multidimensional data. You go from reading columns to seeing shape.

In my own workflow, 3D Matplotlib is the early-warning tool: I use it to catch drift, clustering, and nonlinear behavior before model fitting or pipeline changes. Then I move to 2D summaries for decisions and reporting. That balance gives me the best of both worlds: fast discovery, careful validation, and clear communication.