I'm using Tinkerpop 3.0.1 (Titan 1.0.0), and I try to list all edges for a vertex, sorted by degree of the node on the other end of the edge.
I tried:
g.V(1482896).bothE().order().by(otherV().bothE().count(), decr)
I get the following error from Titan:
The path history of the traverser does not contain a previous vertex: [e[1d2m8u-1d70ts-b2t-vs7k][82628848-DIRECTED->1482896]]
The strange thing is, there is a previous vertex in the path (namely vertex #1482896. I'm confused on how to solve this one.
Answering my own question, after playing around with this, I found a workaround:
g.V(123).bothE().as('edges')
.otherV().order().by(bothE().count(), decr)
.select('edges')
This will effectively sort edges adjacent to vertex #123 by highest degree of the node on the other end of the edge.
Related
I know the networkx could provide the breadth-first search (bfs) results based on the control of depth. I am wondering is there a workaround so I can control the result with the number of edges? For example, I hope to get 10 edges around a node i by bfs. But I don't know what depth it could be.
The bfs controlled by the depth is something like
bfs = nx.bfs_edges(G, source=i, depth_limit=5)
I hope to use a function something like
bfs = nx.bfs_edges(G, source=i, number=k)
As I hope to find all the edges around a node. So it looks like the nx.edge_bfs is a better option? This function returns all the edges currently. Could we modify it somehow? I hope the source node can be located as center as possible, i.e., the yield edges could evenly around the source node.
After looking at the source code of nx.edge_bfs, it looks like this function itself returns an iterator which yields the edges surround the source node one by one. And it basically returns the surrounding edges like a circle.
It could be better if someone could confirm this. Here is the source link
So, I'm using a boolean operator to get the intersection of a bunch of pieces and a wall. Most pieces work fine but occasionally the intersection isn't perfect and you get these vertices that aren't connected to the rest of the mesh and this results in the mesh collider being incorrect, as seen in this picture.
My question is whether there is a way to detect these 'island' or 'lone' vertices.
I can provide additional images, code, or such if needed.
Thanks for any help! Ps. first question here so please be patient with me :)
In the end, I kind of solved it by finding all connected vertices starting from a single vertex.
I started by picking the first triangle and adding it's vertices to a list of connected vertices. Then I go through the list of triangles comparing the position of their vertices to the list of connected vertices. If the triangle has a vertex with a position corresponding to a position in the list of connected vertices I add the entire triangle to the list. That's one iteration and I repeat this until all connected triangles are already in the list. If the connected triangle list is more than half of all triangles then I remove all other triangles, otherwise, I remove the current list of connected triangles. After that, I clear the vertices that aren't in a triangle like Leo Bartkus suggested.
It's extremely slow and it assumes there are only 2 separate islands or that you started on the biggest island, but it worked most of the time and was more for learning purposes anyways.
Thank's for the help!
I think i have a difficult problem right here..
I want to able to get the surfaces of f.e. the orange object in this three.js example https://threejs.org/examples/?q=stl#webgl_loader_stl
i want to click with the mouse, find the correct surface, which should then be highlighted, so i make sure this was the surface i want.
(i already implemented raycaster successfully, so thats not an issue)
The intersectObject method returns an array of intersections, each of which has face property. The face contains vertex indices.
For STL files containing multiple solids, each solid is assigned to a different group, and the groups are available in the geometry object that is returned from STLLoader. Each group is defined by a range of vertex indices.
So, I think you can correlate the vertex indices returned from the raycaster with the vertex indices in the geometry groups.
I am trying to create an advanced shader for an AR application in Unity. Therefore I need all vertices and their neighbors from my gameobject (within a C# script). Getting the vertices is not the problem, but how do I get their neighbors(maybe with an indexbuffer)?
I am not new to shaders, but to shaders within Unity.
After I got the neighbors I would like to pass them from a C# script to a function within a shader file. I guess that should be possible in Unity, is it not?
The easiest way I can think of is by searching the triangle index. The pattern is always the same, always 3 indices define a vertex. since you know the index of your vertex, you can just search the triangle array and return the other two of any triangle, which will give you all vertices within the range of the desired one.
This is in gremlin-scala. I have the traversal at a Vertex point (which is what '_' stands for below:
_.as("vertex").outE().as("outEdge").in().inE().as("inEdge")
.select("inEdge","outEdge").by("fullName")
.where("inEdge", P.eq("outEdge")).select("vertex")
But I am getting an error referencing the .in() after the .as("outEdge") statement:
Error:(55, 40) Cannot prove that org.apache.tinkerpop.gremlin.structure.Edge <:< gremlin.scala.Vertex.
Can anyone help me figure out what is going wrong here, and more importantly, is this the correct way to find Vertices that have a matching property on its edges?
Thanks in advance.
I think that syntax is incorrect. Change:
_.as("vertex").outE().as("outEdge").in()
to
_.as("vertex").outE().as("outEdge").inV()
when you do outE() you are on an edge, so you must traverse to a Vertex which would be either inV() (the vertex adjacent to where you started), outV() (the vertex you started from since you traversed outE(), or bothV() which would yield both the vertices at either end of the edge.
I think your method for comparing properties makes sense. Someone else might post a way to simplify further.