struggling to find a replacement for SCNGeometry to tie to ARAnchors
the "AnchorEntity" class with a model MeshResource appears to be for school students building "boxes"/cubes...
ARMeshGeometry appears to be fully locked down... can't even create one it appears..
MDLMesh appears to be the only way to go, which is fine, except I have not found the proper way to add it to an "AnchorEntity"
I can take the ARMeshGeometry and strip out the vertexes and normals and such to construct "something".... in the new "reality" of realityKit which for some reason decided to strand SCNNodes... that is fine, except there are no ARNodes to let us take a few years of work and practical examples and construct new real time nodes as we did before to interact with AR.... (or did I miss a big chunk here?)
in other words there needs to actually be that middle ground between school student projects, and fully ray traced Metal objects... there are several use cases for this middle ground extremely practical use cases for many professions. ( if I missed it, I apologize in advance) I am looking at several years of work that can not be translated yet as far as I can tell... I am sure I can do it with a few months of work... just with a code base that looks like something out of machine language flavor... which is not fun...
in other words, what is this "something" I spoke of above? can you provide code example of taking the result of one ARMeshGeometry that is being created by lidar, take a specific piece of it like ".floor" faces... construct this "something" from it... give it a "false" color and tie it to an "AnchorEntity"... that would be an awesome example.
this seems like there would be some sample code to show such... but I have not found it yet? does it exist? if not, could you show quick example of doing it...? thanks in advance.
also why in the world did Apple just randomly construct the "ARMeshGeometry"? one thing a person looks at immediately from the sample app of the lidar mesh, is the classification... of course it is just doing it on the fly...
but a great suggestion would be a 'switch' that says put all ".floor" faces in one mesh, and ".wall" in another mesh, upon some trigger, keep it randomly mixed but a 'trigger' at some point of user choosing to "reorganize" them... not sure how that was not constructed in, sure we can separate them out, but that is one more real time process that could have been avoided (on the developer end)...
and the same with the horizontal/vertical planes constructed out of faces... one would think it would be natural to put those in their own "ARMeshGeometry"? (they are, but they are together, and it is one more process to actually try and discover which mesh they are in (as far as I can tell)) I don't think it would have been hard to simply name the anchor, and a "switch" to put them in their own mesh, (horizontal in one, vertical in another)...
why have us make the process slower by having to do it on our own?
anyway, any help would be appreciated...
the "AnchorEntity" class with a model MeshResource appears to be for school students building "boxes"/cubes...
ARMeshGeometry appears to be fully locked down... can't even create one it appears..
MDLMesh appears to be the only way to go, which is fine, except I have not found the proper way to add it to an "AnchorEntity"
I can take the ARMeshGeometry and strip out the vertexes and normals and such to construct "something".... in the new "reality" of realityKit which for some reason decided to strand SCNNodes... that is fine, except there are no ARNodes to let us take a few years of work and practical examples and construct new real time nodes as we did before to interact with AR.... (or did I miss a big chunk here?)
in other words there needs to actually be that middle ground between school student projects, and fully ray traced Metal objects... there are several use cases for this middle ground extremely practical use cases for many professions. ( if I missed it, I apologize in advance) I am looking at several years of work that can not be translated yet as far as I can tell... I am sure I can do it with a few months of work... just with a code base that looks like something out of machine language flavor... which is not fun...
in other words, what is this "something" I spoke of above? can you provide code example of taking the result of one ARMeshGeometry that is being created by lidar, take a specific piece of it like ".floor" faces... construct this "something" from it... give it a "false" color and tie it to an "AnchorEntity"... that would be an awesome example.
this seems like there would be some sample code to show such... but I have not found it yet? does it exist? if not, could you show quick example of doing it...? thanks in advance.
also why in the world did Apple just randomly construct the "ARMeshGeometry"? one thing a person looks at immediately from the sample app of the lidar mesh, is the classification... of course it is just doing it on the fly...
but a great suggestion would be a 'switch' that says put all ".floor" faces in one mesh, and ".wall" in another mesh, upon some trigger, keep it randomly mixed but a 'trigger' at some point of user choosing to "reorganize" them... not sure how that was not constructed in, sure we can separate them out, but that is one more real time process that could have been avoided (on the developer end)...
and the same with the horizontal/vertical planes constructed out of faces... one would think it would be natural to put those in their own "ARMeshGeometry"? (they are, but they are together, and it is one more process to actually try and discover which mesh they are in (as far as I can tell)) I don't think it would have been hard to simply name the anchor, and a "switch" to put them in their own mesh, (horizontal in one, vertical in another)...
why have us make the process slower by having to do it on our own?
anyway, any help would be appreciated...