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.

E-Mail

The support@techsoft3d.com 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:

• HOOPS Communicator: support.hc@techsoft3d.com

• HOOPS Exchange: support.he@techsoft3d.com

• HOOPS Publish: support.hp@techsoft3d.com

• HOOPS Visualize: support.hv@techsoft3d.com

• HOOPS Luminate: support.hl@techsoft3d.com

• Polygonica: support.polygonica@techsoft3d.com

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: paavo@techsoft3d.com

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:

• Siemens Kineo: support.kineo@techsoft3d.com

• Siemens Parasolid: support.parasolid@techsoft3d.com

Tech Soft 3D Website User Access

If you have trouble accessing our Support Portal or https://developer.techsoft3d.com/, please send email to support@techsoft3d.com

Phone

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:

• Reviewed pertinent sections of our https://docs.techsoft3d.com/landing/latest/?

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

• Looked through our ?

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

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

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 .

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

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:

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

• 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

HOOPS Suite

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