3D / Digital Twin / AR Developer – Existing Automotive Platform -- 2

About the project

3D / Digital Twin / AR Developer – Existing Automotive Platform I are looking for an experienced 3D, Digital Twin, WebGL/AR or computer-vision developer to implement a clearly defined 3D capability within an existing automotive technology platform. This is not a greenfield project. The wider system architecture, digital-twin concepts, component identity model, interfaces, schemas, test requirements and integration boundaries already exist. I am looking for someone who already knows this area and can efficiently implement the supplied SP-06 High-Fidelity 3D, Scanning and AR Capability work package. Initial Assignment The Upwork engagement is focused on a bounded / proof-of-capability for one supplied vehicle or use case. The implementation should demonstrate the core technical pipeline required for the wider SP-06 capability. Depending on the supplied assets and agreed implementation approach, the work will include relevant elements of: • importing and processing a supplied 3D vehicle asset; • preserving the supplied vehicle/component hierarchy and component IDs; • converting/optimising geometry for interactive rendering; • GLB/glTF or equivalent production-friendly asset handling; • component-level selection and interaction; • exploded/reassembled vehicle views; • component highlighting/isolation; • metadata association with individual components; • Level of Detail (LOD) / geometry optimisation where appropriate; • efficient asset loading and rendering; • basic scan/geometry registration against a known reference model; • coordinate-system and alignment handling; • confidence/alignment result output; • AR-ready positioning/overlay structure where supported; • redaction/visibility handling; • source/licence metadata associated with visual assets; and • integration against the supplied Apex interface contracts. The exact implementation boundary and acceptance requirements will be supplied. Important Existing Position I already have: • the wider application architecture; • digital-twin governance; • component/node identity conventions; • geometry-manifest concepts; • interface contracts; • synthetic fixtures; • mock data; • an existing synthetic exploded-view demonstrator; and • controlled acceptance/conformance requirements. You are therefore not being asked to invent the overall product or digital-twin architecture. Your responsibility is specialist implementation. Core Behaviour Required For the bounded proof-of-capability, a user should be able to interact with a supplied vehicle model and demonstrate a flow similar to: Vehicle Model → Component Hierarchy → Select Component → Highlight/Isolate → Exploded View → Component Metadata → Geometry/Alignment Information Where scan/registration is included in the supplied task, the implementation must also return an explicit registration/alignment result rather than silently treating an uncertain scan as an exact vehicle state. Critical System Boundaries The 3D/AR implementation must not become the authority for the actual installed state of the vehicle. A visual model, scan or registration result may provide an observation or candidate interpretation. It must not silently declare that a component is physically fitted, removed or changed. The implementation must preserve supplied: • component/node IDs; • coordinate-frame information; • asset/source information; • confidence/alignment information; • approval status; • redaction status; and • guidance/no-guidance state. If confidence is insufficient, the implementation must be capable of displaying or returning that condition rather than presenting uncertain information as verified. The AR/3D client must not provide any physical machine, robot or vehicle-control capability. Rights and Assets Any third-party 3D asset, library, model, texture or other dependency introduced by the freelancer must have a clearly identified licence. Do not: • use pirated vehicle models; • scrape proprietary automotive geometry; • introduce assets without known usage rights; • remove existing source/provenance metadata; or • introduce a dependency that prevents Apex from using the delivered work commercially. If a supplied asset is used, preserve its associated identity/source metadata. Deliverables The completed assignment must include: 1. Working source code for the agreed SP-06 proof-of-capability. 2. Working 3D vehicle rendering using the supplied test asset. 3. Component hierarchy and stable component selection. 4. Exploded/reassembled view capability where required by the supplied package. 5. Component metadata interaction. 6. Geometry optimisation/loading appropriate to the selected implementation. 7. Registration/alignment implementation where included in the assigned slice. 8. Confidence/error/failure handling. 9. Relevant automated or reproducible tests. 10. Dependency and licence information. 11. Short README explaining: • how to install; • how to run; • how to test; • asset format used; • key dependencies; and • any assumptions or limitations. The returned implementation must be capable of being built and tested independently against the supplied Apex fixtures/interfaces. Architecture Boundary Please do not redesign the wider system. Do not: • change Apex component identity semantics; • invent a separate vehicle-state model; • treat scan geometry as authoritative installed-state truth; • bypass confidence or redaction controls; • silently replace supplied interface contracts; • introduce physical-control functionality; • make unrelated changes to the system; or • create dependencies on freelancer-controlled infrastructure. If you believe a supplied interface requires modification, raise the issue rather than changing it silently. Suitable Experience We are particularly interested in developers with proven experience in one or more of: • Three.js • Babylon.js • React Three Fiber • WebGL / WebGPU • Unity • Unreal Engine • glTF / GLB pipelines • 3D configurators • CAD/mesh conversion • mesh optimisation • digital twins • automotive 3D visualisation • ARKit / ARCore / WebXR • photogrammetry • LiDAR / depth scanning • point-cloud or mesh registration • coordinate transforms • computer vision / 3D registration You do not need to have experience in every technology above. We want someone whose previous work demonstrates that the assigned 3D problem is already familiar to them. This is a deliberately bounded implementation/proof-of-capability within an already-designed system. The architecture, interfaces, expected behaviours and controlled supplier package are provided. Please apply only if the scope and fixed-price budget are commercially suitable for you. When Applying Please begin your proposal with: APEX 3D Then answer the following questions. 1. What is the most similar 3D configurator, digital twin, AR or interactive 3D application you have personally developed? Please provide a link, screenshot or short description if possible. 2. Which technology would you choose for an interactive vehicle model with component-level selection and exploded views, and why? 3. How would you preserve individual component identity when converting or optimising a vehicle model for real-time rendering? 4. If a scanned vehicle cannot be aligned reliably to its reference 3D model, how would you handle that condition in the application? 5. What experience do you have with glTF/GLB, mesh optimisation, coordinate systems, point clouds, photogrammetry or 3D registration? Only describe technologies you have actually used. 6. What information would you need from us to begin implementation immediately? Selection We are not looking for somebody to learn 3D development during this assignment. We are looking for a developer for whom this type of implementation is already familiar and who can move quickly using an existing technical specification. Applicants who provide generic AI-generated proposals without answering the technical questions will not be considered. Successful delivery may lead to additional bounded 3D, scanning, digital-twin and AR work as the platform progresses.

Skills required