Developer Support Policy

1.0 Contacting Support

An important part of our relationship with you is responding to your technical inquiries. These can be bug reports, feature requests or simple usage questions. Please find below details on the best ways to engage with us on these technical queries. It's generally more efficient for everyone to use our support portal but if that is proving difficult feel free to call us directly at our offices or just sending an email.

If you are on a self-guided evaluation of a Tech Soft 3D product, please submit your support questions via the Tech Soft 3D Community Forum for help. You should receive a response to your question within 3 business days. We welcome feedback in the forum from both evaluators and partners. However, the ability to request bug fixes and submit official feature requests is reserved for our commercial partners

1.1 Methods of Contact

Support Website

When you require technical assistance, we encourage you to submit the information via our Support Portal.

If you are accessing the site for the first time click on the link, Forgot Password, and you will be sent your initial password. After logging in, select the appropriate submission form to "Report a bug", "Ask a question" or "Suggest a new feature".
An ID will be associated to your request and included in the subject line of related emails, and be displayed in the following format: SDHE-xxxxx Issue Summary.
SD for Service Desk, HE for HOOPS Exchange (SDHV for HOOPS Visualize, etc.) xxxxx for the issue number.
Please include the issue ID (and maintain its original formatting) in the subject of any further correspondence on the matter. You can also use the support portal to track the status of your issues, submit test files, etc.


The address is a generic Tech Soft 3D Developer Support account. We encourage you to review the following and choose an alternative method to contact us which will be more efficient.

HOOPS SDK Products

We strongly encourage you to use our Support Portal to review your issues and report new ones. This helps ensure all the required information is provided which will result in quicker resolution times.

You can send email to one of the following aliases to automatically create an Info Request in the portal:

NOTE: You must have access to the new portal and log in at least once in order to effectively use these addresses.

HOOPS Demo Viewers

To request a License key for our Demo Viewers, submit an info request in any of the HOOPS portals as described above.

OEM Products

For support with the AutoCAD OEM or Inventor OEM development platforms please send an email to:

Paavo Rantanen:

If your support inquiry pertains to RealDWG, the AutoCAD API (ObjectARX) or the Inventor API then please login to your Autodesk Developer Network (ADN) account and log a support case there.
Alternatively you can log into the partner centre and create a case there.

3rd Party Support Accounts

For technical assistance please send an email to:

Tech Soft 3D Website User Access

If you have trouble accessing our Support Portal or, please send email to


You can also contact our support group via the following:

  • Americas (includes U.S.A.): +1.510.883.2180

  • Europe, Africa & Middle East: +33 4 72 81 68 81

  • Asia & Australia (includes Japan and South Korea): +81-(0)45-313-2555

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:

B. If you are "Reporting a bug"; you should first download the latest release from the 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 system:

  1. Open 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 .

  4. If an issue is a Feature Request, it is given a status (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

Issue Type


Issue Type


Info Request

A request for information about product usage, distribution, licensing, etc.


The issue is an apparent bug with our product and/or documentation.

Feature Request

A request for new functionality within the product, or a limitation which Tech Soft 3D has determined can only addressed via new functionality.

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 .

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;

Issue Status


Issue Status



A new, unassigned issue.


A Support Engineer is actively working on the issue.

Needs Partner Review

The issue requires customer feedback or activity. Your response returns the status to Assigned.


The confirmed bug will be reviewed by our engineering . After triage the issue may be moved to Archived, Declined, Backlog or Assigned.


The confirmed bug/feature has been added to our product backlog. No specific timeline has been determined. The time frame for action is a maximum of 24 months. See for details.


The confirmed bug/feature has been reviewed by our engineering team and a release target identified resulting in a "Fix version" notification. The time frame to resolves a bug in an official release is generally 3 months. The time-frame for new feature delivery in an official release is ~6 months.


The confirmed bug/feature has been assigned to an upcoming sprint. Development will generally begin within two to four weeks.

In Development

The engineering team is actively working on the fix/implementation including development, review and testing.

Pending Review

The Feature Request has been forwarded to Product Management. There is no timeframe for reviewing requests in this quasi-archived state.

PO/PM Review

Product Management is actively reviewing & considering the Feature Request.

Needs Input

Product Management requires feedback or additional information related to a Feature Request. Your response returns the status to PO/PM Review.


The bug has been confirmed and reviewed in our engineering . It is currently considered a lower priority relative to other bugs and development efforts. In this state, it will not be scheduled for resolution unless it is strategically grouped with other development work. Please let us know, if your business needs change and we will reevaluate this status.


The bug/feature has been confirmed but will not be fixed/implemented. It is possible that issues with the Backlog, Planned, Scheduled and even In Development status may be Declined. See for more information about this status and process.


The issue has been handled (answered, fixed, implemented).

This is the terminal status for all issues.

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 . 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.

This is not the terminal status of an issue. Please contact Support, if you have additional information or need to adjust the Issue Severity or Business Impact. We recognize these are dynamic situational concepts and desire to understand and adapt to your changing needs.

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 2022 SP2" but sometimes you might see a Fix version like "2022-Q2" (i.e. second quarter of 2022).

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:

Issue Severity


Issue Severity


0- Highest Priority / Blocking Failure

  • Stopping business and/or development operations and schedules

  • Complete loss of functionality without workaround

1- Critical Failure

  • Critical loss of functionality

  • No workaround identified

2- Major Failure

  • Significantly affecting business and/or seriously impeding development operations and schedules — work proceeds but is restricted

  • Major loss of functionality

3- Minor Failure

  • Somewhat affecting business and/or development operations and schedules — work continues mostly unaffected

  • Minor loss of functionality

4- Cosmetic

  • Minimally affecting business and development operations and schedules

  • No loss of functionality

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. ).

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 . 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:

Business Impact


Business Impact


1- Customer Report / All Users

  • Issue reported by several of your customers

  • Multiple datasets/files failing

  • Affecting many users

2- Customer Report / Few Users

  • Issue reported by a small number of your customers

  • Some datasets/files failing

  • Affecting small number of users

3- Internal Report / All Users

  • Issue found internally by your team

  • Some datasets/files failing

  • Could affect many users

4- Internal Report / Few Users

  • Issue found internally by your team

  • Some datasets/files failing

  • Could affect small number of users

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.

Issue Type

Response Time Target

Issue Type

Response Time Target

Info Request

Response time target is 48 hours. We prioritize Info Requests over Bugs and Features since these generally require a product delivery.


Response time target is 4 days to review and confirm issue description, materials, reproduction steps. Once confirmed the issue will be referred to engineering .

Feature Request

We receive numerous feature requests, and strive to balance them against product direction and available resources. Simple feature requests are considered in the same time scale as bugs. More complex ones may be reviewed during our annual product planning sessions. If you have a complex request, we encourage you to reach out directly to the Product Manager (via the support ticket).

Documentation Issues

Documentation Bugs/Features are fixed in a similar process to bugs.

Third Party Bugs/Features

These are reported to the third party supplier with no further action by Tech Soft 3D. If something is assigned a P1 then we will encourage the Third Party to resolve the issue, and notify the customer of the likelihood/timing of any solution.

2.9 Deprecation Process

Deprecation indicates End of Support for a designated functionality (cf. )

  • 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 .

See our for specific release timing details.

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


Prior to HOOPS 2024, the naming convention is HOOPS <Product> <Service Pack> <Update> and the frequency for our releases is:

  • One major feature release per year (e.g. HE 2020).
    Our major releases go out in the December/January time-frame

  • Two Service Pack releases per year (e.g. HE 2020 SP1).
    Our SP1 and SP2 releases generally go out in the March/April and June/July time-frame

  • Update Releases to any of the above releases are unscheduled and released as required (e.g. HE 2020 SP1 U1).

Starting with HOOPS 2024, the naming convention is HOOPS <Product> (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 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.