C for complicated.

​@@deleted_handle C for coping.

So far so good

I think its one of the best resources out there certainly.

Me too lol

Me too

me too

Me too, years and years ago

occams razor for you

Same thing ! But I did it for 3D, now that's a bit more stupid ...

@@antoninperonnet6138 well worry not you have aabb now implemented then!

Be proud. _I_ nudged Javi in this direction with one of my comments on his "code a DOOMlike engine as a Windows console app" video he made last year. _You_ made a working implementation, which takes more work. EDIT: This one, kzfaq.info/get/bejne/rr1ops6AnLOqias.html

@9:06 its very difficult for me to get into perspective from math information firstly , at first i thought when dx=1 dy/dx=dy which means the problem is solved... but actually we are finding the distance not the gradient so we need to calculate that.. other thing that made me confuse was from previous part sin RayAngle would give unit vector which means the hypoteneus is 1 and x has some value (i.e EyeX) the same is true for cos RayAngle which gives the y value to update (EyeY) so in the previous video that diagonal is moved by 1 unit .. or maybe (0.1 unit) but this time we want to move x or y direction so that we know what is hypoteneus distance so does that mean we need to check whether sin RayAngle < cos RayAngle or do we need to compare nTestX < nTestX nTestX=playerX+distanceToWall*EyeX nTestX=playerX+distanceToWall*EyeX to know which direction to go whether in y direction or x direction? i think we must compare nTestX < nTestY

is it faster than the raycasting api provided by spigot?

@@jaylawlmc1915 My implementation is in a data pack, so that is unlikely.

@@Dominexis oh interesting! i didnt know you could code things like raytracing into datapacks. thats cool

@@jaylawlmc1915 If you want to learn more, you could hop on my Discord server and we can discuss how it works. I'd love to share it. The link is in the description of every one of my videos.

Yeah, maths with a bit of sparkle goes a long way 🤣 Thanks Marc!

heh yeah its a little different in RCW because it yields coordinate perfect wall planes, and is selective about the side of the tile hit.

Probably can make it even faster using branchless version from shadertoy, and even then its possible to optimize it even further by doing early termination and applying mask without if statements etc etc, there many ways to implement it

lol thank you Robben, make sure you share your PGE adventures!

I don't think you need to repeat the ray casting, just store more data in the ray (distance, block side, block height, block texture, maybe block array). If you do define different levels (in height) of blocks, I think you do need to to cast for each level.

@@PaulSpades You are correct; by the end I had the concept of cubes rather than walls and floors, so using a 3D array and walking each level was the way to go for me. But if the ground were just a heightmap, then yes, one cast for all levels would be more efficient.

Haha me too! I've got it to real-time raycasting for small scenes on CPU, but want to improve my algorithm before porting to GPU. There are some clever ways of exploiting progressive rendering, to skip empty areas, and some shadow caching tricks I want to explore first.

you definitely want some sort of accelerating structure to skip empty space instead of marching it. you can start with a simple octree raycasting and then go in the direction of SVO's that are far more efficient on big datasets (>1024^3)

@@Alexander_Sannikov I've tried using oct-trees, but this kind of optimized ray marching code is so efficient, that the overhead of navigating the tree is often more expensive than just "dumb" marching. Obviously this does depend on scene complexity & other factors. A mostly empty scene will always be faster with an oct tree. I'm thinking of using a '64-tree' in combination with a progressively rendered depth buffer. Render at low resolution, use the lowest depth value of adjacent pixels to inform a guaranteed voxel free frustum for that region of the render, Render at the next highest resolution, skipping those regions, etc...

@@benjaminmiller3620 for any two given algorithms, one of which has O(log(N)) complexity and the other one has O(N) comlexity, there exists M large enough so that for any N > M, the log-algorithm will be faster than the linear one. However, it also means that for any N < M it will be slower. Octree algorithms do have a significant constant hiding in that O()-notation that's why they will be slower on small datasets. However, there will always be a threshold in dataset size so that it'll be faster for datasets greater than that threshold. That hidden constant in O(log N) also greatly depends on your implementation details. For example, if you're using pointers to store the octree, it's a no-go -- you need to store it flattened. Even something as simple as rearranging your tree breadth-first vs depth-first has no change from algorithmic point of view, but has drastic impact on cache coherency and overall performance.

Hey thanks Python++ 😄 much appreciated!

Fixed-point only requires addition and bitshifts IIRC in each loop iteration with the exception of a single multiplication and division outside the loop. A code snippet from my codebase which can rasterize over 1 billion projected 3D lines per second with the added cost of a hierarchical Z-Buffer depth test per pixel on the CPU (the code shown below is the simpler 2D version which accepts 2-vectors, but I use an extended version in 3D which accepts floating-point 3-vectors which then get converted into fixed-point within the function with the Z value interpolated at each step using bitshifts). // Calls plot(x, y) for each pixel of a line drawn from p1 to p2 using fixed-point DDA. template void plot_line(Plot plot, Vec2i p1, Vec2i p2) { const Vec2i64 slen = p2 - p1; constexpr int32_t sign[2] = {-1, 1}; const bool a_small = abs(slen.y) < abs(slen.x); const bool a_large = !a_small; const int64_t end_val = slen[a_large]; const int64_t step = sign[slen[a_large] >= 0]; const int64_t x_len = slen[a_large] * step; const int64_t slope = div_nz(slen[a_small] > 32ll)}; plot((int32_t)pt[a_large], (int32_t)pt[a_small]); } } Can use 32-bit instead with 16-bit shifts, or even 16-bit with 8-bit shifts, or 8-bit with 4-bit shifts depending on acceptable precision/range and hardware demands. 'div_nz' is just a function to perform division with a check to avoid division by zero, returning zero in that case. Not sure how well it'd perform on C64 with the single division and multiplication per line (not per step), but it's something I lean on heavily to rasterize wireframes on very high-resolution 3D meshes (millions of polygons each) in real-time and faster than the GPU can do it (at least consumer-grade NVIDIA and AMD GPUs are surprisingly slow to rasterize lines; I think because they actually convert each line to a triangle strip and rasterize them as triangles). It'd need to be adapted a bit for raycasting to avoid possible ray leaks (the above doesn't plot any doubles as pixel artists call them) but the same fixed-point concept should apply to change the requirements for division and multiplication each iteration into bitshifts. I keep hearing that Bresenham is faster than DDA for line rasterization but I think that's assuming floating-point and not fixed-point. I've yet to find any Bresenham implementation beating this at least on today's hardware.

When I developed this method independently, all those years ago (heh, as many others did, it seems), I realized it's the 2D generalization of Bresenham's. (Which is to say the same thing, merely going the other direction!) You keep two error accumulators, increment and conditionally-decrement each by their respective slopes -- importantly, the slope doesn't need to be normalized anymore -- and just let it spin! The importance of denormal is, for creating a 3D view, you project a view plane relative to the view angle, and this all happens with basic 2D geometry. Which, I didn't know complex arithmetic or linear algebra at the time, but it's exactly that, as it happens. There's no trig involved whatsoever (beyond the one sin/cos pair to start with), no divide by zero, no janky hacks for special angles or quadrants -- it just works! And the thing about denormal slope is, it gives you the perspective-corrected distance automatically. Dividing the view plane into angles, say, is a whole different projection and needs a complicated correction to look right (to preserve straight lines). This does of course mean, you can't go to 180° FOV, but that's typical of perspective projection.

There's another tutorial that's been around for a while, like Lode's... though it recommends using pre-calculated look up tables for sin and cos... www.permadi.com/tutorial/raycast/rayc8.html so no overhead of square roots

can you expands on how it could be used on AABBs? I know how it's aabb vs aabb is done(add the sizes of one box to the another and then raycast), but I simply can't imagine how it can be done with this algorithm

Well infinity is a valid floating point number and the maths still works out when it is used, so should be ok.

@@javidx9 yeah. but NaN is not infinity... well we all assumed something

I have a video which is "maths for aspiring game developers" which covers the basics

@@javidx9Hello javi dou you know how to scale sprites when texturizing the walls? mi grid size is designed for 8 units but my sprites are 128*128. Do you know if its possbile?

Thanks Harshit, my RayCastWorld "engine" does floor and ceiling sample still with columnar rays. kzfaq.info/get/bejne/jM-aktKTzNydmGg.html

Detecting the face just requires some creative if/else action based upon the ray direction, and yes I believe this will work just as well in 3D.

zeno's paradox at it finest, you'll be eternally computing it and never reaching that edge.

If you follow the link to the source you'll see an even faster implementation commented out that just uses abs() function.

It could be If you are prepared to interrogate the cell for some alternative description of collision. This of course slows you down.

Typically these types of visibility tests benefit from terminating as quickly as possible (finding the nearest occluder ASAP and stopping the search). If you want everything that intersects the ray or other primitive like view cone or a circular/spherical search parameter without the occlusion, I think best bet is to use a spatial index and use it to find all things that intersect the primitive in logarithmic time.

@@darkengine5931 I didn't say can't use an index table with this, I'm saying that you use the size of the scene to determine how far in the table to jump x and y indices before reading the next index before switching axis, in other words because you know how far to jump you skip the "is dist 1 greater than dist 2" check and keep adding the values until you passby the scene boundaries or find an indice that is not 0

​@@zxuiji I see! But I think #7 sounds a bit expensive if I understand since you're performing a parameter search if I understand correctly (something that I think would require a miniature loop or some additional inner branching). DDA achieves the equivalent of #7 by exactly determining which grid cell to check each marching step when all we have is a grid and slope from #6 with just a tiny bit of arithmetic each step and no need for any inner loop. If I'm misunderstanding, could you describe #7 with some pseudocode along with the overall loop?

Raycasting must both hit every tile and tell you how far away that hit was. I think you might be able to do something similar by testing all the x intersections then all the y then taking the shortest, but I doubt it would be any better.

I'd rather use existing solution for voxelization, or at least look at existing implementations. Maybe "gvox" can do it, idk. One way I was thinking of is generating point cloud from from mesh by taking each triangle and generating points on the triangle , and then voxelizing that point cloud..

@@sti3167, Yeah, I'm just having a break from it for now. I did try something similar to voxelating a point cloud. I simply turned every point in the mesh into a voxel. The problem I was having, as I increase the resolution, gaps appear, Lack of experience with this sort of thing I think. I did think maybe I just subdivide all the faces down to a size smaller than the voxel faces but I don't know how efficient that would be and I haven't given it a go as of yet. I wish I could find a 3rd party lib for Java, trust me I have looked. I have a working implementation in Python using TriMesh. Its fast enough and gives good results but,...bound to Java. I toyed with the idea of compiling python into an executable and then running that from Java but this in itself has problems. I also toyed with the idea of hitting an end point to get the job done. While that will work I don't like the idea of having to host a server and have the application call out every time I need to voxelize something. Either way thanks for the suggestions.

Yes, just always choose the minimum each time

I studied Computer Systems Engineering, then Neuromorphic Engineering. But I have a variety of programming interests and have programmed for over 30 years. You tend to pick up a thing or two over that time lol

@javidx9 Neuromorphic Eng sounds rude man, hope to learn too much from you. Thanks for your content and pick up at least one thing, haha

Ah sorry, I miss this part: float(vMapCheck.y)

That's how reflections work, rays and angles

@@supersonictumbleweed Yes but, could tiles (the DDA algorithm showcased in this video) improve performance for raycasting reflections/lighting/etc?

@@ZlotyChannel yes, kind of You can use the generalised rule to speed up rendering of arbitrary geometry. It's called octrees and it's a binary tree for 3 spatial dimensions. It divides space into cubes, where cubes are of various sizes, but they're all on the integer boundary. If you look at such trees from any 2d side be it XY or XZ or YZ you get a square grid