Change History › 5.1.0
Edit this page

5.1.0 Change Notes

Table of contents:

Electron 36 and 37 support

In addition to already supported Electron versions, iTwin.js now supports Electron 36 and Electron 37.

Google Photorealistic 3D Tiles support

iTwin.js now supports displaying Google Photorealistic 3D Tiles via the new Google3dTilesProvider. See this article for more details.

Google Photorealistic 3D Tiles - Exton

Google Photorealistic 3D Tiles - Philadelphia

Station formatting enhancements

Available in @itwin/core-quantity, station formatting now supports a new stationBaseFactor property in FormatProps to provide greater flexibility in station offset calculations. This property works in conjunction with the existing stationOffsetSize property to determine the effective station offset using the formula: effective offset = stationBaseFactor * 10^stationOffsetSize.

The stationBaseFactor property allows for non-standard station intervals that aren't simple powers of 10. The default value is 1, which maintains backward compatibility with existing station formats.

Note: The stationBaseFactor property is currently implemented as an iTwin.js-specific extension and is not supported in the native EC (Entity Context) layer. This feature will eventually be incorporated into the ECFormat specification to provide broader compatibility across the iTwin ecosystem.

Examples

stationOffsetSize stationBaseFactor Value Effective Offset Formatted
2 1 1055.5 100 10+55.50
2 5 1055.5 500 2+55.50
3 2 1055.5 2000 0+1055.50

This enhancement enables more flexible station formatting for applications that require custom station intervals, such as specialized surveying or engineering workflows.

Coordinate KindOfQuantity support

The QuantityFormatter now supports the AecUnits.LENGTH_COORDINATE KindOfQuantity for coordinate formatting. This provides better schema integration and consistency with other iTwin applications when formatting coordinate values.

The default QuantityTypeFormatsProvider has been updated to include format properties for AecUnits.LENGTH_COORDINATE, ensuring coordinate formatting is available out of the box without requiring additional schema configuration.

Previously, coordinate formatting was only available through QuantityType.Coordinate. With this enhancement, applications can now use the KindOfQuantity-based approach:

// Using KindOfQuantity for coordinate formatting const formatSpec = IModelApp.quantityFormatter.getSpecsByName("AecUnits.LENGTH_COORDINATE"); if (formatSpec) { const formattedCoordinate = IModelApp.quantityFormatter.formatQuantity(coordinateValue, formatSpec.formatterSpec); }

This change aligns with the broader migration from QuantityType enum values to KindOfQuantity-based formatting, providing:

  • Schema-based format definitions that can be customized per iModel
  • Consistent formatting behavior across iTwin applications
  • Better integration with the FormatsProvider system

For migration guidance, see the Quantity Formatting documentation.

Text changes and styling

Persisting text

TextAnnotation2d and TextAnnotation3d now use the new BIS property textAnnotationData to persist the TextAnnotation instead of storing it in the jsonProperties. You should still use setAnnotation and getAnnotation to interact with the persisted TextAnnotation.

Drawing scale

Producing geometry for a TextAnnotation inside of a Drawing now automatically scales the text by the Drawing.scaleFactor.

Styling text

AnnotationTextStyle is a new class enabling TextStyleSettings to be persisted in the iModel. It replaces the TextStyle class which is now removed.

TextBlocks, Paragraphs, and Runs no longer refer to a persisted style by name. Instead, TextBlocks refer to an AnnotationTextStyle by ID. Paragraphs and Runs can only provide style overrides.

TextFrameStyleProps and TextLeaderStyleProps are now part of TextStyleSettingss. TextAnnotationLeaders can only specify style overrides.

Text styling is now inherited by child TextBlockComponents. That means each style property overridden or inherited by the parent is also applied to the child, unless the child explicitly provides its own override for that property. TextAnnotationLeaders are a special case. They are children of TextAnnotations. So are TextBlocks. Leaders inherit their default styling from the AnnotationTextStyle specified by their sibling TextBlock. Use the TextStyleResolver class to resolve the effective style of TextBlockComponents and Leaders, taking into account overrides/style of the instance and its parent(s)/sibling.

API deprecations

@itwin/presentation-common

  • UnitSystemFormat, FormatsMap and KoqPropertyValueFormatter constructor using the latter type have been deprecated. Instead, the constructor overload with "props" object should be used. The props object allows passing an optional FormatsProvider to use for finding formatting props for different types of values. When not specified, the SchemaFormatsProvider is used by default, so the behavior stays the same as before. Ideally, it's expected that frontend apps will pass IModelApp.formatsProvider for this prop.

@itwin/presentation-backend

  • The PresentationManagerProps.schemaContextProvider property has been deprecated. Starting with 5.0 release, SchemaContext is always available on IModelDb, so this prop is no longer needed. If supplied, it will still be preferred over the iModel's schema context, until the property is removed completely in a future release.
  • The PresentationManagerProps.defaultFormats property has been deprecated in favor of the new formatsProvider property.

@itwin/presentation-frontend

  • The PresentationManagerProps.schemaContextProvider property has been deprecated. Starting with 5.0 release, SchemaContext is always available on IModelConnection, so this prop is no longer needed. If supplied, it will still be preferred over the iModel's schema context, until the property is removed completely in a future release.
  • The PresentationManagerProps.defaultFormats property has been deprecated in favor of the FormatsProvider now being available on IModelApp.formatsProvider.

Schedule Script Editing Mode

DisplayStyle3dState now offers an interactive editing mode for RenderSchedule.Scripts, allowing interactive, dynamic modification of the style's schedule script with immediate visual feedback. Previously, every modification of the script would trigger a refresh of all of the graphics; the new mode instead draws temporary graphics just for the elements affected by the script changes.

Use DisplayStyle3dState.setScheduleEditing to enter this mode, or to update the script again after entering the mode. Once all edits are complete, call DisplayStyle3dState.commitScheduleEditing to finalize the changes a trigger a full refresh of the graphics. Example:

/** Applies color and visibility changes to a specified element using interactive * schedule script editing. * Note that a real workflow would involve user interaction between each call to `setScheduleEditing`. */ export function editElementTimeline(vp: Viewport, elementId: Id64String, modelId: Id64String): void { const builder = new RenderSchedule.ScriptBuilder(); const now = Date.now(); const modelTimeline = builder.addModelTimeline(modelId); const elementTimeline = modelTimeline.addElementTimeline([elementId]); // Change color over time elementTimeline.addColor(now, new RgbColor(255, 0, 0)); elementTimeline.addColor(now + 3000, new RgbColor(0, 255, 0)); // Enter interactive script editing mode let script = RenderSchedule.Script.fromJSON(builder.finish()); assert(script !== undefined); vp.displayStyle.setScheduleEditing(script); // Change visibility over time elementTimeline.addVisibility(now, 0); // fully transparent elementTimeline.addVisibility(now + 3000, 100); // fully visible // Update the script under construction script = RenderSchedule.Script.fromJSON(builder.finish()); assert(script !== undefined); vp.displayStyle.setScheduleEditing(script); // ...make some other changes to the script if desired... // Commit changes, triggering full graphical refresh. vp.displayStyle.commitScheduleEditing(); }

Last Updated: 08 August, 2025