How is this implemented?

[io12]

This is the coolest mod I've ever seen ever. I'm curious how the portal rendering and physics is implemented. It would be awesome if there were a high-level description of how the mod works in the repo.

[MacDue]

Not this mod exactly but you may find these videos interesting (they explain how these kinds of portals generally work in games -- they're both great videos & are fairly high level): Coding Adventure: Portals - https://www.youtube.com/watch?v=cWpFZbjtSQg&t=736s How were the portals in Portal created? - https://www.youtube.com/watch?v=_SmPR5mvH7w

[Designation6of10]

I've actually been doing research on this, considering using a similar system in a game I'm working on in Unity. The question I have is this: How do you achieve this effect when either end of the portal are in a separate world space? I wish to implement a similar system using scenes in Unity, but I'm not sure it's possible to load both scenes in separate worldspaces, so they never overlap. Are you simply able to preload the dimension in a different space?

Sorry for the long question.

[Johni0702]

@Designation6of10 I'm not familiar with Unity but large parts of MC were actually built with multiple worlds loaded at the same time (namely anything running on the server). The client however only expects one active world at any time and BP just swaps out that reference with different World instances as required during client-side ticking, packet handling and rendering. It also fixes various instances of MC expecting there to be only one world, e.g.

• replacing the main message queue with one that remembers the world (ref)
• wrapping packets for secondary worlds so they're handled with the right world active (ref)
• replacing the chunk compile&upload system with one that simultaneously supports chunks from multiple worlds (ref)
• replacing the management i.e. scheduling of new chunks to be rendered and disposing of distant rendered chunks with one which supports multiple render passes from the same world (ref), otherwise MC would unload chunks when you render the view for a distant same-world portal and would then have to re-compile/upload them each frame
• fixing vanilla bugs which only manifest when rapidly swapping the world (e.g. thread-unsafe access to the player, multiple times)

And that's probably where you may be out of luck with Unity since you cannot just change any engine code at will.

wrt to the original issue: I intend to write a file with high-level and detailed description (cause for some things it's probably not easy to understand just from the code how they're supposed to work) once I have solved most of the 1.14 issues (so I don't have to re-write the whole thing once that's supported).