I know that for OpenGL, by default, the vertices are set in a counterclockwise direction. Is this the case in Vulkan?
For OpenGL:
A
|\
| \
| \
B---C
In Vulkan you need everything explicitly specified, and you can choose between counter-clockwise or clockwise when you set your VkPipelineRasterizationStateCreateInfo (see VkFrontFace).
VkPipelineRasterizationStateCreateInfo rastStateInfo{};
rastStateInfo.frontFace = VK_FRONT_FACE_COUNTER_CLOCKWISE;
Related
I created a simple triangle in a blender with three vertices.
The picture shows the coordinates in the blender.
I export the model with default settings, including "+Y up"
However, here are the vertexes that the .bin file contains.
vertexes:
-1 0 2
1 0 1.5
0 0 -3
indeces
0 1 2
As can be seen, the Z-axis values have changed sign.
Why so?
My guess:
Blender as far as I understand uses left-side coordinate system, and gltf uses right-side coordinate system, maybe that's why it changes the Z-axis.
But, the gltf specification says: "glTF defines +Y as up, +Z as forward, and -X as right;" why then does the X axis not change? After all, in blender +X is right.
Are there any options or requirements which make
CGAL::Polygon_mesh_slicer output to be in correct order.
eg. I've loaded a mesh and converted it to CGAL::Surface_mesh. Then I've used slicer on that mesh to get list of polylines. Problem is that these polylines are not in any order CW or CCW.
To be more precise, output polylines are not consecutive
Here is a slice of a cube from the top.
o---1--o
| |
2 3
| |
o--4---o
I would expect that output will be like: 1->2->4->3 or reverse
But I got more or less 1->4->2->3
As stated here, "Each resulting polyline P is oriented such that for two consecutive points p and q in P, the normal vector of the face(s) containing the segment pq, the vector pq, and the orthogonal vector of plane is a direct orthogonal basis. The normal vector of each face is chosen to point on the side of the face where its sequence of vertices is seen counterclockwise."
So the orientation of the polylines depends on the orientation of the plane and of the mesh faces.
in my program, I have a solid in top view which I cut using cutting plane (by drawing a line on top view - XY plane). After the solid is cut using this line, I have to show the front face of the cut part on XY plane so I can print the diagram of cross section on paper. So once I have a rectangle of cut face (in front view - XZ plane) and I have to transform it to show in XY plane. How can I do this using VB.net.
I saw this question here: convert 3D plane to 2D
and code provided by user Kieth.
Is this solution relevant to my problem?
Edit: This edit is related to Nico Schertler's answer. I read up on vectors and basic coordinate geometry. how should I get direction vector? For example, the cut line that cuts my solid cube is defined by: stPt(-1500, 24038, 0) and edPt(45500, 24038, 0). The cut face of the solid is rectangle: pt1(-350, 24038, 0), pt2(1335, 24038, 0), pt3(1335, 24038, -350) and pt4(-350, 24038, -350).
I have to transform each coordinate of this rectangle, so that it is lying in XY plane. Currently it is XZ plane. So here, the direction vector is the direction of cut line or each edge of the rectangle? I hope I am not confusing anyone.
You basically want to transform the 3D-Points to a local 2D coordinate system. We need several things for that:
The coordinates of the local origin. This might be the center of mass of the cut shape or the point average. Anyway, it should lie in the same plane as the cut shape.
The direction of the local up-vector. This is simply (0, 0, 1) because you don't transform this direction.
The direction of the local right-vector. This is given by the cut line's direction. It is of the form (rx, ry, 0). This vector should be normalized.
Then we can calculate the local coordinates (u, v) of a 3D point p as follows:
d = p - origin;
u = dot(d, rightVector);
v = dot(d, upVector); //this is simply d.z because upVector=(0,0,1)
You can use the local coordinates (u, v) to display the cut shape. This can also be expressed using a matrix:
/ u \ / rightVector.x rightVector.y rightVector.z \ / d.x \
\ v / = \ upVector.x upVector.y upVector.z / * | d.y |
\ d.z /
I have two rectangles, one is moving and one is stationary. I have the size of both rectangles and both the current coordinates of the moving rectangle and the coordinates of where it wants to go. It will move in a straight line. With this information, what is the most effective way to find if the two boxes will collide on the path. Is it more efficient to do this or to move the box a small amount each frame and do a collision detection each time?
Since one of the rectangles is stationary, one way to do this is to create a polygon of the path travelled by the moving rectangle, which can be done using only its initial and final positions:
(initial position)
+--------+
|\ |\
| \ | \
+--\-----+ \
\ \ \ \
\ +-----\--+
\ | \ |
\| \|
+--------+
(final position)
Path polygon:
+--------+
| \
| \
+ \
\ \
\ +
\ |
\ |
+--------+
Then use a normal polygon collision detection algorithm between the stationary rectangle and the path polygon.
If it's moving at a constant speed the most efficient way is to calculate when they will collide (Time = Speed/Distance) and if they will collide (Derive a linear equation of motion, and see if it will pass through the stationary rectangle). If it's moving at a variable speed, perform these calculations each time the speed changes. These are both far more efficient than comparing for each frame.
My concern are quadratic bezier triangles which I'm trying to tesselate for rendering them.
I've managed to implement this by subdividing the triangle recursively like described in a wikipedia page. Though I'd like to get more precision to subdivision. The problem is that I'll either get too few subdivisions or too many because the amount of surfaces doubles on every iteration of that algorithm.
In particular I would need an adaptive tesselation algorithm that allows me to define the amount of segments at the edges. I'm not sure whether I can get that though so I'd also like to hear about uniform tesselation techniques.
Hardest trouble I have trouble with calculating normals for a point in bezier surface, which I'm not sure whether I need, but been trying to solve out.
Adaptive tesselation. There are many algorithms to this. But here's one:
def line_angle((x0,y0),(x1,y1)):
return atan2(y1-y0,x1-x0)
def adaptive_bezier(p0,p1,p2,lev=32):
p01 = midpoint(p0,p1)
p12 = midpoint(p1,p2)
m = midpoint(p01, p12)
da = abs(line_angle(p0,p1) - line_angle(p1,p2))
if da <= max_tolerance or lev <= 0:
yield m
else:
for p in adaptive_bezier(p0,p01,m,lev-1): yield p
for p in adaptive_bezier(m,p12,p2,lev-1): yield p
For tesselating triangles this way there are complications to the matter. You need to drive the adaptive tesselator algorithm according to the angles of the edge beziers. There's three unique ways how your triangle can split when tesselating.
2 edges one edge 3 edges
-------- --------- --------
\ ...// \ | / \ / \ /
\/___/ \ | / \____/
\ / \ | / \ /
\/ \|/ \/
Define tesselation results for these patterns and you're well off. Only the tesselation with one edge is described in wikipedia article.
Two other tesselation results can be obtained by studying the case of one edge split.
"2 edges" can be obtained straight out by splitting first one edge and then another.
"3 edges" is a bit more work to find out. But you can see the "2 edges" -case brings you a mid-edge. In the case of quadratic bezier triangle it is an averaged sum of diamond appearing there:
-------- /\
\ / / \
\____/ -____-
\ / \ /
\/ \/