Hey, I'm currently trying to extract information from a 3d array, where each entry represents a coordinate in order to draw something out of it. The problem is that the array is ridiculously large (and there are several of them) meaning I can't actually draw all of it.
What I'm trying to accomplish then, is just to draw a representation of the outside coordinates, a shell of the array if you'd like. This array is not full, can have large empty spaces with only a few pixels set, or have large clusters of pixel data grouped together. I do not know what kind of shape to expect (could be a simple cube, or a complex concave mesh), and am struggling to come up with an algorithm to effectively extract the border. This array effectively stores a set of points in a 3d space.
I thought of creating 6 2d meshes (one for each side of the 3d array), and getting the shallowest point they can find for each position, and then drawing them separetly. As I said however, this 3d shape could be concave, which creates problems with this approach. Imagine a cone with a circle on top (said circle bigger than the cone's base). While the top and side meshes would get the correct depth info out of the shape, the bottom mesh would connect the base to the circle through vertical lines, making me effectivelly loose the conical shape.
Then I thought of annalysing the array slice by slice, and creating 2 meshes from the slice data. I believe this should work for any type of shape, however I'm struggling to find an algorithm which accuratly gives me the border info for each slice. Once again, if you just try to create height maps from the slices, you will run into problems if they have any concavities. I also throught of some sort of edge tracking algorithm, but the array does not provide continuous data, and there is almost certainly not a continuous edge along each slice.
I tried looking into volume rendering, as used in medical imaging and such, as it deals with similar problems to the one I have, but couldn't really find anything that I could use.
If anyone has any experience with this sort of problem, or any valuable input, could you please point me in the right direction.
P.S. I would prefer to get a closed representation of the shell, thus my earlier 2d mesh approach. However, an approach that simply gives me the shell points, without any connection between them, that would still be extremely helpful.
Thank you,
Ze
I would start by reviewing your data structure. As you observed, the array does not maintain any obvious spatial relationships between points. An octree is a pretty good representation for data like you described. Depending upon the complexity of you point set, you may be able to find the crust using just the octree - assuming you have some connectivity between near points.
Alternatively, you may then turn to more rigorous algorithms like raycasting or marching cubes.
Guess, it's a bit late by now to be truly useful to you, but for reference I'd say this is a perfect scenario for volumetric modeling (as you guessed yourself). As long as you know the bounding box of your point cloud, you can map these coordinates to a voxel space and increase the density (value) of each voxel for each data point. Once you have your volume fully defined, you can then use the Marching cubes algorithm to produce a 3D surface mesh for a given threshold value (iso value). That resulting surface doesn't need to be continuous, but will wrap all voxels with values > isovalue inside. The 2D equivalent are heatmaps... You can refine the surface quality by adjusting the iso threshold (higher means tighter) and voxel resolution.
Since you're using Java, you might like to take a look at my toxiclibs volumeutils library, which also comes with sevaral examples (for Processing) showing the general approach...
Imagine a cone with a circle on top
(said circle bigger than the cone's
base). While the top and side meshes
would get the correct depth info out
of the shape, the bottom mesh would
connect the base to the circle through
vertical lines, making me effectivelly
loose the conical shape.
Even an example as simple as this would be impossible to reconstruct manually, let alone algorithmically. The possibility of your data representing a cylinder with a cone shaped hole is as likely as the vertices representing a cone with a disk attached to the top.
I do not know what kind of shape to
expect (could be a simple cube...
Again, without further information on how the data was generated, 8 vertices arranged in the form of a cube might as well represent 2 crossed squares. If you knew that the data was generated by, for example, a rotating 3d scanner of some sort then that would at least be a start.
Related
For my work I had to get into OpenGL 3d rendering recently, and I admit I'm quite new to this topic.
Without getting into too much detail, I have to deal with a HUGE array of data (vertices) from which I need to draw a shape. Basically, think of a plane of a very odd shape in 3d space. This shape is being added to on the fly. Think of a car moving on a plane and painting it's trail behind it - but not just a simple trail, but with holes, discarded sections, etc. And it generates a new section several times per second for hours.
So, obviously, what you end up with is A LOT of vertices, that do get optimized somewhat, but not enough. Millions of them.
And obviously I can't just feed it to a GPU of embedded system as a vertex VBO.
So I've been reading about culling and clipping, and as far as I understand I only need to display the visible triangles of this array, and not render everything else.
Now, how do I do that properly?
The simplest brute-force solution would be to go through all triangles, and if they lie outside of frustum - just not draw them. Generate a buffer of what I DO draw and pass it to GPU
One idea I had is to divide world space into squares, a kind of chunks, and basically split the "trail" mesh between them. So each square will hold data for it's part of the trail, and then I could use frustum culling, maybe, to decide which squares to render and which to skip.
But I'm not convinced it's a great solution. I also read that you should reduce the number of GL function calls as much as possible, and calling it for hundreds of squares doesn't seem great.
So I decided to ask for advice among people who would understand the subject better then me. Sadly, I don't get much learning time - I need to dive right into it.
If anyone could give me some directed tips it'd be appreciated.
You'd be better off using some form of spatial partitioning tree (e.g. OctTree, QuadTree, etc). That's a similar approach to your second suggestion, however because it's hierarchical, searching the tree is O(logN) vs O(n).
I'm attempting to render a hemisphere in java. However, I'm wanting to render the slice that is defined by 2 angles - Azimuth and Elevation. Since I'm defining a slice, I cannot (to my knowledge) use any built in primitives. If the azimuth range is defined 0-360 and the elevation range is defined as 0-70, this will be a hemisphere with an upside-down cone-shaped hole in the top.
When rendering this inside "cone", I have chosen to do it as triangles in 5 degree increments. This means that with a 360 degree cone, there are 73 different vertices (if I did the math correctly: 360/5degree slices with the origin or tip of the cone being shared with all sides, and all other vertices shared by adjacent triangle slices)
My question:
Is it more efficient to render these as a single polygon with with many vertices, or many triangles with only 3 vertices each. If I do a single polygon, will I still have to include all three points for each triangle, or if it is a shared vertex, would I only include it once? Sorry, my graphics rendering knowledge is limited. Also sorry for being so verbose; I'm hoping someone may spot something erroneous in my thought process which may clear things up either way.
First - Use Google to find an algorithm to create a sphere that is not a primitive.
Second - Somewhere down the chain - triangles will be used. Most likely by the underlying library. But for you - it depends upon whether or not you plan to chop up the created region. If you are not going to subdivide the region further I would just make it one polygon. Actually, after thinking about it for a second - you can always divide up the polygon afterwards too. So just make it one polygon.
I thought about it some more and decided to amend this answer. There are two ways you can create a polygon in openGL. You can either create it as a triangular mesh or as an outline polygon. So if you were asking "Should I use a triangular mesh or an outline polygon" I would say use the triangular mesh. It is a lot easier to break up the triangular mesh than a polygon outline since, to break the mesh, all you have to do is to just stop at one of the points, include the last two points in the new object, and continue on down the triangular mesh. An outline polygon requires you to go both left and right around the polygon to locate the two points where the break occurs. If that is clear. If not say so.
Update: 12:05pm
When making a polygon you can use a triangular mesh or a polygon outline. The outline is mainly good for 2D whereas the triangular mesh works in both 2D and 3D systems. If you have any kind of a polygon at all bigger than just three points then it is a good idea to put them all into an array. This allows you to use the built-in routines that take an array and simply go through it to build your polygon. By putting everything into an array you also make it easier on yourself to add new points or remove points or adjust points. All you do is to change the array entry and then call the same routine to draw everything again. (Which should be just a single call to a function.)
following on from my previous post , I have a separate issue that I want to check.
I want to redo my calculations of having objects orbit a sphere on their own unique orbit, at various heights (radius) and angles (orbital plane). My previous post explains the method I am using, however I am getting quite a bit of unexpected behaviour, which I think is due to the mapping method I use. Objects start "turning" on their own and going off in changing directions when uncommanded.
SETUP:
I have a flat 2D grid of 1000x1000 where I keep track of objects
I then map these to the sphere and convert to 3D coords.
However, this is probably causing issues with a flat 2x2 not being able to be wrapped onto a sphere without huge distortion, so need to convert it to Mercator Projection, then wrap that onto the sphere.
Before it gets too complicated, would it be far easier to just deal with Matrix4 or Quaternions and represent everything by rotations instead? I still need to keep track of all objects, and the position on the sphere (for simplicity, lets say on the surface), but I need to be able to modify the objects orbits. For example, modify their height, or direction (orbital plane).
Can someone suggest a cleaner way to represent these valyes locally? I can see this getting very messy otherwise.
Many thanks,
J
I am looking for an algorithm that would let me find an enclosing bounding box for a lat/long without using map data. Essentially I want to be able to define grids for the planar world map given a set size and then plot which grid a lat/long falls in.
Does anyone know of previous work that might have been done in this? Are there standard ways of doing this over home grown solutions where I create a hash map (or the like) of my own bounding boxes for the world and do lookups etc.
I dont want to utilize actual cartography for this. Just looking for some math that would return a fixed bounding box for all the lat/longs that fall under it
Thanks for your help!
I guess you mean that you want to do something like cover the surface of the Earth with squares (or rectangles) of a fixed size, perhaps 100km square, and figure out a way of mapping from any (lat,long) coordinate pair to the square in which it sits ? Well, forget about that, it can't be done, there is simply no way to cover the surface of a sphere (ignore the slight non-sphericity of the Earth for this discussion) with squares of the same size.
You might be interested in Universal Transverse Mercator which is close to what you want to do but it will require you to engage with some of the mathematics of map projections. I see no way around this.
I exclude from consideration that you would be satisfied with 'squares' of equal angular measure, I mean (for example) something like 'squares' of 2 degrees of lat or long on each side. The maths for that would be trivial and you wouldn't have asked here on SO for guidance.
I am planning to develop a jigsaw puzzle game.
Now I already have images and image pieces, so we don't need algorithm to cut the image in pieces.
On the UI side there would be two sections
First section contains the broken images in random order.
Second section contains the outline of the full image. User need to drag and drop the the cut images onto the outline image.
I am not sure how can the pieces be matched on the the outline image?
Any idea about the algorithm or the starting pointers?
Allow the user to drag each piece into the outline area. Allow the piece to be rotated in 90 degree increments.
Option 1:
If a piece is in the correct location in the overall puzzle, and at the correct angle, AND connected to another piece, then snap it into place with some user feedback. The outside edge of the puzzle can count for a connection to edge pieces.
Option 2:
A neighbor is an adjacent puzzle piece when the puzzle is assembled. When the puzzle pieces are mixed up, they still have the same neighbors. Each puzzle piece (except the edge pieces) has four neighbors.
If a piece is near one of its neighbors at the correct angle relative to that neighbor, then snap it to the other piece. Then allow the two (or more) pieces to be dragged around as a unit, as is done with a single piece. This would allow the user to assemble subsections of the puzzle in any area, much like is done with a physical jigsaw puzzle, and connect the subsections with one another.
You can check the piece being moved to its four neighbors to see if they are close enough to snap together. If a piece has its proper edge close enough to the proper edge of its neighbor, at the same angle, then they match.
There are several ways to check relative locations. One way would be to temporarily rotate the coordinates of the piece you are testing so it is upright, then rotate the coordinates of all its desired neighbors, also temporarily, to the same angle. (Use the same center of rotation for all the rotations.) Then you can easily test to see if they are close enough to match. If the user is dragging a subassembly, then you will need to check each unmatched edge in the subassembly.
Option 2 is more complex and more realistic. Option 1 can be further simplified by omitting the rotation of pieces and making every piece the proper angle initally.
For a regular shapes you can go with a matrix. I recommend this as the first approach. Dividing the puzzle is as simple as defining X,Y dimensions of the matrix. For each piece you have a series of four values then, one for each side, saying whether it is flat, pointing out, or pointing in. This will give you a very classic jigsaw puzzle setup.
How the pieces actually look becomes a strict GUI thing. Now, for the first draft I recommend getting it working with perfectly square pieces. Taking rectangular bits of an image should be easy to do in any GUI framework.
To go to shaped pieces you'll need a series of templates. These will become masks that you apply to the image. Each mask clips out a tiny portion of the image to produce your piece. You'll probably need to dynamically create the masks in order to fit them to the puzzle. At first start with simply triangular connections. Once you have that working you can do the math to get nice bulbous connector shapes. Look up "clip" and "mask" in your GUI framework.
If you wish to do irregular polygon shapes that don't follow a general matrix layout, then you need to do a lot more work. This is why I recommend getting the square first working as a good example. Now you'll need to delve into graph theory and partitioning. Pick up some books on 3D programming -- focusing on algorithms, as they do partitioning all the time. Though I wouldn't doubt if there is a book with this exact topic in it.
Have fun.
the data structure is simple I guess- each peace will point to it's neighbors and will hold the actual shape to display.
on the MMI (UI) of the app - what is your developing environment ?
If it's windows - I would go with c# and winforms or even better wpf.
if it's unix, you'll have to get someone else's advise, as I'm not an expert there.
1) How to break image into random polygons
It seems that you have figured out this part. (from : "Now I already have images and image pieces, so we don't need algorithm to cut the image in pieces.")
2) what kind of data structure can solve the problem
You can create a Class Piece like Scribble class in this example and your pieces would be array of objects of Piece class.
So, you will have two arrays,
(i) actual image pieces array
(ii) image piece outline array
So, whenever you drag and drop one piece on to the full outline of image, it will check whether the image piece object is intersecting more than 80% and ID (member variable of Piece object) of actual image piece and image piece outline matches, then you got the right piece at right place...
3) UI implementation
Check this out.
You could make an array of objects of the class "PuzzleTile"
Every such tile has an image and an integer
After every move, check if the integers are sorted correctly, means:
123
456
789
You could make a function for that which returns a bool.
Note: I'm currently developing under C#, that's why it's probably easiest to realize especially this concept under C#, although other platforms need none up to barely some modification to this.