In that case, maybe use *Triangle pointers instead of Triangle values, and let that address be the identity for map purposes? Then the Vertex order etc doesn't matter any more.
//jb > On 28 Aug 2017, at 14:03, Val <delepl...@gmail.com> wrote: > > That's actually a clever idea, I had not thought of that when dismissing the > vertex struct inspection. Thanks! > > But it turns out that X,Y,Z will change often during my program execution: > vertices move, but their identity (and the triangles identity) must be > strongly preserved. > > On Monday, August 28, 2017 at 1:42:35 PM UTC+2, Jakob Borg wrote: > On 28 Aug 2017, at 13:13, Val <dele...@gmail.com> wrote: > > > > To achieve this, I consider normalizing the triplet so that all keys of the > > map verify > > A < B < C > > for some arbitrary definition of < . This ensures that I can detect any > > Triangle already present as key in the map, regardless the order of its > > Vertex pointers. > > Can't you sort the Vertex slice by their X,Y,Z position? (You're then not > relying on the coordinates for identity, only for order. This breaks for > triangles that are actually lines or points, which may or may not be an issue > and can be handled separately...) > > //jb > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
