Developer Support Policy

1.0 Contacting Support

1.1 Methods of Contacting Support

There are a variety of ways to contact our Developer Support Team. See Contacting Support for details.

1.2 Required Information

Before contacting our support team some of the general guidance we provide is:

A. If you want to "Ask a question", have you:

• Reviewed pertinent sections of our Tech Soft 3D Documentation — Tech Soft 3D documentation?

• Explored the technical articles on the https://developer.techsoft3d.com/ ?

• Looked through our https://techsoft3d.atlassian.net/l/cp/okz7p0w1?

B. If you are "Reporting a bug"; you should first download the latest release from the https://developer.techsoft3d.com/ to confirm it's still an issue. If it is then some items to consider which helps ensure quick resolution of the issue include:

• Do any of the available samples or demonstration programs experience the same results? If yes, which program and how is it used to demonstrate the issue?

• Are special compiler/linker options used?

• Does the same result occur on multiple platforms?

• If you cannot reproduce the problem in the sample programs or demos, it would be very helpful if you could provide the following information:

  • HOOPS Communicator:

    • For viewer-side issues please submit an HTML and JS file(s) that reproduces the problem.

    • For conversion issues, please submit any sample files along with specific converter.exe settings and log files which enable us to reproduce the problem.

  • HOOPS Exchange:

    • a standalone test case.

    • a sample file which demonstrates the problem when loaded into the HOOPS Demo Viewer or the HOOPS Exchange Demo.

  • HOOPS Publish:

    • a standalone test case.

    • a sample file which demonstrates the problem when loaded into the HOOPS Demo Viewer or the HOOPS Exchange Demo.

  • HOOPS Visualize: there are a couple of options here:

    • a standalone test case.

    • a piece of code which can be added to the simple apps on HOOPS Visualize 3DF or the sandbox apps on HOOPS Visualize HPS.

    • a code snippet generated from the code-generation capabilities of HOOPS Visualize.

  • HOOPS Luminate:

    • a .red file which reproduces the scene in question

Once these questions have been considered, please contact Developer Support, who will gather necessary information and work to resolve your issue.

1.3 Uploading Large Files

Files up to a moderate size can be directly attached to support portal issues. In other situations, use our Secure File Transfer system:

1. Open https://transfer.techsoft3d.com in a browser.

2. Register for a new account using your email address.

3. Review Create a File Link to learn how to generate file links to share with Tech Soft 3D Support.

4. Once you have generated a file link you can copy and paste it into your support ticket.

2.0 Support Process

The following steps outline the standard process for requesting and obtaining support assistance:

1. Use the Create Issue form to log an issue in the online support system and submit any related test programs/files. At creation time, you may indicate the severity and the Business Impact of the issue. These influence the urgency with which the support team will respond. To ensure the system works well please use the highest level severity for only your most urgent issues.

2. Once an issue is created it's assigned to a support engineer who works on the issue until it is resolved. Resolution is defined as either arriving at a point where the issue can be closed (a question was answered, feedback was provided, etc...), or assigning the Bug or Feature to our Engineering team.

3. If an issue is a confirmed Bug, it is given a status (Archived, Declined, Backlog) based on our analysis and Developer Support Policy | 2.3 Triage Process.

4. If an issue is a Feature Request, it is given a status (Archived, Declined, Backlog) upon review by our Product Management Team.

5. When a decision is made to target the delivery of a Bug-fix or Feature in a specific release, the release value is set in the "Fixed Version" field (the default value is "Unscheduled".) and the status of the issue changes to Planned.

2.1 Issue Category

Duplicate issues reported by the same Organization are closed. The older ticket remains active providing status.

2.2 Issue Status

The issue status and workflow varies by issue type: Info Request, Bug and Feature Request. This section describes the workflow for each type and defines each status. Gold boxes in the workflows highlight changes introduced in autumn 2021.

2.2.1 Issue Workflows

Info Request Workflow

Bug Workflow and Support Analysis

Within ~4 days, the Support Team aims to isolate and reproduce a reported bug. A bug is not considered “confirmed” until the Support Team has an isolated testcase reproducing the problem. There is no guarantee how long this will take but our goal is ~4 days. This process can be very difficult, particularly if the issue can only be reproduced within the partner’s application or is otherwise tough to isolate in a sandbox or sample application. A confirmed bug is then prepared for our Developer Support Policy | 2.3 Triage Process.

Open

Feature Request Workflow

The Support Team works with our partners to understand and document feature requests. The issue is forwarded to our Product Management team for consideration.

2.2.2 Issue Status Descriptions

When applicable, issue states have common meaning across issue type unless otherwise noted. Issue status description are as follows;

2.2.3 Declined Status

The Declined status may be used in a variety of situations. In order to deliver as much value to all our partners, we must balance the value of a bug fix or feature against the cost of delivery with finite development resources. To that end, some issues may be Declined soon after they are confirmed or as a result of our Developer Support Policy | 2.3 Triage Process. In an effort to be transparent and facilitate your planning, we endeavor to draw this conclusion as quickly as possible.

Issues may even reach the Backlog, Planned or Scheduled status when deeper analysis reveals we cannot resolve the issue/implement the feature due to elevated risk or cost relative to the value gained.

2.3 Triage Process

Once a bug is confirmed, our weekly engineering triage process reviews new reproducible testcases. The outcome may be one of the following issue states;

• ASSIGNED – perhaps a workaround is proposed or additional information required

• BACKLOG – The engineering team accepts the testcase as a bug and adds it to the backlog of all partner reported issues. No time frame is yet given for resolution.

• ARCHIVED – The bug is a low priority which will not be added to the backlog at this time. There is no timeframe given for further action. We welcome any additional feedback from the partner as business needs change or additional information becomes available.

• DECLINED – The bug is being Declined with an explanation.

2.4 Backlog and Engineering Process

Once in the backlog some additional, deeper analysis allows the engineering team to better understand the cost of resolution and prioritization of items within the backlog . This type of backlog refinement occurs regularly. A “Fix version” (described below) may be assigned as a result. Engineering and Product Management are responsible for this portion of the bug workflow.

The IN DEVELOPMENT status indicates work is in progress. If all goes well, the next status should be CLOSED which would mean the bug resolution or feature has been implemented and tested internally. The related changes will be available in the specified “Fix version”.

Occasionally (upon request), we make nightly builds available to a partner specifically for testing a single issue. This comes with the caveat that a nightly build has not been fully qualified and validated by our release testing process.

2.5 Fix Version

The “Fix version” indicates an intention to provide a solution in the specified version. Once the issue is closed this field identifies the specific release containing changes to resolve the issue.

Usually you will see a Fix version like "HE 2025.3.0" but sometimes you might see a Fix version like "Q2 2025" (i.e. second quarter of 2025).

This is a more general targeting of a time frame for resolution rather than a specific release. It’s an early assessment so the broad timeframe indicates our level of certainty. It indicates the Product Management team aims to resolve the issue in that general time frame.

The Fix version will be updated later to identify the specific release once it can be confidently determined.

The goal with this approach is to provide an early indication that we are making plans to resolve an issue but our certainty does not allow us to specify the precise release.

2.6 Issue Severity

When creating an issue, you indicate the Severity which contributes to the overall internal issue priority. Please refer to the following table to guide selection of an appropriate severity level for an issue:

Please be judicious when using Severity 0. It should be reserved for your absolute highest priority issues. This severity level should be limited to 0-2 issues (3 at the most). The Severity level should help us understand the relative priority of your open issues (cf. https://techsoft3d.atlassian.net/l/cp/ziEi2fRQ).

If you specify Severity 0 or 1, please include a brief explanation. This helps ensure that appropriate attention is applied to your business critical issue. Also note that severity will not necessarily map to a specific priority.

Selecting the Correct Severity Level

When choosing the severity, please consider these questions to determine the degree to which production is stopped or impeded:

• Does the issue completely prevent forward progress and production with no identified workaround?

• Is some progress possible with an alternative method (even if the workaround is not sustainable or a viable long-term solution)?

• What degree of functionality loss is experienced — total loss in functionality, some or partial loss, minor loss, or no loss?

• The Issue Severity is used to prioritize all your open issues. If you choose the same Severity for all of them, it does not help us prioritize their resolution.

Sorting Issues by Severity

You may be asked to https://techsoft3d.atlassian.net/l/cp/ziEi2fRQ. These Issue Severity levels allow you to review and correct a prioritized list of your bugs. This helps us provide you with the most value in each release with our finite development resources.

2.7 Business Impact

When creating an issue, you indicate its Business Impact which contributes to the priority of the issue. Please refer to the following table to guide selection of the appropriate Business Impact for an issue:

2.8 Support Response Time

We understand responsiveness is extremely important for our partners. Below we detail the response time targets for each issue type. Please note that resolution of an issue may require several rounds of correspondence.

2.9 Deprecation Process

Deprecation indicates End of Support for a designated functionality (cf. https://techsoft3d.atlassian.net/wiki/spaces/SPD/pages/2367881259)

• We plan to remove this functionality in the near future (the timeline will vary in each instance, and may be undefined).

• We urge partners to discontinue use of this functionality as soon as possible.

• We will not fix defects related to this functionality.

3.0 Product Releases

All our product releases are available for download from our https://developer.techsoft3d.com/.

See our https://techsoft3d.atlassian.net/l/cp/5GqwxeNn for specific release timing details.

Tech Soft 3D Documentation — Tech Soft 3D documentation updates will be released every Thursday morning (US Pacific Time).

For detailed discussion below, “HOOPS Suite” includes Communicator, Exchange, Publish, Visualize HPS, and Luminate.

Release Naming and Frequency

HOOPS Suite

Starting with HOOPS 2024, the naming convention is HOOPS <Product> major.minor.dot (e.g. HOOPS Communicator 2024.0.0). New releases are scheduled for every six weeks with the

• One major feature release per year (e.g. HE 2024.0.0) in the December/January time-frame

• Minor version updates will be released every 6 weeks (e.g. HE 2024.1.0).

HOOPS Visualize 3DF

New major versions of Visualize 3DF are also released annually in Jan/Feb. The numbering is <major version>.<minor version> (e.g. 28.00). Generally, the minor version increments by ten (e.g. 28.10 followed by 28.20) but occasionally by one (e.g. 28.21) for small updates.

Generally, two to four update releases are made in a given 3DF release stream following the major release (i.e. May/June and Sep/Oct).

Release Stream Lifecycle

A release stream includes all versions with the same major version. The lifecycle of a release stream begins with its initial major release and it ends with the next major version’s initial release. A release stream is deprecated once the lifecycle ends. Within a release stream, each version update deprecates the previous version.

There is only one active, supported release stream and version per product. Note the https://techsoft3d.atlassian.net/l/c/w1CyPSZP release stream is maintained for several years in parallel with the active 3DF release stream.

No further updates will be made to a deprecated release stream or version. Similarly, support for deprecated release streams and versions draws to a close. Questions for older versions will be addressed. Problems found in older versions will be analyzed and tested in that version as well as the latest version. If the reported problem occurs in the latest version, its resolution will be considered for a subsequent release. If the problem is not reproduced in the latest version, partners will be encouraged to upgrade.