next »

[Crimsontide]

I don't understand then... what is depth going to get you?  Just knowing how far an infinitely thin single ray would penetrate wouldn't give you anything that of use.  I don't understand how that would make convincing hair.

What your describing (if I understand it correctly) sounds like Volumetric Appearance Modelling.  Here's some articles that might help: http://www.cs.cornell.edu/projects/ctcloth/

[gimymblert]

No that's not it at all, it's closer to a simple parallax mapping, that's it. It's not realistic micro scale either.

Another to see it is that it's like interior mapping tricks.

[gimymblert]

It's close to that:
https://computergraphics.stackexchange.com/questions/4094/is-there-a-method-to-do-ray-marching-style-modulus-repeat-with-raytracing
https://www.shadertoy.com/view/lly3Rc
https://www.shadertoy.com/view/MlK3zt

[BorisTheBrave]

1. hair are approximate as parallels, you can then turn that into a 2d problem by taking the cross section.
2. the 2d problem can be turned into a 1d problem, using slopes to compute a delta. So it become an interval overlap problem.
3. The line is wrapping, basically a circle topologically, so it's equivalent to the overlap of the clock needles or planet alignment (that is when big needle move a certain distance (in our case the wrapping unit) the small needle advance at another rate, given the two rate, when will they overlap, here when will have a hit, with in this case discrete movement instead of continuous like clocks and planets).

I understand (1) and (2). What I'm telling you is (3) isn't helpful. You must write a loop either way, and none of the maths is simpler. The stack overflow post tells you the same thing.

It's analytical so there is no recursion (ie no stepping through the volume, it's basically a single primitive intersection that have visual recurrence property due to wrapping).

To re-iterate, I see no way of doing this without a loop.

https://www.shadertoy.com/view/lly3Rc

Ok, I had a look, at this, its very nice. I think it explains very well what you are after. At first glance, this demo contradicts what I wrote above as it has no loops in it. But no. It only works when the mask is very fat. Anthing narrower than 50% of the repeat width runs into problems. You can see that with your second link, with the "thin square". It has graphical glitches which none of the other masks have. So for hair like thicknesses, it's not going to work.

[gimymblert]

    The idea is that you can reduce the problem from 3d to 2d by seeing where the ray hits the first two planes
    and then using the uv coordinates of those intersections as two points defining a 2d ray.  You then do a
    2d raytrace of that ray versus a shape, but valid intersection distances are a multiple of the vector's length
    instead of a continuous calculation.

    For this to work, you need to be able to analystically solve 2d ray vs 2d infinitely repeating shape.

    An way to solve this is to make sure the shape is constrained to a single tile, and when laying the shape on
    a grid, that no border between "open spaces" is less than 0.5 units.

    The reason for that is because the vector can at most move by 0.5 units on any single axis (since we modulus the vector).
   
    If we have a border that is less than 0.5, we will think we got a hit, when in fact it might be a miss, if the sample point
    is not actually inside the solid point!

    The last two shapes are fail cases.

    The checkerboard is a problem because if the ray is moving up and to the right or down and to the left, it can encounter
    border thickness less than 0.5.

    The thin square is a problem because it has a very thin border, which is less than 0.5 in all directions!

    The ultimate goal of this stuff is to try and figure out how to make infinitely repeating shapes in ray tracing, like
    can be done in ray marching via modulus!
    http://computergraphics.stackexchange.com/questions/4094/is-there-a-method-to-do-ray-marching-style-modulus-repeat-with-raytracing

I think it's a bit different, he solve the problem empirically and didn't pursue further (all contribution by him on internet stop by that point) he basically said it wanted to go further than the limitation here. Also he work on a 2d approximation, I further reduce it to 1d. And we can "see" in the 1d problem that it's a periodic or "rate" problem, except I don't have the mathematical competence to translate it, but I can trace it empirically.

I'm not sure the reason that doesn't work has anything to do with the fundamental, for example I don't use the modulo, I avoid modulo by translating into periodicity (hence focusing on wrapping) that's the contribution I'm trying to make.

I think getting stuck on the raytracing/raymarching semantic it emulate is a red herring. That's why I didn't focus so much on the aspects of the idea, but more on the "math". Once you unfold the space, it looks very much like a trig problem, except we don't intercept a continuous line.

Think about it, if you have two interger interval, you can deduce the bigger pattern by simply multiplying them, so if you have a beat on twos and a beat on 3, they pulse the same way on 6 because (2*3=6) so you have a new interval from the former two. Now if you have 2 beat on twos, they are sync, but if you offset one by one unit, they will never be sync ever. By going 1d I basically have the same problem. I need to translate that intuition into proper mathematical terms and formula.

[Crimsontide]

It's close to that:
https://computergraphics.stackexchange.com/questions/4094/is-there-a-method-to-do-ray-marching-style-modulus-repeat-with-raytracing
https://www.shadertoy.com/view/lly3Rc
https://www.shadertoy.com/view/MlK3zt

That is kinda what I pictured you were trying to do.  The thing I don't understand is how that will translate to anything resembling hair.

I think you're also getting a bit confused, or at least I am by your explanation.  The modulo (or similar like bitwise AND on a fixed point/integer) is required to avoid having to repeatedly step through the intervals.

[gimymblert]

Forget hair then lol

I don't need modulo precisely because I don't want to STEP through the interval, we already have the interval (the rates) all my explanation is basically trying to demonstrate it's a problem ANALOGUE to rate superposition or any similar problem (ie intersection between two moving elements, like in dead reckoning) all can be solved analytically without stepping through.

[qMopey]

demonstrate it's a problem ANALOGUE to rate superposition or any similar problem (ie intersection between two moving elements, like in dead reckoning) all can be solved analytically without stepping through.

Unless the shapes are rotating. Then you have an arbitrary non-linear equation, which cannot be solved analytically as there is no geometric pattern of the function to follow.

[gimymblert]

Let's forget about all of that:

Let's say you have two beats with different frequency, is there a formula that tells you when the beat will happen at the same time and or if they will never. With t=0 the start of the primary beat and offset the start of the secondary beat (that happen before the first beat get it's second pulse).

This is the problem I'm really trying to solve.

[BorisTheBrave]

Let's say you have two beats with different frequency, is there a formula that tells you when the beat will happen at the same time and or if they will never. With t=0 the start of the primary beat and offset the start of the secondary beat (that happen before the first beat get it's second pulse).

This is the problem I'm really trying to solve.

Ok, firstly, that'a actually a simpler question than you were asking before (before, the "beats" had a width they could overlap at, now they are instantaneous. I think you'd find the instantaneous variant is actually not useful to you).

And secondly, that question *still* cannot be solved in constant time. It's actually a variant of a "linear diophantine equation", which requires you to compute the GCD of the periods.

[gimymblert]

Are you sure? I don't have many unknown at all! ALso I don't understand the GCD as I don't need to stay on integer, I use beat as a way to illustrate the problem because people where getting stuck.

Since then I found teh planet alignment problem that solve this in a simple equation:
https://www.mathpages.com/home/kmath161/kmath161.htm
In fact I was having problem because I was trying to either divide or multiply, apparently we need to multiply the inverse of the rate, it also similar the common trivial problem of two vehicle traveling at different speed and ask when one will overtake the other, that is you need the ratio of one speed to the other. Also in my case I have a lot or normalisation that simplify the problem.

But maybe I made a mistake I still can't see? I haven't implemented it yet, I'm ready to see my delusion collapse on my feet (or I'll forget a single ";" or swap two variable and cry all my day out until someone point to me I missed something obvious) ... This is hard.

Also I contacted the person who made the shadertoy, and he @ the person who made the original implementation who inspired him (also made the clay sdf game on ps4) and he told me that we can trace cylinder in O(1) using such technique. https://twitter.com/SebAaltonen/status/1115486353649741824

I think in general my questions are confusing because I take a concrete problem, expose it and go through layer of abstraction to reveal the real problem I'm having, then ask about how to solve the abstraction, to which people are lost because between the start and the end there is no easy relation. I mean I got to hair to beat synchrony in 2s :O I'm not good with translating those translation into math either.

I'm currently really reassessing how I ask for help and how to present stuff I'm not good at it lol.

[qMopey]

I can say I’ve always wanted to help you with your projects but have never really understood what you’re talking about 

[gimymblert]

Nah I understood, probably that if I was able to clearly pose the problem I would be able to solve it myself lol, so I think that engaging with you actually help make thing clear by removing the clutter, as I'm forced to distill down the problem in a way that's understandable.

Anyway I took inspiration of the planet thing, which I can see with a renewed light, 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?


WHat bother me is when rate1 < 1

[InfiniteStateMachine]

So I want to make a smallish GUI program for managing projects for a Synthstrom Deluge. Basically involves managing a file system and manipulating some XML.

I thought this might be a good idea to play with ImGUI after not using it for about 5 years. The thing is, I forgot I have to provide my own buffers, context etc..

Is GLFW still the way to go if you'd like to get a window that's compatible with windows/linux/apple? Any other alternatives I should know about?

[qMopey]

IMO SDL2 is superior, but GLFW is fine.

[Schrompf]

To my knowledge the two aim for very different targets. SDL is an all-in-solution. GLFW does the OS interfacing and otherwise leaves you alone with an OpenGL context. The latter I very much prefer.

But now that you say it, qMopey - can I use SDL2 as a Window Opener only? Or do I always have to fight its audio/input/graphics subsystems when I have my own?

[Daid]

But now that you say it, qMopey - can I use SDL2 as a Window Opener only? Or do I always have to fight its audio/input/graphics subsystems when I have my own?

You have to have the event loop of SDL2 running for most things to work. But the rest is generally optional. Except that some things require a window to exist on most implementations (for example audio won't work without a window on Windows). I'm using SDL2 for window+input+OpenGL context creation. But it's rendering things I just ignore, as they are unsuited for me.

[oahda]

SDL allows you to pick and choose quite a bit! You can create an SDL renderer, or you can manage your own graphics context (OpenGL or otherwise). You get to decide what subsystems (video, audio and so on) to initialise or not.

But if GLFW does everything you need then I see no reason not use it since it's nice to have something lightweight!

Then again SDL programs don't tend to end up very big either, and despite its larger size it's very easy to get up and running with, no unholy ritual required to install/link it.

Depending on what you're doing exactly you might benefit a lot from SDL's amazing input support (especially for things like gamepads) or wide cross-platform support, can be worth it just for that.

[Schrompf]

I rolled my own input long ago. That "wide platform support" is tempting, though. There's a slim chance my game will come to Switch, six years after I released it on Steam. And GLFW is not prepared for this.

[Daid]

While I don't know GLFW compared to SDL2, as I have no experience with GLFW. I do know SFML vs SDL2.

And compared to SFML, SDL2 input system is so much better. Both SFML and SDL2 have the same event API. But SFMLs keyboard handling is just broken beyond simple keys. And text input just barely works. Supporting all numpad keys was too hard for them I guess, want to know if the numpad period or the normal one was pressed? You cannot in SFML. SDL2 does this proper.

The gamepad support of SDL2 is nice, just knowing you get a pre-defined mapping is just useful if you want easy and simple gamepad support.



"wide platform support" is tempting, but not as clear cut as you might think. SDL2 on Android took me quite a bit of tinkering to get working, and required a patch
 to actually build properly (still better then SFML, which has Android support, but once again, just barely functional, and a much bigger mess to get it to build)
SDL2 with Emscripten for webassembly works quite well, but has it's own set of quirks, requiring a bunch of changes in your code base. Unless you use threads, then you are pretty much out.