Programming language

REDsdk is a C++ API. Therefore, REDsdk gets used after inclusion of header files that are all located in the 'REDsdk.m' module of REDsdk under the product installation filetree:

Location of the REDsdk 4.0 header files under the installation filetree

There are two categories of objects in REDsdk:

  1. Atomic classes, such as: RED::Matrix, RED::StateShader or RED::String.
  2. Interfaces, such as RED::IShape, RED::ISoftLight or RED::IDataManager.

Atomic classes are generally used a method parameters and can generally be created on the stack and destroyed after use. For example:

// Example of a matrix created locally to the method, and used in a method:
{
  RED::Matrix matrix;
  matrix.SetTranslation( RED::Vector3( 1.0f, 10.0f, 100.0f ) );

  // As an example, set the matrix as a transform node pivot matrix. 'itransform' is a RED::ITransformShape
  // interface, 'iresmgr' is our cluster's resource manager interface:
  RC_TEST( itransform->SetPivotAxis( matrix, iresmgr->GetState() ) );

  // On exiting this code block, 'matrix' is released from memory.
}

Interfaces are accessed from REDsdk objects. Many API methods are manipulating RED::Object pointers. These objects are often returned by REDsdk creation methods (such as the RED::Factory::CreateInstance call). Given the object, it generally implements a set of services that can be accessed through interfaces:

task

Task: Accessing to RED object interfaces

From the user point of view, all the RED objects created through the RED::Factory and passed to the REDsdk API are of the class RED::Object. This base class implements a very small set of methods which mainly consists of the dynamic casting mechanism. The casting mechanism enables the user to retrieve sets of methods, called interfaces, from those base objects.

Hence, here is the example of the creation of a viewpoint:

RED::Object* viewpoint = RED::Factory::CreateInstance( CID_REDViewpoint );
RED::IViewpoint* iviewpoint = viewpoint->As< RED::IViewpoint >();

The list of valid CIDs can be found in REDCID.h. Another example with a light source:

RED::Object* light = RED::Factory::CreateInstance( CID_REDLightShape );
RED::ILightShape* ilight = light->As< RED::ILightShape >();

Some objects may implement several interfaces. For example, the light source created above also implements the RED::IShape interface:

RED::IShape* ishape = light->As< RED::IShape >();

These interfaces allow a smooth evolution of the REDsdk services at a minimal change cost for the calling applications over the successive API versions.

Cross platform compilation

REDsdk builds on Windows x86 and x64; Linux x86 and x64 and MacOSX x64. Some #define statements are required to ensure a proper compilation of REDsdk under each platform:

Please make sure that the right set of #define values are activated for each platform. If these statements are not properly defines, REDsdk *may* compile in your software, but run-time errors will probably crash your application, due to incorrect virtual tables or wrong objects byte sizes.

Linking with REDsdk

To link REDsdk with an application, please refer to the Deployment page.

Coding principles

The REDsdk API is quite small and compact. This is by design choice. We have tried to follow a few rules in the definition of the API and in the names of API parameters:

RED_RC MyMethod( RED::Object*& oParameterOutput, unsigned int iParameterInput );

API evolutions

The REDsdk API is not frozen. This means that each new version of REDsdk will deliver new APIs needed to use the new features that were implemented by the REDWAY3D team. Besides that, the REDWAY3D team may change existing APIs over the time. This may require some changes in the REDsdk client applications. Our objective is to keep the REDsdk API clear and usable to all. Therefore, there's no API deprecation in REDsdk: we do remove a method if it has become useless or if it's replaced by a newer more efficient other service.

In all cases, we publish a REDsdk migration guide to follow to successfully migrate from a REDsdk version to another one. On average, it takes one or two hours for an application to change the REDsdk version it's using, from a pure compilation standpoint.

From a functional perspective, we believe now that REDsdk has reached a high product maturity with the release of REDsdk 4.0:

previous pageGetting supportDeploymentnext page