Getting Started with RealFusion: Import Your First VDS File in One Call

Import your VDS file in the first call, not after a three-week pre-sales process

Most software vendors ask you to fill out a discovery form, book a scoping session, then wait two weeks for a personalised demo. RealFusion doesn't work that way. The first call is a live parse. You bring a real VDS file from your library, we import it, and the full assembly hierarchy lands on the RealNet data thread, right there on the call. No VEG round-trip. No pre-processing. No "we'll set that up before the next session."

What happens when a VDS file is imported

A VDS file is a compact, viewer-optimised 3D file. Based on RealFusion's own reverse-engineering work, VDS files as used in SAP Visual Enterprise Generator workflows typically contain geometry, part names, structure, colours, and annotations compressed into a single package — though SAP has not publicly documented a comprehensive technical specification for the format. SAP Visual Enterprise Generator produces VDS files as a primary output and has used this format for years. The problem manufacturers face now is that as SAP ECC moves toward its end of mainstream maintenance (with mainstream maintenance currently scheduled to end in 2027 for standard contracts, and extended maintenance options available through 2030 — timelines vary by contract, and customers should verify their specific position with SAP directly), the toolchain that produced those files is going dark. No widely communicated, supported migration path for existing VDS libraries has been published to date — though customers should check current SAP roadmap guidance directly, as this situation may have evolved.

RealFusion solves that with a direct parser. Through reverse-engineering, we identified what appears to be a SQLite-based container format underlying VDS files — this is our own finding from analysis of real customer libraries, not a publicly documented SAP specification. The assembly hierarchy, transforms, and metadata come in intact. The library you spent years building becomes the starting point, not something you throw away and re-author from scratch.

On a first call, you pick one file. It imports. You see the result.

On data sensitivity: you control the file

One question that comes up early is understandable. You've got CAD and BOM data that's commercially sensitive, and the idea of handing it to a new vendor feels risky.

Here's how it actually works. The proof-of-concept import runs against a file you choose, on terms you control. You don't need to connect your SAP stack to anything. You don't need to expose your full library to get a result. You pick one file, we parse it, and you see whether the assembly hierarchy and metadata come through cleanly. That's the scope of the first call.

If you want to go further, we can discuss what a controlled evaluation looks like. But nothing about the first import requires opening up your stack or committing to a broader integration.

Your existing VE viewer deployments don't break

This one matters to evaluators who've already deployed SAP Visual Enterprise viewers across the production floor and aren't about to undo that.

RealFusion doesn't replace the viewer as an outbound channel. Based on our current tested integration, SAP VEG remains available as a publishing path to HANA and BTP within RealFusion's architecture — though customers should validate this against their specific SAP VEG version and licensing status, particularly given the evolving SAP ECC landscape. What's already deployed keeps working. The architecture is specifically designed so that customers don't have to choose between moving forward and protecting what they've already built.

A common evaluator question is: "Is there a middleware black box in this integration?" The integration with SAP ECC and S4 uses standard SAP APIs without a middleware layer — meaning there is no separate middleware product to license or custom connector to maintain, and no separate sync job to manage. Evaluators should request technical documentation to assess whether this approach fits their specific SAP environment.

Variant configuration complexity is a feature, not a problem

The most common objection from manufacturers with complex configurations is that their variant rules are too intricate for a new tool to carry. It's a reasonable concern if you've been pitched generic work instruction tools that flatten configuration into a single closest-match instruction.

RealFusion is built specifically for this. The EBOM-to-MBOM-to-Order BOM chain with variant configuration at the order level is the architecture, not an add-on. The instruction an operator sees is configured to the exact product on their workstation, for the specific order, not a generic approximation of the most common variant.

Tools like VKS, Dozuki, and SwipeGuide are designed as general-purpose work instruction platforms and were not built around the EBOM-to-MBOM-to-Order BOM variant configuration chain that RealFusion centres on. Each of those products has its own integration capabilities, and evaluators should assess them directly — but the architectural starting point is different from RealFusion's. Where variant configuration complexity is the primary requirement, the difference between a purpose-built BOM data thread and a general-purpose platform becomes more apparent.

When a BOM change happens upstream, it propagates downstream through the RealNet hierarchy automatically. The floor sees what engineering intended, for that variant, on that order.

How the pilot is structured

The pilot tier starts at $1,500 per month, which covers one product line, up to five named users, and includes the SAP Visual Enterprise read connector. That's the full import capability, not a limited preview of it — though evaluators should request documentation confirming which specific parser features are available at pilot tier versus higher tiers.

The entry point is designed to prove the business case before you commit at scale. One product line is enough to demonstrate whether the VDS parser handles your files cleanly, whether the BOM thread is intact, and whether the instructions delivered to the floor reflect the right variant for the right order.

Professional tier starts at $3,500 per month and covers up to five product lines with the full variant configuration rule engine. Enterprise is $7,500 per month and removes the product line limit entirely, with full SAP ERP and SAP VE migration support included.

Pricing shown is indicative and subject to change. A formal quote will reflect your specific configuration, region, and any applicable implementation or onboarding costs, which are not included in the figures above. Contact us for current pricing.

Most customers start with the pilot. One file, one product line, five users, one call.

What to bring to the first call

One VDS file from your library. Ideally one with a reasonably complex assembly hierarchy, because that's what shows the parser's range. If you have a VZXML file, that works too.

You don't need to prepare anything else. No data room, no pre-work, no integration scoping. The call is the proof.

If you're carrying the weight of a VDS library that's about to lose its supported home, and you've been told the only option is a multi-year re-author programme, this is worth an hour of your time.

Book a live import session at virtualspace.io and bring a file.