When I had this problem while working on my Cubes, I found the paper "A Fast Voxel Traversal Algorithm for Ray Tracing" by John Amanatides and Andrew Woo, 1987 which describes an algorithm which can be applied to this task; it is accurate and needs only one loop iteration per voxel intersected.
I have written an implementation of the relevant parts of the ...
I've implemented something similar to this. I wrote up a post about it on my blog: byte56.com/2011/06/a-light-post. But I'll go into a little more detail here.
While the codeflow article linked in another answer is pretty interesting. From what I understand, it's not how Minecraft does its lighting. Minecraft lighting is more cellular automata then ...
What is a raycast? What are blocking objects and blocking mask?
A ray is a mathematical device that starts at an origin point and continues on in a specific direction forever. With a raycast you're casting a ray, cast being used like the word throw.
It's like if you threw a rock and it continued on in that direction forever, it wouldn't stop until it hit ...
Amit Patel has written a very nice article on 2D ray casting.
This involves casting rays to each of the vertices inside the range of the light source to build a light mesh.
All of the visual examples are interactive in the post and very easy to understand.
You don't have to limit yourself to a box either, the perimeter you trace can be any shape you like....
This really is just the way things are with collision. Not just 3D, but also 2D. Take the following example:
The green and red AABBs are colliding, and the contact manifold is the blue area. The contact points will be in the blue area somewhere (exactly where can vary with algorithm, but the corners where the blue/red/green meets are ideal-ish).
Break movement into two steps
Select a position on a 2D X/Z plane located at the entity's current Y position.
Set the offset (up or down) from that plane.
This is similar to how Homeworld, one of the first 3D space RTS games handled movement. Works really well.
Breaking movement into two steps provides the most control, simply because the mouse is a 2D ...
Ahh yes. I threw my math at it and I think I hit it. You're correct it does involve the Pythagorean theorem and some scaling.
You start with your normalized vector that represents your ray.
It has an x component and a y component. First we want to see how long it is when it travels one unit in the x direction. So what do we do? We want to scale the entire ...
You could try casting "shadow arcs" to cover larger areas at once. While the actual details are a bit involved, Eric Lippert has a very in-depth explanation (with live Silverlight demo) at http://blogs.msdn.com/b/ericlippert/archive/2011/12/12/shadowcasting-in-c-part-one.aspx.
It seems you include a square when you can see any point in it while the eye is at the single fixed point.
However, you should only include a square when you can see the middle of it (assuming the "eye" is also in the middle). Or you can draw rays from each corner of the starting square to the corners of the tested square, if you can see any from any then ...
There is no need for these separate x1, x2 etc. variables. You can compute a, b and c in fewer instructions using vector operations:
vec3 d = p2 - p1;
float a = dot(d, d);
float b = 2.0 * dot(d, p1 - p3);
float c = dot(p3, p3) + dot(p1, p1) - 2.0 * dot(p3, p1) - r*r;
It is possible the compiler will notice this, but there is no reason to make it harder ...
Eric Lippert wrote an excellent series on generating line-of-sight in C# with Shadow Casting on a rectangular planar grid..
Amongst other issues, Eric dealt with various questions that must be answered about the line-of-sight requirements, which give different results, and gives examples of a couple of different results. One of the articles deals in depth ...
Transforming the ray position and direction by the inverse model transformation is correct. However, many ray-intersection routines assume that the ray direction is a unit vector. If the model transformation involves scaling, the ray direction won't be a unit vector afterward, and should likely be renormalized.
However, the distance along the ray returned ...
So you have two coordinates or vectors, one is the center of the screen (C from now on) and the other is your object (P from now on.)
If you know some math, you might know that a line can be expressed as an origin and a direction vector. The origin is your screen-center, while the direction vector can be found subtracting C from P. This equation can also be ...
If you know starting block (you know point X and you dind't include block [0,1] in block list, so I suppose you know also the starting block), I think you should surely use Bresenham's algorithm. You wrote, you looked at it.
It's suitable algorithm for this problem. It can be also written in a way, it computes only with integers. You can find a lot of ...
Two that you're missing which immediately stand out to me are GJK and MPR.
GJK is an algorithm for finding the closest point of two convex polygons. With a little bit of extra work you can use it to find incident points for intersecting objects, and hence calculate a collision manifold. This is done via polygon clipping, same as if using SAT, but GJK ...
There is a (optional) parameter for that in Physics.RayCast which is available in Unity 5.2 and up:
public bool RaycastNoTriggers(Vector3 startPosition , Vector3 direction, float distance)
Ray ray = new Ray(startPosition, direction);
return Physics.Raycast(ray, out hit, distance, DefaultRaycastLayers, QueryTriggerInteraction....
Pixel picking is effective if you need to do lots of raycasts from one source. You bear the overhead of rendering and readback once, then get all your many picks at low incremental cost each. To get just one ray result you've already had to calculate thousands or millions whether you use them or not.
If you're only doing a few raycasts at a time (say a ...
Assuming you've benchmarked this and are sure this is a bottleneck keep reading. If not stop. Don't worry and be happy :).
It's true that you will need to run the collision check algorithm every time you fire a bullet. And depending on how long it takes the bullet/laser to disappear you will have to do it multiple frames. However when you implement a solid ...
I have implemented the algorithm suggested by Jimmy.
Video of the code in action here: https://youtu.be/lIlPfwlcbHo
What this code does:
Rasterizes a single Field Of View octant on a grid, similar to the way
FOV / shadowcasting is implemented in some roguelikes.
Clips to bitmap
Steps on pixel centers
You can calculate the ray from camera for any pixel px,py with the following formula:
ray.origin = camera.getPosition();
relativeX = px * 2 / screenWidth - 1; // [0, screenWidth] -> [-1, 1]
relativeY = py * 2 / screenHeight - 1; // [0, screenHeight] -> [-1, 1], might need to be flipped depending on the coordinate system
ray.direction = vector(...
Writing up an answer from my comments as I believe it's not such a crazy idea after all.
The "Up" direction should not matter in these calculations
You have found the object in focus and you can ray cast from its front just like you did with the character
The "Up" direction is Z. (This could be Y depending on who you are talking to or what ...
You need to use the range instead of the distance when you cast the ray. The range is the length of the projection of the ray onto the camera plane.
See this source.
Though IMHO some amount of fisheye distortion is kind of cool to keep around.
I've had this happen with the 3D raycast in the past, and it seems to be because the raycast functions have so darned many optional parameters, and LayerMasks aren't picky about what type they're treated as.
From the docs:
public static RaycastHit2D Raycast(
float distance = Mathf.Infinity,
It's called a flood fill, and it's what you see in paint programs. It's very fast. Pseudocode:
declare visited list //the results you want
declare unvisited list
add current element (where red dot is) to unvisited list
while unvisited list not empty
get current element from unvisited list
add current element to visited list
for all (8) neighbours ...
I'd recommend testing empirically to confirm, but the second answer at this link says that triangle data for submeshes is indexed sequentially in order of submesh index. That means all the triangles for submesh 0 have lower indices than those in submesh 1, etc...
So, you can iterate over the submeshes until you find the one your triangle belongs within:
Physics.OverlapSphere() and Physics2D.OverlapCircleAll() will return all colliders within a radius of a point. Those colliders are in range, but possibly not in view. If you are going to do this often, create an array once, and pass it to Physics2D.OverlapCircleNonAlloc(), instead.
To see if they are in view, check the dot-product of the normalized collider-...
You could use a Dictionary. Store all Transforms as a key with reference to each Car.
In this example, we have a god Game class that holds references to all Cars. (just make sure your Script Execution Order has Game execute before Car does)
Each Car class adds itself to the Game's Car Dictionary upon Awake.
Then in your Raycast, you get the Car directly ...
SphereCast methods take a sphere and slide it along a line to see where it hits objects along its travel.
The radius parameter is the size of the sphere.
The maxDistance parameter is how far the sphere should travel in the given direction.
To simply check for objects near your player, you want CheckSphere or OverlapSphere / OverlapSphereNonAlloc instead. ...
There are quite a few implementations of BRDFs in pbrt, the (open-source) raytracer described by the Physically Based Rendering book. That book is also a great reference for anyone interested in 3D graphics, even if you're not interested in raytracing.
It works by using spherical coordinates. In particular see the section about converting to Cartesian coordinates. The Wikipedia article uses a slightly different convention for the definitions of the angles than your code, resulting in some sin / cos factors being swapped, but it's the same idea.