Victoire/first structure - #1
Open
Victoire-Perrier wants to merge 42 commits into
Open
Conversation
…nctionality; data structures with nodeIds
…d update StepResult3D to use it
…for engine mount bracket
…y rendering with scalar data
… for 3D rendering container
…izing and code clarity
…, and UNV formats
…d add new sample data
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 856 changed files in this pull request and generated no new comments.
Suppressed comments (1)
README.md:1
- This change deletes the only line in
README.md, leaving the repository without any landing documentation. Given the PR’s scope (frontend + backend + native CLI demo),README.mdshould at minimum contain a proper top-level heading (without the stray|character) and brief instructions to run the demo locally (backend start, frontend start, and any required environment variables likeLD_LIBRARY_PATH). Consider replacing the removed line with a valid# hoops-accessheading and adding minimal setup/run steps rather than removing the file’s content entirely.
… hex dump display and scrollbar styling
…implify StepRawFile.jsx to always treat samples as binary
…isionGeometry functions for improved element representation
…awFile component; clean up Vite config by removing alias resolution
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 855 changed files in this pull request and generated no new comments.
Suppressed comments (2)
README.md:1
- The PR description describes adding a full backend/frontend/C++ CLI demo, but the actual change only deletes the README content. If this PR is meant to include the demo implementation, it looks like the relevant files/commits aren’t included in this diff; otherwise, the PR description should be updated to match the actual change.
README.md:1 - This change removes the README’s only content and leaves
README.mdempty, which hurts discoverability and setup guidance for the demo. Consider keeping at least a minimal README (project name + how to run backend/frontend + expected prerequisites like theaccess_clibinary and runtime.sos).
…ts in StepStructured and TreeNode components
…enhance DemoStage and StepRawFile components for file upload support
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 857 changed files in this pull request and generated 4 comments.
Suppressed comments (1)
README.md:1
- This PR deletes the only README line, leaving the repo without an entrypoint description. Since the PR introduces a multi-component demo (frontend/backend/native CLI), please add a minimal README describing how to run it locally (ports,
POST /translate, requiredLD_LIBRARY_PATHsetup / where the native binary lives) instead of removing the file contents.
| Don't assume that I know what you are talking about when talking about a concept we have never talked about before. | ||
| Explain it to me first before continuing your sentence. | ||
| Take a step back and remind me of what goal we are working on frequently. | ||
| I need the big picture and tend to loos the context if explanations go too deep. |
Comment on lines
+45
to
+55
| ## Sample files — all real, not hand-written mocks | ||
| - `sample_plate.nas` — no longer used, was hand-written, replaced by: | ||
| - Nastran: a real solved `.op2` wing-box model (binary, has real | ||
| results though only geometry is currently extracted) | ||
| - Abaqus: a real solved `.odb` file (`viewer_tutorial_2026.odb`) — | ||
| includes a single-node reference-point element (confirmed correct, | ||
| not a bug) | ||
| - Ansys: a real solved `.rst` file | ||
| - LS-DYNA and IDEAS UNV samples are still the original hand-written | ||
| ones (`sample_plate.key`, `sample_plate.unv`) — not yet replaced with | ||
| real files, unlike Nastran/Abaqus/Ansys |
Comment on lines
+18
to
+20
| package (lives outside this repo, currently at | ||
| `~/Desktop/git/HOOPS_Solve_Access_Mesh_Eval_3.1.0_c3503f96/`), by | ||
| adding `access_cli.cpp` to that package's own |
| runtime `.so` dependencies — never source code, never build tooling. | ||
| Understanding this split is essential before touching anything native. | ||
|
|
||
| **Location:** `~/Desktop/git/HOOPS_Solve_Access_Mesh_Eval_3.1.0_c3503f96/` |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Build a working HOOPS Access demo: real file upload through to a rendered 3D result.
This is the demo's first implementation. A user picks a CAE format,
the corresponding sample file is sent to a backend, which runs it
through HOOPS Access via a native CLI, and the resulting structure
(nodes, elements, parts) is rendered both as a model tree and as an
interactive 3D view.
Approach:
access_cli) built against HOOPS Access opensa CAE file, walks its mesh via Access's Model/Mesh API, and prints
the result as JSON. It's based on Tech Soft 3D's own file-translation
tutorial rather than written from scratch, since it links against
the same third-party dependency chain (HDF5, Intel MKL, METIS, the
Abaqus ODB reader) that Access itself requires. Only the compiled
binary and its runtime .so files are checked into this repo; building
it happens in Tech Soft 3D's own eval package build, not here.
backend/server.js) receives an uploadedfile, spawns
access_clion it with the correct LD_LIBRARY_PATH, andreturns its JSON output over HTTP.
backend, and uses the returned JSON to build both the model tree
(
data/buildTreeAndTable.js) and the 3D view (Envision).and Ansys were considered but dropped: generating valid sample files
in either format requires Dassault/Ansys's own solvers, or a
partnership agreement to redistribute their proprietary reader
libraries for writing output. Neither was in place. LS-DYNA and
IDEAS UNV don't have this constraint and are comparably common
formats.
Known shortcomings, left out of scope for this change:
are geometry-only; producing real result data would mean using HOOPS
Solve to actually run an analysis, which is a substantially larger
task than what's covered here.
file field that should map to Access's per-element PART_ID for this
format specifically wasn't identified.