DEV Community: Yuki Furuta

I Tried TripoSplat to Generate 3D Gaussian Splatting from a Single Image — Then I Tried Animating a Plant

Yuki Furuta — Sun, 02 Aug 2026 14:22:33 +0000

3D generation technology is moving incredibly fast.

A few years ago, if you wanted to create a 3D model from photos, the typical workflow was something like photogrammetry: take many images, match feature points, reconstruct geometry, generate a mesh, apply textures, and clean everything up manually.

That workflow is still useful, of course. But recently, technologies like NeRF, 3D Gaussian Splatting, and single-image-to-3D generation models have made 3D content creation much more accessible.

One of the most interesting technologies in this area is 3D Gaussian Splatting, often called 3DGS.

3DGS represents a 3D scene not as a polygon mesh, but as a large number of small 3D Gaussians. Each Gaussian has properties such as position, rotation, scale, color, and opacity. When rendered from a camera view, these Gaussians are projected onto the image plane as “splats.”

In simple terms, instead of building a surface out of triangles, 3DGS recreates the appearance of a scene using many soft, semi-transparent particles placed in 3D space.

This makes 3DGS very good at reproducing realistic visual appearance. It is not always as easy to edit as a mesh, but it can look surprisingly good and render very fast. That is why it has been getting attention in games, AR/VR, simulation, robotics, and computer vision.

Recently, TripoAI released TripoSplat, which can generate 3D Gaussian Splatting data from just a single image.

Generating 3D from a single image is a very difficult task. The model cannot directly see the back side of the object, hidden parts, or the true depth. So it has to infer the missing geometry based on what it has learned from many examples.

That means the result is not the same as a real 3D scan. Hidden areas can be wrong. Shapes can be distorted. But still, the fact that we can generate a usable 3DGS file from only one image is already very exciting.

So I decided to try it.

First Test: A Coffee Bottle

For the first test, I used a simple object: an aluminum coffee bottle.

The original image had a messy background, which could confuse the 3D generation model. So before using TripoSplat, I removed the background.

For background removal, I used this Hugging Face Space:

not-lain/background-removal

It is very easy to use. You upload an image, and it quickly removes the background.

Then I used the cleaned image as the input to TripoSplat and generated a 3DGS file.

The output was a .ply file. To inspect it, I used the SuperSplat editor:

SuperSplat Editor

The result was honestly quite good.

Since the input was only one image, the bottle was not perfectly reconstructed. The original bottle is circular, but the generated shape became slightly oval. Also, the label and details on the back side, which were not visible in the input image, were not reconstructed correctly.

But the front silhouette was clean, and the color of the label was reproduced quite well. Considering that the input was only a single image, I think the result is already useful for many purposes, depending on the use case.

For example, it could be useful for quick visualization, AR/VR prototypes, simple product previews, or concept testing.

Next Challenge: A Plant

After trying a simple object, I wanted to test something much harder.

So I tried a plant.

Plants are much more difficult than bottles.

Leaves overlap each other. Stems and branches are thin. Leaves are flat and delicate. The structure is complex, and many parts are hidden behind other parts.

I used the same workflow as before:

Remove the background
Input the cleaned image into TripoSplat
Generate a 3DGS .ply file
View it in SuperSplat

Here is the generated result.

And honestly, I thought:

This is actually pretty good.

Of course, it is not perfect. Some hidden parts are strange. Some leaves and branches are not reconstructed correctly. But again, this was generated from only one image.

For understanding the rough appearance of the plant, the result was good enough to be interesting.

At this point, I started wondering:

Can we animate this?

What If We Could Move the Plant?

Recently, there have been projects that animate 3DGS-based avatars. For example, a human character can be represented with Gaussian Splatting and then moved using a skeleton or a proxy mesh.

So I started thinking about plants.

Could we animate a plant generated as 3DGS?

For a plant, the motion I wanted to reproduce was something like this:

Leaves moving in the wind
Stems bending slightly
Leaves drooping when the plant loses water
Leaves recovering when hydration increases again

If this kind of motion could be generated from a 3DGS plant, it could be useful not only for games or AR/VR, but also for agriculture, robotics, plant simulation, and computer vision.

So I decided to build a small experimental tool for this.

I Built `plant-motion-gs`

The code is available here:

https://github.com/fromfactory/plant-motion-gs

The idea is simple:

Given a plant 3DGS .ply file, the program tries to detect rough plant regions such as stems, branches, and leaves. Then, in a web viewer, it animates the plant using wind and hydration parameters.

However, there is an important problem.

A normal 3DGS .ply file does not contain semantic labels like:

this Gaussian is a leaf
this Gaussian is a stem
this Gaussian is a branch

It only contains Gaussian data.

So before animating the plant, we need to estimate which Gaussians belong to which plant organs.

The pipeline roughly works like this:

3DGS PLY
  ↓
Render the 3DGS from multiple viewpoints
  ↓
Use SAM2 to estimate 2D region proposals
  ↓
Project the 2D masks back to Gaussian indices
  ↓
Estimate stems, branches, and leaves in 3D
  ↓
Generate data for the web viewer
  ↓
Animate wind and hydration

SAM2 is used to generate region proposals from the rendered 2D images. Then those masks are mapped back into the 3D Gaussian space.

This is still experimental. The current detection logic is somewhat tuned for the tomato plant structure used in this test. Other plants may not work as well, especially if they have very thin leaves, complex branching, pots, supports, or very different shapes.

But for a first experiment, it was good enough to try.

Running the Pipeline

First, place the generated plant .ply file here:

apps/viewer/public/assets/plant.ply

Then run the preprocessing pipeline:

python tools/ai_ply/run_pipeline.py \
  --ply apps/viewer/public/assets/plant.ply \
  --asset-dir apps/viewer/public/assets \
  --work-dir work/plant_ai \
  --renderer auto \
  --up y \
  --image-size 1024 \
  --views 12 \
  --elevations=-10,15,35 \
  --model-id facebook/sam2.1-hiera-base-plus \
  --stem-segments 18 \
  --proposal-mode fine \
  --rotate-deg 180,0,0

This script renders the plant from multiple viewpoints, runs SAM2-based segmentation, projects the masks back into 3D, and generates the files needed by the web viewer.

After that, install the web app dependencies and start the viewer:

pnpm install
pnpm dev

Then the plant can be viewed in the browser.

Animating Wind

The web viewer has a wind parameter.

When I increase it, the leaves and branches start moving like they are being affected by wind.

The animation is not just moving the whole plant left and right.

To make it feel more plant-like, the motion is different for stems, branches, and leaves.

The main stem moves only slightly.

The lower part stays almost fixed.

Branches inherit some motion from the stem and bend a little.

Leaves inherit branch motion, and their tips and edges move more strongly.

This is not a physically accurate simulation, but it looks much more natural than simply translating the entire 3DGS object.

Simulating Hydration and Wilting

I also added a hydration parameter.

The idea is simple:

High hydration means the plant looks healthy.
Low hydration means the plant is losing water and the leaves start to droop.

One important detail is that the main stem does not simply move downward.

When a plant wilts, the main stem usually does not just sink as one rigid object. Instead, the leaves, petioles, and branch tips tend to droop more visibly.

So in this implementation, the main stem is mostly preserved, while branches and leaf tips receive more drooping motion.

Again, this is still a simplified model. But by changing the hydration value, I was able to create a visual effect where leaves droop and then recover.

That was already pretty satisfying to see.

From One Image to an Animated 3DGS Plant

The full workflow looked like this:

One plant image
  ↓
Background removal
  ↓
TripoSplat 3DGS generation
  ↓
PLY inspection in SuperSplat
  ↓
Plant region estimation with plant-motion-gs
  ↓
Wind and hydration animation in a web app

There are many limitations.

The 3DGS was generated from only one image, so hidden geometry is not accurate.

The plant organ extraction is not perfect.

The animation is not a real biological or physical simulation.

The motion model is still simple.

But even with those limitations, I think the result is very interesting.

Plants are difficult objects for traditional 3D reconstruction. Leaves are thin, stems are narrow, and the overall structure is complex. Creating a clean editable mesh is not easy.

3DGS, on the other hand, is very good at capturing visual appearance. It can represent complex, fuzzy, and detailed-looking structures without requiring a clean mesh.

The challenge is that 3DGS is not naturally editable or animatable. It does not come with bones, surfaces, topology, or semantic parts.

This experiment was an attempt to bridge that gap a little.

ERP in Manufacturing: The Operating System Behind the Business

Yuki Furuta — Sat, 01 Aug 2026 14:16:33 +0000

ERP is one of those acronyms that can make a simple idea sound intimidating.

It stands for Enterprise Resource Planning. In practical terms, ERP is the shared platform that connects a company’s data and business processes across sales, purchasing, inventory, production, costing, accounting, human resources, and more.

For a manufacturer, its biggest value is not simply keeping all the data in one place. It is keeping the relationships between that data intact.

The same item, customer order, bill of materials, production order, and lot number can follow a product from demand to delivery—and eventually into the financial statements.

Without an integrated ERP, a typical process may be split across a sales system, spreadsheets, an inventory application, a production system, and accounting software. Employees then have to copy, reconcile, and correct the same information repeatedly.

A simplified manufacturing flow looks like this:

Customer order
  ↓
Demand for finished goods
  ↓
Explode the bill of materials to calculate material requirements
  ↓
Purchase any materials that are missing
  ↓
Create a production order
  ↓
Issue materials to the shop floor
  ↓
Assemble, inspect, and record production results
  ↓
Receive the finished goods into inventory
  ↓
Ship the order and issue the invoice
  ↓
Post revenue, accounts receivable, inventory, and cost of goods sold

In an ERP environment, these are not treated as unrelated tasks. A change in the customer order can affect material requirements and the production plan. Material prices and actual labor hours can change the finished product cost. Those results can then flow into inventory valuation and accounting.

That is why manufacturing ERP is sometimes described as the operating system of the business. It connects production, procurement, inventory, supply chain operations, costing, and finance through a common data model.

What information does a manufacturing ERP manage?

A manufacturing ERP may cover a surprisingly wide range of information.

Area	Typical information
Sales	Quotations, orders, promised dates, shipments, and invoices
Product data	Item masters, manufacturing BOMs, revisions, and approved substitutes
Production planning	Forecasts, master production schedules, MRP, and capacity requirements
Production execution	Production orders, routes, operations, labor time, material consumption, and completed quantities
Procurement	Purchase requisitions, purchase orders, supplier confirmations, receipts, and supplier invoices
Inventory	Warehouses, locations, lots, serial numbers, work in progress, and stock movements
Quality	Incoming inspection, in-process inspection, final inspection, nonconformance, and rework
Maintenance	Equipment records, inspections, failures, maintenance work orders, and spare parts
Costing	Material, labor, overhead, standard cost, actual cost, and variances
Accounting	Revenue, cost of goods sold, inventory assets, accounts payable, and fixed assets

That is a lot—and it explains why ERP projects can feel overwhelming.

The important point, however, is not that ERP stores each category separately. Its real value comes from preserving the connections between them.

Suppose the cost of a product rises. A useful manufacturing ERP should help the company investigate questions such as:

Did the purchase price of a material increase?
Did defects cause additional material consumption?
Did setup or production time take longer than expected?
Did subcontracting, freight, or energy costs rise?
Did a lower production volume increase the fixed cost allocated to each unit?

Accounting shows that the cost changed. Integrated operational data helps explain why it changed.

ERP is not the same as MES, PLM, APS, or SCADA

ERP does not directly control every machine or every activity inside a factory. Manufacturers usually combine it with specialized systems.

System	Main role
ERP	Connects orders, procurement, inventory, production, costing, and finance at company level
MRP — Material Requirements Planning	Calculates material requirements from demand, BOMs, inventory, and scheduled receipts
PLM/PDM — Product Lifecycle or Product Data Management	Manages drawings, specifications, engineering BOMs, revisions, and engineering changes
APS — Advanced Planning and Scheduling	Creates detailed plans using capacity, labor, setup constraints, and due dates
MES/MOM — Manufacturing Execution or Operations Management	Manages shop-floor instructions, production results, traceability, and quality execution
WMS — Warehouse Management System	Manages warehouse locations, receiving, put-away, picking, packing, and internal movement
EAM/CMMS — Asset or Maintenance Management	Manages equipment, inspections, failures, preventive maintenance, and spare parts
SCADA — Supervisory Control and Data Acquisition	Monitors equipment and sensors and collects operational control data

One useful nuance is that MRP is often a function inside an ERP, not necessarily a separate application. APS, MES, PLM, and WMS may also be included in an ERP suite, supplied as companion products, or provided by independent vendors.

The boundary depends on the product and the architecture.

Start with the manufacturing model, not the brand name

ERP should not be selected by brand recognition alone. In manufacturing, the fit with the production model matters enormously.

Common models include:

Engineer to Order (ETO): Products are designed, purchased, and manufactured for a specific customer requirement.
Make to Order (MTO): A standard or configurable product is manufactured after an order is received.
Make to Stock (MTS): Products are manufactured in advance based on forecasts and inventory targets.
Repetitive manufacturing: The same or similar products are produced continuously on a line.
Process manufacturing: Products are made from formulas or recipes, as in food, chemicals, and pharmaceuticals.
Hybrid manufacturing: Components may be made to stock, while final assembly happens after the customer order arrives.

Two ERP products can both claim to support manufacturing while behaving very differently in a real production scenario. One may be strong in repetitive production, another in project-based ETO, and another in asset maintenance or after-sales service.

Major manufacturing ERP products at a glance

The table below is a starting point, not a ranking. Product fit depends on industry, geography, company size, existing systems, and implementation partners.

Provider and product	Often considered by	Notable angle to investigate
SAP S/4HANA Cloud	Large and global organizations with multiple companies or plants	Broad integration across planning, manufacturing, quality, inventory, costing, and finance, with public- and private-cloud options and a large surrounding ecosystem
Oracle Fusion Cloud ERP and Supply Chain & Manufacturing	Mid-sized to large global companies pursuing a cloud-suite strategy	SaaS integration across planning, manufacturing, inventory, logistics, maintenance, PLM, procurement, and finance
Microsoft Dynamics 365 Finance and Supply Chain Management	Mid-sized and large organizations already invested in Microsoft technology	Manufacturing and supply-chain functions combined with Microsoft 365, Power Platform, Azure, analytics, and an extensive partner ecosystem
Infor CloudSuite Industrial, Infor LN, and Infor M3	Manufacturers with strong industry-specific or production-model requirements	Multiple ERP families aimed at different manufacturing segments; selecting the right Infor product is an important part of the evaluation
IFS Cloud	Asset-, project-, and service-intensive manufacturers	ERP, EAM, supply chain, and field service capabilities on one platform, which can be valuable when installation and service continue long after the initial sale
Epicor Kinetic	Mid-market manufacturers, including job shops and discrete production environments	A manufacturing-focused cloud ERP with production, material, labor, costing, and shop-floor capabilities
QAD Adaptive ERP	Manufacturing-centric global and mid-sized companies	A strong manufacturing and supply-chain focus, including industry use cases where traceability, quality, and international operations matter
Odoo	Small and mid-sized companies that want modular or phased adoption	Integrated apps for manufacturing, inventory, purchasing, quality, maintenance, and more, with cloud and self-hosted options and both Community and Enterprise editions
ERPNext	Small companies and teams exploring open-source deployment or custom development	BOMs, production planning, work orders, job cards, inventory, purchasing, quality, costing, and accounting in an open-source platform

A product demonstration is useful, but a scripted end-to-end scenario is much more revealing than a collection of attractive screens.

Where AI fits into ERP

AI in ERP is not entirely new. Machine learning has been used for years in areas such as demand forecasting, anomaly detection, lead-time prediction, and predictive maintenance.

What has changed is the interface and the scope of possible action.

Technology	Role in ERP	Manufacturing example
Traditional AI and machine learning	Numerical prediction, classification, and anomaly detection	Demand forecasting, late-delivery prediction, defect detection, and failure prediction
Generative AI and large language models	Understanding, summarization, generation, and conversation	Explaining a work instruction, drafting a report, or searching ERP data in natural language
Retrieval-augmented generation (RAG)	Grounds an answer in company documents and business data	Referring to drawings, procedures, past defects, maintenance records, or supplier documents
AI agents	Reasons about a goal and coordinates actions across applications or ERP functions	Preparing a purchase proposal, suggesting a planning change, creating an inventory transfer, or notifying an approver
Physical AI	Connects business plans with robots and autonomous equipment	Material movement, warehouse tasks, component supply, and autonomous handling

Physical AI usually does not mean that the ERP directly controls a robot. More often, ERP provides business context—demand, priority, inventory, and work orders—while MES, WMS, automation platforms, or robotics systems handle real-time execution.

From a system of record to a system that can act

ERP has traditionally been a system of record: the trusted place where transactions and results are stored.

The next step is being described in several ways—system of action, agentic applications, autonomous enterprise, and system of outcomes. The terminology differs, but the direction is similar: AI is moving closer to the processes where work is planned, reviewed, and executed.

In May 2026, SAP introduced its Autonomous Enterprise vision, connecting AI agents with business processes, data, and governance. In March 2026, Oracle announced Fusion Agentic Applications, which use coordinated teams of specialized agents to reason and execute within Fusion application workflows.

These announcements do not mean that companies should hand every decision to AI. In manufacturing, an incorrect purchase order, production-plan change, inventory movement, or maintenance instruction can have financial, operational, and safety consequences.

The important questions are therefore not only, “What can the AI generate?” but also:

What data can it access?
What transactions can it create or update?
What evidence does it show?
Which actions require human approval?
How are permissions, exceptions, and audit trails handled?

A practical ERP evaluation checklist

1. Can it reproduce the way your company actually manufactures?

Test real examples from your business: high-mix low-volume work, mass production, process manufacturing, custom engineering, subcontracting, or a hybrid model.

Do not rely only on a generic demonstration database.

2. Does the process connect from planning to accounting?

Test one complete scenario:

Sales order
  → MRP
  → Purchasing
  → Production
  → Quality
  → Inventory
  → Shipment
  → Costing
  → Accounting

A smooth user interface is useful, but it is not enough. The data and business logic must remain consistent across the whole flow.

3. Can it integrate with shop-floor and engineering systems?

Check how it connects with MES, PLM, machines, handheld terminals, scales, label printers, EDI platforms, logistics providers, and existing databases.

Also clarify which system owns each important data object. For example, is the engineering BOM mastered in PLM and transferred to ERP, or maintained directly in ERP?

4. Can it support international operations?

Review local tax rules, accounting standards, languages, currencies, legal entities, import and export processes, transfer pricing, approval policies, and regional data requirements.

A product may be global in theory but still require substantial localization or partner work in a specific country.

5. What can the AI see, explain, and execute?

“AI-powered” is too broad to be a useful comparison by itself. Ask:

Which ERP data can the AI access?
Can it search documents, email, drawings, and external systems?
Does it cite the source of an answer?
Can it create or update ERP transactions?
Can users review proposed changes before execution?
Can human approval be required by amount, risk, site, or transaction type?
Is every action recorded in an audit log?
Is customer data used to train a model?
In which region is the data stored and processed?

6. What is the total cost—not just the license price?

ERP cost can include subscriptions, consulting, data migration, customization, integration, training, testing, cloud infrastructure, support, upgrades, security, and AI usage.

Open-source ERP can reduce license costs, but implementation, hosting, backup, security, localization, compliance, and version upgrades still require money and technical skill.

Final thoughts

Manufacturing ERP is not just an accounting system.

It translates customer demand into materials, equipment, people, operations, inventory, and cost. It then brings the actual production results back into the financial and management view of the business.

There is no universally “best” ERP. SAP, Oracle, and Microsoft offer broad enterprise platforms. Infor, IFS, Epicor, and QAD emphasize different manufacturing, asset, project, service, and industry requirements. Odoo and ERPNext can be attractive for phased adoption, learning, experimentation, and open-source development.

The best evaluation starts with the company’s real manufacturing model and follows one complete business scenario from order to accounting.

AI agents may make ERP easier to use and more proactive, but they do not remove the need for clean master data, well-designed processes, clear permissions, and human accountability. In fact, the more an ERP can act, the more important those foundations become.

I plan to keep exploring this area as ERP becomes more agentic and manufacturing systems become more connected.

Turning Real Objects into CAD Models

Yuki Furuta — Wed, 17 Jun 2026 14:57:34 +0000

Testing photogrammetry and AI-based 3D generation to bring physical objects into CAD workflows.

When I design something in CAD, even a simple bracket, it is always easier if I already have a 3D model of the machine, device, or equipment around it.

With a 3D model, I can quickly check how the new part looks, whether it interferes with anything, and how it fits into the overall system. It also makes documentation much easier. A screenshot from CAD explains the idea much better than a long paragraph.

But in the real world, we often do not have clean CAD data for existing machines or equipment.

Of course, if the manufacturer provides the CAD model, that is ideal. But if not, we need to create the model ourselves. And honestly, building a 3D CAD model from scratch is painful. Unless it is absolutely necessary, it is the kind of task I tend to postpone.

Recently, though, 3D reconstruction tools have become much more practical. We can now reconstruct objects from videos, multiple photos, or even a single image, convert them into meshes, and bring them into CAD.

So I wanted to test a practical workflow:

Can I take a real object, reconstruct it as a 3D mesh, and use it inside CAD for layout checks and interference checks?

This time, I used a small network camera as the test object.

It is a common industrial-style network camera: a white metal housing, a camera unit on one side, and a rear box where cables such as LAN are connected. I chose it because it is small and easy to test quickly.

Photogrammetry with Meshroom

There are many possible methods, but I started with a classic and very well-known tool: Meshroom.

Meshroom is an open-source photogrammetry tool based on AliceVision. In simple terms, photogrammetry tries to reconstruct a 3D model from multiple 2D images.

The rough idea is:

Detect feature points in each image
Match the same points across multiple images
Estimate the camera positions
Create a sparse point cloud
Create a dense point cloud
Generate a mesh
Apply texture

So instead of modeling the object manually, we let the software estimate the 3D shape from many photos taken from different angles.

For this test, I captured around 30 seconds of video with a smartphone. Then I extracted frames using FFmpeg:

ffmpeg -i input.mp4 \ 
-vf "fps=2" \ 
frames/frame_%05d.jpg

This gave me around 60 images.

In a proper photogrammetry workflow, it would be better to remove blurry images before processing. Even better, instead of recording video, I should take high-quality still images one by one from many angles.

But for this first test, I wanted to see how far I could get with a quick video capture.

Then I opened Meshroom, selected the Photogrammetry pipeline, and loaded the images.

After loading the images, they appeared in the Image Gallery. The Graph Editor also automatically generated the photogrammetry pipeline.

One small but important note: if nothing appears in the Graph Editor, the pipeline is not ready. In that case, the reconstruction will not run correctly.

After that, I clicked the Start button at the top, and Meshroom started the full 3D reconstruction process automatically.

When the process finished, the result appeared in the 3D Viewer on the right side. I could see both the reconstructed object and the estimated camera positions.

Then I exported the result as an OBJ file and opened it in Blender to check the shape.

The result was usable as a rough mesh, but honestly, the camera shape was not very good. There were unwanted parts such as the desk, and the main object surface was rough and noisy.

Of course, I could delete the unnecessary parts in Blender. But as a model of the camera itself, the quality was not quite enough.

Photogrammetry with RealityScan

Next, I tried RealityScan from Epic Games.

Many people may know the smartphone app version, but there is also a desktop/Linux workflow, so I tested that as well.

The overall workflow is similar to Meshroom: load multiple images, align them, and generate a 3D model.

However, the operation flow is slightly different.
In Meshroom, pressing Start runs the whole pipeline automatically, from feature extraction to meshing.
In RealityScan, I first ran Align Images. This step performs feature extraction, image matching, camera estimation, and point cloud generation.

After confirming that the alignment looked reasonable, I ran Calculate Model to generate the 3D mesh.

The result was also not as clean as I hoped.

Again, this does not mean RealityScan is weak. RealityScan is a very powerful photogrammetry tool. The issue was probably my input data.

I think the main problems were:

I extracted still images from a handheld video, so some frames were blurry or motion-blurred.
The target object was mostly white, so it did not have many easy-to-detect visual features.
I did not capture enough angles carefully. I just moved around the object quickly with a phone.
The desk and background were also included, which made the reconstruction harder.

If I improved these points, I think both Meshroom and RealityScan could create much better models.

Still, for this kind of small, white, smooth industrial object, photogrammetry can easily create a bumpy mesh. Even if the overall shape is reconstructed, the surface may not be clean enough for CAD-style visualization.

So I decided to try another approach: AI-based single-image 3D generation.

Hunyuan3D-2.1

The first AI-based tool I tested was Tencent Hunyuan3D-2.1.

Hunyuan3D-2.1 can generate a 3D asset from an image. It is probably more commonly used for games, digital content, and 3D assets rather than mechanical CAD.

I will skip the full setup here because the GitHub repository already explains it, but the model is quite large and requires a reasonably powerful machine.

My environment was:
OS: Ubuntu 22.04
RAM: 64 GB
GPU: NVIDIA RTX 4090

The easiest way for me was to launch the official Gradio app:

python3 gradio_app.py --model_path tencent/Hunyuan3D-2.1 --subfolder hunyuan3d-dit-v

Then I uploaded a single image of the camera.

The result was generated quickly on my local machine.

Compared with the photogrammetry results, the surface was much smoother. The overall shape was also close to what I expected.

This was impressive because it used only one image.

The tool can export several model formats. For bringing the model into CAD, STL is usually a convenient choice, although OBJ can also be useful depending on the workflow.

Of course, this is not a dimensionally accurate engineering model. It is not a replacement for proper measurement or reverse engineering.

But for visual checks, rough layout studies, and early-stage design discussion, it is already quite useful.

TripoSG

Next, I tested TripoSG, another image-to-3D model.

I used the same single input image as before.

After setting up the environment following the official GitHub repository, I ran the inference script and generated a 3D mesh.

Before importing it into CAD, I opened the output in Blender.

This result was excellent.

The overall shape looked better than the previous results in this test. The surface was smooth, the camera body was recognizable, and unwanted parts such as the desk were automatically removed.

For this specific object and this specific input image, TripoSG gave me the best-looking model.

So I decided to use the TripoSG output for the CAD test.

In Blender, I exported the generated OBJ file as an STL file.

Importing the mesh into CAD

Finally, I opened the STL file in Autodesk Fusion.

The mesh loaded without any major issue.

There are some important limitations.
First, the scale needs to be corrected. AI-generated models and photogrammetry models are often not created at the exact real-world size unless we add scale references or manually adjust them.
Second, this is still a mesh. It is not the same as a clean parametric CAD model. I cannot simply grab a surface and extend it like I would with a normal CAD body.

But for my purpose, it was useful.

I could place the camera model near other equipment, check the approximate appearance, and think about the installation layout.

For interference checks, visual confirmation, and documentation, this workflow feels very promising.

Practical Takeaways

This test was not about creating a perfect engineering CAD model.

The real question was more practical:

How far can we go if we just want to bring a real-world object into CAD quickly enough for design support?

For that purpose, this workflow is already useful.

The most important point is to separate two different goals.

If you need accurate dimensions, clean surfaces, and editable CAD features, neither quick photogrammetry nor single-image AI generation is enough by itself. You still need proper measurement, reverse engineering, or manual CAD modeling.

But if you need a model for visual checks, layout studies, interference checks, installation planning, or documentation, these tools can save a lot of time.

From this test, I would use the tools differently depending on the purpose.

Photogrammetry tools like Meshroom and RealityScan are powerful when you can prepare good input images. They are especially useful when you can take many sharp photos from many angles under good lighting. However, the result depends heavily on image quality. Smooth, white, reflective, or low-texture objects can be difficult. Blurry frames from video can also make the result much worse.

AI-based tools like Hunyuan3D-2.1 and TripoSG are different. They may not reproduce the exact dimensions, but they can create a clean and recognizable mesh very quickly from just one image. For early-stage CAD visualization, this can be more useful than a noisy photogrammetry mesh.

So my current practical rule is:

Use photogrammetry when geometry accuracy from multiple real images matters. Use AI-based image-to-3D when speed and visual quality matter more.

For this specific test, TripoSG gave the most practical result. The model was clean, the object shape was easy to recognize, and unnecessary background parts were mostly removed automatically. After exporting it through Blender as an STL file, I could import it into Fusion and use it as a reference object.

This does not replace real CAD data.

But it creates a useful middle ground between “I have no model at all” and “I need to manually model everything from scratch.”

For industrial automation, robotics, equipment layout, and field engineering work, that middle ground is valuable. Many times, we do not need a perfect model at the beginning. We just need something close enough to support discussion, check space, explain an idea, or avoid obvious design mistakes.

In future tests, I want to compare more workflows, including better photogrammetry capture, Gaussian Splatting, multi-image AI reconstruction, and hybrid pipelines.

The bigger direction is clear:

The gap between real-world objects and CAD workflows is getting smaller.

And that could make practical engineering design much faster.

Same Prompt, Very Different UI, Comparing Codex With and Without `ui-ux-pro-max-skill`

Yuki Furuta — Sat, 11 Apr 2026 05:29:07 +0000

Same Prompt, Very Different UI: Comparing Codex With and Without `ui-ux-pro-max-skill` on "Virtual Factory"

Figure 1. The comparison setup. Standard Codex on the left, Codex with ui-ux-pro-max-skill on the right, the shared prompt in the center, and the comparison axes summarized along the bottom.

When you ask AI to build a UI, the difference does not come only from the model itself. The output also changes a lot depending on what prior knowledge you give it and what design criteria you make it operate with.

For this experiment, I gave Codex the exact same prompt and asked it to build two versions of a browser app called Virtual Factory, a factory 3DGS dashboard. One version was generated by standard Codex. The other was generated by Codex with ui-ux-pro-max-skill enabled.

According to its README, ui-ux-pro-max-skill can be installed for Codex CLI with uipro init --ai codex, and it is designed to auto-trigger on UI/UX-related requests. It is not just a styling pack. It includes a Design System Generator, stack-specific guidance, persistent design rules via --persist, and support for multiple frontend stacks including React and Next.js.

Here is the prompt I used:

Create a browser-based web app called "Virtual Factory".

It’s a SaaS-style dashboard for factory 3DGS:

upload scans

view them

add notes

link documents

Use a modern frontend stack (prefer React / Next.js).
Mock complex parts if needed.

Important:

it should run locally in a development server

I should be able to open it in a browser and see a working UI

prioritize frontend demo quality over production completeness

Deliver a runnable project with setup instructions.

Note
This comparison is based on the attached source code and screenshots. In virtual-factory-2, app/page.js references FactoryDashboard, but that component itself was not included in the attached source bundle I reviewed. So the code-level comparison below is limited to what could actually be verified from the files provided.

The Main Takeaway

The most interesting difference was not whether one version looked flashier.

Standard Codex was very good at producing a strong, immediately demoable UI with functional flow and visual punch in a short distance. The version generated with ui-ux-pro-max-skill, on the other hand, looked more like it was trying to build a product with information architecture, not just assemble attractive components.

In other words, the real difference showed up less in decoration and more in design thinking.

`virtual-factory-1`: A Strong Demo You Can Show Right Away

Figure 1. Full-screen capture of virtual-factory-1. The hero area, metrics, viewer, scan list, notes, and documents all connect within a single screen.

virtual-factory-1 makes a strong first impression. It leans hard into the kind of UI that feels great as a SaaS demo: dark tones, glassy panels, glowing accents, a hero section, and metric cards.

But it is not just visual polish. The upload flow, scan switching, search, note creation, document linking, viewer mode changes, and layer toggles are all wired together in one screen. Even the complex 3DGS part is handled smartly: instead of trying to solve everything for real, it uses a canvas-based mock viewer. For a prompt that explicitly said “mock complex parts if needed,” that is a very effective response.

The source structure is easy to read too. The center of gravity is src/App.jsx, where state, handlers, the viewer, and note/document interactions are mostly gathered into a single file. Architecturally that is fairly monolithic, but it also explains why the result feels so complete so quickly: it is optimized to ship a working demo fast.

If the goal is a sales demo, an internal proof of concept, or something you can open in a browser and show immediately, virtual-factory-1 is genuinely strong. Its value is obvious at first glance.

`virtual-factory-2`: Closer to a Product With Information Architecture

Figure 2. Full-screen capture of virtual-factory-2. For the clearest comparison, use a screen that shows the left sidebar, center viewer, and right-side rail together.

virtual-factory-2 points in a noticeably different direction, even from the files that were visible. Its entry structure uses the Next.js App Router, with app/layout.js and app/page.js. In the CSS, you can already see vocabulary that suggests a more structured screen model: sidebar, hero-grid, workspace-grid, viewer-stage, viewer-hud, rail-card, and rail-item.

The visual tone is different too. Instead of a dark, “showy SaaS” feel, this version leans toward a softer gray operational-console aesthetic—something closer to a factory, blueprint, or monitoring tool. The background grid, HUD-like layers, and three-column structure with a sidebar and right rail make it feel calmer and more like a system people would use every day.

That is the important point. The difference is not simply whether it is more or less flashy. virtual-factory-2 appears to decide the placement of navigation, viewing, monitoring, and supporting information first. It feels less like “make one great-looking screen” and more like “design how this product should be used.”

That lines up closely with the philosophy of ui-ux-pro-max-skill. Its SKILL.md explicitly frames the skill around things like dashboard design, navigation structure, information hierarchy, brand expression, and UX quality control. In other words, it is trying to get the AI to think beyond “place nice-looking components” and toward “organize the product as a system.”

Side by Side, They Optimize for Different Things

Lens	`virtual-factory-1`	`virtual-factory-2`
First impression	Strong hero section and dark SaaS energy	Calm, factory-like operational UI
Center of gravity	Make one screen feel impressive and complete	Establish role separation across the interface
Implementation feel	High completion through a single-file core	Layout vocabulary and product structure come first
Best fit	Fast PoC / sales demo	UI exploration with future expansion in mind

What this comparison reveals is not which one “wins.” It reveals what the AI is optimizing for.

Standard Codex optimizes for short-distance output: connect the required elements quickly, package them into a convincing screen, and make something that is ready to show.

The version with ui-ux-pro-max-skill seems to optimize differently. It tries to identify the product type, impose layout order, decide where information belongs, and then move toward implementation. The README reinforces that interpretation: the skill is built around a Design System Generator and encourages persistent design rules via --persist, with a structure based on shared design guidance and page-level overrides. That is a very different mindset from simply generating prettier UI code.

What Exactly Makes `ui-ux-pro-max-skill` Effective?

What stood out to me in this comparison was not just that the skill can make CSS look better.

Its real value is that it changes the AI’s default questions from:

“How do I make this look impressive?”
“How do I style this?”

into questions like:

“How is this supposed to be used?”
“What information hierarchy should this product have?”
“Where should each function live to support everyday workflows?”

The README describes a workflow where the skill automatically generates a design system for UI/UX tasks, recommends styles, colors, and typography based on product type, and then checks for UI/UX anti-patterns at the end. That maps very well to the feeling I got from virtual-factory-2: it looks like design structure was considered before surface polish.

Final Thoughts

The clearest lesson from this experiment is that even with the exact same prompt, the quality and character of the output can change significantly depending on the prior knowledge and design framework you give the AI.

Standard Codex can absolutely generate a strong UI demo on its own. virtual-factory-1 is a good example of that. It is fast, visually compelling, and immediately usable as a frontend demo.

But with ui-ux-pro-max-skill, the AI seems to think over a longer time horizon. Instead of simply decorating a screen, it starts trying to organize a product. The gap I saw here was less about visual taste and more about the point of view behind the design.

That is the part I find most valuable. It does not just improve the UI output. It upgrades the way the AI thinks about UI in the first place. And that, to me, is where ui-ux-pro-max-skill feels genuinely impressive.

oh-my-claudecode is a Game Changer: Experiencing Local AI Swarm Orchestration

Yuki Furuta — Sat, 04 Apr 2026 14:50:23 +0000

While the official Claude Code CLI has been making waves recently, I stumbled upon a tool that pushes its potential to the absolute limit: oh-my-claudecode (OMC).

More than just a coding assistant, OMC operates on the concept of local swarm orchestration for AI agents. It’s been featured in various articles and repos, but after spinning it up locally, I can confidently say this is a paradigm shift in the developer experience.

Here is my hands-on review and why I think it’s worth adding to your stack.

Why is oh-my-claudecode so powerful?

If the standard Claude Code is like having a brilliant junior developer sitting next to you, OMC is like hiring an entire elite engineering team.

Instead of relying on a single AI to handle everything sequentially, OMC leverages multiple specialized agents working in parallel.
What’s even more fascinating is its multi-model support: you aren't locked into Claude. You can integrate Gemini or Codex as Workers. This allows for highly optimized, multi-model team compositions—for instance, assigning frontend UI generation specifically to a Gemini worker because of its distinct strengths.

Before diving into the code, here is a quick matrix to help you choose the right OMC mode based on your task scale and preferred approach:

oh-my-claudecode Mode Selection Matrix

Approach \ Task Scale	🟢 Small (Q&A, Minor Fixes)	🟡 Medium (Few Files, Features, Refactors)	🔴 Large (Multi-file, Complex Architecture)
Hands-off Autonomous (Set it and forget it)	Native Claude Code	Autopilot (End-to-end, minimal ceremony)	-
Guaranteed Completion (No silent partial stops)	-	Ralph (Persistent verify/fix loops)	-
Burst Parallelism (Maximum speed)	-	Ultrawork (Burst parallel execution)	-
Phased & Robust (Plan & review focused)	-	Pipeline (Strict sequential ordering)	Team (★ Recommended) (Plan → PRD → Exec → Verify)
Multi-Model Collaboration (Codex / Gemini)	-	-	ccg (Claude synthesizes AI inputs) omc team (Standalone CLI workers)

Taking `team 3:executor` for a Spin

To test the waters, I built a prototype app using OMC’s built-in team 3:executor command. The verdict? It is absurdly fast.

It’s not just about the raw speed of code generation; the velocity of the entire development lifecycle is on another level.

1. Seamless Collaboration and Parallel Execution

When you hit enter, it doesn't just linearly spit out code. Multiple agents spin up to handle high-level planning, actual coding, and peer-reviewing in parallel. Because the agents actively verify and review each other’s work, the output quality is exceptionally high right out of the gate. You barely need to touch the keyboard.

2. The Orchestrator’s "Check-ins"

You might worry that a swarm of AIs will go rogue and wreck your codebase. OMC handles this beautifully.
An "Orchestrator" acts as the tech lead. At the end of every major phase, it pauses and prompts you: "Here is our progress so far. Do we have permission to proceed to the next phase?" You essentially become the engineering manager, reviewing the report and giving the "LGTM" to proceed. It’s the perfect balance of massive automation and human-in-the-loop control.

3. The `tmux` Spectacle

As an engineer, the coolest part is arguably the visual feedback. OMC integrates natively with tmux. When executed, your terminal automatically splits into multiple panes.

Multiple AI agents working concurrently in separate panes, while the orchestrator summarizes progress.

Watching different AI agents stream logs simultaneously in their own panes while collaborating to build a system is, frankly, spectacular. It feels like a scene straight out of a hacker movie.

⚖️ OMC vs. Anthropic Official Agent Teams: Which should you use?

The elephant in the room: "Anthropic just released official Agent Teams. Why bother with a third-party wrapper?"

It boils down to Official Stability vs. OMC's Extreme Flexibility and Speed.

Feature	🛠️ oh-my-claudecode (OMC)	🏢 Anthropic Official Agent Teams
Core Concept	Maximum flexibility & speed	Predictability & stability
Agent Pool	19+ agents (Custom additions supported)	Limited, pre-defined setups
Model Routing	Smart, automatic routing	Manual user configuration
Skill Learning	Automatically learns project quirks	None (Requires repeated context)
Support/Stability	OSS (Fast updates, potential breaking changes)	Official support, highly stable

3 Reasons OMC is Hard to Give Up

If the table isn't convincing enough, here are three specific pain points OMC completely solves:

Escaping the Single-Agent Bottleneck (Parallelism) Official tools often force sequential execution. OMC’s Team Mode and Ultrawork execute tasks concurrently. If you are doing a massive multi-file refactor, the speed difference is staggering.
Saving Your API Budget (Smart Routing) Running Opus for every minor file read will burn through your tokens in hours. OMC intelligently routes tasks: Haiku for quick searches, Sonnet for heavy coding, and Opus for complex architectural decisions. It saves money automatically.
The "Don't Repeat Yourself" Memory (Skill Learning) OMC learns the specific patterns, rules, and context of your project and remembers them across sessions. You no longer have to paste the same architectural guidelines into the prompt every single day.

The Verdict: If you cannot tolerate a single bug or breaking change in your tooling, stick to the Official Agent Teams. But if you want to push the boundaries of development speed, slash your API costs, and experience the bleeding edge of AI orchestration, OMC is the clear winner.

💻 GUI Alternative: Using Cursor

While OMC truly shines in the terminal (especially for the tmux parallel execution views), not everyone loves living in the CLI.

If you prefer a GUI, you can achieve a similar setup within Cursor. By installing the Claude Code extension and adding OMC as a plugin, you can tap into this swarm intelligence directly from your favorite AI code editor.

Final Thoughts

oh-my-claudecode bridges the gap between simple AI autocomplete and a fully autonomous AI engineering team.

If you want to ship applications at lightning speed...
If you want to see AIs collaborate in real-time...
If you want to optimize your token usage...

DEV Community: Yuki Furuta

I Tried TripoSplat to Generate 3D Gaussian Splatting from a Single Image — Then I Tried Animating a Plant

First Test: A Coffee Bottle

Next Challenge: A Plant

What If We Could Move the Plant?

I Built plant-motion-gs

Running the Pipeline

Animating Wind

Simulating Hydration and Wilting

From One Image to an Animated 3DGS Plant

ERP in Manufacturing: The Operating System Behind the Business

What information does a manufacturing ERP manage?

ERP is not the same as MES, PLM, APS, or SCADA

Start with the manufacturing model, not the brand name

Major manufacturing ERP products at a glance

Where AI fits into ERP

From a system of record to a system that can act

A practical ERP evaluation checklist

1. Can it reproduce the way your company actually manufactures?

2. Does the process connect from planning to accounting?

3. Can it integrate with shop-floor and engineering systems?

4. Can it support international operations?

5. What can the AI see, explain, and execute?

6. What is the total cost—not just the license price?

Final thoughts

Turning Real Objects into CAD Models

Photogrammetry with Meshroom

Photogrammetry with RealityScan

Hunyuan3D-2.1

TripoSG

Importing the mesh into CAD

Practical Takeaways

Same Prompt, Very Different UI, Comparing Codex With and Without `ui-ux-pro-max-skill`

Same Prompt, Very Different UI: Comparing Codex With and Without ui-ux-pro-max-skill on "Virtual Factory"

The Main Takeaway

virtual-factory-1: A Strong Demo You Can Show Right Away

virtual-factory-2: Closer to a Product With Information Architecture

Side by Side, They Optimize for Different Things

What Exactly Makes ui-ux-pro-max-skill Effective?

Final Thoughts

oh-my-claudecode is a Game Changer: Experiencing Local AI Swarm Orchestration

Why is oh-my-claudecode so powerful?

oh-my-claudecode Mode Selection Matrix

Taking team 3:executor for a Spin

1. Seamless Collaboration and Parallel Execution

2. The Orchestrator’s "Check-ins"

3. The tmux Spectacle

⚖️ OMC vs. Anthropic Official Agent Teams: Which should you use?

3 Reasons OMC is Hard to Give Up

💻 GUI Alternative: Using Cursor

Final Thoughts

I Built `plant-motion-gs`

Same Prompt, Very Different UI: Comparing Codex With and Without `ui-ux-pro-max-skill` on "Virtual Factory"

`virtual-factory-1`: A Strong Demo You Can Show Right Away

`virtual-factory-2`: Closer to a Product With Information Architecture

What Exactly Makes `ui-ux-pro-max-skill` Effective?

Taking `team 3:executor` for a Spin

3. The `tmux` Spectacle