Im trying to implement a little 2d-raytracer for education and art purposes.
But there seems to be a bug in my lightmodel code.
As you can see one site of the line is appearing much brighter than the other one.
Here's the rendering code:
RENDERING CODE GLSL
I think the cause could probably be the random number generator, but i'm not shure and don't know how to proof this.
Edit: But sometimes I'm getting quite good results like this:
I used this pice of code for the Ray Line - Intersection.
Ray Line - Intersection
Found the bug in the code here:
public static Vector2? lineSegmentIntersection(Vector2 r0, Vector2 r1, Vector2 a, Vector2 b)
{
Vector2 s1, s2;
s1 = r1; // FOR A RAY IT HAS TO LOOK LIKE THIS !
s2 = b - a;
float s, t;
s = (-s1.Y * (r0.X - a.X) + s1.X * (r0.Y - a.Y)) / (-s2.X * s1.Y + s1.X * s2.Y);
t = (s2.X * (r0.Y - a.Y) - s2.Y * (r0.X - a.X)) / (-s2.X * s1.Y + s1.X * s2.Y);
if (s >= 0 && s <= 1 && t >= 0 && t <= 1)
{
// Collision detected
// Return the point of intersection
return new Vector2(r0.X + (t * s1.X), r0.Y + (t * s1.Y));
}
return null; // No collision
}
Related
int Electra2D::Collision()
{
for (std::list<Entity>::iterator affecting = entities.begin(); affecting != entities.end(); ++affecting) {
for (std::list<Entity>::iterator affected = entities.begin(); affected != entities.end(); ++affected) {
if (affecting->type == DrawTypes::Circle && affected->type == DrawTypes::Circle && affecting->object->id != affected->object->id) {
float distance = affected->pos.getDistance(affecting->pos);
float limit = ((ObjectCircle*)affected->object)->radius + ((ObjectCircle*)affecting->object)->radius;
if (distance <= limit) {
Vector2 SP = affected->velocity * affected->mass + affecting->velocity * affecting->mass;
Vector2 V2 = (SP - (affected->velocity-affecting->velocity) * affecting->mass) / (affected->mass + affecting->mass);
affecting->velocity = V2 + (affected->velocity-affecting->velocity);
affected->velocity = V2;
//Equation https://imgur.com/cQqBn9S
}
}
}
}
return 0;
}
I wrote base for 2d simulation in c ++ with d2d1 but when I wrote an equation for collision algorithm I made mistake but I don't know where I mistaken so i need help guys :)
affecting pointer is V1,m1 and affected pointer is V2,m2.
V2' is in code V2, and Sum of momentum in code SP
Source
Edit:
I found my mistake, still thanks. My mistake is I created one dimension equation for two-dimension simulation. When I create an equation I will share my equation and code in this post.
I'm developing a collision system for my game and I want it to be generic.
Also I want to make objects bounce between themselves, so the shape of the sprite is important.
My problem is that I need to convert my sprite shape into a polygon / polygons.
My final question will be: Do you know a way to do it that will be more easy than mine or a way to make mine work ?
Now, here are the details of what I've currently done:
I implemented the axis separating algorithm to detect intersections between my polygons.
To create the polygons I first implemented the marching square algorithm to get the contour of the internal shape, then I convert it into segments.
I now have a polygon, but it can be concave, that's why I need to find a way to split it into multiple convex polygons.
I tried to implement the ear clipping algorithm but there are some cases where is fails. Also I've read somewhere that it doesn't work when the polygon self intersects.
Bellow some bad visuals of my problem:
Also, bellow is the skeleton I generated for that sprite, sorry it's a draw, but it's just to give you more visual information:
As you can see I also 'crop' the corners (don't know how to say it).
Ok, so should the ear clipping algorithm work on that polygon and the problem comes from my implementation or is it not supposed to work ?
Also my next goal was to merge the triangles while the were still forming a convex polygon.
I'm also looking for an easier way to do it if you know one.
Thanks in advance.
EDIT-1
Code of my implementation of the triangulation:
#include "Triangulation.hh"
bool Triangulation::isConvex(const Position &a, const Position &b,
const Position &c) const {
float crossp = (c.x - a.x) * (b.y - a.y) - (c.y - a.y) * (b.x - a.x);
return (crossp >= 0 ? true : false);
}
bool Triangulation::inTriangle(const Position &a, const Position &b,
const Position &c, const Position &x) const {
std::array<float, 3> barCoef = {0, 0, 0};
barCoef[0] = ((b.y - c.y) * (x.x - c.x) + (c.x - b.x) * (x.y - c.y)) /
(((b.y - c.y) * (a.x - c.x) + (c.x - b.x) * (a.y - c.y)));
barCoef[1] = ((c.y - a.y) * (x.x - c.x) + (a.x - c.x) * (x.y - c.y)) /
(((b.y - c.y) * (a.x - c.x) + (c.x - b.x) * (a.y - c.y)));
barCoef[2] = 1.f - barCoef[0] - barCoef[1];
for (float coef : barCoef) {
if (coef >= 1 || coef <= 0)
return false;
}
return true;
}
std::pair<bool, std::array<Position, 3>>
Triangulation::getEar(std::vector<Position> &polygon) const {
int size = polygon.size();
bool triTest = false;
std::array<Position, 3> triangle;
if (size < 3)
return {false, triangle};
else if (size == 3) {
triangle = {polygon[0], polygon[1], polygon[2]};
polygon.clear();
return {true, triangle};
} else {
for (int i = 0; i < size; ++i) {
triTest = false;
triangle[0] = polygon[(i + size - 1) % size];
triangle[1] = polygon[i];
triangle[2] = polygon[(i + 1) % size];
if (this->isConvex(triangle[0], triangle[1], triangle[2])) {
for (const Position &point : polygon) {
auto it = std::find(triangle.begin(), triangle.end(), point);
if (it != triangle.end())
continue;
if (this->inTriangle(triangle[0], triangle[1], triangle[2], point)) {
triTest = true;
break;
}
}
if (triTest == false) {
polygon.erase(polygon.begin() + i);
return {true, triangle};
}
}
}
}
return {false, {}};
}
My points are in counterClockwise order, the problem comes from the isConvex method where, for my first image, it will return true.
EDIT 2
Thank you #svs for the notes, I updated the code in EDIT 1 for the others to see, bellow is my bad drawing of the obtained result:
The ear clipping algorithm should be able to triangulate this polygon without a problem so I think you have a problem with the implementation. Here are couple of things you could check so that you ensure that you've implemented it correctly:
make sure you input the polygon vertices in a consistent manner - either clockwise or counterclockwise. For example, if you have a square with vertices (0, 0), (1, 1), (1, 0), (0, 1) you should input the polygon as vertices (0, 0), (0, 1), (1, 1), (1, 0) if you use the counterclockwise manner
check your algorithm for testing if a vertex is an ear again. If you you are using the clockwise manner a vertex v[i]=(x[i], y[i]) is an ear if the signed area of the vertices v[i-1]=(x[i-1], y[i-1])), v[i], v[i+1]=(x[i+1], y[i+1])) is positive and no point of the polygon is in the interior of v[i-1], v[i], v[i+1]. Here is a formula for signed area.
Seeing your code you should move the deleting statement of a vertex outside the polygon vertex loop. The psedocode of the algorithm is:
for each vertex v[i] of the polygon:
if v[i] is an ear:
if there is no polygon vertex in triangle v[i-1], v[i], v[i+1]:
delete vertex v[i] from the polygon
The problem is that you delete the vertex while you check if there exist a vertex of the polygon in the triangle. Update your code to:
if (this->isConvex(triangle[0], triangle[1], triangle[2])) {
for (const Position &point : polygon) {
auto it = std::find(triangle.begin(), triangle.end(), point);
if (it == triangle.end())
continue;
if (this->inTriangle(triangle[0], triangle[1], triangle[2], point)) {
triTest = true;
break;
}
}
if (triTest == false) {
polygon.erase(polygon.begin() + i);
return {true, triangle};
}
}
I am writing a ray tracer. So far I have diffuse, Blinn lighting and reflections. Something has gone wrong with my refractions and I have no idea what. I'm hoping someone can help me out.
I have a big red diffuse + Blinn sphere and a small refractive one with refraction index n = 1.5.
The small one is just really screwed up.
Relevant code:
ReflectiveSurface::ReflectiveSurface(const Color& _n, const Color& _k) :
F0(Color(((_n - 1)*(_n - 1) + _k * _k) / ((_n + 1)*(_n + 1) + _k * _k))) {}
Color ReflectiveSurface::F(const Point& N, const Point& V) const {
float cosa = fabs(N * V);
return F0 + (F0 * (-1) + 1) * pow(1 - cosa, 5);
}
Color ReflectiveSurface::getColor(const Incidence& incidence, const Scene& scene, int traceDepth) const {
Point reflectedDir = reflect(incidence.normal, incidence.direction);
Ray ray = Ray(incidence.point + reflectedDir * epsilon, reflectedDir);
return F(incidence.normal, incidence.direction) * scene.rayTrace(ray, traceDepth + 1);
}
Point ReflectiveSurface::reflect(const Point& N, const Point& V) const {
return V - N * (2 * (N * V));
}
bool RefractiveSurface::refractionDir(Point& T, Point& N, const Point& V) const {
float cosa = -(N * V), cn = n;
if (cosa < 0) { cosa = -cosa; N = N * (-1); cn = 1 / n; }
float disc = 1 - (1 - cosa * cosa) / cn / cn;
if (disc < 0) return false;
T = V / cn + N * (cosa / cn - sqrt(disc));
return true;
}
RefractiveSurface::RefractiveSurface(float _n, const Color& _k) : ReflectiveSurface(Color(1, 1, 1) * _n, _k) {}
Surface* RefractiveSurface::copy() { return new RefractiveSurface(*this); }
Color RefractiveSurface::getColor(const Incidence& incidence, const Scene& scene, int traceDepth) const {
Incidence I = Incidence(incidence);
Color reflectedColor, refractedColor;
Point direction = reflect(I.normal, I.direction);
Ray reflectedRay = Ray(I.point + direction * epsilon, direction);
if (refractionDir(direction, I.normal, I.direction)) {
Ray refractedRay = Ray(I.point + direction * epsilon, direction);
Color colorF = F(I.normal, I.direction);
reflectedColor = colorF * scene.rayTrace(reflectedRay, traceDepth + 1);
refractedColor = (Color(1, 1, 1) - colorF) * scene.rayTrace(refractedRay, traceDepth + 1);
}
else {
reflectedColor = scene.rayTrace(reflectedRay, traceDepth + 1);
}
return reflectedColor + refractedColor;
}
The code is all over the place, since this is a homework and I'm not allowed to include additional headers and I have to send it in in one cpp file, so i had to separate every class into forward declaration, declaration and implementation in that one file. It makes me vomit but I tried to keep it as clean as possible. There is tons of code so I only included what I thought was most related. ReflectiveSurface is RefractiveSurface's parent class. N is the surface normal, V is the ray direction vector this normal, n is the refraction index. The incidence structure holds a point, a normal and a direction vector.
Formulas for the Fersnel approximation and the refraction vector respectively:
You can see in the code that I use an epsilon * ray direction value to avoid shadow acne caused by float imprecision. Something similar seems to be happening to the small sphere, though.
Another screenshot:
As you can see, the sphere doesn't appear transparent, but it does inherit the diffuse sphere's color. It also usually has some white pixels.
Without refraction:
RefractiveSurface::refractionDir takes the normal N by (non-const) reference, and it may invert it. This seems dangerous. It's not clear the caller wants I.normal to be flipped, as it's used in color calculations further down.
Also, refracted_color is not always initialized (unless the Color constructor makes it black).
Try (temporarily) simplifying and just see if the refracted rays hit where you expect. Remove the Fresnel computation and the reflection component and just set refracted_color to the result of the trace of the refracted ray. That will help determine if the bug is in the Fresnel calculation or in the geometry of bending the ray.
A debugging tip: Color the pixels that don't hit anything with something other than black. That makes it easy to distinguish the misses from the shadows (surface acne).
The answer turned out to be pretty simple, but it took me like 3 days of staring at the code to catch the bug. I have a Surface class, I derive from it two classes: RoughSurface (diffuse+blinn) and RelfectiveSurface. Then, RefractiveSurace is derived from RefleciveSurface. ReflectiveSurface's constructor takes the refractive index(n) and the extinction value (k) as parameters, but doesn't store them. (F0) is computed from them during construction, and then they are lost. RefractiveSurface, on the other hand, uses (n) in the refraction angle calculation.
Old constructor:
RefractiveSurface::RefractiveSurface(float _n, const Color& _k) :
ReflectiveSurface(Color(1, 1, 1) * _n, _k) {}
New Constructor:
RefractiveSurface::RefractiveSurface(float _n, const Color& _k) :
ReflectiveSurface(Color(1, 1, 1) * _n, _k), n(_n) {}
As you can see, I forgot to save the (n) value for RefractiveSurface in the constructor.
Small red sphere behind big glass sphere lit from the two sides of the camera:
It looks awesome in motion!D
Thank you for your time, guys. Gotta finish this homework, then I'll rewrite the whole thing and optimize the hell out of it.
I've been hacking up a raytracer for the first time over the past few days. However, there are a few quirks which bother me and I don't really know how to work out. One that has been there since the beginning is the shape of spheres in the scene - when rendered, they actually look like ovals. Of course, there is perspective in the scene, but the final shape still seems odd. I have attached a sample rendering, the problem I have is especially visible on the reflective sphere in the lower left part of the image.
I don't really know what could be causing this. It might be the ray-sphere intersection code which looks as follows:
bool Sphere::intersect(Ray ray, glm::vec3& hitPoint) {
//Compute A, B and C coefficients
float a = glm::dot(ray.dir, ray.dir);
float b = 2.0 * glm::dot(ray.dir, ray.org-pos);
float c = glm::dot(ray.org-pos, ray.org-pos) - (rad * rad);
// Find discriminant
float disc = b * b - 4 * a * c;
// if discriminant is negative there are no real roots, so return
// false as ray misses sphere
if (disc < 0)
return false;
// compute q
float distSqrt = sqrt(disc);
float q;
if (b < 0)
q = (-b - distSqrt)/2.0;
else
q = (-b + distSqrt)/2.0;
// compute t0 and t1
float t0 = q / a;
float t1 = c / q;
// make sure t0 is smaller than t1
if (t0 > t1) {
// if t0 is bigger than t1 swap them around
float temp = t0;
t0 = t1;
t1 = temp;
}
// if t1 is less than zero, the object is in the ray's negative direction
// and consequently the ray misses the sphere
if (t1 < 0)
return false;
// if t0 is less than zero, the intersection point is at t1
if (t0 < 0) {
hitPoint = ray.org + t1 * ray.dir;
return true;
} else { // else the intersection point is at t0
hitPoint = ray.org + t0 * ray.dir;
return true;
}
}
Or it could be another thing. Does anyone have an idea? Thanks so much!
It looks like you're using a really wide field of view (FoV). This gives the effect of a fish-eye lens, distorting the picture, especially towards the edges. Typically something like 90 degrees (i.e. 45 degrees in either direction) gives a reasonable picture.
The refraction actually looks quite good; it's inverted because the index of refraction is so high. Nice pictures are in this question.
My brain has been melting over a line segment-vs-cylinder intersection routine I've been working on.
/// Line segment VS <cylinder>
// - cylinder (A, B, r) (start point, end point, radius)
// - line has starting point (x0, y0, z0) and ending point (x0+ux, y0+uy, z0+uz) ((ux, uy, uz) is "direction")
// => start = (x0, y0, z0)
// dir = (ux, uy, uz)
// A
// B
// r
// optimize? (= don't care for t > 1)
// <= t = "time" of intersection
// norm = surface normal of intersection point
void CollisionExecuter::cylinderVSline(const Ogre::Vector3& start, const Ogre::Vector3& dir, const Ogre::Vector3& A, const Ogre::Vector3& B, const double r,
const bool optimize, double& t, Ogre::Vector3& normal) {
t = NaN;
// Solution : http://www.gamedev.net/community/forums/topic.asp?topic_id=467789
double cxmin, cymin, czmin, cxmax, cymax, czmax;
if (A.z < B.z) { czmin = A.z - r; czmax = B.z + r; } else { czmin = B.z - r; czmax = A.z + r; }
if (A.y < B.y) { cymin = A.y - r; cymax = B.y + r; } else { cymin = B.y - r; cymax = A.y + r; }
if (A.x < B.x) { cxmin = A.x - r; cxmax = B.x + r; } else { cxmin = B.x - r; cxmax = A.x + r; }
if (optimize) {
if (start.z >= czmax && (start.z + dir.z) > czmax) return;
if (start.z <= czmin && (start.z + dir.z) < czmin) return;
if (start.y >= cymax && (start.y + dir.y) > cymax) return;
if (start.y <= cymin && (start.y + dir.y) < cymin) return;
if (start.x >= cxmax && (start.x + dir.x) > cxmax) return;
if (start.x <= cxmin && (start.x + dir.x) < cxmin) return;
}
Ogre::Vector3 AB = B - A;
Ogre::Vector3 AO = start - A;
Ogre::Vector3 AOxAB = AO.crossProduct(AB);
Ogre::Vector3 VxAB = dir.crossProduct(AB);
double ab2 = AB.dotProduct(AB);
double a = VxAB.dotProduct(VxAB);
double b = 2 * VxAB.dotProduct(AOxAB);
double c = AOxAB.dotProduct(AOxAB) - (r*r * ab2);
double d = b * b - 4 * a * c;
if (d < 0) return;
double time = (-b - sqrt(d)) / (2 * a);
if (time < 0) return;
Ogre::Vector3 intersection = start + dir * time; /// intersection point
Ogre::Vector3 projection = A + (AB.dotProduct(intersection - A) / ab2) * AB; /// intersection projected onto cylinder axis
if ((projection - A).length() + (B - projection).length() > AB.length()) return; /// THIS IS THE SLOW SAFE WAY
//if (projection.z > czmax - r || projection.z < czmin + r ||
// projection.y > cymax - r || projection.y < cymin + r ||
// projection.x > cxmax - r || projection.x < cxmin + r ) return; /// THIS IS THE FASTER BUGGY WAY
normal = (intersection - projection);
normal.normalise();
t = time; /// at last
}
I have thought of this way to speed up the discovery of whether the projection of the intersection point lies inside the cylinder's length. However, it doesn't work and I can't really get it because it seems so logical :
if the projected point's x, y or z co-ordinates are not within the cylinder's limits, it should be considered outside. It seems though that this doesn't work in practice.
Any help would be greatly appreciated!
Cheers,
Bill Kotsias
Edit : It seems that the problems rise with boundary-cases, i.e when the cylinder is parallel to one of the axis. Rounding errors come into the equation and the "optimization" stops working correctly.
Maybe, if the logic is correct, the problems will go away by inserting a bit of tolerance like :
if (projection.z > czmax - r + 0.001 || projection.z < czmin + r - 0.001 || ... etc...
The cylinder is circular, right? You could transform coordinates so that the center line of the cylinder functions as the Z axis. Then you have a 2D problem of intersecting a line with a circle. The intersection points will be in terms of a parameter going from 0 to 1 along the length of the line, so you can calculate their positions in that coordinate system and compare to the top and bottom of the cylinder.
You should be able to do it all in closed form. No tolerances. And sure, you will get singularities and imaginary solutions. You seem to have thought of all this, so I guess I'm not sure what the question is.
This is what I use, it may help:
bool d3RayCylinderIntersection(const DCylinder &cylinder,const DVector3 &org,const DVector3 &dir,float &lambda,DVector3 &normal,DVector3 &newPosition)
// Ray and cylinder intersection
// If hit, returns true and the intersection point in 'newPosition' with a normal and distance along
// the ray ('lambda')
{
DVector3 RC;
float d;
float t,s;
DVector3 n,D,O;
float ln;
float in,out;
RC=org; RC.Subtract(&cylinder.position);
n.Cross(&dir,&cylinder.axis);
ln=n.Length();
// Parallel? (?)
if((ln<D3_EPSILON)&&(ln>-D3_EPSILON))
return false;
n.Normalize();
d=fabs(RC.Dot(n));
if (d<=cylinder.radius)
{
O.Cross(&RC,&cylinder.axis);
//TVector::cross(RC,cylinder._Axis,O);
t=-O.Dot(n)/ln;
//TVector::cross(n,cylinder._Axis,O);
O.Cross(&n,&cylinder.axis);
O.Normalize();
s=fabs( sqrtf(cylinder.radius*cylinder.radius-d*d) / dir.Dot(O) );
in=t-s;
out=t+s;
if (in<-D3_EPSILON)
{
if(out<-D3_EPSILON)
return false;
else lambda=out;
} else if(out<-D3_EPSILON)
{
lambda=in;
} else if(in<out)
{
lambda=in;
} else
{
lambda=out;
}
// Calculate intersection point
newPosition=org;
newPosition.x+=dir.x*lambda;
newPosition.y+=dir.y*lambda;
newPosition.z+=dir.z*lambda;
DVector3 HB;
HB=newPosition;
HB.Subtract(&cylinder.position);
float scale=HB.Dot(&cylinder.axis);
normal.x=HB.x-cylinder.axis.x*scale;
normal.y=HB.y-cylinder.axis.y*scale;
normal.z=HB.z-cylinder.axis.z*scale;
normal.Normalize();
return true;
}
return false;
}
Have you thought about it this way?
A cylinder is essentially a "fat" line segment so a way to do this would be to find the closest point on line segment (the cylinder's center line) to line segment (the line segment you are testing for intersection).
From there, you check the distance between this closest point and the other line segment, and compare it to the radius.
At this point, you have a "Pill vs Line Segment" test, but you could probably do some plane tests to "chop off" the caps on the pill to make a cylinder.
Shooting from the hip a bit though so hope it helps (:
Mike's answer is good. For any tricky shape you're best off finding the transformation matrix T that maps it into a nice upright version, in this case an outright cylinder with radius 1. height 1, would do the job nicely. Figure out your new line in this new space, perform the calculation, convert back.
However, if you are looking to optimise (and it sounds like you are), there is probably loads you can do.
For example, you can calculate the shortest distance between two lines -- probably using the dot product rule -- imagine joining two lines by a thread. Then if this thread is the shortest of all possible threads, then it will be perpendicular to both lines, so Thread.LineA = Thread.LineB = 0
If the shortest distance is greater than the radius of the cylinder, it is a miss.
You could define the locus of the cylinder using x,y,z, and thrash the whole thing out as some horrible quadratic equation, and optimise by calculating the discriminant first, and returning no-hit if this is negative.
To define the locus, take any point P=(x,y,z). drop it as a perpendicular on to the centre line of your cylinder, and look at its magnitude squared. if that equals R^2 that point is in.
Then you throw your line {s = U + lamda*V} into that mess, and you would end up with some butt ugly quadratic in lamda. but that would probably be faster than fiddling matrices, unless you can get the hardware to do it (I'm guessing OpenGL has some function to get the hardware to do this superfast).
It all depends on how much optimisation you want; personally I would go with Mike's answer unless there was a really good reason not to.
PS You might get more help if you explain the technique you use rather than just dumping code, leaving it to the reader to figure out what you're doing.