I spent the day working on an OpenGL application that will tessellate a mesh and apply a lens distortion. The goal is to be able to render wide angle shots for a variety of different lenses. So far I've got the shaders properly applying the distortion but I've been having issues controlling the tessellation the way I want to. Right now my Tessellation Control Shader just breaks a single triangle into a set number of smaller triangles, then I apply the lens distortion in in the Tessellation Evaluation Shader.
The problem I'm having with this approach is that when I have really large triangles in the scene, they tend to need more warping. This means they need to be tessellated more in order to ensure good looking results. Unfortunately, I can't compute the size of a triangle (in screen space) in the Vertex Shader or the Tessellation Control Shader, but I need to define the tessellation amount in the Tessellation Control shader.
My question is then, is there some way to get a hold of the entire primitive in OpenGL's programmable pipeline, compute some metrics about it, then use that information to control tessellation?
Here's some example images of the problem for clarity...
Figure 1 (Above): Each Red or Green Square was originally 2 triangles, this example looks good because the triangles were small.
Figure 2 (Above): Each Red or Green Region was originally 2 triangles, this example looks bad because the triangles were small.
Figure 3 (Above): Another example with small triangles but with a much, much larger grid. Notice how much things curve on the edges. Still looks good with tessellation level of 4.
Figure 4 (Above): Another example with large triangles, only showing center 4 columns because the image is unintelligible if more columns are present. This shows how very large triangles don't get tessellated well. If I set the tessellation really really high then this comes out nice. But then I'm performing a crazy amount of tessellation on smaller triangles too.
In a Tessellation Control Shader (TCS) you have read access to every vertex in the input patch primitive. While that sounds nice on paper, if you are trying to compute the maximum edge length of a patch, it would actually mean iterating over every vertex in the patch on every TCS invocation and that's not particularly efficient.
Instead, it may be more practical to pre-compute the patch's center in object-space and determine the radius of a sphere that tightly bounds the patch. Store this bounding information as an extra vec4 attribute per-vertex, packed as shown below.
Pseudo-code for a TCS that computes the longest length of the patch in NDC-space
#version 420
uniform mat4 model_view_proj;
in vec4 bounding_sphere []; // xyz = center (object-space), w = radius
void main (void)
{
vec4 center = vec4 (bounding_sphere [0].xyz, 1.0f);
float radius = bounding_sphere [0].w;
// Transform object-space X extremes into clip-space
vec4 min_0 = model_view_proj * (center - vec4 (radius, 0.0f, 0.0f, 0.0f));
vec4 max_0 = model_view_proj * (center + vec4 (radius, 0.0f, 0.0f, 0.0f));
// Transform object-space Y extremes into clip-space
vec4 min_1 = model_view_proj * (center - vec4 (0.0f, radius, 0.0f, 0.0f));
vec4 max_1 = model_view_proj * (center + vec4 (0.0f, radius, 0.0f, 0.0f));
// Transform object-space Z extremes into clip-space
vec4 min_2 = model_view_proj * (center - vec4 (0.0f, 0.0f, radius, 0.0f));
vec4 max_2 = model_view_proj * (center + vec4 (0.0f, 0.0f, radius, 0.0f));
// Transform from clip-space to NDC
min_0 /= min_0.w; max_0 /= max_0.w;
min_1 /= min_1.w; max_1 /= max_1.w;
min_2 /= min_2.w; max_2 /= max_2.w;
// Calculate the distance (ignore depth) covered by all three pairs of extremes
float dist_0 = distance (min_0.xy, max_0.xy);
float dist_1 = distance (min_1.xy, max_1.xy);
float dist_2 = distance (min_2.xy, max_2.xy);
// A max_dist >= 2.0 indicates the patch spans the entire screen in one direction
float max_dist = max (dist_0, max (dist_1, dist_2));
// ...
}
If you run your 4th diagram through this TCS, you should come up with a value for max_dist very nearly 2.0, which means you need as much subdivision as possible. Meanwhile, many of the patches on the periphery of the sphere in the 3rd diagram will be close to 0.0; they don't need much subdivision.
This does not properly deal with situations where part of the patch is offscreen. You would need to clamp the NDC extremes to [-1.0,1.0] to properly handle those situations. Seemed like more trouble than it was worth.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I'm currently doing a model of the solar system. I have a planet that moves around the sun. This is the planet:
glPushMatrix();
glColor3f(1.0, 0.0, 0.0);
glRotatef(theta * 10, 0.0, 1.0, 0.0);
glTranslatef(P1[0], P1[1], P1[2]);
gluSphere(quad, 0.05, 100, 20);
glPopMatrix();
Now, I want to draw a trial around the sun exactly where the planet moves. How do I do this? I'm supposed to use GL_LINES to draw it. So far I've got this, but I'm not getting the desired result. The circular path isn't exactly the same as the rotation orbit of the planet.
glBegin(GL_LINES);
for (float i = 0; i < 2 * PI; i += 0.01)
{
float x = P1[0] * cos(i) + 0.0;
float y = 0.0;
float z = P1[2] * sin(i) + 0.0;
glVertex3f(x, y, z);
}
glEnd();
Given the information about the planet, how do I draw its orbit trial?
If the planet is following a circular orbit, you need to know the center of the circle, the radius, and the axis of rotation. In your case, the axis of rotation is the y-axis. Therefore the points on along orbit can be computed by the trigonometric functions sin and cos Define a center point (float CPT[3]) and a radius (float radius). Use the Line primitive type GL_LINE_LOOP to draw the circular orbit:
glBegin(GL_LINES);
for (float angle = 0; i < 2 * PI; angle += 0.01)
{
float x = CPT[0] + cos(angle) * radius;
float y = CPT[1];
float z = CPT[2] + sin(angle) * radius;
glVertex3f(x, y, z);
}
glEnd();
I've been writing GLSL shaders, and using an integer texture (GL_RED) to store values in the shader.
When I attempt to divide a value taken from the usampler2D texture, it stays the same.
The following is the minimal reproducible shader.
#version 440
in vec2 uv;
out vec3 color;
layout (binding = 1) uniform usampler2D tm_data;
void main(){
float index = texture(tm_data, uv).r;
float divisor = 16.0f
color = vec3(index / divisor, 0, 0);
}
The rendered red value is always 1.0 regardless of a way i try to divide or mutate the index value.
When the sampler is changed to a normalized one (sampler2D) the color manipulation works as expected
#version 440
in vec2 uv;
out vec3 color;
layout (binding = 1) uniform sampler2D tm_data; //Loads as normalized from [0,255] to [0,1]
void main(){
float index = texture(tm_data, uv).r * 255.0f; //Convert back to integer approximation
float divisor = 4.0f
color = vec3(index / divisor, 0, 0); //Shade of red now appears considerably darker
}
Does anyone know why this unexpected behaviour happens?
The tm_data texture is loaded as GL_RED -> GL_RED
The OpenGL version used is 4.4
There is no framework being used (no sneaky additions), everything is loaded using gl function calls.
For the use of usampler2D, the internal format has to be a unsigned integral format (e.g. GL_R8UI). See Sampler types.
If the internal format is the basic format GL_RED, then the sampler type has to be sampler2D.
Note, sampler* is for the use of floating point formats, isampler* for signed integral formats and usampler* for unsigned integral formats.
See OpenGL Shading Language 4.60 Specification - 4.1.7. Opaque Types and OpenGL Shading Language 4.60 Specification - 8.9. Texture Functions
i have two Objects in a 3D World and want to make the one object facing the other object. I already calculated all the angles and stuff (pitch angle and yaw angle).
The problem is i have no functions to set the yaw or pitch individually which means that i have to do it by a quaternion. As the only function i have is: SetEnetyQuaternion(float x, float y, float z, float w). This is my pseudocode i have yet:
float px, py, pz;
float tx, ty, tz;
float distance;
GetEnetyCoordinates(ObjectMe, &px, &py, &pz);
GetEnetyCoordinates(TargetObject, &tx, &ty, &tz);
float yaw, pitch;
float deltaX, deltaY, deltaZ;
deltaX = tx - px;
deltaY = ty - py;
deltaZ = tz - pz;
float hyp = SQRT((deltaX*deltaX) + (deltaY*deltaY) + (deltaZ*deltaZ));
yaw = (ATAN2(deltaY, deltaX));
if(yaw < 0) { yaw += 360; }
pitch = ATAN2(-deltaZ, hyp);
if (pitch < 0) { pitch += 360; }
//here is the part where i need to do a calculation to convert the angles
SetEnetyQuaternion(ObjectMe, pitch, 0, yaw, 0);
What i tried yet was calculating the sinus from those angles devided with 2 but this didnt work - i think this is for euler angles or something like that but didnt help me. The roll(y axis) and the w argument can be left out i think as i dont want my object to have a roll. Thats why i put 0 in.
If anyone has any idea i would really appreciate help.
Thank you in advance :)
Let's suppose that the quaternion you want describes the attitude of the player relative to some reference attitude. It is then essential to know what the reference attitude is.
Moreover, you need to understand that an object's attitude comprises more than just its facing -- it also comprises the object's orientation around that facing. For example, imagine the player facing directly in the positive x direction of the position coordinate system. This affords many different attitudes, from the one where the player is standing straight up to ones where he is horizontal on either his left or right side, to one where he is standing on his head, and all those in between.
Let's suppose that the appropriate reference attitude is the one facing parallel to the positive x direction, and with "up" parallel to the positive z direction (we'll call this "vertical"). Let's also suppose that among the attitudes in which the player is facing the target, you want the one having "up" most nearly vertical. We can imagine the wanted attitude change being performed in two steps: a rotation about the coordinate y axis followed by a rotation about the coordinate z axis. We can write a unit quaternion for each of these, and the desired quaternion for the overall rotation is the Hamilton product of these quaternions.
The quaternion for a rotation of angle θ around the unit vector described by coordinates (x, y, z) is (cos θ/2, x sin θ/2, y sin θ/2, z sin θ/2). Consider then, the first quaternion you want, corresponding to the pitch. You have
double semiRadius = sqrt(deltaX * deltaX + deltaY * deltaY);
double cosPitch = semiRadius / hyp;
double sinPitch = deltaZ / hyp; // but note that we don't actually need this
. But you need the sine and cosine of half that angle. The half-angle formulae come in handy here:
double sinHalfPitch = sqrt((1 - cosPitch) / 2) * ((deltaZ < 0) ? -1 : 1);
double cosHalfPitch = sqrt((1 + cosPitch) / 2);
The cosine will always be nonnegative because the pitch angle must be in the first or fourth quadrant; the sine will be positive if the object is above the player, or negative if it is below. With all that being done, the first quaternion is
(cosHalfPitch, 0, sinHalfPitch, 0)
Similar analysis applies to the second quaternion. The cosine and sine of the full rotation angle are
double cosYaw = deltaX / semiRadius;
double sinYaw = deltaY / semiRadius; // again, we don't actually need this
We can again apply the half-angle formulae, but now we need to account for the full angle to be in any quadrant. The half angle, however, can be only in quadrant 1 or 2, so its sine is necessarily non-negative:
double sinHalfYaw = sqrt((1 - cosYaw) / 2);
double cosHalfYaw = sqrt((1 + cosYaw) / 2) * ((deltaY < 0) ? -1 : 1);
That gives us an overall second quaternion of
(cosHalfYaw, 0, 0, sinHalfYaw)
The quaternion you want is the Hamilton product of these two, and you must take care to compute it with the correct operand order (qYaw * qPitch), because the Hamilton product is not commutative. All the zeroes in the two factors make the overall expression much simpler than it otherwise would be, however:
(cosHalfYaw * cosHalfPitch,
-sinHalfYaw * sinHalfPitch,
cosHalfYaw * sinHalfPitch,
sinHalfYaw * cosHalfPitch)
At this point I remind you that we started with an assumption about the reference attitude for the quaternion system, and the this result depends on that choice. I also remind you that I made an assumption about the wanted attitude, and that also affects this result.
Finally, I observe that this approach breaks down where the target object is very nearly directly above or directly below the player (corresponding to semiRadius taking a value very near zero) and where the player is very nearly on top of the target (corresponding to hyp taking a value very near zero). There is a non-zero chance of causing a division by zero if you use these formulae exactly as given, so you'll want to think about how to deal with that.)
I have been working for too long on the business applications it seems... And graduated too long ago perhaps :) Recently i have been tasked writing a small simulation of robotics using C (although this question is more math/algorithm than C) where i have two units (tank-bots) starting at an X and Y coordinate on a playfield.
Now there are keys on a panel to rotate them, and a key to move them forwards. I am now facing a minor brain meltdown on the translation from degrees of rotation to the next X,Y coord to move to in the cartesian playfield.
Due to limitations in HW only fixed point is available for the actual movement, but calculations can be done by float values.
I wrote the following code just from memory just now:
/* Recalculate to radians */
int radians;
/* Use sin and cos to get a vector (new x and y coords). Translate from polar to
cartesian coordinates */
radians = (int) _tanks[0].rotationAngle * (M_PI / 180);
_tanks[0].x += _tanks[0].speed * cos(radians);
_tanks[0].y += _tanks[0].speed * sin(radians);
radians = (int) _tanks[1].rotationAngle * (M_PI / 180);
_tanks[1].x += _tanks[1].speed * cos(radians);
_tanks[1].y += _tanks[1].speed * sin(radians);
Unfortunately it seems my brain is not really refreshed on polar coordinate math and geometry after all these years on writing pure biz software, so it seems to not work as intended.
For instance if rotationAngle is 180, instead the next x/y is to the left, causing the bot to topple over :)
What i want is a movement scheme similiar to the old Micro Machines games if you remember where the next point would be in front of where the object is facing, so it moves (speed) number of steps there.
Can someone suggest where i'm going wrong here...
Also, if there is a smoother way of doing this in C than the pure mathematical attempt that i just wrote (badly at that), give me a hint.
EDIT:
Tried to add :
float radians;
radians = (45 - _tanks[0].rotationAngle) * (M_PI / 180);
_tanks[0].x += (int) (_tanks[0].speed * cos(radians));
_tanks[0].y += (int) (_tanks[0].speed * sin(radians));
according to answer below as 0 degrees is indeed the positive Y-axis. But this also gives incorrect results. Now movement for 180 degrees starting point is upwards to the left. At 180 degrees should be movement along the negative Y axis.
Some more code:
Init of _tank struct -
tanks[0].acc = 0;
tanks[0].dec = 0;
tanks[0].rotationAngle = 180;
tanks[0].speed = 0;
tanks[0].x = 400;
tanks[0].y = 150;
tanks[0].turretRotationAngle = 180;
The rotation degree is just a number (fixed integer), and i wrap it around as according to the circle # 360 degrees, like so -
switch(direction) {
case 0:
tank->rotationAngle -= degrees;
if(tank->rotationAngle < 1) {
tank->rotationAngle = 360;
}
break;
case 1:
tank->rotationAngle += degrees;
if(tank->rotationAngle > 360) {
tank->rotationAngle = 0;
}
break;
}
One key for rotating clockwise, one for counter clockwise.
The rotation works, but the movement does not, as described...
Results of debug run:
Initial state (no movement due to 0 speed) -
radians = -2.3561945
x = 400
y = 150
speed = 0
After movement (speed > 0) -
radians = -2.3561945 (the same since i only press the move button)
x = 399
y = 149
speed = 2
This seems odd. The X coord should not change at all if the rotation is 180 degrees from the initial origin right? Only the Y should change, and in the opposite direction. I would translate the change instead to if speed is 2, vector length should be 2 so change would be 2 steps in the direction the object is facing, so y = y + 2 and x = x + 0 for 180 degree rotation on the object?
I feel like i'm getting there :)
Further EDIT:
Seems to be ALMOST correct along the lines of what i need for the playfield if i do this:
radians = (_tanks[0].rotationAngle - 90) * (M_PI / 180);
Note -90...
Still when speed is lowered it seems to glitch but at least it moves in the right direction.
For instance if rotationAngle is 180, instead the next x/y is to the left, causing the bot to topple over :)
Yes, that is what your code does: your code is correct, aside from the int radians issue that user3386109 mentions above, provided that 0° is the positive x-axis, 90° is the positive y-axis, 180° is the negative x-axis, 270° (or -90°) is the negative y-axis.
I'm guessing that instead, you want 0° to be the positive y-axis? And — do you want 90° to be the positive x-axis (so your angles proceed clockwise around the circle), or the negative x-axis (so they proceed counterclockwise)? For the former (clockwise) case, just change _tanks[...].rotationAngle to (90 - _tanks[...].rotationAngle) (to "flip" around the 45° line); for the latter (counterclockwise) case, just change it to (_tanks[...].rotationAngle + 90) (to "rotate" it 90° about the origin).
#ruakh and #user3386109 well discuss the issues about angle units and phase.
In addtion, for a "smoother way of doing this in C" also consider:
Use round(), else code will introduce a bias. (Assuming _tanks[1].x is some integer)
double radians = _tanks[0].rotationAngle * (M_PI / 180);
_tanks[0].x += (int) round(_tanks[0].speed * cos(radians));
Use float rather than double as the extra precision with its longer calculation time are not needed.
float radians = _tanks[0].rotationAngle * (float)((M_PI / 180));
_tanks[0].x += (int) roundf(_tanks[0].speed * cosf(radians)); // note function names
If processing time is limited, an integer look-up-table could be used with 360 int scaled sine and cosine values rather than all the floating point math.
_tanks[0].x += (_tanks[0].speed * LUT_cos[_tanks[0].rotationAngle])/scale;
How can I modify/rotate an axis angle from world coords to object coords?
See below:
void RotateMatrix4(float *m, float angle, float *axis);
//This function rotates a matrix in object space
void RotateLocal(float angle, float *axis) {
RotateMatrix4(m, angle, axis)
}
void RotateGlobal(float angle, float *axis) {
//Do something to axis here
RotateMatrix4(m, angle, axis)
}
You found the answer yourself - that is simply a multiplication between a tranformation matrix and a vector - you are simply transforming the axis vector into object coords.
Look at Transformation Matrix for more information on Transformation matrices.
(I would comment on your answer - but my rank is not yet high enough...)