Comparing embedded 3D visualization vs. external viewer integration for analytics dashboards in engineering workflows

PLM Aras Innovator
, , , , , , , ,
1

We’re evaluating options for 3D visualization in our Aras 13.0 analytics dashboards and I’d like to hear experiences from teams who have implemented either approach. Our engineering team needs to overlay analytics data on 3D models - things like highlighting parts by cost, showing quality metrics, or displaying change status directly on the CAD geometry.

The native Aras viewer offers tight integration and seems simpler to deploy, but we’re concerned about performance with large assemblies. External viewers like Hoops or WebGL-based solutions might offer better rendering performance and more advanced analytics overlay capabilities, but they add integration complexity and potential security concerns with data leaving the Aras environment.

From a data security perspective, the embedded viewer keeps everything within Aras authentication and access control, which is important for our IP protection requirements. But external viewers often have more mature analytics APIs for custom overlays. What trade-offs have others encountered when choosing between native versus external 3D visualization for analytics use cases?

2

From a security standpoint, the native viewer is significantly simpler to audit and maintain. External viewers create additional attack surface - you’re exposing geometry data through APIs that need careful rate limiting, input validation, and monitoring. If your organization has strict IP protection requirements or operates in regulated industries, the embedded approach reduces compliance complexity. That said, external viewers can be secured properly with the right architecture, it just requires more security engineering effort upfront.

3

I’ve worked with both approaches across multiple implementations. External viewers definitely win on performance and advanced analytics features. We used Hoops Communicator with custom REST API integration to Aras and could handle assemblies with 5000+ parts smoothly. The analytics overlay capabilities were excellent - heatmaps, real-time highlighting based on complex queries, and custom annotations. However, the security model required careful design. We had to implement a token-based system where the external viewer requested geometry through secured Aras APIs, never directly accessing files. This added several weeks to the implementation but maintained our security requirements.

4

Having implemented both approaches across different organizations, I can provide perspective on all three focus areas you mentioned.

Native vs. External Viewer Comparison: The native Aras viewer is the right choice when: (1) your assemblies are under 1000 parts, (2) your analytics overlay needs are relatively simple (color coding, basic highlighting, property display), and (3) you want minimal maintenance overhead. It provides adequate performance for most engineering analytics scenarios and the integration is straightforward.

External viewers excel when: (1) you’re dealing with very large assemblies (2000+ parts), (2) you need advanced analytics features like heatmaps, complex animations, or custom rendering modes, and (3) you have development resources to build and maintain the integration layer. The performance difference becomes significant at scale - we’ve seen 3-5x better frame rates with Hoops on large assemblies compared to the native viewer.

3D Analytics Overlays: For analytics overlays, external viewers provide much richer APIs. With the native viewer, you’re limited to predefined overlay types - essentially property-based coloring and basic annotations. External viewers like Hoops or Three.js-based solutions let you implement custom shaders, dynamic heatmaps based on real-time data queries, and sophisticated visual analytics like exploded views with cost annotations or quality metric gradients across surfaces.

However, these advanced capabilities require JavaScript development expertise and ongoing maintenance. The native viewer’s simpler overlay API means faster implementation for standard analytics use cases. Most engineering teams don’t actually need the advanced features external viewers provide.

Data Security and Access Control: This is where the native viewer has a clear architectural advantage. It operates entirely within the Aras security context - no data leaves the server except through standard Aras mechanisms, and all access control is automatically enforced. You don’t need additional security infrastructure.

External viewers require careful security architecture: implement token-based authentication (OAuth or JWT), create a secure API layer that validates all geometry requests against Aras permissions, add rate limiting to prevent data exfiltration, and implement audit logging for all 3D data access. This is doable but adds significant complexity.

One hybrid approach worth considering: use the native viewer as your default, but implement an external viewer option for power users working with large assemblies. This gives you the security and simplicity of the native viewer for most users, while providing the performance benefits where needed. The external viewer becomes an optional enhancement rather than a core dependency, reducing your security and maintenance burden.

For your specific situation with analytics dashboards, I’d recommend starting with the native viewer unless you have confirmed performance issues with your actual assembly sizes. The tight integration and automatic access control alignment are significant advantages for analytics scenarios where users are exploring data across many parts and assemblies.

5

James, that’s helpful context on the security implementation. How did you handle the authentication flow between Aras and the external viewer? Did users need to authenticate twice or did you pass tokens through?