Seeking Strategy for "Globe Topology" Data Management - Subdivided Dodecahedron

Hiya folks!

I've run across some articles discussing the topic of managing a globe shape in 3D games, and each example I've encountered features a sphere projection of a subdivided cube. And for good reason, I know.

Interestingly, this is technique is a non-starter for me. I'm specifically interested in the properties of using tris instead of quads, not only for aesthetics, but for data management as well.



Exactly none of the data management techniques employed by cube-based solutions seem to apply. This is day-one brainstorming and I'm already stumped, so I thought I'd ask for any thoughts on data management strategies.

The only thing that comes to mind is building a design-time utility that creates a navigable network. Each tri painstakingly discovers and records a collection of its neighbors, and this can plug directly into something like A-Star, perhaps featuring a layer which treats each of the 20 dodecahedral sections independently.

edit: For comparisons which don't consider walkability, it may be sufficient that I be able to convert freely between 3D vectors representing cell positions and actual cell indicies, using vectors and angles between vectors as criteria for simple queries. My question then becomes, is there a superior strategy for creating relationships between cells in this odd situation?

I can't picture this being terribly bad to work with for simple navigation, but as a full-fledged data management solution? Sounds like a performance nightmare, even with threading or strictly limiting queries. Any commentary on this would be helpful.

Letting go of 2D arrays for cell management is a huge mechanical upset - a problem I've never really encountered before - and perhaps I'm not thinking clearly about what discarding that strategy could mean. Any thoughts on this would help too.

Thanks a bunch for sharing your time,