In this tutorial author displays a cube by defining its 6 faces (6*4 vertices) and then telling webgl about triangles in each face.
Isn't this wasteful? Wouldn't it be better to define just 8 vertices and tell webgl how to connect them to get triangles? Are colors shared by multiple vertices a problem?
To make my concern evident: if the author defines triangles with indices array, why does he need so many vertices? He could specify all triangles with just 8 vertices in the vertex array.
Author of the example here. The issue is, as you suspected, to do with the colouring of the cube.
The way to understand this kind of code most easily is to think of WebGL's "vertices" as being not just simple points in space, but instead bundles of attributes. A particular vertex might be be the bundle <(1, -1, 1), red>. A different vertex that was at the same point in space but had a different colour (eg. <(1, -1, 1), green>) would be a different vertex entirely as far as WebGL is concerned.
So while a cube has only 8 vertices in the mathematical sense of points in space, if you want to have a different colour per face, each of those points must be occupied by three different vertices, one per colour -- which makes 8x3=24 vertices in the WebGL sense.
It's not hugely efficient in terms of memory, but memory's cheap compared to the CPU power that a more normalised representation would require for efficient processing.
Hope that clarifies things.
You can use Vertex Buffer Objects (VBO). See this example. They create a list of Vertices and and a list of Indexes "pointing" to the vertices (no duplication of vertices).
Related
Given an array of triangulate points int[][] so that every three points represents a triangle, how can I mark (identify) just one point for each triangle so that no individual triangle has more than one point marked.
I'm trying to add a z-value to each point so that every triangle only has one point elevated and the other points both have a z-value of 0. The reason I don't want any flat triangles is because then my light source will have little to no affect on the triangle because the normal angle is always facing the light.
Here's a video. The mouse cursor represents the light source above (ignore the beginning where the mouse doesn't affect the lighting). You'll notice some of the triangles have a constant color to them since all its point have a z-value of 0.
https://streamable.com/w5spi
I've tried just adding a point to the centroid of the triangle and creating three new triangles, but it messes with the uniformity of the triangle spacing.
Since Delaunay doesn't provide any simple mean to generate depth, I would suggest using a combination of a Simplex noise function and the Delaunay triangle points.
This way you can "map" the two on top of each other, extract a value underneath the normalized Delaunay triangle points from the Simplex noise function and use that for Z/elevation.
Principle: normalize triangle points from Delaunay, extract Z via the SN function using the normalized x/y position.
There are many Simplex Noise implementations out there for JavaScript. It's worth noting that the 3D version has a patent attached if using the techniques described within the patent. See OpenSimplex noise for an alternative if 3D is needed - npm - in this case though, the 2D version will probably be enough.
Has anyone tried accelerating collision detection via GPU? I thought about passing position+radius for a simple sphere intersection, rendering all intersecting triangle indices to a texture.
Using the GPU
I'm not sure if this is an good idea at all, but the math doesn't seem to be costly for this in vertex shader. It wouldn't resolve anything, just fetching the face indices to indicate which faces are relevant. It's also only supposed for the terrain.
Using the octree
The terrain is generated via dual contouring, and in it's highest lod several thousand nodes can be required, storing face indices based on the dual cells or connecting them to their octree nodes are costly in terms of memory and cpu. It already required a lot optimizations and needs to run multi-threaded, i'd like to avoid additional steps on this side.
It might work using the octree and the density function on the boundaries and trilinear interpolating the surface, but it requires to pass the nodes from the worker, or position to worker. Anyway this wouldn't completely match the polygons of a cell, but at least smooth out the error.
Using the density function
While required octree-nodes and their polygons are adaptive, their size are varying much, so a collision based on the density field function won't always fit the actual underlying geometry, surface can be far below or above the geometry.
Any suggestions?
I'm working on a way to turn the information from 3d-files into THREE geometries. I receive them formated like this:
{"N":"name of the block","V":[[0,1,2]..[N1,N2,N3]],"F":[[0,1,2]..[M1,M2,M3]],"P":[[O1,O2,P3,..,Op]..[..]]}
N should be obvious. It's the name of the geometry.
V is an array of vertices.
F is an array of triangular faces.
So far so good. That's easy to convert into THREE geometries. P is the tricky part. It's an array of polygons. A polygon is in this case a face consisting of a number of vertex indices bigger than four.
There's no actual restriction how many vertex indices may hold, apart from the minimum of five.
Is there any working way to convert a structure like this for THREEjs?
three.js supports a Face3 class only. It used to have a Face4 class, but you need something completely different to handle polygons. The short answer is no, three.js does not handle this out of the box.
A simple way to tackle it is to create a fan out of your polygons by fixing one vert, and looping through the rest, but this will work only on convex polygons.
https://en.wikipedia.org/wiki/Polygon_triangulation
Not a trivial problem.
I've started using three.js, and I know there is coloring on vertices in three.js, but I'm investigating whether there is some way in three.js or generally in WebGL to have indexed colors for vertices? For example I would restrict coloring from blue, over yellow to red on a scale from minimum to maximum value, based on some values i give to the vertex, and the gradient between two vertices must use that scale of indexed colors. The practical example would be use in Finite Element Method visualisation.
So, do you know how one might hack this?
Store the indices with the vertex, and pass them on to the fragment shader. In the fragment shader, use the interpolated index to do a lookup in a 1d(*) texture containing the color gradiënt.
(*) Note that WebGL doesn't actually support true 1d textures, the common approach is to use an Nx1 2D texture.
I am trying to learn some WebGL (from this tutorial http://learningwebgl.com/blog/?page_id=1217). I followed the guide, and now I am trying to implement my own demo. I want to create a graphics object that contains buffers and data for each individual object to appear in the scene. Currently, I have a position vertex buffer, a texture coordinate buffer, and a normals buffer. In the tutorial, he uses another buffer, an index buffer, but only for cubes. What is the index buffer actually for? Should I implement it, and is it useful for anything other than cubes?
Vertices of your objects are defined by positions in 3D coordinate system (euclidian coordinate system). So you can take every two following vertices and connect them with line right after your 3D coordinate systems is projected to 2D raster (screen or some target image) by rasterization process. You'll get so called wireframe.
The problem of wireframe is that it's not definite. If you look to the wireframe cube at particular angles, you cannot say, how is the cube exactly rotated. That's because you need to use visibility algorithms to determine, which part of the cube is closer to the observers position (position of camera).
But lines itself cannot define surface, which is necessary to determine which side of the cube is closer to observer that others. The best way how to define surfaces in computer graphics are polygons, exactly the triangle (it have lots of cons for computer graphics).
So you have cube now defined by triangles (so call triangle mesh).
But how to define which vertices forms triangle? By the index buffer. It contains index to the vertex buffer (list with your vertices) and tells the rasterizing algorithm which three vertices forms triangle. There are lot of ways, how to interpret indexes in index buffer to reduce repetition of same vertices (one vertex might be part of lot of triangles), you may find some at article about graphics primitives.
Technically you don't need an index buffer. There are two ways to render geometry, with
glDrawArrays and glDrawElements. glDrawArrays doesn't use the index buffer. You just write the vertices one after the other into the buffers and then tell GL what to do with the elements. If you use GL_TRIANGLES as mode in the call, you have to put triples of data (vertices, normals, ...) into the buffers, so when a vertex is used multiple times you have to add it mutliple times to the buffers.
glDrawElements on the contrary can be used to store a vertex once and then use it multiple times. There is one catch though, the set of parameters for a single index is fixed, so when you have a vertex, where you need two different normals (or another attribute like texture coordinates or colors) you have to store it for each set of properties.
For spheres glDrawElements makes a lot of sense, as there the parameters match, but for a cube the normals are different, the front face needs a different normal than the top face, but the position of the two vertices is the same. You still have to put the position into the buffer twice. For that case glDrawArrays can make sense.
It depends on the data, which of calls needs less data, but glDrawElements is more flexible (as you can always simulate glDrawArrays with an index buffer which contains the numbers 0, 1,2, 3, 4, ...).