I'm writing an OpenGL 2D library in Python. Everything is going great, and the codebase is steadily growing.
Now I want to write unit tests so I don't accidently bring in new bugs while fixing others/making new features. But I have no idea how those would work with graphics libraries.
Some things I thought of:
make reference screenshots and compare them with autogenerated screenshots in the tests
replace opengl calls with logging statements and compare logs
But both seem a bad idea. What is the common way to test graphics libraries?
The approach I have used in the past for component level testing is:
Use a uniform colored background, with a few different colors.
Use uniform colored rectangles as graphical objects in tests (with a few different colors).
Place rectangles in known places where you can calculate their projected position in the image by yourself.
Calculate expected intensity of each channel of each pixel (background, foreground or mixture).
If you have a test scenario that results in non-round positions, use a non-accurate compare (e.g. correlation)
Use calculations to create expected result images.
Compare output images to expected result images.
If you have a blur effect, compare sum of intensity instead of discrete intensities.
As graham stated, internal units may be unit-testable free from graphics calls.
Break it down even further.
The calls that make the graphics will rely on algorithms - test the algorithms.
Related
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 am currently developing an application based on OpenCV/C++ to track small animals:
Here is a example of the kind of video it should process. The program simply output the x,y position of the animal and the time for each area. This is graphical representation of the result onto the original.
My question is a bit awkward --- and maybe off topic --- in that I am not asking how to improve my program, but how to assess it. I am aware of the existence Bonn Benchmark on Tracking dataset, but it is not appropriate to my case.
The program is meant to process very long video, therefore, I cannot realistically ask independent humans to assess the position of the animals and compare human vs. program.
I have also considered using robots or putting transponders on bigger animals in order to have the precise positions, but I do not really have the resources.
I came out with the idea of using a program to generate videos of blobs moving in a 2d environment. My question is simple:
Are you aware of any programmable high-level framework that I could use to graphically simulate the motion of an object moving stochastically in a parametrisable background ?
My dream would be to have a command line tool that would work like this:
$ program [BACKGROUND_OPTIONS] [OBJECT_OPTIONS] -V VIDEO_OUTPUT -P POSITIONS_OUTPUT
The background texture could be manipulated as well as the shape, colour and motion pattern of the object moving.
I know that I could probably "easily" make it myself (and I will if I cannot find anything), but I would prefer if the program assessed and the reference were as much independent as they can (for instance not both made by the same person).
One thing I've seen several motion detection/tracking projects do is create test videos with some 3D rendering software such as Blender. It doesn't have the simple interface of your dream test creator, but it's a good testing tool for lots of reasons:
You can set up whatever scenario you want (varying perspective, number of objects, test length, motion paths, etc.)
You completely control lighting parameters, shapes, sizes, etc.
You can design simple tests to verify basic functionality (solid color background with solid colored moving spheres makes a good starting point), then branch into more complex scenarios (other static objects, objects occluding other objects, background images, and so on).
I'm working with an environmental reflection in OpenGL+GLSL.
I want to reflect the environment around an object in the most accurate way possible.
I found basically two way to do this, one is called SphericalMapping and the other is CubeMapping.
They differ in the shader code but really don't understand what is the difference between them.
Obviously for the cubemapping shader I have 6 images printed on a cube that are needed for the fragment shader to look the right pixel, and for my Spheric mapping shader a single image which is distorted with a photo-retouch software or obtained by taking a photo of a specular reflective sphere.
The drawbacks of spherical mapping seems to be that the camera (and the person which holds it) is always showed in the image and the sampling is non-uniform. What is meant by this latest statement? What is meant by "black-hole" effect in spherical mapping?
I would like to find an interactive demonstration of the differences and drawbacks of these two approaches, it seems like cubemapping is the best, but don't know why.
What is the best of the two especially for a realtime simulation with head tracking in your opinion?
Spheremaps are usually for small, low quality stuff.
The drawbacks of spherical mapping seems to be that the camera (and the person which holds it) is always showed in the image
We're talking about computer graphics here; there is no real camera, or no real person. Try imagegoogling "spheremap", you won't see anybody in the pictures.
the sampling is non-uniform
This means that the center of the spheremap has many pixels for a relatively small area, while near the border, you have few pixels for a relatively large area.
Cubemaps are almost always better : you can generate them at runtime easily, it's faster to sample for the hardware, and even though you have 6 textures instead of 1, you can use a lower resolution and still get the same quality.
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.