So how do I specify my triangles exactly??

I'm attempting a procedural generation experiment and its come time to assign values to the triangle's.

The Unity docs say to use clockwise corner ordering. My question is: from what perspective? Topdown? Camera perpsective? This is in 3d.

 

From the perspective of the camera. It just defines the normal vector direction, so if your camera is looking at it from one side it's visible and from the other side it isn't. Just try it one way or the other and you'll probably see what I mean.

 

The normals are totally independent of camera. The vertex positions are defined in object space. You define a triangle with 3 points, so geometrically you have two faces. But how would tell which one is front or which one is back? You can't. So there are conventions to decide with one is the front-face or the back-face. The Unity convention is that the vertices are ordered around the normal in a clockwise rotation. So if you follow the three points by their indice order, they define a rotation in space. That rotation defines where the face normal is pointing. To help your visualisation, imagine a screw driver: when you rotate clockwise to tighten the screw, it moves the screw forward in the material, that's where the face normal is pointing.

Edit:
In fact, the screw driver analogy gives you the exact negative of the face normal,
since Unity has a left-handed coordinate system. So if you rotate clockwise to tighten, the normal is the direction from the tip to the head of the screw driver.

 

ericbegue is right. One other note: don't pretend your the camera when assigning the vertices, imagine you standing directly in front of the triangle. Then you want to assign the vertices in a clockwise order from that perspective. Imagine a cube it has 8 corners. the front square we'll label them 0,1,2,3 0 is the top left, 1 is the top right, 2 is the bottom left, 3 is the bottom right. the back square we'll label in the same manner 4,5,6,7.
To make our front 2 triangles we to this:
0,1,2 // this is the top left triangle of the front face
1,2,3 // this is the bottom right triangel of the front face

Now lets to do the back face. if we were still standing in the "front" of the cube we might do this:
4,5,6
5,6,7
This is wrong.. we have to rotate ourselves 180 degrees and face the cube from the back. that puts 4 on the top RIGHT and 5 on the top LEFT so our correct indices are
5,4,7
7,4,6

you would then do the same thing for all the other faces. Keep you numbers static on the corners and pretend your hovering directly in front of that face.
Why do we do this? Because our normal (an arrow pointing directly out from the face of the triangle) is determined to point out from the clockwise direction of the indices. So our front face normal points toward the camera. If we used the first set of indices I showed for the back face (the wrong set) its normal would also point directly to the camera. You don't want that. You want its normal to point away from the camera (since its the back face). Similiar you want the top of the cube to point "up" and so on.
Among other problems with having incorrect normals, is you end up drawing a lot of extra triangles you don't need. One method of culling triangles out of your scene is to detect if the normal is facing away from the camera. So we only draw the front facing traingles, not the backs of them. If the back of your cube was facing the camera (that is its normal is pointing towards it) it would draw that back face, but it would be useless since the front face overwrites it.

 

Just repeating what @takatok said.

Introducing the camera, another way to see (pun: or not) that clockwise bizness is as follow:
From the camera point of view, if you trace the triangle vertices by their index order and they describe a clockwise rotation, then you are looking at the front-face. Otherwise, if you see a counter-clockwise rotation, you are looking at the backface, which is, most of the time, not drawn (backface culling) for performance reason, so invisible.

 

In other words, from the perspective of the camera if you count around the vertices in the clockwise direction the face will be visible because the normal will be facing the camera. Otherwise it won't.

 

I'll have to give this some careful reading later on.

On a related note: is procedural generation supposed to be so much work? I barely got a shape working yesterday after an hour of work (it was a box but with improper normals and missing a corner!). How do games like NMS do this? I would assume they have a crap ton of algorithms. My question is what algorithms specifically?

 

From perspective of looking AT triangle from "outside". If your triangles form a cube, you look at them from outside the cube, the direction of visible triangle verts should be clockwise for all triangles that are facing towards you.

Yes, if you're implementing it from scratch by yourself.

They spend more time writing procedural generation code. Code used in projects like spore or no man's sky can easily take few months or a whole year to create... and that's with a team of people. You won't make a procedural planet in a hour from scratch.

One way to make a procedural planet is to define a sphere via a density field and add/subtract perlin noise from it... then turn the density field into polygons/voxels/something renderable.

Or you could just get a very high-poly sphere and distort it by noise ffunction along the direction of face normal (or away from planet's center).

For a flat map it will be easier to just use recursive fractal generation of landscape.... OR recursive 2d perlin/simplex noise again.

So a lot of it ends up using noise functions.

 

It's not as tough as it sounds. I have an article series on my blog that was for XNA but everything is applicable. It demonstrates using a heighmap to generate terrain and implement LOD and it uses the concepts you're looking for. If you look at the code you can see how to generate triangles in the mesh in clockwise order, and also how to calculate normals for each triangle.

Unfortunately my webserver rebooted and my database died so I'm trying to get my blog back up and running at the moment.

 

Got it:
http://www.dustinhorne.com/post/2011/08/30/XNA-Terrain-with-LOD-Part-4-Drawing-the-Base-Terrain

 

If someone is trying to procedurally generate a box out of indexed triangles for the first time in their life (and they have no experience with modeling, drawing, or never made a blueprint for something on papaer), it wouldn't surprise me if it took them an hour.

Otherwise it is not "impossibly difficult", but "something that takes a bit of getting used to".

 

Yes. On average a procedural system will take about as much effort to build as hand crafting the same content will.

 

Agreed. My point was that once you get your head around the concepts it all just clicks and isn't terrible. That terrain tutorial was actually my first ever exercise in procedural geometry.

 

Yes, procedural generation is a lot of work. Here's a grab from a spline based system I've been working for almost two weeks so far that is supposed to be part of a sponson for a formula racing boat, just to see what type of shapes can be done. I'm on the second rewrite and it's not even generating the triangles yet, these are just little sphere prefabs instantiated where the verts will go.




This is a new system to jazz up my current project, Design it, Drive it : Speedboats.

http://store.steampowered.com/app/501090

It uses procedural mesh generation for the boats so the players can design their own boats and see how they handle. The physics is all done directly on the mesh triangles, so any changes affect how it drives, how fast it goes, etc.. The system it uses right now is something I came up with that's a lot simpler, I'm just trying splines now because I want to make tunnel boats and have a system in place I can use to create newer types of boats more quickly that are better looking and hopefully can be meshed at different resolutions.

Not showing that just for a shameless plug (ok, maybe just a little bit ), this is leading up to your question about algorithms:

The old system that's currently in the simulator was a rib based system. The way it basically worked was that an array of points (vector3s) was defined for the vertices following each rib in the boat which traced around the outside of it in cross sections when viewed from the back of the boat. These were all computed from the specs the player inputs for the boat (width, deadrise angles, step sizes and positions, etc.). These points were more or less copied and scaled forward. Really it was a 2D array where each rib was in one dimension and all the points around that rib were in the other dimension.

Once all the vertices were set in a cross section it would basically just scale each rib down as you moved forward along the boat. There was a little more to it then that, but the basic idea is that it started with ribs of vertices and then duplicated and modified them as you moved forward along the length of the boat. Once all the vertices were laid out, the mesh would be created mostly by tracing around pairs of ribs and making a triangle strip out of the vertices on those ribs. Then move to the next pair and the next and before you know it you've got a whole boat.

The new system from the pic above is similar, but instead of ribs I'm trying to do it all with splines. I start by creating some anchor splines (the pic actually only has three of these in it). Then those anchor splines are linked together in one or more patches and a bunch of other splines are autogenerated to connect all the anchor splines. Then along each of those splines I compute a bunch of vertices. Those splines are created in a certain order so when it comes time to generate the mesh it should just be a matter of walking along the verts in pairs of splines and connecting them with triangles in pretty much the same manner as was done in the simpler rib based system. Only now the shape is defined by the splines so the mesh resolution can be changed with just a few numbers. It should be able to generate an invisible low poly mesh for the physics and a super high detailed one for the graphics.

If I remember correctly, the original rib based system took about two months to do (as close to full time as I could manage) starting with knowing nothing about the Unity Mesh class. At that time I was just looking at simple tutorials showing how to make single triangles and cubes and so on and making it up as I went. So yes, expect to spend a lot of time if you're going the procedural route. Start simple and go from there. I'd start even simpler than a cube, really. Just see if you can do a single triangle first, then maybe see if you can add a fourth vert so you can get two triangles.

By the way, you don't actually have to compute the normal vectors yourself. When your mesh is all built up just call this: https://docs.unity3d.com/ScriptReference/Mesh.RecalculateNormals.html