So I saw these posts DX10+ multiple vertex buffers, single index buffer and Using Multiple Vertex Buffers In DX10/DX11 and vague understood Why Directx11 doesn't support multiple index buffers in IASetIndexBuffer
When rendering indexed tris, I was wondering if it is possible to have a vertex buffer and a separate texture coordinate buffer. But then specify the triangles when drawn by like a set of indices into the vertex buffer and a set of indices into the texture coordinate buffer (separate), so a total of 6 indices per triangle. So that I can reuse texture coords and vertices. Because otherwise i have to duplicate vertices for every texture coordinate which I am not too keen on.
Is this possible in DirectX 11?
Duplicating vertices is in fact the standard solution if you need different vertex elements with shared positions.
Related
Let say I have a geometry having unnecessary vertices in vertex list. But those unnecessary vertices are not referenced in face list of this geometry. Will three.js make an extra calculation while rendering this geometry due to unused vertices or will it just ignore those vertices?
Three.js technically doesn't care about the contents of the vertex list. It uses that data to create a buffer, which it sends to the GPU. The same is true for the faces list.
The GPU will look at the faces buffer to determine which vertices to use to draw a particular face. If there are extra vertices in the vertex list, they should be ignored, but they do take up extra memory.
Take a look at how BufferGeometry builds its vertex list (BufferGeometry.attributes.position) and faces list (BufferGeometry.index). This is much closer to how GL and the GPU use these lists, and should give you a clearer picture of how the relationships work.
I'm working on 2D quad batching. The vertex array is very structured: 4 vertices per quad with position and texture vectors, but I only need one color per quad.
Putting duplicate color information in every vertex seems like a waste.
Is there a way I can optimize this?
Color is attribute of vertex and not of primitive. While using vertex attribute arrays openg mandates to have number of vertices should be equal to no tex coords, no of normals, no of colors and so on.
Some references:
How can I specify per-face colors when using indexed vertex arrays in OpenGL 3.x?
How to specify color per primitive for glDrawElements()
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.
I'm drawing a simple cube using 8 vertices and 36 indices. No problem as long as I don't try to texture it.
However I want to texture it. Can I do that with only 8 vertices? It seems like I get some strange texture behaviour. Do I need to set up the cube with 24 vertices and 36 indices to be able to texture the cube correctly?
It just doesn't make sence to use vertices AND indices to draw then. I could just as well use vertices only.
One index refers to one set of attributes (vertex, normal, color, edge flag, etc). If you are willing to have the texture mirrored on adjacent faces of the sides of your cube, you could share both texture and vertex coordinates for the sides. However, the top and bottom faces sharing those same coordinates would not work -- one axis of the texture coordinate would not vary. Once you add other attributes (normal in particular) then a cube would need 24 individual indexes (each with vertex, texture and normal) to have "flat" sides.
Another approach that may work for you is texture coordinate generation. However, needing 24 individual vertices for a cube is perfectly normal.
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.