Add labels to landmark points on mesh

[BridgetDS]

Each point should be numbered - the numbers should correspond to to labels provided in the "Meshes" and "Calculate distances" drop-downs.

There is a certain order in which we normally order the landmarks, so the user should be able to specify which number corresponds to which landmark.

[NickolausDS]

Can I double check how the ordering for landmarks is derived? For example given the list here I could see a couple different possibilities. I might suggest adding an additional optional field to each landmark called "order" to specify this feature explicitly. This make make it easier for new folks creating landmarks to understand how to order them.

        "landmark": [
            {
                "group": "3V72",
                "description": null,
                "point": [9, 3, 3],
                "color": [1, 0, 0],
                "label": "2",
                "link": null,
                "radius": 0.1,
                "id": "1-3X62"
            },
            {
                "group": "3V72",
                "description": null,
                "point": [7, 2, 2],
                "color": [1, 0, 0],
                "label": "3",
                "link": null,
                "radius": 0.1,
                "id": "1-3X64"
            },
            {
                "group": "3V72",
                "description": null,
                "point": [8, 2, 3],
                "color": [1, 0, 0],
                "label": "4",
                "link": null,
                "radius": 0.1,
                "id": "1-3X66"
            },
            {
                "group": "3V72",
                "description": "Mandible 1",
                "point": [10, 3, 3],
                "color": [1, 0, 0],
                "label": "Mandible 1",
                "link": null,
                "radius": 0.1,
                "id": "1-3X60"
            }
        ],

[BridgetDS]

Adding an order field would be good -- our lab has published a paper that establishes certain mouse landmarks so we like to use that ordering for the sake of consistency, but we probably don't want to impose that on other people, and for other species/body parts there is no established order. Ideally the user would drag-and-drop the landmarks into the desired order.

[NickolausDS]

How about using the order field if it exists, but defaulting to the order they're listed in the mesh?

[BridgetDS]

Great. Thank you

[NickolausDS]

Changes are up, and handle explicit ordering, no ordering, or mixed.

When each landmark is given a specific number, they are displayed in order from first to last like this:

No ordering looks like this (defaulting to the listing in the mesh):

And Mixed ordering looks like this, where unlisted are pushed to last:

[BridgetDS]

Great - thank you. And are the points themselves correspondingly numbered on the mesh? The goal would be something like this

[NickolausDS]

No, can you link the location of that viewer? I can look into displaying the number alongside the landmark point on the mesh.

[BridgetDS]

http://chailab.usc.edu/3Dmodel/C57BL6-E185.html On Nov 14, 2018, 9:42 AM -0800, Nickolaus D. Saint notifications@github.com, wrote:

No, can you link the location of that viewer? I can look into displaying the number alongside the landmark point on the mesh. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[NickolausDS]

I looked into this one, and putting numbers on each landmark appears more daunting than expected at first glance.

Looking at the USC example above, they wrote the whole viewer in pure WebGL. The approach is to take the image here containing all the numbers and snip them into individual images so each number can be displayed independently. It does this with the initTexture() function here and is fairly complex.

Other libraries similar to XTK simplify the texture coordinate mapping. Three.js has a built-in class for rendering text in the viewer, and additional built in utilities for rendering sprite-sheets requiring texture coordinate mapping (see page source) like the WebGL example above.

For XTK, there don't appear to be many options. The docs support single textures but no built-in support for either texture coordinate mapping or text-to-texture mapping. Text objects were proposed (6 years ago) but it doesn't look like they made it in I don't think it would be possible to snip a spritesheet using WebGL and render it using XTK. It may be possible to save several pre-cut images and render them individually, but that could get complex very quickly, especially if we needed to display more than 9 landmarks.

[BridgetDS]

Ok, thank you. I think a viable workaround would be for authors to just specify each landmark with a different color, and then they’ll be identifiable. I’ll do this for 972 when I have some time. On Nov 29, 2018, 12:49 PM -0800, Nickolaus D. Saint notifications@github.com, wrote:

I looked into this one, and putting numbers on each landmark appears more daunting than expected at first glance. Looking at the USC example above, they wrote the whole viewer in pure WebGL. The approach is to take the image here containing all the numbers and snip them into individual images so each number can be displayed independently. It does this with the initTexture() function here and is fairly complex. Other libraries similar to XTK simplify the texture coordinate mapping. Three.js has a built-in class for rendering text in the viewer, and additional built in utilities for rendering sprite-sheets requiring texture coordinate mapping (see page source) like the WebGL example above. For XTK, there don't appear to be many options. The docs support single textures but no built-in support for either texture coordinate mapping or text-to-texture mapping. Text objects were proposed (6 years ago) but it doesn't look like they made it in I don't think it would be possible to snip a spritesheet using WebGL and render it using XTK. It may be possible to save several pre-cut images and render them individually, but that could get complex very quickly, especially if we needed to display more than 9 landmarks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[NickolausDS]

If no extra changes are required, this should be good to go. Just for reference, issue #37 shows landmarks with different colors.

[NickolausDS]

This should now be complete in the above merged code. Please re-open or add another issue if there is anything else.