I have a digraph graph G=(V,E) that I would like to redraw because it is currently very messy. This is a flow chart that is being visualized and since |V|>1000 and each v in V has more than 1 outgoing edge, it is very hard to trace by eye. For instance; a node on the lower left corner is connected by an edge to a node on the upper right corner. It would be better, for example, if these two nodes were placed next to each other. There are too many edges and it is a pain to trace each of them.
I have access to and can change the (x,y) coordinates of all the vertices. I would like to redraw G by maintaining it's current structure, in a way that is more human-friendly. I thought that minimizing the number of intersecting edges may be something to start with.
Is there an algorithm that can help me redraw this graph?
My question is, how do I assign (x,y) coordinates to each v in V such that it is organized better and easier to trace and read? How do I express these requirements formally? Should I go with a heuristic, if this is NP? Here is an example for a somewhat organized graph and this is something messy (although much smaller than what I'm dealing with).
Any help will be greatly appreciated. Thanks.
EDIT: I'm still looking for a to-the-point answer. I've researched into planar straight-line and orthogonal drawing methods but what I've got is lengthy research papers. What I'm seeking is an implementation, pseudo-code or at least something to get me started.
EDIT 2: I'm not trying to display the graph. The input to the algorithm shall be the graph G (composed of V and E) and the output shall be {(xi, yi) for each vi in V}
You want to look at graphviz.org; this is a difficult problem on which there has been a lot of research, reimplementing the wheel is not the right way to go.
Probably you'll have to get the java to write out a datafile which a tool like 'dot' can read and use for the graph layout.
That messy one seems to be drawn using spline, try planar straight line algorithm instead. Indeed this is a very difficult problem and I always use GraphViz as my backend graph drawing tools, you can generate that graph you want with -Gsplines=line option.
Related
I'm working on a visualization project. From the data I have calculated the X, Y, and Z coordinates for a large set of points. Using Processing it was very simple to draw this out with lines and dots.
From the top it looks like this:
And from a side angle you can see how it occupies 3D space
The part I'm struggling with is turning this into polygons. I need the end result to be something I can export as a .obj file, and then later open in Blender or similar 3D modelling programs.
The two main issues are that these points are not on a grid, but are instead organized in a circle based on radian angles, and that the triangle structure isn't all that simple.
I tried drawing out my own polygons (it's kinda sorta working), but I'm getting to the point where the maths are getting a bit too complex to handle and my code is bloated with arrays, if statements, and for loops...
Surely there must be a better way? Are there any plugins maybe that would help me with this task? Or some techniques I should take a look at?
Processing has screenX() and screenY() functions that take a 3D point and return a 2D point. That sounds like pretty much exactly what you're looking for. Please see the reference for more info.
So I've been assigned a recursive art project for my AP CS class and have a bunch of spare time, so I've decided to try something a little bit more ambitious.
My plan is to create a 3D fractal, either rendered and shaded in a visualization with GL, or represented via spatially mapping the respective equations' outputs to points on a cube and drawing those. If this explanation seems unclear, please check out the links at the bottom for images. Now, I don't need the fractal to be able to be modified in-program. I just need it to render a single BufferedImage, which I'll be putting directly on a JFrame.
My experience in Java, as far as this project goes, is a bit limited. I've drawn Mandelbrot and Julia set fractals before, but I have little to no experience drawing/rendering objects in 3D in Java. This is all stuff I can look up and figure out myself though, so no worries here.
Thus, the question: How does one map a fractal that should be in the 2nd dimension (e.g. log(no. of subdivided entities)*log(side length of subdivision) = 2) to the 3rd dimension (e.g. log(no. of subdivided entities)*log(side length of subdivision) = 3)? I'm lost trying to mathematically work this out, and I believe there is a more organized approach to go about this circumventing a lot of the math that already exists.
Also, if you are aware of a structured approach to render a 2D fractal, as drawn by a formula, and render it in 3D, provided the respective formula is provided (power is raised), please let me know. I've heard of Ray Tracers, no idea what they are, a brief summary would be cool.
Here are links with pictures of the result I want to obtain:
http://2008.sub.blue/assets/0000/4575/power8_large.jpg
https://www.youtube.com/watch?v=rK8jhCVlCtU
It looks like the image is an example of a Mandelbulb. The is a similar iteration formula to the Mandlebrot set but using 3D points and a novel idea of what raising a 3D point to a power means.
I see that there are some fairly similar questions, but those are mostly regarding performance. I would be very grateful if someone could take the time to explain as to how I could implement what I currently have into the vertex shader(For animation, as the title states).
I have a simple .FBX file reader which extracts the following:
Vertex coordinates (X, Y, Z);
Vertex indices;
Normal coordinates (X, Y, Z);
As far as bones go:
Bone names
Indices of the vertices attached to the bones;
The weight of each of the vertices;
A 4x4 matrix array of the bone. (Not sure how this is laid out, please explain! Wouldn't the matrix only hold the position of 1 end?)
Help appreciated!
Looks like you may be missing a few things. Most notably, the bone hierarchy.
The way it typically works, is you have a root node, whose transformations propagate down to the next level of "bones", whose transformations propagate, and so on until you reach the "leaf" bones, or bones with no children. This transformation chain is done using matrix multiplication.
There are a few ways to then transform the vertices. It's sometimes done with with an "influence" that is decided on beforehand and is usually loaded from a 3d application such as 3dsmax.
There's another way of doing this which is simple and straightforward. You simply calculate the distance from the vertex to the bone node. The influence of the bone's transformation is directly related to this distance.
The 4x4 matrix you speak of holds much more than just position. It holds rotational data as well. It has the potential to hold scaling data as well but this typically isn't used in skinning/bone applications.
Getting the orchestra to play together nicely requires a thorough understanding of matrix math/coordinate systems. I'd grab a book on the subject of 3D math for game programming. Any book worth its weight will have an entire section devoted to this topic.
I have a simple game that uses a 3D grid representation, something like:
Blocks grid[10][10][10];
The person in the game is represented by a point and a sight vector:
double x,y,z, dx,dy,dz;
I draw the grid with 3 nested for loops:
for(...) for(...) for(...)
draw(grid[i][j][k]);
The obvious problem with this is when the size of the grid grows within the hundreds, fps drop dramatically. With some intuition, I realized that:
Blocks that were hidden by other blocks in the grid don't need to be rendered
Blocks that were not within the person's vision field also don't need to be rendered (ie. blocks that were behind the person)
My question is, given a grid[][][], a person's x,y,z, and a sight vector dx,dy,dz, how could I figure out which blocks need to be rendered and which don't?
I looked into using JMonkeyEngine, a 3D game engine, a while back and looked at some of the techniques they employ. From what I remember, they use something called culling. They build a tree structure of everything that exists in the 'world'. The idea then is that you have a subset of this tree that represents the visible objects at any given time. In other words, these are the things that need to be rendered. So, say for example that I have a room with objects in the room. The room is on the tree and the objects in the room are children of the tree. If I am outside of the room, then I prune (remove) this branch of the tree which then means I don't render it. The reason this works so well is that I don't have to evaluate EVERY object in the world to see if it should be rendered, but instead I quickly prune whole portions of the world that I know shouldn't be rendered.
Even better, then when I step inside the room, I trim the entire rest of the world from the tree and then only render the room and all its descendants.
I think a lot of the design decisions that the JMonkeyEngine team made were based on things in David Eberly's book, 3D Game Engine Design. I don't know the technical details of how to implement an approach like this, but I bet this book would be a great starting point for you.
Here is an interesting article on some different culling algorithms:
View Frustum Culling
Back-face Culling
Cell-based occlusion culling
PVS-based arbitrary geometry occlusion culling
Others
First you need a spatial partitioning structure, if you are using uniform block sizes, probably the most effective structure will be an octree. Then you will need to write an algorithm that can calculate if a box is on a particular side of (or intersecting) a plane. Once you have that you can work out which leaf nodes of the octree are inside the six sides of your view frustum - that's view culling. Also using the octree you can determine which blocks occlude others (sometimes called frustum masking), but get the first part working first.
It sounds like you're going for a minecraft-y type thing.
Take a look at this android minecraft level renderer.
The points to note are:
You only have to draw the faces of blocks that are shared with transparent blocks. e.g.: don't bother drawing the faces between two opaque blocks - the player will never see them.
You'll probably want to batch up your visible block geometry into chunklets (and stick it into a VBO) and determine visibility on a per-chunklet basis. Finding exactly which blocks can be seen will probably take longer than just flinging the VBO at the gpu and accepting the overdraw.
A flood-fill works pretty well to determine which chunklets are visible - limit the fill using the view frustum, view direction (if you're facing in the +ve x direction, don't flood in the -ve direction), and simple analyses of chunklet data (e.g.: if an entire face of a chunklet is opaque, don't flood through that face)
i would like to build a dynamic data structure that can hold a list of polygons and return a list of polygons that overlaps a specified rectangle.
i looked into bst trees (and quad trees) but these dont seem to work too well when the polygons overlap heavily.
any good ideas i should check out before i roll my own nonsense?
edit
lets assume all the polygons are normal non rotated rectangles. im willing to take the hit (point in polygon test) during point tests (i might be doing it anyway), and during a region test getting their bounding boxes is just as good. only a small percentage of them will actually not overlap the region in question.
I would look at 2-d segment delaunay graphs. Look also at Nef polygons. CGAL has a lot of set operations on polygons. Answers to this question may also be of value
Edit If your polygons are non rotated rectangles see R-Trees
Why do you write that yourself? Java offers complex intersection tests. You can convert your polygon data structures and your rectangle to Java.awt.geom.Area and then call the Area.intersect() method which does all the math for you.
It also takes care of all the rarely occurring (but still important) special cases which are really nasty to catch.
i just wrote a regular quadtree, that allowed each leaf node to hold unlimited polys, if the intersection of the bounds of the leaf and the bounds of each poly in the bucket were equivalent. otherwise leaf nodes are limited to 8 polys, before splitting.