I'm using 2 of the sensors on the asus xtion pro (kinect knockoff), the RGB cam and the user data as a mask. Not sure if it's called user data, the other one that's not depth or color.
It works except for 2 issues:
When you combine the 2 textures together, the mask is actually slightly offset from the color texture, leaving an outline around the character of the background. I believe it's because the two sensors are simply shooting straight out and aren't calibrated, so one is 2" in real world space off from the other.
The second problem is a question about optimizing the mask edges. Is there any way to feather the edges around the character, or smooth based on the difference of neighboring pixels? I find that the edges really jump around on the edges of objects.
So, the shader I'm using to combine the base texture with the mask requires both textures to be the same size, so I can't simply resize it to be slightly smaller to get rid of the gap around the character.
I'm curious of how you would shrink the mask texture by a couple % and add more black around the edges, like if you resized the texture smaller than the rect it occupies, how could you fill in the perimeter with black?
I'm using Unity + OpenNI + Asus xtion pro sensor. The mis-alignment ins't noticeable in most uses, but when doing something really precise it's not that accurate...
Any ideas or pointers? Looking for direction.
Are you using two Asus Xtion Pro sensors at the same time ? The 3 images on the left look like the scene, depth and rgb streams.
Which version of OpenNI are you using ? I haven't used OpenNI with Unity, but I assume you there are equivalent calls to the original API.
For OpenNI 1.5.x look into the Alternative View Point Capability:
yourDepthGenerator.GetAlternativeViewPointCap().SetViewPoint(image);
For OpenNI 2.x it should be something like:
device.setDepthColorSyncEnabled(true);
If you want to calibrate between two sensors, it's a bit more complicated.
Related
I made a mesh from a Digital Elevation Map that spanned 1x1 degree box of geography, but when I scale the mesh up to 11139m in blender I get these visible jagged shadows on the peaks of the mesh. I'd prefer to not scale everything down but I suppose I can, it just seems like a strange issue I want to better understand.
My goal is to use the landscape in a WebVR application, but when I put this mesh into an Aframe scene it also has this issue. Thanks for any tips!
Quick answer:
I think this may be caused by the clipping start/end values. Also called near/far clipping planes. Adjusting them may fix the issue but also limit the rendering distance.
Longer explanation:
Take a look at this:
It's a simple grayscale, but imagine it is scaled across your entire scene depth (Z depth buffer). The range of this buffer is set by the start/stop clipping (near/far) camera setting.
By default Blender has its start/stop (near/far) clipping set to 0.01 - 1000.
While A-Frame has it like 0.005 - 10000. You may find more information here: A-Frame camera #properties
That means the renderer has to somehow fit every single point in that range somewhere on the grayscale. That may cause overlapping or Z-fighting because it is simply lacking precision to distinguish the details. And that is mainly visible at edges/peaks because the polygons are connected there at acute angles and the program has to round up the Z-values. That causes overlapping visible as darker shadows (most likely the backside of the polygon behind).
You may also want to read more about Z-fighting because it is somewhat related.
Example
I have a problem with detection of chessboard-like pattern. The image is very noisy because it is registered with the use of laser scanner.
The only thing I have managed to achieve is detection of big rectangle:
Now I have no idea how to detect those small squares. I tried all sorts of different algorithms, but the contrast in the squares seems too low. Does anybody have any ideas?
Other pattern images: https://dl.dropboxusercontent.com/u/3681534/kalibrator/6.png https://dl.dropboxusercontent.com/u/3681534/kalibrator/8.png
A way to progress would be to determine the grayvalue level at the inner border of the rectangle, then:
Adjust the average brightness inside the rectangle border.
With that knowledge it is possible to adjust the average brightness inside the rectangle to one value (the small square will still be a bit lighter than the rest)
Increase the contrast a lot
Find the lines that run along the edges of the squares
Either access the line crossings directly or paint white and black
Calculate your calibration data
Im having a weird issue in opengl, it goes like this: im designing a 2d engine, so far i coded the routines that let's you draw sprites, rectangle, boxes, translate and scale them... however when i run a small demo of my engine i notice when scaling gradually rectangles in an animation (drawn using 4 vertices and GL_LINE_LOOP), the rectangle edeges seems to bounce between the two neighboring pixels.
I can't determine the source of the problem or even formulate a proper search query in google, if someone can shed some light on this matter. If my question is not understood please let me know.
Building a 2D library on OpenGL ES is going to be problematic for several reasons. First of all, the Khronos specifications state that it is not intended to produce "pixel perfect" rendering. Every OpenGL ES renderer is allowed some variation in rendered results. This is because the actual rendering is implemented in hardware and floating point rounding can be a little different from platform to platform. Even the shader compilers are completely different from one GPU to the next.
Another issue is that most of the GPUs on mobile devices today are tile-based deferred renderers, and they do not typically support partial screen rendering. In other words, every screen update requires replacing the entire frame.
I want to display mesh models in OpenGL ES 2.0, where it clearly shows the actual mesh, so I don't want smooth shading across each primitive/triangle. The only two options I can think about are
Each triangle has its own set of normals, all perpendicular to the triangles surface (but then I guess I can't share vertices among the triangles with this option)
Indicate triangle/primitive edges using black lines and stick to the normal way with shared vertices and one normal for each vertex
Does it have to be like this? Why can't I simply read in primitives and don't specify any normals and somehow let OpenGL ES 2.0 make a flat shade on each face?
Similar question Similar Stackoverflow question, but no suggestion to solution
Because in order to have shading on your mesh (any, smooth or flat), you need a lighting model, and OpenGL ES can't guess it. There is no fixed pipeline in GL ES 2 so you can't use any built-in function that will do the job for you (using a built-in lighting model).
In flat shading, the whole triangle will be drawn with the same color, computed from the angle between its normal and the light source (Yes, you also need a light source, which could simply be the origin of the perspective view). This is why you need at least one normal per triangle.
Then, a GPU works in a very parallelized way, processing several vertices (and then fragments) at the same time. To be efficient, it can't share data among vertices. This is why you need to replicate normals for each vertex.
Also, your mesh can't share vertices among triangles anymore as you said, because they share only the vertex position, not the vertex normal. So you need to put 3 * NbTriangles vertices in you buffer, each one having one position and one normal. You can't either have the benefit of using triangle strips/fans, because none of your faces will have a common vertex with another one (because, again, different normals).
I vaguely remember seeing something in OpenGL (not ES, which was still at v1.0 on the iPhone when I came across this, which is why I never used it) that let me specify which edges of my polygons were considered outlines vs those that made up the interior of faces. As such, this isn't the same as the outline of the entire model (which I know how to do), but rather the outline of a planar face with all its tris basically blended into one poly. For instance, in a cube made up of tri's, each face is actually two tris. I want to render the outline of the square, but not the diagonal across the face. Same thing with a hexagon. That takes four tris, but just one outline for the face.
Now yes, I know I can simply test all the edges to see if they share coplanar faces, but I could have sworn I remember seeing somewhere when you're defining the tri mesh data where you could say 'this line outlines a face whereas this one is inside a face.' That way when rendering, you could set a flag that basically says 'Give me a wireframe, but only the wires around the edges of complete faces, not around the tris that make them up.'
BTW, my target is all platforms that support OpenGL ES 2.0 but my dev platform is iOS. Again, this Im pretty sure was originally in OpenGL and may have been depreciated once shaders came on the scene, but I can't even find a reference to this feature to check if that's the case.
The only way I know now is to have one set of vertices, but two separate sets of indices... one for rendering tris, and another for rendering the wireframes of the faces. It's a real pain since I end up hand-coding a lot of this, which again, I'm 99% sure you can define when rendering the lines.
GL_QUADS, glEdgeFlag and glPolygonMode are not supported in OpenGL ES.
You could use LINES to draw the wireframe: To get hidden lines, first draw black filled triangles (with DEPTH on) and then draw the edges you are interested in with GL_LINES.