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, const, const-correctness, nullptr, std::, 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.