I want to create a random fractal terrain on the gpu (with a compute shader). I've started with implementing marching cubes: Generating Complex Procedural Terrains Using the GPU, and it works really good: marching cubes on the gpu. However, marching cubes can't extract sharp features or use an adaptive resolution.
So I looked for an advanced isosurface extraction algorithm and found Dual Contouring of Hermite Data. So I implemented dc in Java to test this algorithm and it looks great: dc on the cpu. (There are some holes in the mesh and no sharp features, but I was too lazy to implement/fix this because it's only a prototype.)
But I've noticed some negative aspects:
Intercell-dependent. (I have no idea how to port this to the gpu: the only resource I've found is Dual Contouring with OpenCL.)
I don't know how to create a chunk system, because there are no "clear" borders https://i.stack.imgur.com/62dy6.png.
So I continued my search for a better algorithm and found Cubical Marching Squares: Adaptive Feature Preserving Surface Extraction from Volume Data. This seems to be the perfect algorithm for me: intercell-independent, adaptive, sharp features, primal structure and even manifold. Unfortunately, there are no resources on how to implement this algorithm except for this Cubical Marching Squares Implementation. I think I understand the two parts of the algorithm: create a grid, for each cell:
Subdivide until the maximum depth is reached or there is no need to do so.
Split each cell into 6 faces, extract their surface and stitch them together.
But I don't know how to connect those two parts (especially the part with transitional faces, page 38).
So does anybody know how to implement dc as a shader, how to implement cms or a better algorithm (maybe dual marching cubes, I think it has the same problem as dc, but I haven't tested it yet)?
As you have already mentioned for the GPU you would need no intercell-dependencies... I'm sure people have come up with workarounds for that on DC but CMS should be one of the best for all those things that you need, namely intercell-independent (by definition), preserves sharp features, creates manifold geometry, and supports adaptive resolution.
In terms of resources on CMS I agree they are quite limited.
The original paper: http://graphics.csie.ntu.edu.tw/CMS/
This project by Matt Keeter has a 'C' CMS implementation in it (https://www.mattkeeter.com/projects/kokopelli/)
https://github.com/mkeeter/kokopelli <-- code
I used Matt Keeter's implementation as a reference for my partial 'C++' implementation (the thesis that you linked), here is the code for it in case you didn't find it:
https://bitbucket.org/GRassovsky/cubical-marching-squares
However keep in mind that it is indeed partial, that is to say it has the main algorithm working (adaptive and manifold), but I haven't got around to implement the sharp-feature preservation, 2D and 3D disambiguation, etc. It is also currently a basic CPU implementation... I had the good intentions to implement all those things and make a GPU implementation but for now have had no time.
"But I don't know how to connect those two parts" - that only goes to say how badly I have written my thesis, because I try to explain how I do this :D (Mind you, I am not sure exactly how this was done in the original paper... should we say that some things are not very clear there and you would have to use your imagination :))
Related
Working on a small side project related to Computer Vision, mostly to try playing around with OpenCV. It lead me to an interesting question:
Using feature detection to find known objects in an image isn't always easy- objects are hard to find, especially if the features of the target object aren't great.
But if I could choose ahead of time what it is I'm looking for, then in theory I could generate for myself an optimal image for detection. Any quality that makes feature detection hard would be absent, and all the qualities that make it easy would exist.
I suspect this sort of thought went into things like QR codes, but with the limitations that they wanted QR codes to be simple, and small.
So my question for you: How would you generate an optimal image for later recognition by a camera? What if you already know that certain problems like skew, or partial obscuring would occur?
Thanks very much
I think you need something like AR markers.
Take a look at ArToolkit, ArToolkitPlus or Aruco libraries, they have marker generators and detectors.
And papeer about marker generation: http://www.uco.es/investiga/grupos/ava/sites/default/files/GarridoJurado2014.pdf
If you plan to use feature detection, than marker should be specific to used feature detector. Common practice for detector design is good response to "corners" or regions with high x,y gradients. Also you should note the scaling of target.
The simplest detection can be performed with BLOBS. It can be faster and more robust than feature points. For example you can detect circular blobs or rectangular.
Depending on the distance you want to see your markers from and viewing conditions/backgrounds you typically use and camera resolution/noise you should choose different images/targets. Under moderate perspective from a longer distance a color target is pretty unique, see this:
https://surf-it.soe.ucsc.edu/sites/default/files/velado_report.pdf
at close distances various bar/QR codes may be a good choice. Other than that any flat textured object will be easy to track using homography as opposed to 3D objects.
http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.html
Even different views of 3d objects can be quickly learned and tracked by such systems as Predator:
https://www.youtube.com/watch?v=1GhNXHCQGsM
then comes the whole field of hardware, structured light, synchronized markers, etc, etc. Kinect, for example, uses a predefined pattern projected on the surface to do stereo. This means it recognizes and matches million of micro patterns per second creating a depth map from the matched correspondences. Note that one camera sees the pattern and while another device - a projector generates it working as a virtual camera, see
http://article.wn.com/view/2013/11/17/Apple_to_buy_PrimeSense_technology_from_the_360s_Kinect/
The quickest way to demonstrate good tracking of a standard checkerboard pattern is to use pNp function of open cv:
http://www.juergenwiki.de/work/wiki/lib/exe/fetch.php?media=public:cameracalibration_detecting_fieldcorners_of_a_chessboard.gif
this literally can be done by calling just two functions
found = findChessboardCorners(src, chessboardSize, corners, camFlags);
drawChessCornersDots(dst, chessboardSize, corners, found);
To sum up, your question is very broad and there are multiple answers and solutions. Formulate your viewing condition, camera specs, backgrounds, distances, amount of motion and perspective you expect to have indoors vs outdoors, etc. There is no such a thing as a general average case in computer vision!
I am looking for a method by which to generate 3D models for use in video games. The idea is virtual primitives that are simply points with associated data for size, shape, material and rotation.
For instance an asteroid might start as two simple spheres that intersect. Material of dusty rock which would tell the skinning algorithm to provide smooth sandy curves and occasional jagged boulders. Probably end up with a sort of lumpy peanut shape.
After that add smaller spheres with material of void or crater, peppered around the object. These would produce crater like areas in the surface of the peanut and the skin would adjust to suit. In the end you would have a semi plausible representation of an asteroid.
Now with that in mind, my question is, are there any decent open source or public domain examples of skinning algorithms that can find the surface of a model and generate a smooth, evenly distributed quad-strip mesh that could be then textured?
Some more information; I'm looking at CSG methods for the underlying models (adding and subtracting volume) then looking at other methods for remeshing the whole thing.
Skinning is an art more than a scientific process (and so almost impossible to automate) because skinning is a visual approximation of movement. To get something fully automatic, you would either have to assume bone placement or simply assume there are none at all.
Here's an example. This is an open-source project that skins automatically based on the fact that the provided mesh is a humanoid.
http://igl.ethz.ch/projects/fast/
EDIT: Wait, you mean the other way around? Isn't that similar to marching cubes? http://en.wikipedia.org/wiki/Marching_cubes
This is an exciting question and no doubt there are many ways it could be done. Personally I'd probably start by getting basic shapes on .obj format, which is easy to both parse and create programmatically, and then do exactly that in my code: tweak or randomize the the vertices you export from a modelling program to create an infinite variety of similar but slightly different objects, like asteroids. Of course if you need more than asteroids, you'd go back to a different .obj file. It's hard to say the best technique for your case since I think some experimentation would be required no matter what you try.
I have been trying to find a suitable global illumination technique, preferably based on OpenGL or GPGPU, to light an outdoor scene which has static objects and dynamic light sources (it is a city model). It does not need to be very detailled or accurate, but it should be rather simple and if possible, iterative and refining (so I can display the intermediate results).
The best matches I found on the internet is Ray tracing, Precomputed Radiance Transfer(PRT) and Radiosity.
Ray tracing will be far too slow for my application. PRT seems to be too complex and has a huge precomputation step, and radiosity seems too slow and I am not sure if it can be implemented multi threaded.
Does anyone know a better technique, or a workaround of the above problems?
In terms of a more realistic and usable approach than svoGI (Crassin's voxel technique), you might consider deferred irradiance volumes, there is a great webGL demo with full source available here, its based around using spherical harmonics.
There are also older techniques like LPV, which you can check out here, here and here.
Yes, this question is old, but people might still stumble upon it.
How about "Voxel Cone Tracing"?
The Unreal Engine 4 implements it and they also described the algorithm in a presentation.
http://www.unrealengine.com/files/misc/The_Technology_Behind_the_Elemental_Demo_16x9_%282%29.pdf
Does anyone know of an implementation of vector fonts in directx?
If not does anyone have a good starting place for this?
Or even any examples of a reader written in Directx with basic zoom support.
Direct vector fonts don't work to well in D3D, as it requires an intermediary texture to hold rasterized data(verts or pixels) and need to do a lot more extra work, thus you need a approach them a little differently to get them working easily and efficiently(if you are performance constrained/care about performance). You should use signed distances fields for this (they up-scale VERY well, but are horrid for down-scaling if your fonts are complex. Hard edges also don't store too well, but this can be fixed by using two channels to store data. Distance fields also allow easy smoothing, bolding, outlining, glowing and drop shadows), al la valve's improved alpha tested advanced vector texture rendering (which incidently references a paper on vector fonts, if you do want to go that way). It is heavily shader reliant (though it can be done in FFP via alpha testing, but using smoothstep in the pixel shader provides a far better result with minimal overhead), but one doesn't need anything beyond ps v1. see http://www.valvesoftware.com/publications.html for the paper, see the shaders in valves source sdk for a complete implementation reference. (I incidently just built a Dx11 based text renderer using this, works wonderfully, though I use a tool to brute force my sdf's so I don't need to create them at runtime).
I'm trying to, in JOGL, pick from a large set of rendered quads (several thousands). Does anyone have any recommendations?
To give you more detail, I'm plotting a large set of data as billboards with procedurally created textures.
I've seen this post OpenGL GL_SELECT or manual collision detection? and have found it helpful. However it can take my program up to several minutes to complete a rendering of the full set, so I don't think drawing 2x (for color picking) is an option.
I'm currently drawing with calls to glBegin/glVertex.../glEnd. Given that I made the switch to batch rendering on the GPU with vao's and vbo's, do you think I would receive a speedup large enough to facilitate color picking?
If not, given all of the recommendations against using GL_SELECT, do you think it would be worth me using it?
I've investigated multithreaded CPU approaches to picking these quads that completely sidestep OpenGL all together. Do you think a OpenGL-less CPU solution is the way to go?
Sorry for all the questions. My main question remains to be, whats a good way that one can pick from a large set of quads using OpenGL (JOGL)?
The best way to pick from a large number of quad cannot be easily defined. I don't like color picking or similar techniques very much, because they seem to be to impractical for most situations. I never understood why there are so many tutorials that focus on people that are new to OpenGl or even programming focus on picking that is just useless for nearly everything. For exmaple: Try to get a pixel you clicked on in a heightmap: Not possible. Try to locate the exact mesh in a model you clicked on: Impractical.
If you have a large number of quads you will probably need a good spatial partitioning or at least (better also) a scene graph. Ok, you don't need this, but it helps A LOT. Look at some tutorials for scene graphs for further information's, it's a good thing to know if you start with 3D programming, because you get to know a lot of concepts and not only OpenGl code.
So what to do now to start with some picking? Take the inverse of your modelview matrix (iirc with glUnproject(...)) on the position where your mouse cursor is. With the orientation of your camera you can now cast a ray into your spatial structure (or your scene graph that holds a spatial structure). Now check for collisions with your quads. I currently have no link, but if you search for inverse modelview matrix you should find some pages that explain this better and in more detail than it would be practical to do here.
With this raycasting based technique you will be able to find your quad in O(log n), where n is the number of quads you have. With some heuristics based on the exact layout of your application (your question is too generic to be more specific) you can improve this a lot for most cases.
An easy spatial structure for this is for example a quadtree. However you should start with they raycasting first to fully understand this technique.
Never faced such problem, but in my opinion, I think the CPU based picking is the best way to try.
If you have a large set of quads, maybe you can group quads by space to avoid testing all quads. For example, you can group the quads in two boxes and firtly test which box you
I just implemented color picking but glReadPixels is slow here (I've read somehere that it might be bad for asynchron behaviour between GL and CPU).
Another possibility seems to me using transform feedback and a geometry shader that does the scissor test. The GS can then discard all faces that do not contain the mouse position. The transform feedback buffer contains then exactly the information about hovered meshes.
You probably want to write the depth to the transform feedback buffer too, so that you can find the topmost hovered mesh.
This approach works also nice with instancing (additionally write the instance id to the buffer)
I haven't tried it yet but I guess it will be a lot faster then using glReadPixels.
I only found this reference for this approach.
I'm using the solution that I've borrowed from DirectX SDK, there's a nice example how to detect the selected polygon in a vertext buffer object.
The same algorithm works nice with OpenGL.