Skip to content

Conversation

@Leguark
Copy link
Member

@Leguark Leguark commented Mar 23, 2025

Description

Improved the marching cubes implementation for mesh extraction with proper masking support. The changes include:

  1. Added proper masking for lithological groups vs fault groups
  2. Fixed scalar field value assignment to structural elements
  3. Implemented helper functions to generate masking arrays and set scalar field values
  4. Modified the mesh extraction process to correctly handle masks during marching cubes
  5. Updated test resolution for better visualization

Relates to mesh extraction functionality

Checklist

  • My code uses type hinting for function and method arguments and return values.
  • I have created tests which cover my code.
  • The test code either 1. demonstrates at least one valuable use case (e.g. integration tests)
    or 2. verifies that outputs are as expected for given inputs (e.g. unit tests).
  • New tests pass locally with my changes.

@Leguark Leguark changed the title [WIP] Adding next todo [WIP] Adding masking to marching cubes Mar 23, 2025
@Leguark Leguark changed the base branch from integrate_mc to graphite-base/1006 March 23, 2025 08:12
@Leguark Leguark force-pushed the graphite-base/1006 branch from dc284ad to 901dbed Compare March 23, 2025 08:19
@graphite-app graphite-app bot changed the base branch from graphite-base/1006 to main March 23, 2025 08:20
@Leguark Leguark added the gempy 3 Will come with the next major update label Mar 23, 2025 — with Graphite App
@javoha
Copy link
Member

javoha commented Mar 24, 2025

Hi,
not sure if this is now the right place, but: the current test for MC in main does not actually work properly. Here an image of the result (with slightly increased resolution).

image

I see two problems:

  1. While surfaces have the right shape, they are shifted.
  2. There is a surface missing, probably because there are two surfaces in that group.

I will take a look and see if I can find the problems. Does it make sense to do this in this pull request now or should I open a new one @Leguark?

EDIT: Problem was that the correct sclar values per element were not passed (or stored). I fixed it but put some ToDos because it should probably be done somewhere else.

@javoha javoha mentioned this pull request Mar 26, 2025
4 tasks
Copy link
Member Author

Leguark commented Mar 27, 2025

added it here or in another pr if it is completely independent on the marching cubes code

@javoha
Copy link
Member

javoha commented Mar 27, 2025

added it here or in another pr if it is completely independent on the marching cubes code

I already added a solution for creating the correct MC surfaces. Probably the solution is not in the right place for a final merge, but it does work.

I was not able to create the correct mask yet, though I added some ideas and suggestions.

@javoha
Copy link
Member

javoha commented Apr 8, 2025

Hi,

so I got a working solution now. But I basically did everything "manually" (getting the rigth scalar field values and scalar fields, creating new masks and going through the groups/elements in the right order). @Leguark maybe you can take a look and check where you can simplify and move things for clarity.

image

@Leguark Leguark changed the title [WIP] Adding masking to marching cubes [ENH] Improve marching cubes mesh extraction with masking support May 1, 2025
@Leguark Leguark marked this pull request as ready for review May 1, 2025 13:30
@Leguark Leguark changed the title [ENH] Improve marching cubes mesh extraction with masking support [ENH] Improve marching cubes mesh extraction with masking support | GEN-12031 May 2, 2025
Copy link
Member Author

Leguark commented May 2, 2025

Merge activity

  • May 2, 5:28 AM EDT: A user started a stack merge that includes this pull request via Graphite.
  • May 2, 5:28 AM EDT: @Leguark merged this pull request with Graphite.

@Leguark Leguark merged commit 96bc2bf into main May 2, 2025
2 checks passed
Leguark added a commit that referenced this pull request May 2, 2025
# Description
Since the release of gempy v3 we noticed some outliers in the lithology block. These are basically single cells that have a wrong element ID in the lithology block. They generally appear close to surface boundaries and are appearing depending on resolution. This might be caused when mapping sclar field values to int for the lithology block.
As I don't think the isse is related to Octrees or DC I opened a new pull request. This issue will cause problems when reintroducing MC as a meshing approach in #1000 and #1006 .

For now I added a single example as a test (see screenshot). I will add more examples whe I come across them and have time.

![image](https://github.com/user-attachments/assets/5703b874-c566-4f7a-9771-bdaa2db7e2de)

# Checklist
- [ ] My code uses type hinting for function and method arguments and return values.
- [x] I have created tests which cover my code.
- [x] The test code either 1. demonstrates at least one valuable use case (e.g. integration tests) 
or 2. verifies that outputs are as expected for given inputs (e.g. unit tests).
- [ ] New tests pass locally with my changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gempy 3 Will come with the next major update

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants