-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix vectorlayer 3D entity generation by filtering duplicates #52064
Conversation
7081cb7
to
2a9ba5c
Compare
Wouldn't this mean that features will become invisible as soon as the node containing their centroid out of view? (Even if other nodes containing part of the geometry are still visible) |
Yes, exactly! |
@benoitdm-oslandia isn't that a regression? Objects will disappear unexpectedly from the edge of views as a 3d map is navigated.... |
@benoitdm-oslandia also, keep in mind to perform any benchmarking on the optimized release build, as the debug build can have significantly different results! |
2a9ba5c
to
5facc7a
Compare
You were right! It was more obvious for concave geometries. I rework my PR by clipping the 2D polygon with the bbox of the current chunk node. Only the used part is kept in the chunk node entity. There is no more duplicate but the clipping increase by a little (17µs per geom) the rendering time. I will push some perf stats on monday. |
69632bf
to
a0e3ffc
Compare
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
|
@uclaros @nyalldawson can you please have a look? |
I'm not sure I like the idea of clipping on the chunk extents. The seams will be visible when rendering edges is enabled. On another note, I love the tidying up and setting of objectNames! That will help debugging and exploring the scene in Gammaray! |
Yes indeed.
From the exporting function pov the only known objects are the
IMHO the 2. and 3. solution are prone to error due to the need to think (or to forget) to add the property or the component. 1. solution in another hand, by changing the But this is a big change just to filter objects during export. |
One more issue with the current clipping approach is that it is likely not going to work with polygons that are not horizontal (this is common with city models, for example with roofs) - as far as I know, GEOS only does the operations in 2D. By the way, in the PR, expected_polygon3d_extrusion_opacity.png seems to have a visible horizontal shift compared to the original image - is that correct? The de-duplication of features in export should be doable with the current implementation - for the purposes of the identify tool, we keep a data structure to understand what triangles map to what feature ID (for tessellated polygon geometries), so this data structure could be used for de-duplication too. A proper solution would be nice to have for the 3D view too - for solid objects it's all fine, but semi-transparent objects on tile boundaries may be drawn more solid due to the duplication. Apart from the original approach with one feature being only in one tile, and the current approach with clipping, I can imagine a third approach - entities for tiles would only contain features fully inside, and the features spanning more than one tile would be rendered on special "shared" entities which would be enabled whenever adjacent entity gets enabled. That approach would solve all the issues: edge highlighting, semi-transparent objects and export. |
3e3ac5d
to
0ca88ca
Compare
please @nyalldawson, @lbartoletti or @troopa81, can I have a review? |
@nyalldawson @uclaros can you review please? |
Just some very minor changes from my end, otherwise all looks good! |
@nyalldawson I have squashed the history too. Let me know! |
0ca88ca
to
7d4c85d
Compare
…inct empty and data entities
…he same function. Were created in one function and deleted from another.
…StartingIndices accessors
14adf84
to
4c484ec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few const
s here and there
…llocation by uniq ptr
…ndexes are a subset of all vertice
…e scene * keep memory of exported features * compute polygon triangle subsets matching the feature to export
…ltering for 3d scene export
…me and avoid the use mFactory->mLayer->name()
4c484ec
to
ce2522f
Compare
thanks @nyalldawson @uclaros! |
@benoitdm-oslandia looks like the new test is a bit fragile -- see eg https://github.com/qgis/QGIS/actions/runs/6179574806/job/16777801856?pr=54578 for a random failure it's been triggering |
Train trip today! I will try to fix that asap |
This PR follow #53063
The feature selection, in
QgsVectorLayerChunkLoader
, was made according to the intersection of the current quadtree node and the feature geometry. For all features with geometry across quadtree nodes, the geometries were duplicated inducing memory and cpu degradations. This fix uses the previous filter (bbox intersection) then filters according to the geometry centroid.closes #50971
Geometry / entity
Old version
A feature is included in multiple quadtree nodes. We use 1064 primitives in 18 geometries.
If we export the scene and import it into Blender we obtain 14 full objects (11 duplicates):
New version
Features across multiple quadtree nodes are clipped in the node bbox. We use 838 primitives in 18 geometries.
If we export the scene and import it into Blender we obtain 14 partial objects (one per quadtree node). The only duplicated faces are those created by the walls when the geometry is clipped:
Computation time
To do this test, I use a bigger project with 57000 features (from a Geopackage) with QGIS built in release.
I add a
QElapsedTimer
to monitor the time (I will remove it before the merge).Old version
Log extract:
(3317+2205+2895+2327)÷4 ~= 2686ms
for 3672934 primitives ==> 0,73µs per primitives.New version
Log extract:
(3116+2120+2775+2170)÷4 ~= 2545ms
==> for 3299502 primitives ==> 0,77µs per primitiveWe lost ~5% in speed and we gain ~11,3% in primitive count.
The main gain is we have no more geometry duplicates.