Faster Mesh Rendering and Raycasting in 3D viewport #8106
Conversation
…peed up raycasting.
…h to optimize performance
…nto faster-caster
This reverts commit 36f5c0f.
…nto faster-caster
fm3
changed the title
|
Thanks for updating the title and PR description @fm3 :) I'll continue with restoring the 3D viewport proofreading using vertex colors once I'm back in office. I'll also have a look at the washed out colors then. |
philippotto
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (4)
17-17: Remove the unused importMeshBVHHelper.
Currently,MeshBVHHelperis never referenced in the module. Removing it addresses the static analysis hint and cleans up the code.Apply this diff to remove the unused import:
- import { MeshBVHHelper, acceleratedRaycast } from "three-mesh-bvh"; + import { acceleratedRaycast } from "three-mesh-bvh";🧰 Tools
🪛 Biome (1.9.4)
[error] 17-17: This import is unused.
Unused imports might be the result of an incomplete refactoring.
Safe fix: Remove the unused import.(lint/correctness/noUnusedImports)
19-21: Use type-only import forBufferAttribute.
SinceBufferAttributeis only used for type assertions and not instantiated directly, switching toimport typehelps reduce overhead and aligns with best practices.Apply this diff:
-import { BufferAttribute } from "three"; +import type { BufferAttribute } from "three";🧰 Tools
🪛 Biome (1.9.4)
[error] 21-21: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.(lint/style/useImportType)
152-157: Consider handling errors fromcomputeBvhAsync.
A rejection incomputeBvhAsyncwould be unhandled, potentially leaving the geometry incomplete.Wrap the call in try/catch or handle the promise rejection to ensure robust error handling:
try { bufferGeometry.boundsTree = await computeBvhAsync(bufferGeometry); } catch (err) { console.error("Failed to compute BVH", err); // fallback or additional handling }
265-267: Remove or conditionally guard debug instrumentation.
console.timeandconsole.timeEndare useful while profiling, but can clutter production logs.Either remove or wrap them with a debug flag:
- console.time("constructMesh"); const meshChunk = this.constructMesh(segmentId, layerName, geometry, isMerged); - console.timeEnd("constructMesh");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
CHANGELOG.unreleased.md(1 hunks)frontend/javascripts/oxalis/controller/segment_mesh_controller.ts(12 hunks)frontend/javascripts/oxalis/view/plane_view.ts(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/javascripts/oxalis/view/plane_view.ts
🧰 Additional context used
🪛 Biome (1.9.4)
frontend/javascripts/oxalis/controller/segment_mesh_controller.ts
[error] 17-17: This import is unused.
Unused imports might be the result of an incomplete refactoring.
Safe fix: Remove the unused import.
(lint/correctness/noUnusedImports)
[error] 21-21: All these imports are only used as types.
Importing the types with import type ensures that they are removed by the compilers and avoids loading unnecessary modules.
Safe fix: Use import type.
(lint/style/useImportType)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (2)
frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (1)
90-102: Validate the color index range.
IfindexRangeextends outside the bounds of the color attribute, the loop may attempt out-of-bounds writes. Consider clamping or validating the range before iterating.Please confirm that all call sites supply a valid index range.
CHANGELOG.unreleased.md (1)
19-19: LGTM on the update note.
The changelog entry clearly highlights the improved 3D mesh rendering and mouse interaction performance.
| getUnmappedSegmentIdForPosition(position: number) { | ||
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | ||
| return this.unmappedSegmentIds[index]; | ||
| } | ||
|
|
||
| getRangeForPosition(position: number): [number, number] { | ||
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | ||
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | ||
| } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Check for potential out-of-bounds usage.
When subtracting 1 from the sorted index, a position smaller than the first entry may yield -1, causing an invalid array access. Similar issues may occur with out-of-range indexes.
Would you verify that callers always pass valid positions? If not, consider boundary checks. For example:
getUnmappedSegmentIdForPosition(position: number) {
const idx = _.sortedIndex(this.cumulativeStartPosition, position) - 1;
+ if (idx < 0 || idx >= this.unmappedSegmentIds.length) {
+ return null;
+ }
return this.unmappedSegmentIds[idx];
}Run this script to locate all usages and confirm they enforce valid positions:
🏁 Script executed:
#!/bin/bash
rg -A5 "getUnmappedSegmentIdForPosition"
rg -A5 "getRangeForPosition"Length of output: 1978
Ensure proper boundary checks on sorted index results
The current implementations in both getUnmappedSegmentIdForPosition and getRangeForPosition subtract 1 from the result of _.sortedIndex, which may result in a negative index (or an index that exceeds the array bounds) when the passed position is out of the expected range. For instance, in plane_view.ts the method is called with face.a without pre-validating that the value lies within the valid positions. This can lead to accessing invalid array elements.
Recommendations:
- Add explicit boundary checks in
getUnmappedSegmentIdForPositionto handle cases where the computed index is negative or not withinthis.unmappedSegmentIds. - Similarly, update
getRangeForPositionto ensure bothindexandindex + 1fall within the valid boundaries ofthis.cumulativeStartPosition.
Example diff for getUnmappedSegmentIdForPosition:
getUnmappedSegmentIdForPosition(position: number) {
- const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1;
- return this.unmappedSegmentIds[index];
+ const idx = _.sortedIndex(this.cumulativeStartPosition, position) - 1;
+ if (idx < 0 || idx >= this.unmappedSegmentIds.length) {
+ return null;
+ }
+ return this.unmappedSegmentIds[idx];
}A similar check should be applied to getRangeForPosition to ensure the returned range is valid.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| getUnmappedSegmentIdForPosition(position: number) { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| return this.unmappedSegmentIds[index]; | |
| } | |
| getRangeForPosition(position: number): [number, number] { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | |
| } | |
| getUnmappedSegmentIdForPosition(position: number) { | |
| const idx = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| if (idx < 0 || idx >= this.unmappedSegmentIds.length) { | |
| return null; | |
| } | |
| return this.unmappedSegmentIds[idx]; | |
| } | |
| getRangeForPosition(position: number): [number, number] { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | |
| } |
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (1)
45-88:⚠️ Potential issueAdd boundary checks to prevent array out-of-bounds access
The
getUnmappedSegmentIdForPositionandgetRangeForPositionmethods subtract 1 from the result of_.sortedIndex, which can lead to negative indices or out-of-bounds access if the position is outside the expected range.Add boundary checks to prevent potential errors:
getUnmappedSegmentIdForPosition(position: number) { const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; + if (index < 0 || index >= this.unmappedSegmentIds.length) { + return null; + } return this.unmappedSegmentIds[index]; } getRangeForPosition(position: number): [number, number] { const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; + if (index < 0 || index >= this.cumulativeStartPosition.length - 1) { + return [0, 0]; + } return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; }
🧹 Nitpick comments (6)
frontend/javascripts/oxalis/api/wk_dev.ts (1)
196-209: Well-structured benchmark method for 3D view rotationThe
benchmarkRotatemethod is a well-implemented developer tool for measuring 3D rotation performance. It properly wraps therotate3DViewTofunction in a promise and systematically rotates through each view 10 times.Consider adding performance measurement and result reporting similar to what exists in the
benchmarkMovemethod, to provide consistent benchmarking capabilities across both methods.async benchmarkRotate() { + const start = performance.now(); + console.time("Rotate Benchmark"); const animateAsPromise = (plane: OrthoView) => { return new Promise<void>((resolve) => { rotate3DViewTo(plane, true, resolve); }); }; for (let i = 0; i < 10; i++) { + if (i > 0 && i % 2 === 0) { + console.log(`Progress: ${(i / 10) * 100}%`); + } await animateAsPromise(OrthoViews.PLANE_XY); await animateAsPromise(OrthoViews.PLANE_YZ); await animateAsPromise(OrthoViews.PLANE_XZ); await animateAsPromise(OrthoViews.TDView); } + const duration = performance.now() - start; + console.timeEnd("Rotate Benchmark"); + this.benchmarkHistory.push(duration); + if (this.benchmarkHistory.length > 1) { + console.log( + `Average of all ${this.benchmarkHistory.length} benchmark runs:`, + _.mean(this.benchmarkHistory), + ); + } }frontend/javascripts/oxalis/view/plane_view.ts (2)
25-28: Consider moving lighting settings to a dedicated configuration moduleThe lighting settings are currently defined at the file level. For better maintainability, consider moving these to a dedicated configuration module along with other visualization settings.
154-245: Performance instrumentation should be conditional in production codeThe raycasting performance measurement (lines 183-185) and console log (line 231) are useful for development but should be conditional in production code.
Consider wrapping these in a debug flag condition:
-const before = performance.now(); +const before = DEBUG_MODE ? performance.now() : 0; const intersections = raycaster.intersectObjects(intersectableObjects, true); -const after = performance.now(); +const after = DEBUG_MODE ? performance.now() : 0; // Later in the code: -console.log("raycast took", after - before, "ms"); +if (DEBUG_MODE) console.log("raycast took", after - before, "ms");frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (3)
191-198: Remove commented-out code and TODOsThere are several commented-out code sections and TODOs throughout the file (like this one) that should be addressed or removed before merging.
-// todop: would it help to set it to false once the opacity is 1 ? hopefully not... meshMaterial.transparent = true; const colorArray = color.convertSRGBToLinear().toArray() as Vector3; meshMaterial.originalColor = colorArray; -// todop: necessary? -// meshMaterial.blending = THREE.NormalBlending; -// const colorArray: readonly [number, number, number] = HOVERED_COLOR_VEC3; -// todop: can we avoid constructing this when not necessary? const colorBuffer = new Float32Array(geometry.attributes.position.count * 3);
357-432: Extensive GUI controls might impact production performanceWhile the detailed light settings GUI is excellent for development, ensure it's only enabled in development mode to avoid performance impact in production.
Consider wrapping the GUI initialization in a development-only check:
getGui() { + if (process.env.NODE_ENV === 'production') { + return null; + } if (!window.gui) { window.gui = new GUI(); } return window.gui; }Then check for null return values before using the GUI in other methods.
416-418: Avoid using @ts-ignore commentsUsing
@ts-ignorebypasses TypeScript's type safety. It's better to fix the underlying type issues.Consider creating a properly typed interface or type for the settings object:
+interface LightIntensitySettings { + [key: string]: number; +} +const settings: LightIntensitySettings = { ambientIntensity: 0.41, dirLight1Intensity: 0.54, // ... }; // Then later: const light = new THREE.DirectionalLight( WHITE, - // @ts-ignore - settings[`dirLight${index + 1}Intensity`] || 1, + settings[`dirLight${index + 1}Intensity`] || 1, );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
frontend/javascripts/oxalis/api/wk_dev.ts(2 hunks)frontend/javascripts/oxalis/controller/segment_mesh_controller.ts(12 hunks)frontend/javascripts/oxalis/model/sagas/mesh_saga.ts(7 hunks)frontend/javascripts/oxalis/view/plane_view.ts(6 hunks)webpack.config.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- frontend/javascripts/oxalis/model/sagas/mesh_saga.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (9)
webpack.config.js (1)
205-210: Enhanced warning suppression for Three.js exportsThe modification adds additional patterns to ignore warnings related to Three.js exports (
SRGBColorSpaceandLinearSRGBColorSpace), similar to the existing pattern forSTLExporter. This is a good approach to handle dynamically added exports, keeping the build clean from expected warnings.frontend/javascripts/oxalis/api/wk_dev.ts (1)
5-6: Appropriate imports for the new benchmark methodThe new imports properly support the functionality needed for the benchmarkRotate method.
frontend/javascripts/oxalis/view/plane_view.ts (4)
30-35: Good type definition for raycaster hitsThe
RaycasterHittype properly encapsulates all necessary information for raycaster hits.
37-60: Improved dynamic light configuration with GUI controlsThe updated
createDirLightfunction with GUI controls provides excellent flexibility for adjusting lighting settings during development, which is valuable for visualizing 3D meshes.
63-63: Performance optimization for raycastingSetting
raycaster.firstHitOnly = trueis a good optimization that will improve performance by stopping the raycast calculation after the first hit is found.
247-254: Good separation of concerns with clearLastMeshHitTest methodExtracting the cleanup logic to a separate method improves code organization and reusability.
frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (3)
24-26: Properly extending Three.js with accelerated raycastingAdding the accelerated raycast function to THREE.Mesh.prototype is a good approach for improving raycasting performance across the application.
152-177: Excellent async BVH computation for improved performanceRefactoring the mesh creation to use async BVH computation is an excellent improvement that will prevent UI freezing during complex mesh generation.
595-629: Good implementation of throttled highlightingThrottling the highlight method is a good performance optimization that will prevent excessive updates during rapid interactions.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
frontend/javascripts/oxalis/controller/mesh_helpers.ts (1)
13-33:⚠️ Potential issueImplement boundary checks for position index calculations.
Following up on previous review comments, the
PositionToSegmentIdconstructor logic is sound, but the methods that use the calculated indices need boundary checks to prevent potential array out-of-bounds access.The absence of boundary checks in methods like
getUnmappedSegmentIdForPositioncould lead to runtime errors if provided with invalid positions. Add defensive checks to ensure indices are valid before accessing arrays.
🧹 Nitpick comments (7)
frontend/javascripts/oxalis/api/wk_dev.ts (2)
195-211: Add performance metrics to the rotation benchmark.The new benchmarkRotate method is well-implemented with async/await and promises to handle animation completion. However, unlike the existing benchmarkMove method, it doesn't measure or log any performance metrics, which limits its utility as a benchmark.
Consider adding timing measurements and storing results in benchmarkHistory:
async benchmarkRotate() { // Dynamic import to avoid circular imports. const { rotate3DViewTo } = await import("oxalis/controller/camera_controller"); const animateAsPromise = (plane: OrthoView) => { return new Promise<void>((resolve) => { rotate3DViewTo(plane, true, resolve); }); }; + console.time("Rotation Benchmark"); + const start = performance.now(); for (let i = 0; i < 10; i++) { await animateAsPromise(OrthoViews.PLANE_XY); await animateAsPromise(OrthoViews.PLANE_YZ); await animateAsPromise(OrthoViews.PLANE_XZ); await animateAsPromise(OrthoViews.TDView); } + const duration = performance.now() - start; + console.timeEnd("Rotation Benchmark"); + this.benchmarkHistory.push(duration); + if (this.benchmarkHistory.length > 1) { + console.log( + `Average of all ${this.benchmarkHistory.length} benchmark runs:`, + _.mean(this.benchmarkHistory), + ); + } }
195-195: Add JSDoc comment for the benchmarkRotate method.The method lacks documentation unlike other methods in the class. Adding a JSDoc comment would maintain consistency and make the purpose of the method clear.
+ /* + * Benchmark rotating through all orthogonal views 10 times. + * Useful for testing animation performance in the 3D viewport. + */ async benchmarkRotate() {frontend/javascripts/oxalis/view/plane_view.ts (2)
168-170: Remove performance logging from production code.The performance measurement logging should be removed before merging to production to avoid unnecessary console output.
- const before = performance.now(); const intersections = raycaster.intersectObjects(intersectableObjects, true); - const after = performance.now();
215-215: Remove debug logging statement.This console log for raycast performance should be removed before merging to production.
- console.log("raycast took", after - before, "ms");frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (3)
137-151: Clean up commented and debug code.There are several commented code lines and TODO comments that should be addressed before finalizing this PR.
meshMaterial.transparent = true; const colorArray = color.convertSRGBToLinear().toArray() as Vector3; meshMaterial.originalColor = colorArray; - // todop: necessary? - // meshMaterial.blending = THREE.NormalBlending; - - // const colorArray: readonly [number, number, number] = HOVERED_COLOR_VEC3; - // todop: can we avoid constructing this when not necessary? const colorBuffer = new Float32Array(geometry.attributes.position.count * 3); for (let i = 0; i < geometry.attributes.position.count; i++) { colorBuffer.set(colorArray, i * 3);
211-213: Remove performance timing in production code.The console.time calls should be removed before merging to production.
- console.time("constructMesh"); const meshChunk = this.constructMesh(segmentId, layerName, geometry, isMerged); - console.timeEnd("constructMesh");
429-448: Clean up commented code from updateMeshAppearance.Remove all the commented code that is no longer needed to improve code readability.
- // todop: restore? - // const targetOpacity = mesh.hoveredState ? 0.8 : 1.0; // mesh.parent.parent contains exactly one geometry (merged from all chunks // for the current segment). const parent = mesh.parent.parent; if (parent == null) { // Satisfy TS throw new Error("Unexpected null parent"); } // We update the opacity for all meshes that belong to the current // segment ID (in contrast to the color) so that the user can // see which other super voxels belong to the segment id of the // hovered super-voxel. - // parent.traverse((child) => { - // if (child instanceof THREE.Mesh) { - // child.material.opacity = targetOpacity; - // } - // });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (7)
frontend/javascripts/oxalis/api/wk_dev.ts(2 hunks)frontend/javascripts/oxalis/controller/mesh_helpers.ts(1 hunks)frontend/javascripts/oxalis/controller/segment_mesh_controller.ts(12 hunks)frontend/javascripts/oxalis/model/sagas/mesh_saga.ts(7 hunks)frontend/javascripts/oxalis/view/plane_view.ts(6 hunks)frontend/javascripts/test/helpers/apiHelpers.ts(1 hunks)package.json(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- package.json
- frontend/javascripts/oxalis/model/sagas/mesh_saga.ts
🧰 Additional context used
🧬 Code Definitions (1)
frontend/javascripts/oxalis/api/wk_dev.ts (1)
frontend/javascripts/oxalis/controller/camera_controller.ts (1) (1)
rotate3DViewTo(217:355)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (19)
frontend/javascripts/oxalis/api/wk_dev.ts (3)
5-5: Import adjustment for new benchmark functionality.The import has been correctly modified to include the
OrthoViewtype andOrthoViewsenum needed for the new benchmarkRotate method.
197-197: Good practice using dynamic import to avoid circular dependencies.Using a dynamic import for the camera controller is an effective approach to avoid circular imports while still maintaining type safety.
199-203: Well-implemented Promise wrapper for animation callback.The animateAsPromise function elegantly wraps the rotate3DViewTo callback in a Promise, enabling sequential execution with async/await. This is a clean pattern for handling completion callbacks.
frontend/javascripts/test/helpers/apiHelpers.ts (1)
103-103: Mock added for new BVH computation dependency.The addition of this mock for the async BVH computation aligns with the testing strategy used for other dependencies in this file.
frontend/javascripts/oxalis/view/plane_view.ts (6)
23-28: Good addition of structured RaycasterHit type.This type definition improves code clarity by providing a structured way to represent raycaster hits, including segment ID mapping information.
30-44: Improved light attachment to camera.Attaching lights directly to the camera rather than to a parent object is a better approach. This ensures the lights move with the camera, providing consistent illumination as the user navigates the 3D space.
47-48: Performance optimization with firstHitOnly and faster throttling.Setting
firstHitOnly = truewill improve raycasting performance by stopping after the first hit. Reducing the throttling delay from 150ms to 50ms will make hover interactions feel more responsive, which is a good user experience improvement.
175-181: Improved segment identification in raycasting.This addition makes effective use of the new
PositionToSegmentIdclass to determine which segment was hit and extract its range, enabling more precise highlighting of individual segments within merged meshes.
185-198: Better hit detection with tool-specific behavior.The improved hit detection logic now behaves differently based on whether the proofreading tool is active, optimizing for the different interaction models required. This is a good example of conditionally applying optimization based on the use case.
231-238: Cleaner handling of last mesh hit.The extraction of mesh hit clearing into a separate method improves code organization and maintainability. This is a good refactoring that follows the single responsibility principle.
frontend/javascripts/oxalis/controller/mesh_helpers.ts (3)
4-11: Well-defined types for buffer geometries.The clear type definitions extend THREE.js's BufferGeometry with additional properties needed for the application, making the code more maintainable and type-safe.
45-51: Well-implemented segment ID range retrieval.This method properly checks for invalid segment IDs and returns null when appropriate, which is a good practice. The method correctly handles the case where the segment ID is not found in the array.
53-55: Efficient segment ID lookup using sorted index.Using
_.sortedIndexOfis an efficient way to check for the existence of a segment ID in a sorted array, which is appropriate for this use case where performance is important.frontend/javascripts/oxalis/controller/segment_mesh_controller.ts (6)
23-25: Excellent performance improvement with accelerated raycast.Using the Three.js Mesh BVH library's accelerated raycaster is a significant performance enhancement for 3D scene interaction, particularly for complex meshes with many triangles.
27-33: Good color handling with sRGB conversion.Converting colors from HSL to sRGB linear space ensures consistent color representation across different rendering contexts. The use of constants for commonly used colors also improves maintainability.
98-113: Async BVH computation improves responsiveness.Converting the mesh creation to an asynchronous process with BVH computation off the main thread is an excellent performance improvement. This prevents blocking the UI during complex mesh operations.
304-344: Improved lighting setup with configurable intensities.The revised lighting setup with well-defined light positions and intensities creates a more balanced and consistent lighting environment for 3D visualization. The use of array iteration for light creation is also more maintainable.
464-483: Clear conditional rendering logic based on highlight state.The new highlighting approach with uniform colors for full mesh highlights and vertex colors for partial highlights is well-implemented. The conditional logic makes it clear when each approach should be used.
507-536: Improved segment highlighting with vertex-level granularity.The renamed
highlightActiveUnmappedSegmentIdmethod now leverages thePositionToSegmentIdclass to enable highlighting specific portions of merged meshes, which is a significant improvement for the proofreading workflow.
| getUnmappedSegmentIdForPosition(position: number) { | ||
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | ||
| return this.unmappedSegmentIds[index]; | ||
| } |
There was a problem hiding this comment.
Add null return for invalid positions.
The getUnmappedSegmentIdForPosition method should handle cases where the calculated index is out of bounds.
getUnmappedSegmentIdForPosition(position: number) {
const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1;
+ if (index < 0 || index >= this.unmappedSegmentIds.length) {
+ return null;
+ }
return this.unmappedSegmentIds[index];
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| getUnmappedSegmentIdForPosition(position: number) { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| return this.unmappedSegmentIds[index]; | |
| } | |
| getUnmappedSegmentIdForPosition(position: number) { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| if (index < 0 || index >= this.unmappedSegmentIds.length) { | |
| return null; | |
| } | |
| return this.unmappedSegmentIds[index]; | |
| } |
| getRangeForPosition(position: number): [number, number] { | ||
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | ||
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | ||
| } |
There was a problem hiding this comment.
Add boundary checks for range calculation.
Similar to the previous issue, this method also needs boundary checks to prevent potential array out-of-bounds access.
getRangeForPosition(position: number): [number, number] {
const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1;
+ if (index < 0 || index >= this.cumulativeStartPosition.length - 1) {
+ return [0, 0];
+ }
return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]];
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| getRangeForPosition(position: number): [number, number] { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | |
| } | |
| getRangeForPosition(position: number): [number, number] { | |
| const index = _.sortedIndex(this.cumulativeStartPosition, position) - 1; | |
| if (index < 0 || index >= this.cumulativeStartPosition.length - 1) { | |
| return [0, 0]; | |
| } | |
| return [this.cumulativeStartPosition[index], this.cumulativeStartPosition[index + 1]]; | |
| } |
There was a problem hiding this comment.
Ok this wasn't very easy to get my head around. But what I understood now is that you optimized the "chunked meshes" in proofreading mode away so that a mesh has no sub meshes anymore and instead the selective "sub mesh highlighting" is done via the vertex coloring feature (assigning the correct vertices a different color to highlight the sub mesh)? Is that correct?
This was also necessary nessecity as the PR description states, correct?
Please find my code review comments below :D
| @@ -191,4 +191,22 @@ export default class WkDev { | |||
| ); | |||
| } | |||
| } | |||
|
|
|||
| async benchmarkRotate() { | |||
There was a problem hiding this comment.
benchmark sounds like time measurement is involved here. But I cannot find any runtime measuring. Is this maybe missing here?
| } | ||
| cumsum += bufferGeometry.attributes.position.count; | ||
| } | ||
| this.cumulativeStartPosition.push(cumsum); |
There was a problem hiding this comment.
To me this reads like the last entry could be duplicated in case the last bufferGeometry has also a new unmapped segment id. Does this matter here? (Just a thought as I do not full understand the purpose of this class yet.)
There was a problem hiding this comment.
So this behaviour is actually useful for getRangeForPosition to not return something out of range with this.cumulativeStartPosition[index + 1]?
There was a problem hiding this comment.
last entry could be duplicated in case the last bufferGeometry has also a new unmapped segment id.
a strict duplicate should never happen, because even if isNewSegmentId is true in the last iteration, cumsum will still be incremented by the position count. I think, this is the typical way of maintaining an offsets table (the last entry is usually the index at which new data could be appended or where existing data ends).
So this behaviour is actually useful for getRangeForPosition to not return something out of range with this.cumulativeStartPosition[index + 1]?
yes, that's true.
| ): MeshSceneNode { | ||
| const color = this.getColorObjectForSegment(segmentId, layerName); | ||
| const meshMaterial = new THREE.MeshLambertMaterial({ | ||
| color, | ||
| }); | ||
| // color, |
There was a problem hiding this comment.
why is color commented out here?
| meshMaterial.side = THREE.FrontSide; | ||
| // todop: would it help to set it to false once the opacity is 1 ? hopefully not... |
frontend/javascripts/oxalis/view/right-border-tabs/segments_tab/segments_view.tsx
Show resolved
Hide resolved
frontend/javascripts/oxalis/view/right-border-tabs/trees_tab/skeleton_tab_view.tsx
Show resolved
Hide resolved
| // todop: remove again | ||
| gui: any; |
There was a problem hiding this comment.
jup, ai is correct :)
| const before = performance.now(); | ||
| const intersections = raycaster.intersectObjects(intersectableObjects, true); | ||
| const after = performance.now(); |
There was a problem hiding this comment.
I'd say the performance measurement should be removed after this pr
|
|
||
| // Highlight new hit | ||
| if (hitObject?.parent != null) { | ||
| segmentMeshController.updateMeshAppearance(hitObject, true); | ||
| console.log("raycast took", after - before, "ms"); |
There was a problem hiding this comment.
and also remove this :D
|
During testing I noticed that it is possible to hover a mesh even when the rendered viewports are in the way (my mouse is not rendered in the screenshot :/): But some testing showed me that this is also the case on the master. Do you think it makes sense to make the rendered viewport planes "blocking" the raycasting in case they are configured? Would be a candidate for a new issue imo. Besides this, I noticed that rendering precomputed meshes is broken in the current state. They shortly flicker into being rendered for a few frames when loaded and afterwards they are no longer rendered 👻 |
Initially started in a Hackathon project in 2024.
URL of deployed dev instance (used for testing):
Steps to test:
TODOs:
Issues:
(Please delete unneeded items, merge only when none are left open)