You are of course porting this to the Pokitto as we speak?
I’ve seen this trick done many times before
In the Tardis mod for Garry’s Mod:
And in Antichamber:
And obviously before that in Portal.
Nice to have some MIT-licenced code for it though.
Especially given that the code is pretty good quality.
I’m a bit unhappy about some of the naming contentions,
but it’s using references,
override, smart pointers…
All the good stuff it should be doing.
Theoretically this kind of thing has been possible from as far back as Doom.
There’s a technique that can achieve the same effect using Doom’s sector-based render engine.
Said technique is cheaper to implement, and thus would probably work on Pokitto.
(I was once working with a friend on an engine like that intended for a certain monochrome console, but neither of us is particularly brilliant at maths so we got stuck on figuring out the projections and put the project on semi-permenant hiatus.)
I greatly sympathise with the “Why do I keep writing engines?” question. I have several similar problems.
I know this engine, it’s awesome, think I must have talked about it in some other thread here.
@Pharap the engine is fundamentally different from those used in Antichamber, Gary’s Mod, Portal and Doom, and it can natively do things that these traditional engines can’t (at least not without many trouble AFAIK). The traditional engines are rasterization based (object-order) and though they can “fake” some kinds of non-euclidean space with portals and deformations of level geometry, they can’t easily model a general non-euclidean space, e.g. a continuously curved one, because to do so you need to cast rays from the camera that will travel through the curved space and land in not very predictable places, plus deforming 3D objects requires their dynamic subdivision etc. – attempts at doing such stuff results in not very nice solutions and not very precise results. The non-euclidean engine can do this thanks to being an image-order ray-tracing engine:
I take it you know this from reading the code?
Or is there a write-up about it somwhere?
The author didn’t mention any of this in the video,
his description of what’s going on appeared to match the typical ‘portal’ process.
I also didn’t see anything that could only be done using a non-Euclidean engine,
hence my skepticism that it was doing anything special.
The sequel video is far more impressive:
I haven’t looked at the code actually, I’m just thinking about the math, but in the video description the guy says the same:
I decided to do something with it that cannot be done using traditional rendering (at least to my knowledge)
Also e.g. in the video you linked at 2:58 he says this and shows an example room, even though I think that would still be possible with normal engines, just not very easy.
I’ve studied these rendering techniques a lot, my thesis was about rendering curved mirrors – a similar topic that deals with curved spaces – reflections and refractions on curved surfaces are one example of what ray tracing can do easily which traditional rasterization can’t do in general. These things are nowadays only approximated, mostly by screen space techniques, but these only work sometimes and the results are generally not correct, they just cheat the eye. I personally haven’t even gotten to try to actually deform the space in the mirror because it’s complicated as hell, both the math and programming, rasterization simply wasn’t designed for this. Rendering a non euclidean space is a very similar problem of tracing the rays of light that travel through curved space into the observer’s eyes.
The specific things I’ve seen showcased in the videos probably wouldn’t be impossible in normal engines (even though I think it wouldn’t be difficult to come up with such things), but would require a lot of manual work, placing portals, scripting the deformations etc. I imagine with a non euclidean engine you only define the curvature, which can mean just writing a simple equation, and it simply works.
Also the guy says the physics uses the same code as the graphics, which is a huge advantage.
Yes, I edited the video link in afterwards rather than posting an additional comment,
hence the horizontal line separating the edit.
Until that point I had not seen any definitive evidence to the contrary.
I would have edited out the earlier comment after having reached that point in the video,
but I was expecting it to actually register as an edit,
and I didn’t really have time to do more than drop the video link in.