There is this thing I need to get done, it’s an extension and end goal of experiment with relief function shader. Basically I want to trace in fragment shader hair that had parallax property. Since I’m having problem with simple math due to a past burn out, my brain blanking out on thing I should know, I figure out that chronicling the attempt publicly and verbalizing it to other people might help me get thing fall into place, and maybe some people might be interested and drop some clue.
Hair rendering is notoriously hard and costly, due to the high number of occluded elements, which may or not contribute to the final image. I propose a technique that use a simplified model of hair, as parallel line in an extruded grid, and a mathematical representation that would allow to find the first visible intersection to a line without having to pay the cost for the occluded many, and potentially infer how many hair has been traversed with the same operation at the exit of the volume.
The main idea is to realize that the simplified hair is “coherent”, ie all are in the same position in the grid (idea to shuffle it will be explored later) and therefore all cells are indistinguishable from another, they can be superposed. This mean that a ray entering at one cell boundary will have a predictable trajectory wrapping in the superposed space. The challenge will be to figure out the math of intersection in that wrapping space, which would be the equivalent of determining occlusion in one hit. To simplify further, we will move the hair position to the origin corner of the cell so it’s 0,0. We will adapt the DDA algorithm to get to that result. https://www.scratchapixel.com/lessons/advanced-rendering/introduction-acceleration-structure/grid
Further analysis show we can simplified the problem more by simply projecting to 2d position as it’s extruded, therefore we can align the grid with one axis, then project to 1d, where it become a problem similar to the " how many timed clock hand overlap in a day" or planetary alignment puzzle https://www.mathpages.com/home/kmath161/kmath161.htm
The end goal is to have a version of the shader that can also represent curly hair (intersection with helix line).
Given I found all the mathematical foundation it should have been trivial from there … I’ll add image later to illustrate the technique.
Oups, end of years + a loss in the family + a new occupation didn’t make me live up to those statement. Slowly coming back to it…
a. the basic
I was trying to model afro textured hair cut, but wasn’t satisfied with the result. Afro textured is inherently volumetric and I wanted to reflect that fact.
There is multiple way to implement that idea but my first instinct was to try a parallax shader, to model the superposition of strand, basically representing multiple layer displaced virtually by the view vector.
Going through the math I realized there was opportunity to expand on that. But let’s review the math of layer parallax (I hope there is no mistake, I’m not the most competent mathematician here).
Let’s consider an UV surface, with layer at regular interval d, and a view normal vector v. Let’s simplify the representation of a 2d cross section.
Due to thales theorem, we can see than the offset is a ratio k of distance to the plane. If we set d=1 then k<1 because v is a unit vector as such k is equivalent to the depth when v is looking from the top.
Once we see the result we understand that the sample are regularly space in a predictable way, we might be able to derive mathematically an intersection with a fixed position, and skip sampling multiple time an occlusion assuming it happen at the same regular interval.
If we assume hair strands are regularly space line in uv space, we can approximate the hair volume occlusion mathematically. While strands have thickness, we will assume they are mathematical line and try to find the basis of the math from there.
The insight is that multiple plane at the same distance is equivalent to a wrapping plane, also UV wrap around the 0-1 range. SO if we can port the math to wrapping space … it would be equivalent to tracing through an infinite regular grid. Also since we have wrapping, we can realize it’s equivalent to looping, stepping at regular interval is therefore equivalent to the clock needle overlap problem.
The other trick is to realize that the support (the triangle face) can bias the visual such has the straight line become curved while the math stay the same (operating on UV space not in visual space). Of course it has limitation (such has curving beyond the horizon wouldn’t work, as the ray would need to intersect twice the same strand.
It’s not really a new idea, some people have experimented with modulo space, though I need to find one that give interesting result for hair strands occlusion.
First let’s assume the hair strands are all situated at position 1 in x in all layers, and the view rays start at position 0 in x on the first. We will trace rays through all layers such as they intercept the strand position at each layer.
If we trace back to the first layer, every intersections with a layer before hitting a strand position, we can observe a pattern. Because the ray slope is constant, and each layer distance is the same, the projected intersection to the first layer are equidistant. We can see there is a correlation between the depth of the layer, where the ray hit the strand is, and the number of projected intersection. Therefore the intersections number give us the depth. We then know we can just divide the distance, between the ray x origin and the strand x position, by the number of intersection to get the depth.
The corollary is that we can guess which depth a strand is hit, by looking at the number of step it takes, which is a function of the slope. Figuring the slope at the first layer give you the delta of the step, you then just to divide the distance.
Wrapping horizontally is similar, the difference is that the number of step happen vertically. But really we just need to observe, that the distance to the targeted strand horizontally, is a multiple of the distance to the reference strand on the first later.
Those simplified observation are here to demonstrate how we can infer positions of virtual strands (ie strand beyond the first layer and horizontal wrapping), based on the rays slopes vs the reference strand position, in a kind of wrapping trigonometry. And also how we can basicaly simplify the math to a linear convergence using division or modulo.
However to generalize further, we still need to demonstrate how it works when we start changing the slopes and the offset of the ray, instead of assuming all ray point to a strand from the zero position. And we need to verify when the math allow convergence to a virtual position of a strands and when it does not. Doing so would allow us to guess the first hit in a virtual volume.
Once we have done that, we have effectively found a way to trace an infinite volume of primitive, however hair has thickness, we will need to find a way to intercept more than an infinitely small position. Ideally we would also generalized to different kind of wrapping shape, such has helix, which would allow us to emulate curly hair.
Up until we cheated by locking the ray slopes and position to the a single place into the receiving surface and only to slopes guaranteed to hit a target point. It was done to demonstrate how it would translate to a 1d problem of interval overlapping. But now we need to introduce two new parameter:
arbitrary slopes
arbitrary starting position of the ray.
1. variation of slopes
As we have shown earlier, the slope of the ray translate into discrete steps, with same size, on the “surface”, and there is collision when they are basically a multiple of the wrapping size, and that multiple give you the depth or distance of the collision within the infinite space. But what happen when we have an arbitrary slope, that give us an arbitrary step, and we want to find the multiple to the wrapping size, does that multiple even exist?
Basically we can reformulate the problem as beat synchronicity, let say you have two beat, one that goes on twos and the other on three, when will the beat pulse together? In this simple set up it’s easy, they will be synchrone every 6 beats, that’s the “collision depth”. But what does that mean in mathematical form, how can we generalize it? seems simple though isn’t it?
2. variation of position
Up until we cheated (again), by fixing the position at the start we made it easier, since the space is wrapping the starting and the target are basically the same position, and since we normalized the wrapping distance, it also mean we had neat number to play with. But what happen when we move the ray to anywhere within the wrap space, as it should happen in a real case? Well let’s see the beat analogy again, let’s say we have two beat on twos, but one start half way after the first beat, they will never be in sync again, ie similar beat with an offset, they will never pulse, can beat we translate that into mathematical form, to check that two beat will never converge to the same time?
I use beat analogy, but we can basically use other one, since the space is wrapping, we can also see the surface “segment” as a circle, since we have stuff moving at different rate on that circle is analogous to a clock needles, which mean we can relate to the clock needle superposition problem (itself analogous to the planet alignement problem), with the added complication that we are moving by “discrete steps” rather than a “continuous rate”.
So basically it’s this, given two elements moving at discrete step, can they overlap and when? The minimal distance will gave us the depth of the collision, and probably we can define the periodicity of the collision after that.
So here is where my competence end, I need to translate those insight into mathematical form to resolve.
Up until now I showed that the problem could express as a 1d line with interval overlapping. But since the space is wrapping on itself, that is the first line and teh last line is basically the same, instead of an infinite line with repeated “beat”, we can represent it as a circle with interval stop around it: In this example the black tick overshoot the target after one wrap, the red tick is the resulting position of overshooting. We need to calculate how many wrap before it can actually overlap the target.
Using this representation allow us to find equivalence, it looks like a clock, it also look like circular planet orbital. Turns out we can probably get inspire by that to find mathematical equivalence. If you think a bit about it, it turns out that’s a similar problem than planets alignment, or the clock needle superposition riddle. The hair target
If it’s correct we have this:
let say we have two point moving at two rate,
the position of each point = rate * t.
Therefore position1 = position2 it mean that rate1 * t = rate2 * t,
that is (rate1-rate2) * t .
What’s missing is the bigger period in which rate1 and rate2 are inscribed,
we can get it by having rate1 * rate2.
So rate1 and rate2 are sync for t= k(rate1*rate2) / (rate1 -rate2) with k being the number of period.
However we have a specific case where rate2 = the normalized wraping size, rate2 = 1, for k = 1 we have t = rate1 / (rate1-1).
But we only assume no rate as an offset,
so if we check with offset we have position1+ offset = position2,
which translate (rate1 *t) +offset = rate2 *t
which lead to t * (rate1 - rate2) + offset
and we can probably write the final result as t = k(rate1*rate2) / (rate1-rate2+offset)
which finalized as
t = k(rate1) / (rate1+offset-1) which has no solution when rate1+offset = 1
Probably? Any mistake?
Extruding 2d intersections points
More math (help given by someone else in another forum), this would help us define the line in 3d, since hair is axis align with the support geometry UV space (the deformation/orientation of that support geometry being the approximation of the hair direction) once we have the virtual depth, we can compute the virtual position as a function of the origin and the slope.
Jittering the depth alignment
Anyway, we can have some more insight, we have assumed the wrapping itself was fixed, if the wrapping windows itself move, it’s equivalent to find 3 planets alignment … What’s the use? well if we stay in the two beat system, we get all hair perfectly aligned in regular interval, if the wrapping move too, we can jitter the depth predictably by multiplying by clever number.
However this isn’t that easy, if we go back to the 2d representation, let say we have an angle where the beat is bigger than the wrapping size, we would wrap horizontally first, so the jittering position will not match a ray sampling the nearby cells position, because the order of traversal would matter, so we need to define the wrapping displacement as a 2d problem. Which I haven’t figure out yet.
More works is needed
Up until then we have assume mathematical object, ie point that have no size. In order to properly compute hair, we need thickness, we need to find a way to detect when our beat is within a distance of the target to get a hit, not just right on the target. Once we can do that, we can probably extend to a 3d volume cross section (the circle shape of the hair), the problem still being finding a single point, so the extrusion should remain the same.
We also need to find a way to intersect helicoidal shape, they are too repeating, so a wrapping function is fine, the challenge is that there isn’t cheap formula to intersect sin wave, which is needed to get the helix.
The end game of this exercice, infinite field of infinite helix shape!
NOTE:
If we were to just do infinite straight hair, probably a beat base solution is overkill, on shadertoy, there is already wrapping tracing shader, we could just extend them to get hair approximation.
Doing recursive interception on wrapping helix is hard, the equation of the helix is x = r cos t, y =r sin t, z=a t … all those sin and cos create problem, there is no simple equation to intercept them. And it’s a curve that is not convex, it’s hard to find simplification.
I try simplifying by boxing the shape abusing the inherent symmetry, and then approximate it with a x² curves that we can reliably intercept but I wasn’t able to see anything that will put me closer to the goal.
Up until I decided to step back and instead of trying to intercept the coil, intercept the support cylinder, it can be reduce to a 2D problem of line circle intersection, which doesn’t have any sin or cos, but then that lead to a realization that the cylinder unroll into a 2D wrapping space where the coil is basically just the diagonal line …
Now the idea is to try and translate the cylinder intersection equation into an equation of all potential wrapping hit points, given that all points are in the form of (x+n, y+m, z+o), with n,m,o being the wrapping period. Convert that into cylinder space, hope that no sincos appear and trying to intercept the diagonal for hit on the helix…
I spend some time with math equation … that lead nowhere Trying to express thing into varying variable, couldn’t do it, maybe I wasn’t using the proper visualization:
Oh …
You can turn the whole 2D cylinder projection into a single dimension where the line move at integer wrapping step … where I have seen that before?
That also open the possibility of doing 3D sampling of pseudo noise integral, ie doing cloud without raymarching a noise?
Anyway, now I can cleanly project the point back to the cylinder with a cos and have a definitive way to measure hit and miss of rays. Also it solve the vertical on the unwrapping of the cylinder, but now we need to find the delta ie where on that vertical the infinite set of point fall and how to find that intersection with the helix … We have the horizontal delta but we need the vertical delta, if possible as a predictable pattern. My guess is that it will be nasty SIN, my hope is that it is quadric instead …
Hairtech flat only
[code]
#define DARKEN_OVER_DISTANCE 1 // This makes it easier to see the different layers in a static image, not to hide a max distance.
#define SHOW_2D_SHAPE 1 // This makes the 2d shape be shown in upper left corner
const float c_camearaDistance = 6.0;
const float c_cameraViewWidth = 24.0;
//============================================================
//============================================================
bool BooleanFunction_Square (vec2 current)
{
return (current.x < 0.25 || current.x > 0.75 || current.x < 0.25 || current.x > 0.75);
}
//============================================================
float NumberStepsFunction_Square (vec2 current, vec2 stepValue)
{
// if it's already in the shape, no steps to take
if (BooleanFunction_Square(current))
return 0.0;
float stepsX;
if (stepValue.x < 0.0)
stepsX = (current.x - 0.25) / -stepValue.x;
else
stepsX = (0.75 - current.x) / stepValue.x;
return ceil(stepsX);
}
//============================================================
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
// set up the camera
vec3 cameraPos;
vec3 rayDir;
{
vec2 percent = (fragCoord / iResolution.xy) - vec2(0.5,0.5);
vec3 offset = vec3(0.5, 0.5, iTime+0.01);
float angleX = 0.0;
float angleY = 0.0;
if (iMouse.z > 0.0) {
vec2 mouse = iMouse.xy / iResolution.xy;
angleX = 3.14 + 6.28 * mouse.x;
angleY = (mouse.y - 0.5) * 3.14;//(mouse.y * 3.90) - 0.4;
}
vec3 cameraFwd = (vec3(sin(angleX)*cos(angleY), sin(angleY), cos(angleX)*cos(angleY)));
vec3 cameraRight = normalize(cross(vec3(0.0,1.0,0.0),cameraFwd));
vec3 cameraUp = normalize(cross(cameraFwd, cameraRight));
cameraPos = vec3(0.0, 0.0, -1.0) + offset;
vec3 cameraTarget = vec3(0.0, 0.0, 0.0) + offset;
float cameraViewHeight = c_cameraViewWidth * iResolution.y / iResolution.x;
vec3 rayTarget = cameraPos + cameraFwd * c_cameraDistance + cameraRight * c_cameraViewWidth * percent.x + cameraUp * cameraViewHeight * percent.y;
rayDir = normalize(rayTarget - cameraPos);
}
// keep the camera in a unit cube
cameraPos = fract(cameraPos);
// If ray facing negative on z axis, just flip direction and invert where we are in the cube on the z axis.
// Now we only have to deal with positive z directions.
if (rayDir.z < 0.0) {
rayDir *= -1.0;
cameraPos.z = 1.0 - cameraPos.z;
}
// calculate the 3d position of the next two plane intersections
float intersection1Distance = (1.0 - cameraPos.z) / rayDir.z;
float intersection2Distance = (2.0 - cameraPos.z) / rayDir.z;
vec3 intersection1 = fract(cameraPos + rayDir * intersection1Distance);
vec3 intersection2 = fract(cameraPos + rayDir * intersection2Distance);
// Calculate how much the uv changes from intersection1 to intersection2.
// Convert it from [0,1] to [-0.5, 0.5].
// We need to know this to know if the uvs are going positive or negative and by how much, on each axis.
vec2 uvStep = intersection2.xy - intersection1.xy;
uvStep = fract(uvStep + 0.5) - 0.5;
// calculate how many steps it takes to hit something on the X and Y axis and take whichever hits first.
float steps = 0.0;
steps = NumberStepsFunction_Square(intersection1.xy, uvStep);
// calculate how far it is to the intersection we found
float dist = (1.0 - cameraPos.z) / rayDir.z + steps / rayDir.z;
#if DARKEN_OVER_DISTANCE
float tint = clamp(1.0 - dist / 5.0, 0.0, 1.0);
#else
float tint = 1.0;
#endif
// calculate the hit point
vec3 hitPoint = cameraPos + rayDir * dist;
vec2 uv = hitPoint.xy;
// sample the texture
fragColor = vec4(texture(iChannel0, uv).rgb * tint, 1.0);
}
//============================================================
float binarySign (float v)
{
return step(0.0, v) * 2.0 - 1.0;
}
//============================================================
// returns t
// circle xy = position, z = radius
// Adapted from "real time collision detection" IntersectRaySphere()
float RayIntersectCircle (in vec2 rayPos, in vec2 rayDir, in vec3 circle)
{
// rayDir isn't normalized, so normalize it but remember it's length
float rayLen = length(rayDir);
rayDir = normalize(rayDir);
vec2 m = rayPos - circle.xy;
float b = dot(m, rayDir);
float c = dot(m, m) - circle.z*circle.z;
// Exit if the ray is outside the circle and pointing away from the circle
if (c > 0.0 && b > 0.0)
return -1.0;
float discr = b*b - c;
// A negative discriminant means it missed the sphere
if (discr < 0.0)
return -1.0;
float t = -b - sqrt(discr);
if (t < 0.0)
t = -b + sqrt(discr);
return t / rayLen;
}
//============================================================
bool BooleanFunction_Checker (vec2 current)
{
if (current.x >= 0.5)
{
return current.y < 0.5;
}
else
{
return current.y >= 0.5;
}
}
//============================================================
float NumberStepsFunction_Checker (vec2 current, vec2 stepValue)
{
// if it's already in the shape, no steps to take
if (BooleanFunction_Checker(current))
return 0.0;
// there are different values to reach based on where we are in the pattern.
float lower = step(0.5, current.x) * 0.5;
float upper = lower + 0.5;
// see how long to escape the box on each axis, take sooner event
float stepsX;
if (stepValue.x < 0.0)
stepsX = (current.x - lower) / -stepValue.x;
else
stepsX = (upper - current.x) / stepValue.x;
float stepsY;
if (stepValue.y < 0.0)
stepsY = (current.y - lower) / -stepValue.y;
else
stepsY = (upper - current.y) / stepValue.y;
return ceil(min(stepsX, stepsY));
}
This limitation only allow for negative shapes (hole in a plane) instead of positive…
However an observation is that they do a lossy modulo, they don’t keep the original vector, I don’t know if that help, but maybe using a division and a modulo can reconstruct the missing data?
About my solution on earlier post:
Turns out the math I did, I realized was an extension of the DDA algorithm to corner of grid, so the final algorithm is likely to be a généralization of the DDA.
DDA main part is in the form of
cell size / normal vector component
and return the closest plane
My algorithm is
common period / delta rate
but can both can be interpreted as
period / interception velocity
which make sense, it mean how long before we catch up to a point for a given velocity, the main difference is that to intercept corner we scale the grid to the common denominator of the grid and velocity, that is when they overlap. DDA can be understood as a function to find the periodic intersection of planes.
Now the main problem is how do I handle interval testing?
The problem is we have 3 cases:
the stepping is bigger than the interval and jump over it
the stepping hit one time in any point inside the interval
the stepping hit multiple time inside the interval.
So If we consider stepping as interval too, it’s about finding recurrent interval overlap.
That’s a visual that’s not math, how do I turn that into math?
The general idea is that I find a way to turn the problem into a 1d interval problem, ALMOST …
The gist:
intersection with circle is done by projecting the center to the ray line (using a simple dot product)
that give you an intersection point with the perpendicular of the ray that goes through the center
because all space are basically the same, the line (the projection line) that goes through the intersection and the center of the circle is the same in all space, it’s constant as it has the same direction and goes through the same point
by only wrapping one axis (here the vertical axis) I make evident all interval, (here projected on teh horizontal axis), the cell size , the radius and the vertical intercept of the projection line are all nested constant.
but the vertical rate of the ray casted have differing offset, isn’t tied to the frequency of the cell size BUT the ray vertical rate is constant.
Which mean that the recurrent intersection of the ray with the fixed projection line is the key to solving the problem, IF the delta between intersection is constant, it’s basically just a distance equation from the first intersection to the center of the circle minus the radius and divided by the delta step to get how many step before first hit.
The magic is to find that delta formula, given we have a lot of triangle rectangle, it’s basic trigonometry or Thales theorem … should be … if someone figure it out
Studying the representation above I realized that while I was abusing symmetry to stay in a single gradient I could go on further, and only have rising rays (black angled lines), since the circle axis (pink lines) are always perpendicular we know they are intersected at regular rate by the rays, at least in a single span (in between two projection of the vertical wrapping), the thing is we can see that we kinda can predict where the “bubble” are, ie basically place where the ray will hit or miss in succession. That make sense, in some way the ray is kind of scanning the circle axis at a regular rates, we are jumping through the axis at fixed interval, which mean base on the first intersection we can “march” analytically on the circle axis of a single wrapping interval to define when there is a hit and how many, basically dividing the distance of the intersection to the radius divided by the step size, with an extra check to see if we jump over the primitive interval.
If we can generalize that to get the set of all interval, we are set, but the main observation is that it looks like, once projected on the horizontal axis, to a problem similar to interference pattern: Moiré pattern - Wikipedia there might be some math useful there
I find a new way to predict the recurrence of primitive intersection, using “empty skip” to solve the first hit problem before one wrapping of the ray.
Now I’m looking to solve the wrapping occurrence. It’s also potential to be generalize to any primitives and at least greatly accelerate any recurring shape. It might also help for “moving” positions based on the grid position.
B represent the ray interval along the minor axis trick. That is I wrapped vertically, with horizontal representing the axis of the largest component, aka the shallowest slope.
S represent the recurring grid interval.
I’m trying to determine occurrences as the interval drift relative to each other. At 0 they start at the same, but end with a slight difference, which is compounded at each respective recurrence, until they eventually sync back, if they ever do.
k is the number of time S repeat within B, so basically B/S as an integer division.
S/d = the fragment of S needed to add to kS to reach size of B, that at time 0 B = kS + (S/d)
r is the reminder of B - (k+1)S, and basically the start of a new recurrence offset.
I need to predict offsetn and (S/dn), let’s call the later dsn, and I cannot guarantee than k is fixed for all n.
Now things looks funny, is that offsetn and dsn are dependent on the previous state of each others. Worse there seems to be funny behavior depending on whether ds is above or below 0.5.
I’m not good enough about math to recognize a pattern, or known conjoncture or anything. More research are needed.
a car B going at 60km/h 1km behind
how long for car B to reach car A?
case 2
a series of cars A going at 30km/h but spaced at regular interval
a car B going at a speed S in between two car A
For what speed car B reach any car A?
case 3
a series of cars A going at 30km/h but spaced at regular interval
Car B is not a car, but a frog that can jump over the cars A, with jump of size J
How many jump before the frog land on a car for any position?
That has been my logic progression to try to solve this, I struggle a bit on part 3 though
function drawFastHits(){
const scale = GlobalStruct.gridScale
const start = collisionData.fasthit.start
const end = collisionData.fasthit.end
// const intEnd = floor(end)
const intEnd = ceil(end)
const intStart = ceil(start)
//loop fastHitList
//draw markers
const overlap = intEnd - intStart
//taking box size
const rayboxSize = collisionData.raybox.x2 - collisionData.raybox.x1
const circleboxSize = collisionData.circlebox.x2 - collisionData.circlebox.x1
//expending the box size together to test against single point
const minkowski = rayboxSize + circleboxSize
const halfCirclebox = circleboxSize/2
const marker1 = {x:intStart*scale,y:50}
const marker2 = {x:intEnd*scale,y:50}
const marker3 = {x:start*scale,y:75}
const marker4 = {x:end*scale,y:75}
color("black")
vertical(start *scale)
vertical(end *scale)
color("red")
horizontalLine(50, intStart*scale, intEnd *scale )
line(marker1.x,marker1.y, marker3.x,marker3.y)
line(marker2.x, marker2.y, marker4.x,marker4.y)
drawMarker(marker1)
drawMarker(marker2)
drawMarker(marker3)
drawMarker(marker4)
text(100,200,end)
text(10,200,intEnd)
text(100,210,start)
text(10,210,intStart)
text(10,220,overlap)
text(10,240,"ray: "+rayData.length)
text(10,250,"raybox: "+rayboxSize)
text(10,260,"minkowski: "+minkowski)
// const rayboxSize = collisionData.raybox.x2 - collisionData.raybox.x1
const gap = collisionData.raybox.x2 + rayData.length - rayboxSize
//verticalLine(gap *scale,0,100)
//----
//minkowski box
color("pink")
//draw the minkowski as a slab
//draw the minkowski as interger offset
//compute start and end of minkowski box
const minkowski_start = collisionData.raybox.x1 - halfCirclebox
const minkowski_end = collisionData.raybox.x2 + halfCirclebox
const minkowski_size = minkowski_end - minkowski_start
//draw minkowski line
horizontalLine(60, minkowski_start*scale, minkowski_end *scale )
//find next offset
const next = minkowski_end + rayData.length - minkowski_size +halfCirclebox
//draw next offset
verticalLine(next *scale,0,100)
//minkowski delta (snap to integer)
//if minkowski < 1 (if bigger always overlap circle box)
if (minkowski_size < 1){
color("green")
//this delta seems wrong
//I want the end of minkowski at 0
//vs the end of minkowski a 1
//that is 0+1 length
//0 = min start (gap before minkowski)
//+ minkowski size
const delta_start = (minkowski_start + minkowski_size)%1
//1 = gap after minkowski + gap avant minkowski
//+ minkowski (basically the whole length)
const delta_end = (minkowski_end + rayData.length)%1
const delta = (delta_end - delta_start)
// const delta_start = (minkowski_start - 0.5)%1
// const delta_end = (minkowski_end - 0.5)%1
// const delta
const sign = sgn(delta)
// distance to next circle box //if 0 no hit
const distance = (rayData.length-minkowski_size)/abs(delta)
//(how many time in integer
//there is delta (aka space to cross))
text(10,280,"delta: "+delta + " s: "+1/delta)
text(10,290,"sign: " +sign)
text(10,300,"distance delta: "+distance)
//every delta, the ray box get closer
//to the next relevant circle box
//actually not raydata length, just gap 1+2
//aka length - minkowski size
const next_hit = minkowski_end+floor(distance * (rayData.length-minkowski_size))//+0.5 -1
text(10,310,"next: "+next_hit)
text(10,320,"length: "+rayData.length)
//draw next hit
verticalLine(next_hit *scale,0,1 *scale)
//next hit should be delta * times in distance
//draw raylength filling delta
//---------
sign > 0 ? color("magenta") : color("aquamarine")
const inter = horizontalIntercept(mice,1)
const markerx = {x:inter*scale, y:100}
drawMarker(markerx)
//----------
}
// const gap2 = collisionData.raybox.x2 + rayData.length - rayboxSize
// verticalLine(gap2 *scale,0,100)
//rectangle(x1*scale,y1*scale, x2*scale,y2*scale, false)
}
Is there anyone whom can help?
And I still have to solve the sin interception on the cylinder,
which mean tracing the hit trajectories on the cylinder,
where probably the sin curve reappear but in distorted form
I just hope that form can be solved by taking advantage of the diagonal trick (ie x=y)
Trying to express thing into varying variable, couldn’t do it, maybe I wasn’t using the proper visualization:
