Rending_Paige
Full_Screen
Input
STL
Main_3D_Model
Output
PDF_Report
Find_improvement_direction
LLM

Problem Statement

Aerodynamic drag directly affects a vehicle's energy consumption, fuel economy, and electric driving range. Drag is commonly expressed through the drag coefficient, or Cd.

High-fidelity computational fluid dynamics (CFD) is the standard way to evaluate aerodynamic performance, but it can require specialist expertise, substantial computing resources, and days to weeks for each design. This creates a bottleneck during early-stage vehicle development, when teams need to compare many concepts quickly but cannot run full CFD for every candidate.

Automotive teams need a faster and more accessible way to screen aerodynamic concepts before deciding which designs should proceed to expensive simulation and physical validation.

Solution Overview

Paragon is a web application that provides rapid, AI-powered Cd estimates through two complementary workflows:

Shape-based screening: A compatible DrivAerNet-format .paddle_tensor point cloud is safely parsed, sampled to 2,048 points, and evaluated by a trained PointNet model served through ONNX Runtime.
Parameter-based exploration: Users adjust 23 numerical design parameters plus rear-body and wheel categories. A deployed RandomForest surrogate updates the Cd estimate while an interactive 3D reference vehicle visualizes supported design changes.

Paragon helps teams compare concepts, identify promising directions, and reserve high-fidelity CFD for a smaller set of candidates. Earlier aerodynamic feedback can also help teams consider energy efficiency sooner and avoid unnecessary simulation work.

Paragon is not a replacement for CFD or wind-tunnel testing. It is an early-stage screening and ranking tool. The application displays model provenance and domain warnings, and parameter-based predictions include a heuristic estimated range.

Key Features

Live PointNet demonstration: Run real ONNX inference on five vehicle point clouds held out from training and validation, then compare each prediction with its CFD reference value.
Point-cloud upload: Upload a compatible .paddle_tensor point cloud for safe parsing, farthest-point sampling to 2,048 points, 3D preview, and Cd prediction through the trained PointNet model.
Interactive design studio: Explore 23 numerical parameters plus rear-body and wheel categories while viewing an approximate Three.js vehicle preview and an updated parametric Cd estimate.
Variant comparison: Save up to five parameter-based design variants and compare a selected pair.
Design guidance: Inspect local sensitivity drivers and search for bounded parameter changes toward a target Cd.
Grounded explanations: Review model provenance, dataset position, domain warnings, and explanations based on computed results. OpenAI integration can optionally improve the wording, but it does not generate the Cd prediction.
Exportable results: Download a structured JSON record or open a printable report that can be saved as a PDF.
Explicit input boundaries: STL import is provided only as a separate, low-confidence geometric fallback. STL files are not processed by the trained PointNet model.

Technologies Used

Frontend: React, TypeScript, Vite, Three.js, and Zustand
Backend: FastAPI, Pydantic, and Uvicorn
Machine learning: PyTorch, PointNet, scikit-learn RandomForest, ONNX, and ONNX Runtime
Research benchmarking: AutoGluon, LightGBM, DGCNN, and RegDGCNN
Data and analysis: DrivAerNet++, NumPy, and pandas
Testing: Vitest, Testing Library, and Python unit tests
Deployment: Docker and Railway
Optional integrations: Google Vertex AI as an alternative parameter-model provider and the OpenAI Responses API for grounded Copilot wording

The public deployment uses the local RandomForest model by default for parameter-based prediction. Vertex AI is an optional integration and is not required to run the deployed application.

Target Users

Automotive designers and engineers who need immediate aerodynamic feedback while evaluating early vehicle concepts
Product and design teams that need to compare candidate directions before committing significant engineering resources
CFD engineers who want to reduce the number of concepts entering high-fidelity simulation and focus validation resources on the strongest candidates

Inspiration

Early-stage vehicle design decisions are made quickly, but aerodynamic feedback is comparatively slow. This creates a gap at the point where design changes are easiest and least expensive to make.

Research datasets such as DrivAerNet++ demonstrate that machine learning can learn meaningful relationships between vehicle geometry and CFD-computed Cd. However, research benchmarks primarily focus on model performance rather than an end-to-end workflow that designers and non-ML specialists can explore.

We built Paragon to bridge that gap. Our goal was to turn aerodynamic surrogate modeling into an accessible and transparent design-screening experience while remaining honest about where AI estimation ends and engineering validation must begin.

How We Built It

We used the DrivAerNet++ dataset, which provides CFD-labelled sedan variants in point-cloud and parametric forms. The available data includes 7,713 point clouds and 4,165 parameter rows.

To compare shape-based and parameter-based modeling fairly, we matched vehicle IDs across both representations. This produced 3,704 common vehicle designs. Both model families were evaluated on the same vehicles using the same body-type-stratified, rotating five-fold protocol. Five additional vehicles were permanently excluded from training and validation for the public live demonstration.

For the shape-based track, we trained and evaluated PointNet, DGCNN, and RegDGCNN. Each point cloud was reduced to 2,048 representative points using farthest-point sampling. PointNet provided the strongest balance between predictive performance and serving cost, so we exported the selected checkpoint to ONNX for CPU inference.

The .paddle_tensor format is pickle-based, so ordinary pickle deserialization would create a security risk for public uploads. We built a restricted parser that reconstructs the numerical point array without executing arbitrary pickle code. The backend validates the uploaded data, applies the required sampling process, and sends it to the PointNet ONNX model.

For the parameter-based track, the design studio sends 23 numerical parameters and two categorical selections to a local RandomForest model. Sensitivity analysis and bounded target search use the same parameter model. The Three.js viewer deforms an approximate Fastback reference mesh to help users visualize supported changes; it is a design aid rather than CAD or CFD geometry.

The frontend was developed with React and TypeScript, while FastAPI serves the prediction APIs and production frontend. The complete application is packaged in one Docker container and deployed as a public Railway service.

Challenges We Ran Into

Creating a fair comparison

The point-cloud and parameter datasets did not contain exactly the same vehicle IDs. Comparing the full datasets would have mixed two questions: whether full geometry contains more useful information and whether one model simply received more training data. We addressed this by evaluating both tracks on the same 3,704 vehicles with identical folds.

Reporting model performance responsibly

A single global R² score can hide failures on underrepresented body types. We therefore examined R², mean absolute error in drag counts, pairwise ranking accuracy, and body-type-specific results. We also kept research metrics separate from the deployed checkpoint's metrics.

Preserving the trained input contract

The PointNet model expects canonically aligned, metre-scale DrivAerNet-format point clouds. Arbitrary meshes, partial scans, and incorrectly scaled geometry cannot be assumed to follow that contract. We documented the supported format and kept STL import separate from trained PointNet inference.

Turning a research model into a web product

Training used PyTorch, while the public application needed lightweight CPU inference. Exporting PointNet to ONNX allowed us to deploy real inference with FastAPI inside the same Docker service as the frontend.

Accomplishments

On the matched 3,704-design, five-fold comparison, PointNet achieved R² 0.878 ± 0.007, 6.25 drag-count MAE, and 89.1% pairwise ranking accuracy.
Under the same vehicles and folds, the strongest parameter benchmark, AutoGluon, achieved R² 0.573, 11.66 drag-count MAE, and 78.3% ranking accuracy. PointNet reduced MAE by approximately 46% in this directly comparable experiment.
We deployed a real held-out demonstration rather than replaying stored predictions. The five demo vehicles run through the packaged PointNet ONNX model in the live application.
We delivered an end-to-end product with point-cloud inference, parameter exploration, 3D visualization, sensitivity analysis, target search, variant comparison, and exportable reports.
We made important limitations visible, including model provenance, supported input formats, domain warnings, approximate geometry visualization, and the distinction between trained PointNet inference and the untrained STL fallback.

What We Learned

Full 3D geometry contains aerodynamic information that design parameters alone cannot fully capture. Matching the vehicles and evaluation folds made this difference measurable.
A larger model is not automatically a better model. PointNet outperformed the larger DGCNN and RegDGCNN architectures while remaining practical for CPU deployment.
Evaluation design matters as much as model architecture. Dataset matching, validation-only model selection, permanent demo holdouts, and body-type analysis were essential for producing defensible results.
R² alone is not enough for a screening product. Ranking accuracy and error in drag counts more directly describe whether the model can distinguish between candidate designs.
Very small predicted differences should not be treated as decisive. Paragon is most useful for screening and ranking meaningfully different candidates.
A trustworthy AI interface must communicate its limits. Users need to know which model produced a result, whether the input is supported, and when the output is only directional guidance.

What's Next

Expand the training data beyond DrivAer sedan variants to include more vehicle classes and geometry families.
Build and validate a trained arbitrary-mesh workflow so common formats such as STL can be connected to a supported geometry model.
Measure performance on noisy, sparse, partial, and real-world scan inputs before presenting them as supported use cases.
Add calibrated uncertainty estimates and stronger out-of-distribution detection.
Validate shortlisted predictions against additional high-fidelity CFD studies and, when available, real wind-tunnel evidence.
Extend geometry-model interpretability into validated shape-based recommendations.
Add accounts, shared team workspaces, prediction history, and model-version audit records.