Zero-Code 3D Charging Station Dashboard Built End-to-End with ChatGPT 5.6
Let me start with the conclusion.
From a design draft to a 3D visualization dashboard that opens in a browser and pops up a status panel when you click a charging pile, I did not write a single line of code, did not manually drag a single control in Blender, and did not slice a single image.
The entire pipeline was handed over to ChatGPT 5.6 (Sol).
But this article is not here to brag about how powerful AI is. What I want to talk about is: the pitfalls I stepped into along the way, and why the same tool, used differently, can produce results that are worlds apart. It also serves as a supplement to the article Having a dashboard design draft wasn't enough, so I used Gpt-image-2 to extract all the assets from it and a fix for the asset extraction prompts.
This is the final web page effect I achieved, and I think it turned out pretty well.
Four Steps, Each Step's Input is the Previous Step's Output
The pipeline itself is not complicated:
Design Draft → Slice Transparent Assets → Blender Automated Modeling → 3D Dashboard Web Page
The tool combination is Codex (ChatGPT 5.6 (Sol)), Blender, blender-mcp, and a dashboard scaffold I made earlier, @lius1314/visual-dashboard-scaffold.
It sounds smooth. In reality, I encountered many problems. Let's go through the overall process step by step and see what problems arose and how they were solved.
Step 1: Design Draft
The design draft wasn't created in one shot; it went back and forth for several rounds. First, a first version of the charging station concept image was generated based on a reference image in a dark-tech isometric sandbox style. After looking at it, I felt the texture wasn't good enough, so I remade it into a highest-quality 16:9 version. At this point, the design draft was already usable, but to cooperate with the subsequent slicing process, I separately produced a version with a reserved transparent background—because asset slicing ultimately requires digging icons and borders out of the background. If the source design draft itself doesn't have clean boundaries reserved for separation, slicing will be difficult no matter what.
The design draft above is mainly blue. I felt too many people do this style, and its interface felt too generic, so I redesigned the draft. The dark black one below is what I thought looked pretty good.
This step took quite a bit of time, but there were no pitfalls, so I'll skip the details and go straight to step two.
Step 2: Slicing
First Version: 27 Assets, All Wasted
After the design draft was finalized, I had Codex extract icons, card borders, and dividing lines based on coordinates. The prompt used was from the previous article Having a dashboard design draft wasn't enough, so I used Gpt-image-2 to extract all the assets from it—background color #0B1426, extract icons and borders, verify dimensions and RGB.
It produced 27 assets. Numerically, everything was correct: 12 icons, 7 card frames, 6 decorative pieces, all dimension and color checks passed.
Then I placed them onto the page.
Icons enlarged to 200% were all blurry. Many icons in the original image were only twenty to thirty pixels square. The slicing script directly interpolated and enlarged them to make up the numbers, resulting in blurry edges and internal hollow areas that were a smeared mess. Even more ridiculous was that the background wasn't transparent at all—when placed on the page, as long as the page background differed slightly from #0B1426, a rectangular color block appeared around the icon, like a sticking plaster.
27 assets, all effectively wasted.
Later, I figured it out. The prompt at the time included a line: "RGB no Alpha, #0B1426 background color verification"—this sentence contradicts itself. Requiring RGB with no Alpha channel means the background can only be a solid color, making true transparency impossible. The model followed this instruction exactly, producing something that perfectly met the requirements but was completely unusable.
This wasn't the model's problem; it was my problem. The prompt only stated what to do, not how to judge if it was done well enough. Without judgment criteria, the model will always choose the easiest path—interpolation enlargement instead of clarity, solid color background instead of true transparency, giving you a result that looks qualified on the surface.
Second Version: Writing "Acceptance Criteria" into the Prompt
I didn't patch the original prompt; I scrapped it and rewrote it from scratch. The core change was just one thing: changing from "describe the task" to "describe the task + acceptance criteria for each step."
Transparency was locked down: icons, card backplates, title backgrounds, dividing decorations—all must be output as PNG-32 RGBA, with Alpha in blank areas strictly at 0. White backgrounds, black backgrounds, and checkerboard pseudo-transparency were all listed as forbidden items.
Clarity was handled via branching logic: if the original subject was larger than 64 pixels and the outline was still discernible, perform precise pixel-level extraction, preserving original pixels; if the original was already blurry, perform a constrained high-definition reconstruction—but only following the original's outer contour, proportions, and line width to clean up edges, strictly forbidding the addition of textures or details not originally present; if there wasn't even enough basis for reconstruction, skip it and explain why, rather than forcing a barely usable version.
Verification actions were also written into the process: after each asset was sliced, place it on pure white and pure black backgrounds to check for residual edge strokes, then use a transparent checkerboard to confirm the Alpha channel was truly effective. Previously, this step relied on manual spot-checking afterward; now the model self-checks before delivering results.
Additionally, a hard rule was set: one asset per file, each element in a separate file. Previously, the model sometimes took shortcuts by assembling icons into a sprite sheet; this version explicitly banned that.
Running with the new prompt produced 20 assets. All four corners had Alpha at 0, and white/black background edge checks all passed.
Here are just a few examples. It seems the sliced resources are still not ultra-high-definition, but they are already quite sufficient.
What made the difference in results wasn't switching to a more powerful model, but writing the acceptance criteria into the prompt. This sentence is worth remembering.
Below is the new asset slicing resource prompt. Feel free to use it if needed.
# Advanced UI Asset Transparent Extraction Expert v5.1
> Input: A complete visualization dashboard design draft (usually 1920×1080 PNG)
>
> Output: Independent transparent PNG assets split by batch, directly usable in frontend projects
You are a professional UI asset extraction and image matting expert. Your task is to identify reusable visual elements in the design draft, separate them one by one, and output production-grade assets with clear outlines, clean edges, and true transparent backgrounds.
---
## Highest Priority Hard Constraints
The following rules take precedence over other requirements in this document; in case of conflict, this section prevails.
1. **True Transparency**: Except for BATCH-05, all outputs must be `PNG-32 RGBA`. Pixels outside the element area must have `Alpha=0`.
2. **No Pseudo-Transparency**: Strictly prohibit using white, black, dark, solid color, or checkerboard backgrounds to simulate transparency; checkerboards can only appear in preview interfaces and must not be written into the image.
3. **One Asset Per File**: Each file contains only one independent element. Outputting sprite sheets, collages, contact sheets, or labeled preview boards is forbidden.
4. **Clarity First**: Do not take low-resolution crops and simply enlarge them using Lanczos, bicubic interpolation, or sharpening to pass them off as high-definition assets.
5. **Faithful to Original**: Maintain the element's contour, proportions, color, line width, lighting effects, perspective, and visual meaning. Do not change the design language or add details not present in the original.
6. **Edge Pollution-Free**: Glows, shadows, feathering, and anti-aliasing must correctly transition to transparency, without residual background color from the original draft forming dark strokes, color fringes, or rectangular halos.
7. **No Output if Unassured**: If the current tool cannot export true Alpha PNGs, you must stop and clearly state this. Substituting with images having solid backgrounds is forbidden.
---
## Task Instructions
Based on the uploaded design draft, process only one batch at a time. Mixing outputs is strictly prohibited:
- 【BATCH-01】General Icons: Function, status, navigation, UI icons
- 【BATCH-02】Card Backplates: Hollow borders, information containers
- 【BATCH-03】Title Backgrounds: Title backplates, title decorative bars
- 【BATCH-04】Dividers and Decorations: Lines, corner marks, tech decorations
- 【BATCH-05】Module Backgrounds: Large area partition backplates, overall backgrounds
- 【RESCAN】Supplementary Scan: Extract missed elements from a specified batch
Each visual element can only be assigned to one batch. Duplicate extraction is prohibited.
---
## Output Constants
| Item | Requirement |
|---|---|
| BATCH-01～04 Background | True transparent, blank areas Alpha=0 |
| BATCH-01～04 Format | PNG-32 RGBA, sRGB |
| BATCH-05 Format | PNG-24 RGB or PNG-32 RGBA, keep as original |
| Safe Margin | 5%～10%; minimum 8px; glowing elements minimum 16px |
| Icon Canvas | 256×256px; subject occupies 70%～85% of canvas |
| File Naming | `{batch_number}_{sequence_number}_{english_description}.png` |
The original design draft background color is only used for identifying elements and eliminating edge pollution; it must not be written into the final images for BATCH-01～04.
---
## Unified Extraction Process
Each asset must complete the following steps in sequence:
1. **Locate**: Scan from top to bottom, left to right, recording the element's position in the original image.
2. **Classify**: Assign batches based on the element's primary function, not arbitrarily by color or size.
3. **Determine Independence**: Only extract elements with complete outlines, unobstructed, and separable from surrounding content.
4. **Choose Processing Method**:
- Original is sufficiently clear: Execute pixel-level precise extraction.
- Original is too small or already visibly pixelated: Execute one "constrained high-definition reconstruction."
5. **Remove Background**: Delete all pixels outside the element, making blank areas Alpha=0.
6. **Edge Cleanup**: Eliminate color fringing caused by the original dashboard background color, while preserving reasonable semi-transparent anti-aliasing and lighting effects.
7. **Standardize Canvas**: Scale proportionally, center, retain transparent safe margins. Stretching is strictly forbidden.
8. **Dual-Background Check**: Place on pure white and pure black backgrounds respectively to check edges, then use a transparent checkerboard to confirm the Alpha channel.
9. **Independent Export**: Output each element as a single PNG file.
---
## Clarity Processing Rules
### A. Pixel-Level Precise Extraction
Use when: The subject's shortest side in the original is ≥64px, and the outline, fine lines, and internal hollows are clearly discernible.
- Maximize preservation of original pixels and original visual effects.
- Do not stylize, redraw, over-sharpen, or enhance contrast.
- If scaling is needed, perform only one proportional high-quality resampling.
### B. Constrained High-Definition Reconstruction
Enable only when the element's shortest side is <64px, visibly blurred, or unusable when enlarged.
- The original image is the sole visual reference. What is reconstructed is the same icon, not a similar icon created anew.
- Must lock: outer contour, aspect ratio, internal structure, line width relationships, color, gradient direction, glow intensity and orientation.
- Only restore clear edges and continuous lines. Do not add textures, symbols, layers, or decorations.
- Simple linear icons should have stable line widths, continuous contours, and clean internal holes.
- Using bold strokes, strong sharpening, excessive glow, or contrast enhancement to create a false impression of "clarity" is forbidden.
If faithful reconstruction is impossible, skip the element and explain why.
---
## Complex Element Classification Rules
1. Conveys function or status meaning → BATCH-01
2. Used to contain or frame content → BATCH-02
3. Specifically serves the title area → BATCH-03
4. Used for separation, corner embellishment, or tech decoration → BATCH-04
5. Constitutes a large-area overall base map → BATCH-05
6. Severely stuck to text, charts, or other elements and cannot be reliably separated → Skip
---
## Per-Batch Rules
### 【BATCH-01】General Icons
Belongs to: Independent function icons, status icons, navigation icons, UI operation icons.
Does not belong to: Chart data points, title decorations, card corner marks, business graphics inseparable from cards.
Requirements:
- Each icon output as an independent 256×256px transparent PNG.
- Icon subject visually centered within canvas, occupying 70%～85% of canvas, must not touch edges.
- Preserve complete contours, internal holes, fine lines, glows, and shadows; no broken lines,粘连 (adhesion), or blocked holes.
- Do not output rectangular crops containing the original background color directly as the final asset.
- Must not contain any text, numbers, watermarks, names, or labels.
Per-icon verification:
- [ ] PNG is RGBA, four corner pixels Alpha=0
- [ ] Transparent areas have no white, black, dark blue, or checkerboard pixels
- [ ] White and black background previews show no rectangular base, dark edges, noise edges, or abnormal halos
- [ ] Clear at 100% display; at 200% display, contours are continuous, fine lines unbroken, internal holes unblocked
- [ ] Icon shape, color, proportions, and visual meaning consistent with original
- [ ] File contains only one icon and no text
### 【BATCH-02】Card Backplates
Belongs to: Complete border containers, independent panel frames.
Does not belong to: Title bars, module overall backgrounds.
Requirements:
- Only retain outer borders, tech corners, strokes, edge glows, and multi-layered decorative structures.
- Remove titles, text, numbers, icons, charts, data, and internal fills.
- Both outside and center area of the container must be truly transparent, forming a hollow border that can be directly overlaid.
- Output width ≥512px, height proportional, transparent safe margins intact.
### 【BATCH-03】Title Backgrounds
Belongs to: Title area backplates, title decorative bars.
Does not belong to: Complete card borders, independent corner marks.
Requirements:
- Remove all title text, only retain the decorative backplate.
- Preserve complex contours, gradients, rhythmic lines, and end fades.
- Fades and glows must naturally transition to Alpha=0.
- Output width ≥640px, height ≥128px.
### 【BATCH-04】Dividers and Decorations
Belongs to: Independent dividing lines, tech lines, corner decorations.
Does not belong to: Parts of card borders, title decorative bars.
Requirements:
- Lines and corner marks must be exported independently.
- Preserve line end feathering, naturally transitioning to Alpha=0.
- Horizontal line length ≥512px; vertical line height ≥512px; corner mark canvas ≥128×128px.
### 【BATCH-05】Module Backgrounds
Belongs to: Large area partition backplates, overall panel background areas.
Requirements:
- Preserve textures, grids, gradients, and glowing outlines.
- Remove text, numbers, icons, charts, and business content.
- Minimum output 1920×1080; if original is larger, keep original dimensions.
- This batch is itself a background layer, can retain original background, not subject to the transparent background hard constraint.
---
## Exclusion Conditions
Skip and explain if encountering the following, do not force output of inferior assets:
- Element is occluded, truncated by the image edge, or cannot be reliably separated from other elements
- Underlying structure cannot be reasonably restored after removing text
- Insufficient original information to faithfully reconstruct shape or internal structure
- Severe color fringing, broken lines, or transparent holes that cannot be eliminated after background removal
- Output still contains text, numbers, business data, or elements from other batches
---
## Unqualified Redo Conditions
If any of the following conditions are met, a redo is mandatory:
| Check Item | Unqualified Condition |
|---|---|
| Transparent Background | Any of the four corner pixels Alpha≠0, or solid color/checkerboard background exists |
| Edge Pollution | White or black background preview shows original background color strokes, noise edges, rectangular halos |
| Clarity | Blur visible at 100%; broken lines, blocked holes, double edges, or severe aliasing at 200% |
| Fidelity | Contour, proportion, color, line width, or visual meaning deviates from original |
| Completeness | Glows, shadows, feathering, or corners are cropped |
| Content Purity | Text, numbers, watermarks, labels, or other irrelevant elements exist |
| File Organization | Multiple elements merged into a single image |
---
## Quantity and Naming
- Maximum 12 assets output per batch per round.
- File naming format: `{batch_number}_{sequence_number}_{english_description}.png`.
- Example: `b01_03_settings-icon.png`, `b02_01_card-frame-large.png`.
- Stop when reaching 12 and prompt:
> This batch has extracted 12 assets. Reply "continue" to extract remaining elements, or specify a new batch.
---
## RESCAN Supplementary Scan Mode
Trigger example:
Rescan BATCH-01, the 3rd icon on the left panel was not extracted
Only extract the specifically indicated missed elements, do not repeat completed assets; must still pass all transparency, clarity, and fidelity checks for the original batch.
---
## Per-Round Text Report
Report content must not be written into images. After completing a batch, list item by item in the reply:
1. File name
2. Element's position in the original image
3. Processing method: `Precise Extraction` or `Constrained HD Reconstruction`
4. Output dimensions
5. Alpha check result
6. White/Black background edge check result
7. Skipped elements and reasons
---
## Startup Method
Please upload the design draft and specify the batch, for example:
Start BATCH-01
Optionally, inform the original dashboard background color. It is only used for removing edge background color pollution and will not be written into the final transparent assets.
Step 3: Modeling and Baking
After the design draft was sliced, the surrounding icons, borders, and dividing lines were handed over to the frontend UI layer; the central 3D scene illustration did not go to the frontend but was given to blender-mcp (get address https://github.com/ahujasid/blender-mcp) as a reference image, letting Codex automatically model it in Blender based on this image.
First, connectivity was verified by having Codex create a cube in the scene to confirm the MCP channel was working. Once connected, a more complete charging station reference image was regenerated from the dark-tech isometric sandbox image in the middle of the design draft. Then Codex was instructed to build modules one by one based on this image: site base, photovoltaic canopy, charging piles, vehicles, energy storage battery cabins, transformer and distribution equipment, control room, glowing ground lines, floating UI panels. The entire process required no manual operation in Blender; Codex issued repeatable modeling scripts via MCP. If something was wrong, the script was modified and rerun, without needing to rebuild the scene from scratch.
First Version Model Problem: Shape was Right, Texture was Missing
After building, something felt off, but I couldn't pinpoint it. Staring for a while, I realized: the materials were flat. Metal had no highlights, the ground was solid color without micro-texture, glass had no transmission, car paint looked like plastic—the whole scene resembled a precise toy, not a real site.
When redoing, the PBR material workflow was completed: metallic and roughness were adjusted separately for metal parts, micro-texture was added to the floor, transmission was done for glass, a clear coat layer was added for car paint, and reflection was added for photovoltaic panels. Modeling granularity was also increased, ultimately building over a thousand objects. Four cars, four sets of charging piles, double rows of energy storage cabinets, cooling equipment, and cable trays were all built individually, no longer using simplified placeholder models to muddle through.
Group Before Baking, Don't Wait Until Frontend Integration to Remember
The model was detailed, but couldn't be directly thrown to the frontend for real-time rendering—the PBR materials on so many objects would kill the frame rate. So lighting and material information needed to be baked into textures. But baking also has its nuances; it's not just baking everything into a static image and calling it done.
Before baking, I first grouped all objects based on "will this need interaction in the future." Objects that would be clicked—vehicles, charging piles, terminals, battery cabinets, servers, transformers, control consoles, over twenty root nodes—each had their textures baked individually, preserving independent material channels, allowing the frontend to control their highlighting and state switching separately. Purely background objects—ground, building main body, photovoltaic canopy, fixed attachments—were merged into several atlas groups by area for baking, reducing rendering overhead.
For each group of textures, four maps were uniformly exported: BaseColor, Normal, ORM, Emission. The ORM map packs AO, Roughness, and Metallic into the R, G, and B channels respectively, allowing the frontend to get three types of material information from one image. Glass parts needed to retain transmission effects and were not merged; they were left as separate transparent sub-objects.
The judgment criterion for this step was only one: any object that interaction logic would touch, it's better to spend extra baking cost to retain independence; purely scene-filling objects, merge as much as possible. This grouping was done during the baking phase, not patched up during frontend integration—precisely because it was thought through in advance, there was basically no rework when connecting to the scaffold later.
Final measured results: source GLB about 77.3 MB, optimized for Web compressed to 25.32 MB, 107 embedded WebP images, max texture edge 1024, 23 interactive root nodes fully preserved.
Step 4: Assembling into a Web Page
The previous three steps produced three piles of independent things: transparent UI assets, a Blender scene with baked textures, and material channel files. To turn these into a web page a user could open, one more skeleton was needed—page layout, block management, screen adaptability. This part used the @lius1314/visual-dashboard-scaffold dashboard scaffold (you can read this article Visualization Dashboard Designer Scaffold: A One-Stop Solution from Design to Delivery, and if you need the source code, you can read this one Visualization Dashboard Scaffold Source Code: Downloads Exceeded 700 in a Week, Why Do So Many People Choose It?), a React dashboard container not tied to any specific chart library, defaulting to 1920×1080, which perfectly matched the asset dimension constraints from the previous slicing process.
Business charts or 3D scenes don't need to modify the scaffold source code. Components are registered as a block ID via registerBlock. The scaffold handles block dragging, scaling, layering, and styling; in preview mode, it integrates autofit.js for overall proportional scaling, allowing adjustment while viewing, without needing to switch resolutions back and forth to test.
The grouping done during the baking phase came into play here: the central 3D scene was wrapped in a Three.js rendering component and placed in the corresponding block position. Individually baked objects like charging piles and energy storage cabinets were interactive objects; the background and building parts were only rendered as a single overall texture, not participating in interaction logic, keeping rendering overhead under control.
The icons, borders, and dividing lines produced by the slicing process were placed into the static resource directory as per the scaffold's conventions and were ready to use. Conventional blocks like information cards, alarm lists, and energy consumption curves were standard React components registered by block ID. The entire configuration was finally exported as JSON to be loaded as the initial configuration. Later layout adjustments didn't require code changes; they were done directly in edit mode by dragging.
Finally
After completing this entire pipeline, I think two things are worth highlighting separately.
The first thing: whether acceptance criteria are present in the prompt determines whether you get usable assets or garbage. Without executable judgment criteria, the model will always choose the easiest path. It's not fooling you; it's just following orders—the orders you wrote simply weren't clear. After explicitly writing acceptance criteria into the prompt, the improvement in output quality was significantly more noticeable than switching to a more powerful model, which surprised me somewhat.
The second thing: early-stage layering decisions determine the amount of rework later. Whether you thought ahead during the baking phase about which objects would be clicked in the future directly determines whether you have to redo everything during frontend integration. Done at the right time, every subsequent step goes smoothly; done late, the cost is re-baking the entire scene.
Codex (ChatGPT 5.6 Sol) could deliver structured, executable results in stages like slicing, generating reference images, and issuing Blender modeling scripts, without needing a human to fill in details midway. This is the prerequisite for the entire pipeline to connect. But beyond the prerequisite, you still have to figure out for yourself what you want at each step.
Additionally, I found that gpt5.6 sol still couldn't truly reproduce the design draft in 3D modeling, nor achieve that industrial-grade texture, but the models it made were indeed quite good. The future is promising.
Preview address: https://liush.top/solar-storage-charging-ems
If you need the source code for reference, you can get it from the article of the same name on the 柳杉前端 public account.