aleph-viewer / aleph Goto Github PK

This is useful when driving the experience from an external menu.

The issue has to do with editing the name of nodes or deleting them (as opposed to moving them on the object).

We should separate the "node panning" function from "node editing" functions. It often takes a long time for the node to become editable after clicking on it because aleph rotates and pans to the node which can take a while for a big mesh. There's no reason those two functions need to be tied to each other.

In the node list, we should have two buttons: 1 says "zoom to node" or "pan to node". the other says "edit". Seems like you should be able to click "edit" and change the node name or delete it without incurring the cost of rotating and zooming the specimen.

It seems best to separate them because we will always have big meshes or files. I just dont see any reason to connect the two functions. When you want to edit the node, that's what you want to do, not pan then edit. Its counter intutive when your goal is editing the node name and instead you have to rotate and pan before you can do that.

This is useful when describing properties of an object as a whole.

measurement tools are not working on certain meshes: for instance the UF Sifrippus tooth: https://morphosource-demo.lib.duke.edu/concern/media/000005227?locale=en.

Could have something to do with it being a very small tooth

Steps to reproduce:

1. Load a mesh
2. Place three nodes
3. Place two edges with one node in common
4. Place an angle between the two edges
5. Create three additional edges.

The third additional edge (i.e., edge 6 overall) will have bugged extra-wide light gray background behind the dark gray background. Weird!

This is useful when Aleph is part of a larger application with a distinct style/colour scheme of its own.

This is useful for driving an experience that aleph is embedded into.

some images have nodes and font that are way too big or way too small. Im not sure how font and node size is currently being determined. It would seem that if was determined via as a constant relative to bounding box dimensions this should be less of an issue.

zooming does not result in scrolling up because (I suppose) the preview is at the top of the page already. But it is a distracting problem especially for meshes

Multiple people I tried showing aleph-viewer's volume models just said "loads forever, and then displays a texture". I think you would avoid confusion over the capabilities if the default view would be the volume :)

Very large meshes (like 16 million polygon meshes) currently perform more poorly in Aleph than in other Three.js-based web GLTF mesh viewers. This seems to be due to the computational overhead of the raycaster calculating when the cursor intersects with the mesh.

The large mesh branch is an example of an experimental fix to this issue, disabling the raycaster for the orbit camera but not the trackball camera. Performance is much higher for orbit than trackball when the cursor intersects with mesh surface. This of course also causes an additional issue where when using the orbit camera, it is impossible to interact with nodes in any way (including highlighting them).

One approach to solving this issue would be to disable the raycaster unless a user has 'enable node placement' switched on, though this would cause the above issue with being unable to highlight previously placed nodes. Alternately maybe the node placement switch should be replaced with some kind of 'node mode' that toggles both visibility of and placement of nodes.

I'll be trying to address this issue as I'm able.

When viewing https://aleph-viewer.com in Firefox 70.0.1 (64-bit) on Windows 10 and clicking on the "Nodes" tab I see unstyled links and input fields.

Here's how it looks in latest Chrome:

Styling problems can also be seen on the "Source" tab, where in Chrome the selection box extends to the full width of the sidebar, and in Firefox it doesn't. Also the input field correctly has a grey background in Chrome, whereas it doesn't in Firefox.

See the attached mesh, which is roughly disc-shaped and has a size of around ~1.7 millimeters as the widest diameter. This particular mesh was not correctly scaled, but it is completely possible to have objects at this size. The src/Constants.ts camera near value (0.05) is not large enough to account for a mesh like this, and on initial load the mesh appears too close to the camera to be viewed.

That can be changed easily enough to something like 0.0001 to address this, but placing annotations on the example mesh produces this error: "THREE.DirectGeometry: Faceless geometries are not supported." Though it seems to relate to a very different issue, this stack exchange answer suggests this particular error may also be caused by the small size of the mesh.

4-glb.glb.zip

https://github.com/aframevr/aframe/releases/tag/v1.0.4

Not sure which change has caused this. Is fine is v1.0.3.