[3D] add support for gl_clipdistance (part 1) #57899

ptitjano · 2024-06-26T15:24:17Z

Description

This PR adds support for gl_clipdistance as suggested by @wonder-sk in #57593 (review)
This allows to properly cut objects which are outside of the 3d scene extent. Contrary to #57593 it does not contain the rotation part. It will be added in a following PR. This is still useful in the general case to propery cut the objects at the border of the scene:

without gl_clipdistance

with gl_clipdistance

The PR itself is quite simple. 3 changes are needed:

Add 4 Qt3DRender::QClipPlane in the framegraph to add gl_clipDistance support
For each material:
-call Qgs3DUtils::addBoundingBoxParametersToEffect to define the plane equation as uniform for the equation
compute gl_clipistance in each vertex or geometry shader by calling setClipDistance (see shaders/clipplane.inc)

The other changes provide some cleanup in the materials to limit the number of shader files and reduce the maintenance burden.

This should work for all the data sources (raster, vector, mesh, pointcloud, etc..)

Update October 8, 2024

This PR has been completely rewritten based on @wonder-sk feedback in #57899 (comment)

This PR introduces the necessary APIs to add support for clipping (gl_ClipDistance). The main logic is handled in Qgs3DMapScene:

- enableClipping() to enable opengl clipping
- disableClipping() to disable opengl clipping

The `enableClipping()` function achieves 3 things:
- it stores the clipping plane equations
- it adds clip planes to the framegraph
- it enables the clipping on the material of the existing entities

`disableClipping()` does the opposite things.

The clip planes equations need to be stored to handle the dynamic
addition of new entities. Indeed, when a new entity is added, clipping
needs to be enabled on its material if necessary. This is achieved
in `finalizeNewEntity` which is called on all new entities.
However, this is not true for the terrain entity. That's why,
`mTerrain` now listens to the `newEntityCreated` signal to call
`handleClippingOnEntity()`.

All the end user Material now inherit from a new QgsMaterial class. This allows to enable/disable on all the entities of a scene.

I have added unit tests to ensure that clipping works for all the existing types handled by QGIS 3D.

github-actions · 2024-06-26T15:47:47Z

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 0bb1e81)

github-actions · 2024-06-26T16:29:08Z

Tests failed for Qt 6

One or more tests failed using the build from commit 162308c

pointcloud_3d_singlecolor_clipping (testPointCloudSingleColorClipping)

pointcloud_3d_singlecolor_clipping

Test failed at testPointCloudSingleColorClipping at tests/src/3d/testqgspointcloud3drendering.cpp:319

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_singlecolor_clipping/expected_pointcloud_3d_singlecolor_clipping.png (found 10028 pixels different)

The full test report (included comparison of rendered vs expected images) can be found here.

Further documentation on the QGIS test infrastructure can be found in the Developer's Guide.

github-actions · 2024-06-26T16:29:09Z

Tests failed for Qt 5

One or more tests failed using the build from commit b3e8f7e

pointcloud_3d_singlecolor (testPointCloudSingleColor)

pointcloud_3d_singlecolor

Test failed at testPointCloudSingleColor at tests/src/3d/testqgspointcloud3drendering.cpp:276

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_singlecolor/default/expected_pointcloud_3d_singlecolor.png (found 20813 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_singlecolor/qt6/expected_pointcloud_3d_singlecolor.png (found 20847 pixels different)

pointcloud_3d_colorramp (testPointCloudAttributeByRamp)

pointcloud_3d_colorramp

Test failed at testPointCloudAttributeByRamp at tests/src/3d/testqgspointcloud3drendering.cpp:316

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_colorramp/default/expected_pointcloud_3d_colorramp.png (found 20813 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_colorramp/qt6/expected_pointcloud_3d_colorramp.png (found 20847 pixels different)

pointcloud_3d_classification (testPointCloudClassification)

pointcloud_3d_classification

Test failed at testPointCloudClassification at tests/src/3d/testqgspointcloud3drendering.cpp:353

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_classification/default/expected_pointcloud_3d_classification.png (found 20813 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_classification/qt6/expected_pointcloud_3d_classification.png (found 20847 pixels different)

pointcloud_3d_classification_pointsizes (testPointCloudClassificationOverridePointSizes)

pointcloud_3d_classification_pointsizes

Test failed at testPointCloudClassificationOverridePointSizes at tests/src/3d/testqgspointcloud3drendering.cpp:392

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_classification_pointsizes/default/expected_pointcloud_3d_classification_pointsizes.png (found 10637 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_classification_pointsizes/qt6/expected_pointcloud_3d_classification_pointsizes.png (found 10646 pixels different)

pointcloud_3d_filtered_classification (testPointCloudFilteredClassification)

pointcloud_3d_filtered_classification

Test failed at testPointCloudFilteredClassification at tests/src/3d/testqgspointcloud3drendering.cpp:430

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_filtered_classification/default/expected_pointcloud_3d_filtered_classification.png (found 15117 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_filtered_classification/qt6/expected_pointcloud_3d_filtered_classification.png (found 15133 pixels different)

pointcloud_3d_filtered_scene_extent (testPointCloudFilteredSceneExtent)

pointcloud_3d_filtered_scene_extent

Test failed at testPointCloudFilteredSceneExtent at tests/src/3d/testqgspointcloud3drendering.cpp:472

Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_filtered_scene_extent/default/expected_pointcloud_3d_filtered_scene_extent.png (found 473 pixels different)
Rendered image did not match tests/testdata/control_images/3d/expected_pointcloud_3d_filtered_scene_extent/qt6/expected_pointcloud_3d_filtered_scene_extent.png (found 1521 pixels different)

The full test report (included comparison of rendered vs expected images) can be found here.

Further documentation on the QGIS test infrastructure can be found in the Developer's Guide.

src/3d/materials/qgsabstractmaterialsettings.h

benoitdm-oslandia

Needs minor comment changes, but LGTM.

src/3d/qgs3dutils.cpp

src/3d/shaders/lines.geom

wonder-sk · 2024-07-15T09:42:03Z

hi @ptitjano - sorry for taking so long to review this PR (holiday season is in full swing!)

Thanks a lot for your efforts, going the route of clipping planes!

It would be great to split this kind of work into smaller bits, it would make the review easier (e.g. one PR for addition of new materials, one PR for phong shaders refactoring, one PR for addition of clipping planes).

As for the code changes:

I like that all materials we use are now contained in the QGIS code, and we can customize them further as needed
good to see the phong "constant" and "data-defined" shaders merged together using #ifdefs
addition of QgsDiffuseSpecularMaterial
- why is it still discarding fragments if alpha is not 1.0 ? is it still needed?
- my understanding is that it is now used only for terrain, but there are also very similar materials created in QgsPhongMaterialSettings and QgsPhongTexturedMaterialSettings - and I strongly feel those materials should be also covered by the newly created QgsDiffuseSpecularMaterial class, given they have pretty much the same use case
- it is quite confusing in addition to the existing diffuseSpecular.frag, this material adds diffusespecular.frag with different implementation - this should be cleaned up
clipping planes implementation
- clipping should be an optional feature, not something that is enabled all the time - materials should apply clipping only when it is requested
- clipping should not be tied to extent() of Qgs3DMapSettings - that is really limiting to how it can be used. There should be a getter/setter in Qgs3DMapSettings to get/set clipping planes (in world coordinates), independent from the extent() - whenever extent() gets changed, we need to do reloading of data, but we should be able to modify clipping planes just by a much "lighter" approach, where the existing materials will only update their uniforms, without heavy rebuilding of the whole scene.
- I agree with Nyall that the introduction of Qgs3DMapSettings in toMaterial() is not a good design choice. In addition to the worry about use of QObject in threads:
  - materials should not need to know about the whole 3d map settings
  - materials should not have clipping planes fixed at the time the material is created - that should be configurable during the lifetime of the material object (just like e.g. diffuse color property of a material)
  - addition of it heavily pollutes many places in the 3D code and adds access to 3D map settings where it should not be available
- what would make sense to me is that:
  1. there would be some kind of base material class derived from QMaterial, that adds function like setClippingPlanes(QVector planes)
  2. all "our" materials derive from it, and respect the clipping planes
  3. at any time, material's clipping planes could be changed, to update the clipping setup
  4. there is some convenience utility function e.g. in Qgs3DUtils that can generate clipping planes (e.g. take a 2D/3D extent and return the planes)

I think the Phong material implementation needs to be cleaned up and clipping planes implementation needs to be updated before we can merge this...

github-actions · 2024-07-30T02:40:56Z

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

that all unit tests are passing
that all comments by reviewers have been addressed
that there is enough information for reviewers, in particular
- link to any issues which this pull request fixes
- add a description of workflows which this pull request fixes
- add screenshots if applicable
that you have written unit tests where possible
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
If there is no further activity on this pull request, it will be closed in a week.

github-actions · 2024-08-20T02:41:55Z

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

that all unit tests are passing
that all comments by reviewers have been addressed
that there is enough information for reviewers, in particular
- link to any issues which this pull request fixes
- add a description of workflows which this pull request fixes
- add screenshots if applicable
that you have written unit tests where possible
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
If there is no further activity on this pull request, it will be closed in a week.

github-actions · 2024-09-04T02:45:16Z

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

that all unit tests are passing
that all comments by reviewers have been addressed
that there is enough information for reviewers, in particular
- link to any issues which this pull request fixes
- add a description of workflows which this pull request fixes
- add screenshots if applicable
that you have written unit tests where possible
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
If there is no further activity on this pull request, it will be closed in a week.

This is achieved by calling `setClipDistance` in the vertex shader if the clipping is enabled.

This is achieved by calling `setClipDistance` in the geometry shader if the clipping is enabled.

This adds two functions to setup clip planes on a 3d scene: - enableClipping() to enable opengl clipping - disableClipping() to disable opengl clipping The `enableClipping()` function achieves 3 things: - it stores the clipping plane equations - it adds clip planes to the framegraph - it enables the clipping on the material of the existing entities `disableClipping()` does the opposite things. The clip planes equations need to be stored to handle the dynamic addition of new entities. Indeed, when a new entity is added, clipping needs to be enabled on its material if necessary. This is achieved in `finalizeNewEntity` which is called on all new entities. However, this is not true for the terrain entity. That's why, `mTerrain` now listens to the `newEntityCreated` signal to call `handleClippingOnEntity()`.

ptitjano · 2024-10-11T17:22:34Z

Please can I ask not to force-push commits during review? That makes it impossible to properly see what exactly has changed since the last round of review, and makes things more frustrating for reviewer...

I'm used to projects where force push during review is considered a good practice. So, it has become a second nature.
Also, based on QGIS git history, one can see that most of the time the merged PRs are either:

squashed into one commit
the "review commits" are kept

In the end, we lose most of the benefits of git tooling :

It the PR has been squashed, it's impossible to do a revert of a subpart of a change if there is an issue. It's also impossible to study the commit because the message contains all the previous individuals messages and there are so many changes that it becomes practically impossible to understand the individual changes
when the "review commits" are kept, it's also impossible to do a proper revert. Git blame information is lost. Also, it's impossible to study an individual commit because the information is split between the original and "the review commit".

I also think that github is well suited to handle review with force pushes. From the "Files Changed" tab, you can select "changes since your last review" which creates the same diffs than if there had not been no force push

wonder-sk · 2024-10-11T21:06:17Z

I also think that github is well suited to handle review with force pushes. From the "Files Changed" tab, you can select "changes since your last review" which creates the same diffs than if there had not been no force push

Nope... if I pick "changes since your last review", I get this because of the force push:

The best github can give me is to unmark changed files as "viewed", but good luck re-reviewing files containing many changes...

There's no way of knowing what has changed after a force push unless I would be keeping a local copy of the branch...

nyalldawson · 2024-10-11T21:32:52Z

@ptitjano we're all well aware there's a review people power problem here, let's not push for non-crucial development practices which make it in ANY way harder to review 🤣👍

ptitjano · 2024-10-11T21:53:27Z

I also think that github is well suited to handle review with force pushes. From the "Files Changed" tab, you can select "changes since your last review" which creates the same diffs than if there had not been no force push

Nope... if I pick "changes since your last review", I get this because of the force push:

The best github can give me is to unmark changed files as "viewed", but good luck re-reviewing files containing many changes...

There's no way of knowing what has changed after a force push unless I would be keeping a local copy of the branch...

My bad. Sorry for the inconvenience. I have never encountered this issue while reviewing PR on other github projects even when force pushed.

ptitjano · 2024-10-11T22:15:02Z

@ptitjano we're all well aware there's a review people power problem here, let's not push for non-crucial development practices which make it in ANY way harder to review 🤣👍

I really don't want to derail this PR or write a rant... And I really thank you and @wonder-sk for all the time you spend reviewing. But as I tried to explain earlier, merged PR which contain "review commits" we lost most of the benefit of git: revert/ history/blame because the commit are not atomic anymore. And unfortunately, this happens often. QGIS has a really big code base and I'm still quite new at this thing. So, I spend a lot of times looking at the history to study the commits. Unfortunately, this is sometimes really hard and frustrating (I really mean it) because I sometimes study one commit for a long time, it does not seem to make sense, and a few commits later I see a commit named something like 'fix based on review' and I realize that if "fixes" the commit that I did not understand. It's not always easy to understand how QGIS internal work and if you can't use the commits, it makes the task much harder.
So yes, the main reason for my force-push are to keep atomic commits. I did not realize it made the reviews that much harder. But, I really think that, we, as a community, should always rebase before merging because git history if for ever. It can not be undone.

nyalldawson · 2024-10-12T01:21:55Z

@ptitjano

My personal thoughts on "best practice" would be:

if a pr has never been reviewed, go ahead and force push and clean up and rebase
if it's mid review, just add new commits until the review process is finished
3a. Either tag with squash for a final squash merge, or
3b. cleanup the history and force push ONLY right before merge.

3a works if it makes sense for a single commit to represent the whole change set. 3b works otherwise, but isn't ideal from a security point of view (the force pushed commits could potentially contain anything, and won't be rereviewed before merging). There's no "perfect" approach here 😝. (That said -- You'll see everyone bends the rules at times and will merge messy things with commits with eg GitHub generated names after applying suggestions via the web, just because the benefit of a super clean history doesn't always outweigh the pain of cleanup/force push/wait hours for ci to finish.)

I agree with @wonder-sk in that force pushed mid review make things really tricky, and force the reviewer to waste time rereading through all the old discussions and manually checking that everything's been addressed. It's slow and frustrating as a result.

The worst option (in my view) is merge commits containing the full history. Those really mess up the git history and break blame/bisect/... etc. 🤮.

wonder-sk · 2024-10-12T11:55:55Z

But as I tried to explain earlier, merged PR which contain "review commits" we lost most of the benefit of git: revert/ history/blame because the commit are not atomic anymore

I would disagree here, but in the end, it is a matter of personal preference what exactly an atomic commit should be. My personal preference is to have even bigger features all done in one "atomic" commit - at least it is easy to see what are all the ingredients. And "review commits" never bothered me really, so it is surprising to me they may be frustrating for others. After all, when doing git blame or looking into git history, one typically needs to look at the original PR anyway to get better context, so it does not matter if the work is done in one, two or ten commits...

Agreed with the suggested "best practice" from @nyalldawson 👍

ptitjano · 2024-10-14T08:47:32Z

But as I tried to explain earlier, merged PR which contain "review commits" we lost most of the benefit of git: revert/ history/blame because the commit are not atomic anymore

I would disagree here, but in the end, it is a matter of personal preference what exactly an atomic commit should be. My personal preference is to have even bigger features all done in one "atomic" commit - at least it is easy to see what are all the ingredients. And "review commits" never bothered me really, so it is surprising to me they may be frustrating for others. After all, when doing git blame or looking into git history, one typically needs to look at the original PR anyway to get better context, so it does not matter if the work is done in one, two or ten commits...

I guess we will agree that we disagree on this point. Anyway, I will try to follow the recommendations of @nyalldawson

This PR should be ready now.

wonder-sk

🎉 Looks good to me now - thanks for your efforts!

wonder-sk · 2024-10-15T12:20:53Z

@ptitjano The PR is freeze exempt - would you like to get it merged now, or shall we merge it after the 3.40 release?

ptitjano · 2024-10-17T07:22:11Z

@ptitjano The PR is freeze exempt - would you like to get it merged now, or shall we merge it after the 3.40 release?

I would like to get it merged now please.

github-actions bot added this to the 3.40.0 milestone Jun 26, 2024

ptitjano self-assigned this Jun 26, 2024

ptitjano added the 3D Relates to QGIS' 3D engine or rendering label Jun 26, 2024

ptitjano mentioned this pull request Jun 26, 2024

[3D] Add support for a rotated 3d scene #57593

Closed

ptitjano force-pushed the 3d-clip-part1 branch from e2594e2 to b3e8f7e Compare June 26, 2024 16:24

nyalldawson reviewed Jun 26, 2024

View reviewed changes

src/3d/materials/qgsabstractmaterialsettings.h Outdated Show resolved Hide resolved

ptitjano force-pushed the 3d-clip-part1 branch from b3e8f7e to 280c663 Compare June 27, 2024 23:00

ptitjano added the Feature label Jun 28, 2024

ptitjano force-pushed the 3d-clip-part1 branch 2 times, most recently from 656cf3c to 6718c15 Compare July 5, 2024 21:35

ptitjano changed the title ~~[3D] add support for gl_clipdistance~~ [3D] add support for gl_clipdistance (part 1) Jul 10, 2024

ptitjano mentioned this pull request Jul 10, 2024

[3D] add support for gl_clipdistance + scene rotation (part 2) #58051

Open

benoitdm-oslandia approved these changes Jul 11, 2024

View reviewed changes

src/3d/qgs3dutils.cpp Outdated Show resolved Hide resolved

src/3d/shaders/lines.geom Outdated Show resolved Hide resolved

src/3d/shaders/lines.geom Outdated Show resolved Hide resolved

ptitjano force-pushed the 3d-clip-part1 branch from 6718c15 to 0bb1e81 Compare July 12, 2024 07:26

This was referenced Jul 15, 2024

[3D] Unify some some shader code #58114

Merged

[3D] Use QGIS material for the terrain #58134

Merged

github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jul 30, 2024

ptitjano removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Aug 5, 2024

github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Aug 20, 2024

ptitjano removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Aug 20, 2024

github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Sep 4, 2024

ptitjano removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Sep 4, 2024

nyalldawson added the Freeze Exempt Feature Freeze exemption granted label Sep 13, 2024

ptitjano added 11 commits October 11, 2024 18:55

shaders/pointcloud: Add support for gl_ClipDistance

16bfac6

This is achieved by calling `setClipDistance` in the vertex shader if the clipping is enabled.

shaders/mesh: Add support for gl_ClipDistance

b4c324e

This is achieved by calling `setClipDistance` in the geometry shader if the clipping is enabled.

testqgs3drendering: Add a test for polygon clipping

3d9b9d3

testqgs3drendering: Add a test for phong datadefined with clipping

bafa64b

testqgs3drendering: Add a test for gooch datadefined with clipping

caf3663

testqgs3drendering: Add a test for simple line clipping

2ceec9d

testqgs3drendering: Add a test for line clipping

4cc40d6

testqgs3drendering: Add a test for instanced rendering clipping

dd352d9

testqgsmesh3drendering: Add a test for mesh clipping

55e5fb6

testqgspointcloud3drendering: Add a test for pointcloud clipping

ae79d8f

ptitjano force-pushed the 3d-clip-part1 branch from 0150229 to ae79d8f Compare October 11, 2024 17:06

wonder-sk approved these changes Oct 15, 2024

View reviewed changes

nyalldawson added Frozen Feature freeze - Do not merge! Freeze Exempt Feature Freeze exemption granted and removed Freeze Exempt Feature Freeze exemption granted Frozen Feature freeze - Do not merge! labels Oct 17, 2024

wonder-sk merged commit 444c41b into qgis:master Oct 17, 2024
34 checks passed

zacharlie added ChangelogHarvested This PR description has been harvested in the Changelog already. and removed Changelog Items that are queued to appear in the visual changelog - remove after harvesting labels Oct 19, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[3D] add support for gl_clipdistance (part 1) #57899

[3D] add support for gl_clipdistance (part 1) #57899

ptitjano commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

benoitdm-oslandia left a comment

wonder-sk commented Jul 15, 2024

github-actions bot commented Jul 30, 2024

github-actions bot commented Aug 20, 2024

github-actions bot commented Sep 4, 2024

ptitjano commented Oct 11, 2024 •

edited

Loading

wonder-sk commented Oct 11, 2024

nyalldawson commented Oct 11, 2024

ptitjano commented Oct 11, 2024

ptitjano commented Oct 11, 2024

nyalldawson commented Oct 12, 2024

wonder-sk commented Oct 12, 2024

ptitjano commented Oct 14, 2024

wonder-sk left a comment

wonder-sk commented Oct 15, 2024

ptitjano commented Oct 17, 2024

[3D] add support for gl_clipdistance (part 1) #57899

[3D] add support for gl_clipdistance (part 1) #57899

Conversation

ptitjano commented Jun 26, 2024 • edited Loading

Description

without gl_clipdistance

with gl_clipdistance

Update October 8, 2024

github-actions bot commented Jun 26, 2024 • edited Loading

🪟 Windows builds ready!

github-actions bot commented Jun 26, 2024 • edited Loading

Tests failed for Qt 6

pointcloud_3d_singlecolor_clipping (testPointCloudSingleColorClipping)

pointcloud_3d_singlecolor_clipping

github-actions bot commented Jun 26, 2024 • edited Loading

Tests failed for Qt 5

pointcloud_3d_singlecolor (testPointCloudSingleColor)

pointcloud_3d_singlecolor

pointcloud_3d_colorramp (testPointCloudAttributeByRamp)

pointcloud_3d_colorramp

pointcloud_3d_classification (testPointCloudClassification)

pointcloud_3d_classification

pointcloud_3d_classification_pointsizes (testPointCloudClassificationOverridePointSizes)

pointcloud_3d_classification_pointsizes

pointcloud_3d_filtered_classification (testPointCloudFilteredClassification)

pointcloud_3d_filtered_classification

pointcloud_3d_filtered_scene_extent (testPointCloudFilteredSceneExtent)

pointcloud_3d_filtered_scene_extent

benoitdm-oslandia left a comment

Choose a reason for hiding this comment

wonder-sk commented Jul 15, 2024

github-actions bot commented Jul 30, 2024

github-actions bot commented Aug 20, 2024

github-actions bot commented Sep 4, 2024

ptitjano commented Oct 11, 2024 • edited Loading

wonder-sk commented Oct 11, 2024

nyalldawson commented Oct 11, 2024

ptitjano commented Oct 11, 2024

ptitjano commented Oct 11, 2024

nyalldawson commented Oct 12, 2024

wonder-sk commented Oct 12, 2024

ptitjano commented Oct 14, 2024

wonder-sk left a comment

Choose a reason for hiding this comment

wonder-sk commented Oct 15, 2024

ptitjano commented Oct 17, 2024

ptitjano commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

github-actions bot commented Jun 26, 2024 •

edited

Loading

ptitjano commented Oct 11, 2024 •

edited

Loading