Skip to content
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

Question: Per Element Indices #194

Open
afabri opened this issue Sep 16, 2024 · 7 comments
Open

Question: Per Element Indices #194

afabri opened this issue Sep 16, 2024 · 7 comments

Comments

@afabri
Copy link
Contributor

afabri commented Sep 16, 2024

On the page on Elements you write "The routines in this section are valid only when the mesh is compressed"

I guess you mean that the indices are no longer a contiguous sequence. So if I have a large enough std::vector V can I still use the index of a vertex for storing something in V?

Which leads me to the next question: Do you offer a function to get the largest index of vertices, regardless of being marked as removed or not.

@nmwsharp
Copy link
Owner

Yes exactly! (And this is how the container types like VertexData<> are implemented under the hood, lazily resizing only occasionally as a mesh is updated).

Do you offer a function to get the largest index of vertices, regardless of being marked as removed or not.

There are these functions, which give an upper bound: https://github.com/nmwsharp/geometry-central/blob/master/include/geometrycentral/surface/surface_mesh.h#L203-L209 (they are used to set the size of the VertexData<> etc containers). The increase in powers-of-2, so they might be a bit larger than the largest index.

I believe the actual largest index comes from these internal members https://github.com/nmwsharp/geometry-central/blob/master/include/geometrycentral/surface/surface_mesh.h#L306-L323 . I don't believe there are any public-facing functions to access these, but I suppose it could be reasonable to expose them since we expose the raw element indices already. Let me know if that would be useful to you!

@afabri
Copy link
Contributor Author

afabri commented Sep 19, 2024

I am interested in a function of SurfaceMesh that returns vHalfedgeArr.size(). And the same for the other elements.
Concerning the doubling, that is the capacity, not the size, right? I mean, in your code, you call reserve() and not resize() to allocate more memory for vertices.

@afabri
Copy link
Contributor Author

afabri commented Sep 19, 2024

It corresponds also to MeshDate<>::size(),

@nmwsharp
Copy link
Owner

nmwsharp commented Oct 1, 2024

I created a PR here that exposes these functions, let me know if I missed anything! #196

@nmwsharp
Copy link
Owner

nmwsharp commented Oct 1, 2024

And regarding the reserve/resize, I believe it is a resize? Here, right? https://github.com/nmwsharp/geometry-central/blob/master/src/surface/surface_mesh.cpp#L1609

(I haven't thought much about this implementation in the last couple years, so I am paging it back into memory)

@afabri
Copy link
Contributor Author

afabri commented Oct 1, 2024

A resize() makes that size() then returns that value. With reserve() the size changes when later you call push_back().

@nmwsharp
Copy link
Owner

nmwsharp commented Oct 2, 2024

I'm familiar with the difference, I was just responding to this comment

in your code, you call reserve() and not resize()

pointing out that at least in the linked location, it is indeed a resize() 😃 But maybe you were referring to somewhere else.

And FYI I have merged that PR above exposing the max-index getters for SurfaceMesh. Note that for corners they behave slightly differently than might be expected, I also added a note about the differences with corner indexing to the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants