Release notes

Changes

4.0.7 changelogs (#5857)
3.7.12 & 3.7.13 Changelogs (#5866)
Bringing devtoolModuleFilenameTemplate in line with webpack documentation. (backport #5845) [release/4.1.x] (#5873)
Code trim behaviors (#5861)
remove new APIs from backport
Revert "remove new APIs from backport"
internalize new api
rush change
re-extract api
Update common/changes/@itwin/core-backend/mergify-bp-release-4.1.x-pr-5861_2023-08-17-16-46.json
Fix OOM in linux CI due to vite memory usage (#5852)
cherry-pick VITE_CI part of #5870 to prevent OOM
fix using old CI variable that doesn't exist in az pipelines
update new addon
rush update
Code trim behaviors (backport #5861) [release/4.1.x] (#5882)

Full changelog: 4.1.0...4.1.1

4.1.0 Change Notes

Table of contents:

Snapping within view attachments
Display
Presentation
- Renderer, editor and category on calculated properties
- Class property categories under custom categories
Electron 25 support
Geometry
Map Layers
- Map Feature Info
- ArcGIS Feature uniqueValueRenderer support
API deprecations
- Geometry

Snapping within view attachments

SheetViewDefinitions can include the contents of other views by way of ViewAttachments. It has always been possible to locate and interact with elements inside of a view attachment, but now you can also snap to their geometry while doing so. This is useful, for example, for measuring distances between elements inside of the attachment. Additionally, when locating elements on a sheet - whether or not snapping is enabled - information about the view attachment is included.

When a locate operation identifies an element inside of a view attachment, the attachment's element Id can be obtained via HitDetail.viewAttachment. If you are using Viewport.readPixels, the Id will be included in Pixel.Data. All world coordinates (e.g., HitDetail.hitPoint) will be in the sheet model's coordinate space. You can pass the attachment Id to ViewState.computeDisplayTransform to obtain the Transform from the view attachment's coordinate space to the sheet.

Note: most view attachments are two-dimensional drawings or orthographic spatial views. Attachments of perspective (camera) views do not support locating elements inside them, nor snapping to them.

Display

Tile decoding in workers

Producing a responsive web app requires limiting the amount of JavaScript code executing on the main thread. To that end, we have moved decoding of tile content to a worker. This helps to reduce stutter when loading a large number of tiles. We plan to move more code to workers in upcoming releases.

Smaller edge encoding

When rendering the contents of a view with edge display enabled, special tiles are requested that encode the edge geometry in addition to the surfaces. A tile containing edges can be many times bigger than the same tile containing only surfaces. iTwin.js 4.1 introduces a new encoding scheme that reduces that size difference by an order of magnitude. Previously, the average tile containing edges weighed 73% more than the corresponding tile without edges; now, the average difference is only 6.7%. This reduces tile transmission times and memory usage when edge display is enabled.

glTF point clouds

The newest evolution of the 3D Tiles specification introduces a streamlined way to represent point clouds using glTF, deprecating the previous "PNTS" tile format. As part of our efforts to align the iTwin platform with open web standards, iTwin.js now supports decoding and displaying point clouds encoded this way.

Presentation

Renderer, editor and category on calculated properties

Previously, the calculated properties specification only allowed specifying property label and value. Now the specification has an ability to assign renderer, editor and category to calculated properties.

Class property categories under custom categories

Now when moving property into a different category using categoryId, IdCategoryIdentifier has a new attribute createClassCategory which specifies whether an additional class category should be created under the category pointed to by the IdCategoryIdentifier.categoryId or not. See property categorization for more details.

Electron 25 support

In addition to already supported Electron versions, iTwin.js now supports Electron 25.

Geometry

Sweeping a section to a sequence of planes

A new method CurveFactory.createMiteredSweepSections moves a section "along" a polyline path; at each vertex the section projects to the plane containing the inbound and outbound edges' bisector.

Here are two examples of sections moving along a (red) path. The first section is a stepped polyline with rounded corners. The second section is a "stadium" shape.

Here are those result sections assembled into RuledSweep solids and then faceted as meshes, illustrating optional output controlled by MiteredSweepOptions.outputSelect.

New constructors

Vector3d.createNormalizedStartEnd returns (if possible) a unit vector from start to end, with start and end given as XYAndZ.
Matrix3d.createFlattenAlongVectorToPlane returns a matrix which sweeps vectors along the given sweep direction to a plane through the origin with given normal.
Transform.createFlattenAlongVectorToPlane returns a transform which sweeps points along the given sweep direction to a plane with given origin and normal.
PolylineOps.createBisectorPlanesForDistinctPoints For each point on a polyline, constructs a plane which bisects the angle between inbound and outbound segments.

Swept surface constructions

The constructors for swept surfaces (LinearSweep, RotationalSweep, RuledSweep) now allow CurvePrimitive input. Internally, the curve is promoted to a CurveChain with one member.

Sweeping a linestring to facets

New method PolyfaceQuery.sweepLineStringToFacets provides new options to specify (a) sweep direction other than vertical, (b) limiting output to forward facing, side facing, and/or rear facing facets, and (c) assembly of output segments into chains.

In the first example, a mesh with an upward facing main surface has smaller vertical sides and a small downward facing flange at the bottom of the side right face. The red linestring is above the mesh. The red linestring is swept downward (along dashed lines), intersecting the mesh. On the left all cut lines are gathered as a single output (orange). On the right the forward, side, and rear facing parts are separated as green, blue, and magenta.

In the second example, the same red linestring is swept to the same facets but along a non-vertical direction.

New method PolyfaceQuery.sweepLineStringToFacetsXY performs the same sweep along the z-axis, optimized around a 2D range search object which the caller supplies. The search object must support the queries in the interface Range2dSearchInterface and be constructed from facet ranges tagged with Polyface read index.

Map Layers

Map Feature Info

The [Viewport.getMapFeatu...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release notes

Changes

Release notes

Changes

Release notes

Changes

Release notes

Changes

Release notes

Changes

Release notes

Changes

4.1.0 Change Notes

Snapping within view attachments