You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been implementing my own version of Dual Contouring (http://faculty.cs.tamu.edu/schaefer/research/dualcontour.pdf) and I noticed that if all the cell data types returned by refine_data are not identical, then split! fails because the child data gets returned as Tuple{Tuple{...}} instead of just Tuple{...}. Having this ability could be useful to leverage multiple dispatch on the cell data, as well as making the package easier to experiment with. Is there a reason the types need to be identical, or might this even be a bug?
The text was updated successfully, but these errors were encountered:
Ah, that sounds like a bug. Do you have some code that you can share to reproduce the error?
I would be somewhat concerned that having heterogeneous data types in each cell could hurt performance, since you'll be doing run-time method dispatch, but it still should at least work.
Sure, I'll see if I can come up with a more simple to work with example.
For my case, it might be useful to have different types for cells that are inside/outside/spanning surfaces to limit the amount of checking I have to do manually. Maybe there's a more elegant solution to this though.
Is there a case to be made for heterogenous data types in each cell? It won't be the hardest thing to be implement but again the question of performance and these tree can become really big ;-;
I've been implementing my own version of Dual Contouring (http://faculty.cs.tamu.edu/schaefer/research/dualcontour.pdf) and I noticed that if all the cell data types returned by
refine_data
are not identical, thensplit!
fails because the child data gets returned asTuple{Tuple{...}}
instead of justTuple{...}
. Having this ability could be useful to leverage multiple dispatch on the cell data, as well as making the package easier to experiment with. Is there a reason the types need to be identical, or might this even be a bug?The text was updated successfully, but these errors were encountered: