I'm currently dealing with OpenGL ES (2, iOS 6)… and I have a question
i. Let be a mesh that has to be drawn. Moreover,
ii. I can ask for a rotation/translation so that the point of view changes.
So,
how can I know (in real time) the position of any vertex that is displayed?
Thank you in advance.
jgapc
It's not entirely clear what it is you are after, but if you want to know where your object is after doing a bunch of rotations and translations, then one very easy option, if you perform these changes in your program code instead of in the shader, is to simply take the entire last row or column of your transformation matrix (depends if you are using row or column major matrices) which will be the final translation of your object's center as a coordinate vector.
This last row or column is the same thing as multiplying your final transformation matrix by your object's local coordinate center vector, which is (0,0,0,1).
If you want to know where an object's vertex is, rather than the object's center, then multiply that vertex in local coordinate space by the final transformation matrix, and you will get the new coordinate where that vertex is positioned.
There are two things I'd like to point out:
Back-face culling discards triangles, not vertices.
Triangles are also clipped so that they're within the viewing frustum.
I'm curious as to why you care about what is not displayed?
Related
In XNA, I can change the world matrix when rendering polygons with vertexes (either buffered or dynamic) to shift their position in the world, without having to reconstruct the vertex arrays. In OpenGL, popping and pushing matrixes (i.e. changing the world matrix) is how you render things at various positions, however, I'm not sure whether this is considered to be the correct way of doing this in XNA.
Is adjusting the world matrix on a per model / per object basis to render them the correct way of doing it in XNA, or should I reconstruct the vertex arrays when I want to draw something at a different position?
You don't need to recosntruct...
The right way is passing the object's world transformation to the effect, and the associated vertex shader will use it to transform your vertex in the GPU.
I'm creating a 3D globe with a map on it which is supposed to unravel and fill the screen after a few seconds.
I've managed to create the globe using three.js and webGL, but I'm having trouble finding any information on being able to animate a shape change. Can anyone provide any help? Is it even possible?
(Abstract Algorithm's and Kevin Reid's answers are good, and only one thing is missing: some actual Three.js code.)
You basically need to calculate where each point of the original sphere will be mapped to after it flattens out into a plane. This data is an attribute of the shader: a piece of data attached to each vertex that differs from vertex to vertex of the geometry. Then, to animate the transition from the original position to the end position, in your animation loop you will need to update the amount of time that has passed. This data is a uniform of the shader: a piece of data that remains constant for all vertices during each frame of the animation, but may change from one frame to the next. Finally, there exists a convenient function called "mix" that will linearly interpolate between the original position and the end/goal position of each vertex.
I've written two examples for you: the first just "flattens" a sphere, sending the point (x,y,z) to the point (x,0,z).
http://stemkoski.github.io/Three.js/Shader-Attributes.html
The second example follows Abstract Algorithm's suggestion in the comments: "unwrapping the sphere's vertices back on plane surface, like inverse sphere UV mapping." In this example, we can easily calculate the ending position from the UV coordinates, and so we actually don't need attributes in this case.
http://stemkoski.github.io/Three.js/Sphere-Unwrapping.html
Hope this helps!
In 3D, anything and everything is possible. ;)
Your sphere geometry has it's own vertices, and basically you just need to animate their position, so after animation they are all sitting on one planar surface.
Try creating sphere and plane geometry, with same number of vertices, and animating sphere's vertices with interpolated values of sphere's and plane's original values. That way, on the start you would have sphere shape and in the end, plane shape.
Hope this helps, tell me if you need more directives how to do it.
myGlobe.geometry.vertices[index].position = something_calculated;
// myGlobe is instance of THREE.Mesh and something_calculated would be THREE.Vector3 instance that you can calculate in some manner (sphere-plane interpolation over time)
(Abstract Algorithm's answer is good, but I think one thing needs improvement: namely using vertex shaders.)
You make a set of vertices textured with the map image. Then, design a calculation for interpolating between the sphere shape and the flat shape. It doesn't have to be linear interpolation — for example, one way that might be good is to put the map on a small portion of an sphere of increasing radius until it looks flat (getting it all the way will be tricky).
Then, write that calculation in your vertex shader. The position of each vertex can be computed entirely from the texture coordinates (since that determines where-on-the-map the vertex goes and implies its position) and a uniform variable containing a time value.
Using the vertex shader will be much more efficient than recomputing and re-uploading the coordinates using JavaScript, allowing perfectly smooth animation with plenty of spare resources to do other things as well.
Unfortunately, I'm not familiar enough with Three.js to describe how to do this in detail, but all of the above is straightforward in basic WebGL and should be possible in any decent framework.
I want to create a shader to outline 2D geometry. I'm using OpenGL ES2.0. I don't want to use a convolution filter, as the outline is not dependent on the texture, and it is too slow (I tried rendering the textured geometry to another texture, and then drawing that with the convolution shader). I've also tried doing 2 passes, the first being single colorded overscaled geometry to represent an oultine, and then normal drawing on top, but this results in different thicknesses or unaligned outlines. I've looking into how silhouette's in cel-shading are done but they are all calculated using normals and lights, which I don't use at all.
I'm using Box2D for physics, and have "destructable" objects with multiple fixtures. At any point an object can be broken down (fixtures deleted), and I want to the outline to follow the new outter counter.
I'm doing the drawing with a vertex buffer that matches the vertices of the fixtures, preset texture coordinates, and indices to draw triangles. When a fixture is removed, it's associated indices in the index buffer are set to 0, so no triangles are drawn there anymore.
The following image shows what this looks like for one object when it is fully intact.
The red points are the vertex positions (texturing isn't shown), the black lines are the fixtures, and the blue lines show the seperation of how the triangles are drawn. The gray outline is what I would like the outline to look like in any case.
This image shows the same object with a few fixtures removed.
Is this possible to do this in a vertex shader (or in combination with other simple methods)? Any help would be appreciated.
Thanks :)
Assuming you're able to do something about those awkward points that are slightly inset from the corners (eg, if you numbered the points in English-reading order, with the first being '1', point 6 would be one)...
If a point is interior then if you list all the polygon edges connected to it in clockwise order, each pair of edges in sequence will have a polygon in common. If any two edges don't have a polygon in common then it's an exterior point.
Starting from any exterior point you can then get the whole outline by first walking in any direction and subsequently along any edge that connects to an exterior point you haven't visited yet (or, alternatively, that isn't the edge you walked along just now).
Starting from an existing outline and removing some parts, you can obviously start from either exterior point that used to connect to another but no longer does and just walk from there until you get to the other.
You can't handle this stuff in a shader under ES because you don't get connectivity information.
I think the best you could do in a shader is to expand the geometry by pushing vertices outward along their surface normals. Supposing that your data structure is a list of rectangles, each described by, say, a centre, a width and a height, you could achieve the same thing by drawing each with the same centre but with a small amount added to the width and height.
To be completely general you'd need to store normals at vertices, but also to update them as geometry is removed. So there'd be some pushing of new information from the CPU but it'd be relatively limited.
When rendering 3D rectangles (i.e. rectangles in 3D space), of course, they are specified as a list of vertexes for two triangles. However, that representation contains a lot of extraneous information that gets tiresome to code multiple times. I'd like to create a "Rectangle" object that will allow me to specify its texture, size, position, and orientation in space and export the list of vertexes (and indexes), but I'm not sure of the best way to do it. Should I specify the position of the lower left corner (pre-rotation), or the center of the rectangle? How should I specify the orientation, as a vector containing rotation angles? This is such a simple and standard requirement that I'm sure people have thought about it before, but I can't find anything on this site or elsewhere on the subject. I plan to use these objects a lot, so my primary goal (apart from performance) is ease of use rather than anything to do with the internal representation. It wouldn't be hard for me to simply code the first thing I can think of, but I don't want to miss anything and make it unnecessarily difficult.
So, how should I represent a Rectangle object? Opinions are welcome, but sources would be especially helpful.
Edit: if it helps, I believe I'd primarily be using the rectangles on the faces of cubes, though not necessarily as the entire faces of those cubes.
It would probably be simplest to store the homogeneous matrix that transforms a standard, axis-aligned square into the desired location, along with a separate matrix that determines how to map the texture onto it.
For the location matrix, you can store the 4x3 matrix that doesn't affect the w-coordinate. This is only a bit redundant: it uses 12 values where a general rectangle needs 8, but on the other hand, it will be much easier to convert it back to a form usable for rendering.
Alternately, you can store a point location (edge or center depending on whatever is most convenient), and two direction vectors, describing the direction and length of each edge; you are relying on your rectangle generator to make sure the edge vectors are orthogonal. This will take 9 values, which is almost the best you can do.
For the texture mapping, you can store a 3x2 matrix that defines an affine mapping of the (u,v) coordinates onto the coordinates defined by the edges of the rectangle. You can choose a zero-based (0,1)x(0,1) mapping, or a symmetric (-1,1)x(-1,1) mapping, based on whatever is convenient for your application. In any case, this will require 6 values.
As a rectangle is just a bounded plane, what about storing it as an extension of that: a point and a normal vector (defining the centre---or perhaps one of the corners---and orientation); but add in two more components for the width and height bounds?
I think it really depends on how you intend to use the rectangle.
For example: If you have lots of rectangles, storing the three points of one of the two triangles might be best, because it you only have to calculate one more point.
If you typically center your rectangles on something the center point, width, height and rotation angles might be more appropriate.
I'd say: start with what ever seems naturally for you. Make sure your class is able to do all the necessary calculations and hide them behind accessors. Have a good suite of tests for that.
That way you can change the implementation any time. Or you can even have different rectangle implementations for different needs
if you are calculating the normals of a polygon for rendering it on WebGL, do you use a normal for every index in the index array or for every vertex on the vertex array?
In the notes here, the user is calculating them for each vertex.
Every vertex. A vertex, in the WebGL sense (which is the same as OpenGL ES and other predecessors), isn't really a point in space, but rather a combination of attributes. One of these is almost always the location (though in unusual cases you might not have that), and others are generally things like the normal vector, the colour, the texture coordinates, and so on.
The index array, by contrast, is an offset into the vertex attribute arrays. So when you specify index (say) 1 in an index array, it's shorthand for "the vertex made of combining the first location in the location buffer, the first normal in the normal buffer, the first colour in the colour buffer, and the first texture coordinate in the texture coordinate buffer".
The most counter-intuitive thing for me when learning this was separating vertices from the locations they happen to occupy. There's no reason why two vertices can't have the same location.