I am working on a project where I am to use the Kinect to track facial expressions and animate a 3D model (.ply) accordingly.
So far I have managed to track a human face with a finite number of key-points on the face. I am able to get the coordinates of each key-point at every frame.
I am not very adept with animating techniques and general concepts of Mesh deformation and would really appreciate if one could provide a library which provides a high-level API so as to do said animation using x,y coordinates of key-points.
I am aware of CUBICA but unsure whether it can be used for what I want. Please excuse me as I am not very adept with this and would appreciate any help.
I too am looking for something that would do this (with .NET if possible), so I could hook Kinect up, set the position of each joint and see the character animate - without needing to set the position and angle of each bone which quickly gets very complex when you take into account the X,Y and Z positions.
So far my research has lead me to believe I will need a 3D engine that supports inverse kinematics - if anyone else had any better advice I'd be keen to hear it.
Related
I am a newbie in both OpenGL as well as Three.js, I am working on a streaming based "on-line" viewer which uses websockets to transmit points (with surface normals) from one system application to a remote web interface. Long story short, I have modified BufferGeometry and use THREE.PointsMaterial to visualize incoming data with points.
Since I already am sending points locations [xyz], color [rgb] and normals [abc] so I would love to use technique such as surface-splatting Splatting. Unfortunately due to my limited knowledge and lack of internet resources can any one guide me to implement a very basic surface splatting technique using three.js?
Question: How to draw elliptical surfaces instead of points in three.js
Any help will be highly appreciated.
it would probably work using points if you compute the point-size per point such that the whole ellipsis fits in there and use the fragment-shader to compute the area of the ellipsis based on the viewing-angle (i suppose this is what you want to do, right?).
Alternatively, you can use instancing based on a simple quad and use instance-attributes for position and orientation of the quads. In this case, you just need to render a circle into each of the quads.
I am curious about the limits of three.js. The following question is asked mainly as a challenge, not because I actually need the specific knowledge/code right away.
Say you have a game/simulation world model around a sphere geometry representing a planet, like the worlds of the game Populous. The resolution of polygons and textures is sufficient to look smooth when the globe fills the view of an ordinary camera. There are animated macroscopic objects on the surface.
The challenge is to project everything from the model to a global map projection on the screen in real time. The choice of projection is yours, but it must be seamless/continuous, and it must be possible for the user to rotate it, placing any point on the planet surface in the center of the screen. (It is not an option to maintain an alternative model of the world only for visualization.)
There are no limits on the number of cameras etc. allowed, but the performance must be expected to be "realtime", say two-figured FPS or more.
I don't expect ayn proof in the form of a running application (although that would be cool), but some explanation as to how it could be done.
My own initial idea is to place a lot of cameras, in fact one for every pixel in the map projection, around the globe, within a Group object that is attached to some kind of orbit controls (with rotation only), but I expect the number of object culling operations to become a huge performance issue. I am sure there must exist more elegant (and faster) solutions. :-)
why not just use a spherical camera-model (think a 360° camera) and virtually put it in the center of the sphere? So this camera would (if it were physically possible) be wrapped all around the sphere, looking toward the center from all directions.
This camera could be implemented in shaders (instead of the regular projection-matrix) and would produce an equirectangular image of the planet-surface (or in fact any other projection you want, like spherical mercator-projection).
As far as I can tell the vertex-shader can implement any projection you want and it doesn't need to represent a camera that is physically possible. It just needs to produce consistent clip-space coordinates for all vertices. Fragment-Shaders for lighting would still need to operate on the original coordinates, normals etc. but that should be achievable. So the vertex-shader would just need compute (x,y,z) => (phi,theta,r) and go on with that.
Occlusion-culling would need to be disabled, but iirc three.js doesn't do that anyway.
I have a photos that is taken by 360 degree lance now does anyone know how to create 360 degree photo viewer ?
please don't send the link of already developed softwares , it would be better if someone has
the road map / example code / articles.
Preferred Technologies Could be
Java/Flash/Flex/HTML 5 / javascript
Well I haven't done it myself yet but it basically boils down to projecting the photos you have to some camera surrounding primitive.
Easiest would be a cube but this will probably result in not so good results especially at the edges and corners. Better would be a sphere on which the images are projected.
But basically, adding 3D-primitives and mapping textures on it should easily be capable with Java or Flash. If you try to program it for browsers, have a look at WebGL. This would be a more future-oriented approach that doesn't need Flash... And it already provides good methods for texture mapping on surfaces.
If by 360° you only mean the horizontal plane you could also use a cylinder, which makes it much easier than projecting on spheres. You'll just need a wide panorama photo that goes around completely and map it to the cylinder.
So basically no matter which primitive you choose you'll need to position your camera within this primitive, project the photos to the primitive and implement some controls that allow the user to rotate the camera freely.
Can you provide any example photos? This would make it easier to find a way to solve your problem and find a good way of projecting the texture...
Hope that helps... if not, keep asking...
I want to convert mouse's current X and Y coordinates into the 3D space I have drawn in the viewport. I need to do this on the OpenGL ES platform. I found following possible solutions implemented in OpenGL, but none fits what I am looking for.
I found NeHe's tutorial on doing exactly this, but in traditional OpenGL way. It uses gluUnProject.
http://nehe.gamedev.net/data/articles/article.asp?article=13
Although gluUnProject is not available in OpenGL ES, its implementation seems simple enough to port back. But before calling it, we need to call glReadPixels with GL_DEPTH_COMPONENT and that is not possible in OpenGL ES. (The reason I found in this thread: http://www.khronos.org/message_boards/viewtopic.php?f=4&t=771)
What I want to do is similar to picking, except that I don't want to select the object but I want exact coordinates so that I can recognize particular portion of the object that is currently under mouse cursor. I went through the Picking tutorials in this answer.
https://stackoverflow.com/posts/2211312/revisions
But they need glRenderMode, which I believe is absent in OpenGL ES.
If you know how to solve this problem in OpenGL ES, please let me know.
Thanks.
I think the general solution is to figure out where in world space the clicked coordinate falls, assuming the screen is a plane in the world (at the camera's location). Then you shoot a ray perpendicular to the plane, into your scene.
This requires "world-space" code to figure out which object(s) the ray intersects with; the solutions you mention as being unsuitable for OpenGL ES seem to be image-based, i.e. depend on the pixels generated when rendering the scene.
With OpenGL ES 2.0 you could use a FBO and render the depth values to a texture. Obviously, this wouldn't be exactly cheap (just a way around the restriction of glReadPixels)...
Further, since - as I understand it - you want to pick certain parts of your object you might want to do some sort of color-picking where each selectable portion of the object has an unique color (note that the Lighthouse 3D tutorial only shows the general idea behind color-picking, your implementation would probably be different). You could optimize a little by performing a ray/bounding-box intersection beforehand and only rendering the relevant candidates to the texture used for picking.
I need the fastest sphere mapping algorithm. Something like Bresenham's line drawing one.
Something like the implementation that I saw in Star Control 2 (rotating planets).
Are there any already invented and/or implemented techniques for this?
I really don't want to reinvent the bicycle. Please, help...
Description of the problem.
I have a place on the 2D surface where the sphere has to appear. Sphere (let it be an Earth) has to be textured with fine map and has to have an ability to scale and rotate freely. I want to implement it with a map or some simple transformation function of coordinates: each pixel on the 2D image of the sphere is defined as a number of pixels from the cylindrical map of the sphere. This gives me an ability to implement the antialiasing of the resulting image. Also I think about using mipmaps to implement mapping if one pixel on resulting picture is corresponding to more than one pixel on the original map (for example, close to poles of the sphere). Deeply inside I feel that this can be implemented with some trivial math. But all these thoughts are just my thoughts.
This question is a little bit related to this one: Textured spheres without strong distortion, but there were no answers available on my question.
UPD: I suppose that I have no hardware support. I want to have an cross-platform solution.
The standard way to do this kind of mapping is a cube map: the sphere is projected onto the 6 sides of a cube. Modern graphics cards support this kind of texture at the hardware level, including full texture filtering; I believe mipmapping is also supported.
An alternative method (which is not explicitly supported by hardware, but which can be implemented with reasonable performance by procedural shaders) is parabolic mapping, which projects the sphere onto two opposing parabolas (each of which is mapped to a circle in the middle of a square texture). The parabolic projection is not a projective transformation, so you'll need to handle the math "by hand".
In both cases, the distortion is strictly limited. Due to the hardware support, I recommend the cube map.
There is a nice new way to do this: HEALPix.
Advantages over any other mapping:
The bitmap can be divided into equal parts (very little distortion)
Very simple, recursive geometry of the sphere with arbitrary precision.
Example image.
Did you take a look at Jim Blinn's articles "How to draw a sphere" ? I do not have access to the full articles, but it looks like what you need.
I'm a big fan of StarconII, but unfortunately I don't remember the details of what the planet drawing looked like...
The first option is triangulating the sphere and drawing it with standard 3D polygons. This has definite weaknesses as far as versimilitude is concerned, but it uses the available hardware acceleration and can be made to look reasonably good.
If you want to roll your own, you can rasterize it yourself. Foley, van Dam et al's Computer Graphics -- Principles and Practice has a chapter on Bresenham-style algorithms; you want the section on "Scan Converting Ellipses".
For the point cloud idea I suggested in earlier comments: you could avoid runtime parameterization questions by preselecting and storing the (x,y,z) coordinates of surface points instead of a 2D map. I was thinking of partially randomizing the point locations on the sphere, so that they wouldn't cause structured aliasing when transformed (forwards, backwards, whatever 8^) onto the screen. On the downside, you'd have to deal with the "fill" factor -- summing up the colors as you draw them, and dividing by the number of points. Er, also, you'd have the problem of what to do if there are no points; e.g., if you want to zoom in with extreme magnification, you'll need to do something like look for the nearest point in that case.