From Digitalization to Digital-Intelligence: The Next Five Years of 3D Visualization Dashboards

After years of working on 3D visualization projects, a feeling has become increasingly obvious:

The dashboards are getting more beautiful, but the features that are actually used are probably getting fewer.

A smart factory project opens straight into a 3D model of the plant. Equipment runs, pipes have flowing light effects, and all around the screen are indicators for output, energy consumption, equipment status, alarm count, and more.

A smart city project opens to a 3D map of the city. Buildings have tech-style outlines, roads have dynamic lighting, and both sides are packed with statistics charts.

The visual effect is indeed impressive.

But if you think about it, the interaction logic of these dashboards has not changed much from a few years ago.

Data is prepared in advance, charts are designed in advance, pages are planned in advance. What users can see and operate is mostly decided by developers beforehand.

If a leader suddenly asks:

“Which areas had abnormal energy consumption last week?”

Or: “Why did output drop on this production line today?”

The dashboard may not be able to answer.

Not because there is no data, but because we did not design that page in advance.

This actually exposes a problem with traditional visualization dashboards:

We have been working hard to make dashboards show more information, yet we rarely think about how to make it easier for users to obtain information.

Entering the 15th Five-Year Plan period, as digitalization moves toward digital-intelligence (数智化), I think 3D visualization dashboards should also change.

The future dashboard should not be just a screen for displaying data.

It should become a unified interaction entry point for an industry.

1. From Digitalization to Digital-Intelligence: The Dashboard Needs to Be Repositioned

During the 15th Five-Year Plan period, digital-intelligence has become an important direction for building Digital China.

From digitalization to digital-intelligence, it looks like just adding the character for “intelligence,” but for software products, the change behind it deserves attention.

In the past, when we talked about digitalization, the focus was often on turning real-world information into numbers.

Equipment operating status can be collected, production processes can be monitored, and urban infrastructure can be mapped into 3D scenes.

So we got smart factories, smart parks, smart cities, and all kinds of data visualization dashboards.

These systems solved an important problem: making previously scattered data visible.

But as data keeps accumulating, a new problem appears.

An industry may have dozens of business systems, hundreds of data indicators, and thousands of devices.

If we keep following the traditional approach and put all important data on one dashboard, the screen usually becomes more and more complex.

Statistics on the left, rankings on the right, key indicators at the top, real-time alarms at the bottom.

To fit everything in, fonts get smaller and charts get denser.

In the end, a dashboard meant to improve information efficiency makes users spend more time searching for information.

The emergence of AI offers another possibility.

Users do not necessarily need to know which page the data is on, or understand the meaning of every indicator.

They may only need to ask a question: “Which devices are abnormal today?”

The system can then query the relevant data, locate the abnormal devices, highlight the corresponding objects in the 3D scene, and show the cause and historical trend.

That is what I understand digital-intelligence to be.

It is not adding an AI chat box to the lower-right corner of an existing dashboard; it is letting AI actually participate in data querying, scene control, and information organization.

Of course, this does not mean traditional charts and fixed dashboards will disappear.

For key indicators that need continuous monitoring, fixed display is still the most efficient way.

What really needs to change is no longer requiring all information to appear on the screen at the same time.

2. One Screen, One Industry: Minimal Display, Maximum Interaction

If I were to redesign a smart factory dashboard, I would try to follow one principle:

Minimal display, maximum interaction.

“Minimal display” here does not mean making the dashboard empty.

It means showing only the most important information by default and leaving complex content to interaction.

I think the future industry dashboard can be divided into three layers.

🍋 1. Default state: understand the whole industry at a glance

When the dashboard opens, the first thing should be the overall state of the industry.

Take a smart factory as an example.

In the center of the screen is a complete 3D factory, with only a few key indicators around it:

Today’s output

Equipment operating rate

Total energy consumption

Current alarm count

Production plan completion rate

Other information is hidden for now.

The 3D scene does not need every device spinning and every pipe flowing.

Normally running equipment stays in a low-interference state; abnormal equipment is highlighted with color, outline, or moderate animation.

After entering the system, users should first know:

Is the factory overall normal? Where are the problems? Is there anything that needs immediate attention?

The default state of the dashboard should help users build global awareness quickly, not show how many features the development team built.

This involves a very important design idea: information hierarchy.

A screen should have a clear visual focus.

If every number glows and every chart flashes, then in the end nothing truly stands out.

🍋 2. Interaction state: drill down from industry to equipment

When users become interested in an area, show more detailed information.

For example, click a workshop building in the factory.

The camera smoothly moves to the workshop, other buildings fade back appropriately, and the interface shows the workshop’s production status.

Continue by clicking a production line.

The camera moves closer, showing line equipment, running status, output, and energy consumption.

Click a device.

The system shows device parameters, real-time data, historical curves, and maintenance records.

The whole process forms a clear interaction path: factory → workshop → production line → device → business data.

There is an easily overlooked detail here:

The 3D model should not be just a visual decoration.

Every 3D object that needs interaction should be linked to a business entity.

For example, the device object in the model has a unique ID: device_001

With this ID, you can find the corresponding device information, real-time data, historical records, and related business interfaces.

In this way, clicking a 3D device no longer just pops up a pre-written introduction panel; it enters the corresponding business context.

This requires us to consider the mapping between models and business data when designing the 3D scene.

The future 3D scene is not just a collection of models; it should be a spatial expression of industry business relationships.

🍋 3. Intelligent state: users ask questions, the system organizes the interface

The first two layers can be implemented with Three.js, Cesium, and ordinary frontend technologies.

The third layer is where AI can really make a difference.

Suppose a user opens the smart factory dashboard and types: “Help me find the production lines with abnormal energy consumption last week.”

A traditional dashboard might require users to enter the energy page, select a time range, and then check line data one by one.

With AI connected, the interaction flow can be designed differently.

First, AI understands that the user wants to query abnormal line energy consumption.

Then it calls the data query tools provided by the business system to get the matching production lines.

Next, it finds the corresponding objects in the 3D scene through the production line ID.

The camera automatically moves to the relevant area and highlights the abnormal lines.

Finally, the system generates a temporary energy consumption trend chart from the query results and shows the abnormal time, degree of deviation, and related indicators.

If the user continues: “Compared with the previous week?”

The system keeps the current context, continues querying, and updates the chart.

If the user asks again: “Locate the device with the most severe anomaly.”

The camera can move further to that device.

Note the big change here.

In the past, developers designed pages in advance; in the future, the system can dynamically organize pages based on user questions.

Of course, this requires a precondition:

AI must be able to access business data through reliable tools and have explicit scene control capabilities.

It cannot just rely on a language model to generate a seemingly reasonable device analysis.

Real data must come from business systems.

Device positioning must be based on explicit object IDs.

Anomaly judgment needs traceable rules or models.

For high-risk operations such as controlling equipment or modifying parameters, permissions and human confirmation mechanisms must be set up.

So I prefer to position AI as an intelligent interaction orchestration layer.

It is responsible for understanding intent, calling tools, and organizing information.

Rather than letting AI generate the entire business system out of thin air.

3. Where 3D Models Come From: In the Future, You Will Not Need to Model Everything Yourself

After talking about interaction, let’s return to the question 3D visualization engineers know best. Where do models come from?

In the past, making a smart factory project meant model production could take up a large part of the time.

Workshops need modeling, equipment needs modeling, pipes need modeling, and the scene needs constant adjustment.

If the client provides CAD or BIM files, the situation is not necessarily easier.

The models may be very detailed, but putting them directly in a browser is often unacceptable in terms of performance.

In recent years, with the development of AI-generated 3D, procedural modeling, and automation tools, model production is changing.

I think future industry dashboards should not rely on just one modeling method.

Instead, choose the most appropriate technology according to asset type.

🍋 1. Core assets still need professional modeling

For example, core production equipment in a smart factory.

These devices may need to show internal structure, operating principles, and exploded-view animations.

Some involve complex mechanical motion.

Such assets have high requirements for precision, topology, and controllability.

Traditional modeling software such as Blender and 3ds Max still has irreplaceable value.

Especially when device animation, structural breakdowns, and detailed interaction are needed, how the model is organized matters more than its appearance.

A model that looks beautiful but has all parts merged together can be very troublesome to use.

🍋 2. BIM, CAD, and GIS data build the scene foundation

For workshops, buildings, pipes, and city-level scenes, it is usually unnecessary to rebuild everything by hand.

If BIM or CAD data already exists, conversion tools can generate 3D assets suitable for the web.

But there is a key problem:

Engineering models are not real-time rendering models.

BIM models contain a lot of engineering information and fine structure.

This content is valuable for engineering design, but not necessarily suitable for real-time rendering in a browser.

Direct loading can cause problems such as overly large model size, too many draw calls, and slow first-screen loading.

Therefore, after conversion, models usually need: geometry merging, instancing, material cleanup, decimation, LOD processing, and texture compression.

For geospatial scenes such as cities and parks, consider Cesium and 3D Tiles.

For regular buildings, roads, and plots, data such as GeoJSON and OSM can be used for procedural generation.

For example, the white-box models of ordinary buildings in a city often do not need to be made one by one by hand.

As long as you have building footprints, heights, and similar data, you can extrude them in batches.

Procedural modeling is best for repetitive, regular, and large-scale problems.

🍋 3. AI-generated 3D is suitable for filling in large numbers of non-core assets

AI-generated 3D is a direction I think is worth continued attention.

There are already tools such as Meshy, Tripo, Rodin, and Tencent Hunyuan 3D that can generate 3D models from text or images.

1. tripo: https://studio.tripo3d.ai/

My most-used web page for generating 3D models. Highly recommended.

1. meshy: https://www.meshy.ai/

I use it less often, usually for making figurines and cute pets.

1. Rodin: https://hyper3d.ai/

The worldGen feature is very appealing.

1. Tencent Hunyuan: https://3d.hunyuan.tencent.com/

It has a free quota of 20 uses, and the generated results are quite good.

On the open-source side, there are also related projects such as TRELLIS.

For dashboard development, this means assets that once required searching for materials or hand modeling can be quickly generated with AI.

Examples: industrial equipment housings, park decoration facilities, ordinary mechanical props, warehouse shelves, logistics containers, and so on.

But in actual use, you cannot only look at the generated result.

Whether a model can enter a project matters more than whether it looks pretty in generation.

A preview image of an AI-generated model may look refined.

But after downloading, you may find: too many faces, messy topology, too many materials, and unreasonable texture resolutions.

Even a very simple device can be generated with hundreds of thousands of faces.

Putting that in a browser, especially when many devices load at once, easily causes performance problems.

Therefore, asset budgets should be defined before generation.

For example, ordinary scene props can be kept to a few thousand to tens of thousands of triangles, while important equipment is evaluated separately based on camera distance, screen share, and the performance of the running device.

This is only an initial budget, not a fixed standard for all projects.

After generation, it still needs to go through a standardized processing pipeline:

AI generation → Blender cleanup → decimation optimization → material cleanup → GLB export → compression → web validation.

GLB compression can combine technologies such as Draco, meshopt, and KTX2.

But compression does not mean the model will run fast.

They mainly solve transfer size, geometry encoding, or texture storage; actual rendering performance still depends on model structure, material count, draw calls, and GPU cost.

So final testing still needs to happen on the target device.

🍋 4. AI-driven Blender may be more worth watching

Compared with pure text-to-3D, I am actually more interested in another approach:

Let AI participate in the operation workflow of traditional modeling software.

For example, through the Blender Python API or tools like Blender MCP, AI can execute scene setup and batch modification tasks from instructions.

Suppose you need to generate a workshop containing 20 devices.

You can prepare standard device assets in advance, then use a script to complete arrangement, naming, material settings, and scene export.

If the spacing between devices needs adjustment, you do not need to manually drag each model.

You can modify the overall layout through parameters or natural language instructions.

Going further, AI coding tools such as Codex can generate and maintain Blender scripts.

The whole process may become: requirement description → AI generates script → Blender executes → model check → GLB export → Three.js load.

This approach has an advantage:

It does not generate models from scratch every time; it builds on existing assets and clear rules.

Controllability and reproducibility are usually better.

Of course, AI-generated scripts also need checking and verification, and complex scenes still require manual adjustment.

But for a large amount of repetitive work, this route is very worth exploring.

I think future 3D visualization engineers may not need to hand-build every model.

More importantly: know which assets should be hand-made, which can be generated procedurally, and which are suitable for AI.

5. The rise of 3DGS adds a new route for real-scene reconstruction

Besides hand modeling, procedural generation, and AI generation, the way real scenes are reconstructed is also changing.

One direction worth attention is 3D Gaussian Splatting, abbreviated as 3DGS, usually called “three-dimensional Gaussian splatting” in Chinese.

A representative study published in 2023 combined high-quality novel-view synthesis with real-time rendering, providing a new technical route for real-scene 3D. It uses multi-view photos to optimize a large number of Gaussian primitives with position, shape, color, and opacity, then restores the scene’s appearance by layering those Gaussians. Original paper (https://arxiv.org/abs/2308.04079)

For visualization dashboards, this means we can try to reconstruct actually photographed factory areas, parks, or interior spaces into realistic scenes where the viewpoint can be switched freely.

How is it different from the oblique photography commonly used in the past?

Here we need to distinguish two concepts first.

Oblique photography mainly describes how imagery is captured; 3DGS is a scene representation and rendering method.

The common oblique photography modeling workflow shoots from multiple angles, then uses image matching and spatial reconstruction to generate point clouds, triangle meshes, and textures. 3DGS instead uses the captured images to optimize a Gaussian representation. The same set of sufficiently covered, suitably high-quality oblique images can also be used for different reconstruction routes. Some real-scene modeling tools already provide both mesh and Gaussian splatting outputs. Esri output type description

So the more accurate comparison is between the textured mesh generated by traditional oblique photography and the 3DGS scene.

Comparison dimension	Traditional oblique photography textured mesh	3DGS scene
Scene representation	Surfaces composed of triangles, then textured	Many Gaussian primitives layered to reproduce appearance from different viewpoints
Detail expression	Depends on mesh and texture quality; fine structures may be simplified	With sufficient capture, fine lines, vegetation, and other details can look more natural
Editing method	Process around vertices, faces, and textures	Select, clip, and transform Gaussian primitives; cannot directly copy mesh editing workflows
Project focus	Easy to integrate into existing mesh processing and spatial analysis workflows	Suitable for environment display and walkthroughs that emphasize realistic appearance

However, a more realistic picture does not mean measurement is necessarily more accurate.

No matter which method is used, when it comes to device dimensions, spatial distances, or engineering quantity calculations, reliable scale, coordinate datum, and accuracy verification are needed.

The Gaussian centers in 3DGS cannot be directly treated as measurement points on object surfaces.

Interaction also needs separate design.

Some web engines already support click-picking on Gaussian scenes. But to further identify “this is a water pump” and associate it with device numbers, alarms, and maintenance records, object segmentation, annotation, or additional business models are still needed. Traditional oblique photography meshes do not automatically have these business meanings either. PlayCanvas picking documentation

In addition, 3DGS performance needs actual evaluation.

The number of Gaussians, transparent layering, VRAM usage, and screen resolution all affect performance. After entering a dashboard project, compression, tiling, LOD, and on-demand loading also need to be considered, with verification on the on-site device. PlayCanvas performance documentation

If I were to design a smart park dashboard, I would consider a hybrid approach:

Use 3DGS to reproduce the real environment of the park, use separate device models to carry exploded views, animation, and fine interaction, then link business data through unified coordinates and object IDs.

For projects focused on spatial measurement and analysis, prioritize accuracy-verified photogrammetry meshes, point clouds, or engineering models.

This also adds another dimension to model selection:

When realistic environment appearance is needed, real-scene reconstruction can be considered; when precise structure, controllable animation, and business interaction are needed, prepare the corresponding models and data for those capabilities.

4. Making a Great Dashboard Is All in the Details

After the technical approach is settled, the final result still depends on many details.

These details may not appear in project introductions, but users feel them every day.

🍋 1. Information hierarchy matters more than flashy effects

Many dashboards like to use glowing borders, gradient backgrounds, particle animations, and various decorative lines.

These elements are not unusable.

But if all content competes for attention, truly important information suffers.

I prefer to make the 3D scene the main visual area.

Other charts appear according to business needs.

Normal states stay restrained, and abnormal states stand out clearly.

Especially red.

If a screen is covered in red decoration, red loses its warning effect when a real alarm occurs.

Color should express business meaning, not just create a tech feel.

🍋 2. Fonts and numbers affect more than appearance

Dashboards usually need to display large amounts of real-time changing data.

For example, output changes from 999 to 1000.

If a regular proportional numeral font is used, changes in digit width can cause layout jitter.

You can use a font that supports tabular numerals, or set it through CSS:

    font-variant-numeric: tabular-nums;

For Chinese fonts, prioritize clear, stable sans-serif fonts.

Examples include Source Han Sans and Alibaba PuHuiTi.

Also, do not just stare at a computer monitor during design.

A 55-inch screen and a large video wall in a meeting room have completely different actual viewing distances.

Font sizes should be verified based on screen size, resolution, and viewing distance.

Rather than stopping when it looks right in the design mockup.

🍋 3. Industry color schemes should have their own logic

Dashboards in different industries do not all need to use the blue tech style.

Manufacturing can use steel blue-gray as the background and industrial orange to emphasize equipment status.

The energy industry can use deep blue and cyan to highlight energy flow and equipment operation information.

Medical scenes suit a low-saturation teal-green system, avoiding excessive glow.

Agriculture and environmental projects can combine dark green, earthy yellow, and other natural color systems.

Transportation and logistics can use dark gray and amber to highlight routes, vehicles, and operating status.

But these are only visual directions.

What truly matters is establishing unified color semantics.

For example: green for normal, amber for warning, red for severe anomaly.

The same color should keep a consistent business meaning across different pages as much as possible.

Only then can users form stable understanding.

🍋 4. Motion should serve information

In 3D scenes, camera animation is very important.

After clicking a device, how does the camera move?

When switching from the whole factory to a workshop, how do you prevent users from losing their bearings?

When locating an abnormal object, how do you let users know where the target is?

These are actually interaction design problems.

Good camera animation is not about flying as flashily as possible.

It is about letting users always know where they are during spatial transitions.

For example, entering a workshop from the factory area can first move to the outside of the workshop, then gradually zoom in to the equipment.

Instead of teleporting directly inside the equipment.

For frequently used functions, users should also be allowed to skip animations.

The value of motion is to help users understand changes, not just to show off rendering capability.

🍋 5. Performance determines whether a dashboard can run long-term

Anyone who has worked on real projects should feel this deeply.

Running smoothly on a development computer does not mean there will be no problems after deployment to the site.

The site may use GPUs with different performance levels.

It may need to drive multiple screens at the same time.

It may also require the system to run continuously for days or even weeks.

Therefore, performance optimization cannot wait until the end of the project.

Resource budgets need to be controlled from the modeling stage.

For example, use technologies such as InstancedMesh, LOD, texture compression, and on-demand loading appropriately.

For Three.js projects, keep a constant eye on draw calls, triangle count, texture memory, and render time.

For Cesium projects, pay attention to tile loading, cache strategy, and the relationship between camera height and level of detail.

Besides rendering performance, system stability also needs to be considered.

How to recover after an API disconnects?

How to sync data after a WebSocket reconnects?

Are there memory leaks during long-running operation?

What should be displayed when data is empty?

What should be done if model loading fails?

These questions do not sound as attractive as AI and digital twins.

But after real deployment, they are often much more important than some special effect.

Only a dashboard that runs stably has the right to talk about intelligence.

5. What AI May Really Change Is How Dashboards Are Built

The earlier sections talked about changes in product form.

But from an engineer’s perspective, I think there is another trend more worth attention.

In the future, the way dashboards are developed may also change.

The traditional dashboard development process is usually:

Product determines requirements, designers complete pages, modelers prepare models, frontend engineers develop interactions, and backend provides APIs.

Every time a business page is added, the entire development process often has to be repeated.

But if dashboards start to have the ability to organize information dynamically, many things can gradually shift from fixed pages to configurable capabilities.

For example, chart components.

In the past, we needed to develop an energy analysis page, an output analysis page, and an equipment failure analysis page in advance.

In the future, you can first build a standardized set of chart components.

AI selects the appropriate chart type based on the user’s question, then organizes the display together with real query results.

The same goes for the 3D scene.

In the past, clicking device A executed a fixed piece of code.

Clicking device B executed another piece of code.

In the future, operations such as camera control, object highlighting, device location, and layer switching can be encapsulated into standard tools.

For example:

locateObject(deviceId)
highlightObjects(deviceIds)
flyToArea(areaId)
showDataPanel(config)

These tools can be called by ordinary interactions, or by AI with proper permissions.

In this way, AI does not need to understand all the implementation details under Three.js or Cesium.

It only needs to know which reliable operation capabilities the system provides.

The frontend is responsible for turning those operations into concrete visual presentation.

Underneath that is a unified industry data model.

Which production line does a device belong to?

Which workshop is a production line located in?

Which energy indicators correspond to a workshop?

Which business data can be queried by device ID?

Only when these relationships are established can AI accurately understand user questions and map results into the 3D scene.

So future dashboards may gradually form a new architecture:

Industry data model + 3D scene engine + standard interaction components + AI orchestration layer.

The AI orchestration layer here does not directly operate all underlying systems.

A more reasonable approach is controlled tool calls, with business systems responsible for data permissions, query rules, and operation validation.

For frontend engineers, this means the focus of work may shift.

We are no longer just developing fixed pages from design mockups.

Instead, we need to build a set of visualization capabilities that can be called by both user interactions and AI.

This also means that future 3D frontend engineers, in addition to mastering Three.js, Cesium, WebGL, and other technologies, need to understand:

How to design data models, how to associate 3D objects with business entities, how to encapsulate interaction capabilities, and how AI can safely and reliably call these capabilities.

Of course, not every project needs to get there in one step.

For many enterprises, connecting device data and getting scene interaction right is already enough to create clear value.

AI can be connected gradually on this basis.

There is no need to make an originally simple and stable system complex in pursuit of digital-intelligence.

6. Where Is the Value of 3D Visualization Engineers in the Next Five Years?

Looking back over the past few years, 3D visualization technology has changed a lot.

In the past, making a complex 3D scene could take a lot of time to handle models, materials, and rendering effects.

Now, with more mature 3D engines, model processing tools, and AI-assisted development capabilities, the barrier to many things is lowering.

It is foreseeable that generating a beautiful 3D scene will become easier and easier.

Even generating a complete data visualization page may no longer take much time.

So where is the value of the 3D visualization engineer?

I think the answer is not making models more complex or animations flashier.

It is understanding the business and turning complex business systems into intuitive, operable interaction experiences.

Take a smart factory.

What users really care about is not how many faces a device model has, but whether the device is abnormal.

Not how smooth the production line animation is, but why production efficiency dropped.

Not how beautiful the energy chart is, but where energy waste exists.

The value of 3D visualization is putting this abstract data and these business relationships back into spatial scenes that users can understand.

The value of AI is further lowering the barrier for users to obtain and use this information.

Only by combining the two can a dashboard truly change from a display tool into a business tool.

Of course, this process will not happen overnight.

Industry data governance, model accuracy, interface standardization, permission control, and the reliability of AI output will all affect the final result.

But the direction is already worth serious thought.

In the past, when evaluating a dashboard, we first looked at whether it was beautiful.

Whether the models were detailed enough, the animations smooth enough, and the visual effects techy enough.

These still matter.

But in the future, I think a few more questions should be added:

Can users quickly find the information they care about?

Can they locate a specific device from an abnormal indicator?

Can they query complex business data through natural language?

Can they trigger actual business processes based on analysis results?

If these problems are solved well, then even if the screen does not have so many charts or glowing effects, it can still be an excellent dashboard.

It may even be more valuable than a traditionally cool-looking dashboard.

Because it truly enters users’ daily work.

A Final Word

I have always thought that 3D visualization should not just move the real world into a browser.

If we only reproduce a factory, a park, or a city, what we end up with may just be a 3D model that can be rotated and zoomed.

What is truly valuable is connecting this 3D world with the business data behind it.

Let users understand data through space, explore problems through interaction, and obtain information more efficiently through AI.

This is also my judgment about the future of industry dashboards:

A screen does not need to show all the information of an industry at once, but it should become an entry point for accessing the entire industry’s information.

Default display can be restrained.

Interaction capabilities can keep expanding.

From viewing data, to querying data, to asking data, to using data.

From fixed pages, to scene interaction, to AI dynamically organizing information.

This may be the direction worth exploring for 3D visualization dashboards after moving from digitalization to digital-intelligence.

In the next five years, what we need to build may no longer be a dashboard that people look up at, but an industry interaction system that people actually use.