Developer Support

1.0 Contacting Support

2.0 Levels of Customer Support

3.0 Support Issue Handling Process

4.0 Release Process

5.0 Assessing Overall Issue Status/Progress

1.0 Contacting Support

1.1 Methods of Contact

Support Website

When you require technical assistance, we encourage you to submit the information via our Online Support Portal, located at:

If you are accessing the site for the first time, click on the link, I’m requesting an initial password, and you will be sent your initial password. After logging in, select the Create Issue link to create and submit your question or description of your problem. TechSoft Support will log your issue, and an ID will be included in the subject line of related emails, and be displayed in the following format: [#]. 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.

Electronic Mail

The support email address for general support correspondence is However, we strongly encourage you to use the aforementioned online support system’s Create Issue form to report new issues. This helps ensure that you provide a variety of essential information, which in turn enables us to provide more efficient and higher quality support.


You can also contact our support group via the following:

United States:

  • Tel: +1.510.883.2180
  • Fax: +1.510.883.2193


  • Tel: +33 (0)4 72 81 68 81
  • Fax: +33 (0)4 72 81 68 88

1.2 Required Information

Before Contacting Developer Support

A. If you have a question, have you:

  • Reviewed pertinent sections of the documentation?
  • Explored the technical articles on the HOOPS Developer Zone?

B. If you have found a Problem that you believe to be a Bug, it may already be resolved in a Service Pack, Maintenance or Major release. Active customers should obtain the latest release from the downloads section of the HOOPS Developer Zone and confirm that the Problem still occurs. Before reporting a problem, please consider the following questions:

  • 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 being used?
  • Does the same result occur on multiple platforms?
  • If you cannot reproduce the problem in the sample programs or demos, we ask that you submit the following types of information:
    • HOOPS Visualize: a standalone test case, information on how to reproduce in the HoopsPartViewer (3DF API), HoopsDemoViewer(HPS API), or a compilable code-generation that has been confirmed to show the problem.
    • HOOPS Exchange/Publish: a standalone test case along with any sample file(s), or information on how to reproduce using the HoopsDemoViewer or HoopsExchangeDemo.
    • HOOPS Communicator: For viewer-side issues, please submit an HTML and JS file(s) that reproduces the problem. For server-side issues, please submit any sample files along with specific converter.exe settings and log files which enable us to reproduce the problem.

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

1.3 Uploading to TS3D

Developers wishing to use TS3D’s anonymous FTP can do so by following these instructions:

  1. From a command line – ftp
  2. When prompted for a username, enter ‘anonymous’, no password is needed
  3. Change directory to ‘incoming’ – cd incoming
  4. To transfer the file in binary mode type – bin
  5. Upload files to this directory using the command ‘put ‘.
  6. The message “Transfer complete” indicates the file was successfully uploaded.
  7. Type ‘quit’ to end the ftp session

If you require a more secure method for uploading data to TS3D, please send an email to and we will set you up with a secure FTP account.

2.0 Levels of Support

Tech Soft 3D offers two levels of support, and organizes its support services into two groups. The Developer Support group assists developers in optimal usage of TS3D products, manages bugs/problems and basic usage questions. The Consulting Engineering group provides developers with design/optimization assistance and training courses, serves as customer advocates, and helps the Developer Support Group in handling more complex issues.

2.1 Priority Support

This program provides maximum support to major commercial development efforts. Priority Support typically includes credits for Consulting Engineering resources and Training services, and also affords higher priority for Issue Handling, Bug resolution and Feature requests.

2.2 Developer Support

This program provides the standard level of support recommended for TS3D Partners. It includes direct e-mail and telephone access to our Developer Support group and special consideration during bug fixing periods.

In addition, all customers automatically receive Major and Service Pack releases of licensed Tech Soft products.

3.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 of the issue. As previously mentioned, the issue ID will be included in the subject line of related emails, and be displayed in the following format: [#]. We encourage you to include the issue ID (and maintain its formatting) in the subject of any further correspondence on the matter.
  2. Support reviews the issue and assigns it a Category and initial Priority. The most common initial categories are Info Request and Problem. The Priority dictates the urgency with which the TS3D support team will provide followup responses.
  3. A Developer Support Engineer works to resolve the Issue. Resolution is defined as either arriving at a point where the issue can be closed (a question was answered, feedback was provided, etc…), or moving the issue from an Info Request/Problem to a Bug or Feature.
  4. If an issue moves to a Bug or Feature, it is given a new Priority and handled via the guidelines covered below.
  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 ‘Target Release’ field located in the Issue details. (The default value for this field is ‘Unscheduled’.)

3.1 Issue Categories

  • Info Request – A request for information about product usage, distribution, licensing, etc.
  • Problem – There is some difficultly with using a TS3D component, your software is not behaving as expected, etc… If you believe that you’ve encountered a bug inside a TS3D Component, the issue must be submitted with detailed information which enables TS3D Support to reproduce the problem, such as product Version, system information, sample data, a small reproducible standalone sample program, etc…
  • Feature Request – A request for new functionality within the product, or a Problem/Bug which TS3D has determined can only addressed via new functionality.
  • Bug – The problem has been confirmed to be an error within our product. Please Note: an Issue is not considered a Bug until the Tech Soft Support group has reproduced it.
  • Docs Bug – Documentation errata.
  • 3rd Party Bug – A verified bug which is not in a Tech Soft 3D component.

3.2 Issue Statuses

  • Open- All issues begin with this designation. If the issue is not resolved immediately (i.e., interactively over the phone or by an e-mail reply within one business day) the issue remains Open, and indicates that we are working on the issue.
  • Open – 3rd Party- We are waiting on a response from a 3rd Party component provider.
  • Customer – The issue is awaiting customer feedback or activity. When we request more information/action on your part, we change the status of your issue to “Customer” until you respond.
  • Customer – On Hold – Similar to ‘Customer’ status, but either you have indicated that you are unable to provide requested information, or the issue has been in Customer status for 30 days. Issues that were automatically moved to this Status will be closed if the issue is not responded to within 15 days. This automatic closure does not apply to issues where the customer has requested additional time to work on an issue.
  • Timed Out – The issue has been in Customer status for 30 days, followed by Customer – On Hold status for 15 days, and was automatically closed.
  • Testing – The issue is a corrected Bug awaiting verification by Developer Support or the Customer, or a new Feature that is undergoing internal testing. (Bug fixes which do not have an extreme confidence may be given this status.)
  • Work Around – A confirmed workaround for a difficult problem was found, and the issue has been closed. Such issues may be reviewed for formal correction in the future.
  • Complete – Pending Release - The issue is a Bug or Feature that has been corrected/implemented, and delivery in an official release is pending.
  • Complete – The issue has been resolved, and the issue has been closed. In the case of a confirmed Bug, it has been fixed. In the case of an Info-Request, the requested information has been provided or the question answered. In the case of a Feature, the new functionality has been delivered in a release.
  • Can’t Verify – A reported problem cannot be reproduced by the Tech Soft 3D support staff, all other measures have been exhausted, and the issue has been closed.
  • Deferred – The Feature is not planned for the next Major Release, but may still be considered Strategic and/or possible to include in a future release, and could be reviewed at the start of the next Major Release’s Development Cycle.
  • Declined – We’ve determined that we are unable to consider adding the Feature to a future release, or that there are no plans to correct a P4 nuisance bug, and the issue has been closed.

3.3 Issue Priorities

The Priority value determines our targets for Info-Request/Problem Response Times, and Bug-fixes delivery times.

Info Requests / Problems

All initial inquiries are classified as either an Info Request or a Problem. Their Priority is determined by the Developer Support Engineer based on a combination of Support Level, nature/specifics of the issue, Severity, and priority relative to other Issues in the system. Response Time refers to the time it takes for Developer Support to reply to a query, or to respond to information that has been freshly provided by the customer. Please note that resolution of an issue may require several rounds of correspondence, such as question/problem understanding/clarification, assistance with arranging test cases, troubleshooting assistance, test case debugging, etc…

  • P1 – highest priority issues for the Developer Support team and targeted for 24 hour response time.
  • P2 – treated with an elevated priority and targeted for 48 hour response time.
  • P3 – default priority for all customer queries and targeted for 4 day response time.
  • P4 – very low grade importance, typically a general nuisance Problem, etc…
  • P5 – unused for Info Requests or Problems.


When Bugs are verified, they are given an initial priority by the Developer Support Engineer. This priority is based upon the descriptions below, and discussions with customer-engineers and TS3D technical staff.

  • P1 – Severe – significantly impedes development, or blocks shipping or testing. The Bug will be reviewed immediately and you will be given an indication of the Service Pack in which you may expect a fix. (P1 Bugs will typically be targeted for the next Service Pack.)
  • P2 – Major – involves behaviors such as import failure, crash, loss of data, severe memory leak or significantly incorrect rendering result. The Bug will be reviewed within the next 20 days and you will be given an indication of the Service Pack in which you may expect a fix
  • P3 – Minor – A nuisance Problem/Bug. We attempt to correct as many P3 bugs in the next Major Release as possible, based on resource availability.
  • P4 – Trivial – The Bug involves no significant loss in functionality and an easy workaround may be present. These are not scheduled to be corrected in any release and will typically be closed out.
Please Note: a Bug is not planned for correction unless the Target Release field value is set.


We receive numerous feature requests, and strive to balance them against product direction and available resources.

  • Basic Feature requests are periodically reviewed and considered for inclusion in the upcoming Major Release or a Service Pack.
  • Complex Feature requests are reviewed at the start of the next Major development period.
  • If a Feature request aligns with strategic direction/roadmap but is not planned for the next Major release or an upcoming Service Pack, it may be marked as Deferred and reviewed again during future development periods.
  • Feature requests which are not considered for implementation will be closed with the Declined status.

Please Note: a Feature is not planned for implementation unless the Target Release field value is set.

Documentation Bugs/Features

Errors in our documentation are fixed in the next official Maintenance Release. Documentation Features are reviewed and a decision made on at the start of the next major development cycle.

Third Party Bugs/Features

These are reported to the third party supplier with no further action by TS3D. If something is assigned a P1 then TS3D will encourage the Third Party to provide resolution, and notify the customer of the likelihood/timing of any resolution.

3.4 Issue Severity

When Creating an Issue, you can indicate the Severity, which will be used as an indicator to help assess the overall Priority of the Issue. We ask you to refer to the following table to determine which severity level reflects the impact to your business:

  • Stopping business and/or development operations and schedules
  • Non-functional – no workaround identified
  • Significantly affecting business and/or seriously impeding development operations and schedules – work proceeds but is restricted
  • Some/partial loss of functionality
  • Somewhat affecting business and/or development operations and schedules – work continues mostly unaffected
  • Minor loss of functionality
  • Minimally affecting business and development operations and schedules
  • No loss of functionality

Selecting the Correct Severity Level

When choosing the severity, please consider these questions:

  • Is this issue affecting one developer/end-user, or multiple people?
  • Is one dataset/model/file failing, or are multiple datasets/models/files failing?
  • Is the issue an isolated case, or far reaching and affecting many customers, developers, or projects?

Next, determine if progress can be made. Ask these questions to determine the degree to which production is stopped or impeded:

  • Is the issue preventing forward progress and production is completely stopped with no identified workaround?
  • Can some progress be made with an alternative method, but the current workaround is not sustainable and is not a long-term solution?
  • To what degree of functionality loss is being experienced – total loss in functionality, some or partial loss, minor loss, or no loss?

If you designate an issue as having a critical severity, we ask that you include a brief explanation as to why. This will help ensure that appropriate attention is applied to your critical business issue. Please note that severity will not necessarily map over to a specific priority.

4.0 Release Process

4.1 Release Fields

For issues which have a category of ‘Bug’ or ‘Feature’, there are two fields which provide information about which version of the product may contain the bug or feature:

  • Target Release: indicates the version of the product that the Bug/Feature is intended to be corrected/provided in. This is an indication of current plans, and is not guaranteed. The default value for this field is Unscheduled.
  • Completed Release: indicates the Version of the product that the Bug/Feature has been corrected/provided in. Note that if the Status is ‘Complete – Pending Release’, then the product version containing the Bug/Feature is still pending release.

4.2 Release Targets

The following outlines our targets for release frequency:

HOOPS Visualize

  • 1 Major feature release once per year
  • 2 Service Pack releases of the current and previous release streams. Service Packs releases will contain fixes to P1 bugs, along with P2 bugs that have been specifically targeted for the Service Pack. Service Pack releases of older versions are considered on a case-by-case basis, based on customer need/demand.
  • Updates to our packages are unscheduled and are released as required.

HOOPS Exchange / HOOPS Publish / HOOPS Communicator

  • 1 Major feature release per year
  • 2 Service Pack releases per year
  • Updates to our packages are unscheduled and are released as required.

5.0 Assessing Overall Issue Status/Progress

While the Status field is fairly specific, depending on the Category several other fields must be looked at to gauge the overall status. The following table provides examples of combinations of Category/Status/Release fields, and covers the vast majority of issues that reside in the system at any point in time:

Info Request Open NA NA TS3D is working on the issue
Problem Open NA NA TS3D is working on the issue
Problem Customer NA NA TS3D is awaiting further customer information
[Bug/Feature] Open Unscheduled NA Bug/Feature not targeted for correction in any release
[Bug/Feature] Open 1.24 NA Bug/Feature targeted for correction/implementation in product version 1.24
[Bug/Feature] Complete- Pending Release 1.24 1.24 Bug/Feature is complete and will be available in product version 1.24

If you are interested in further insight into progress on an Open issue, please contact support so that the issue's Assignee can directly assist.