XComp's Forums

A place to discuss the mods of XComp
It is currently Mon May 29, 2017 1:55 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Hey!
PostPosted: Sat Jun 04, 2016 5:41 am 
Offline
Addon Developer
User avatar

Joined: Sun May 11, 2014 4:30 am
Posts: 149
Hey Xcomp! I was actually considering coming back to minecraft modding to basically create full on portal mod for myself when I saw this. Glad to see my work getting put to good use - Keep up the good work!

Yea - I knew the original was messy. Originally, I wasn't planning on other people seeing the code so soon - I would have cleaned it up! Also - I taught myself. So I usually skipped over many of the 'programming etiquette' sections to just learn how to make stuff... sorry.

I do have some ideas on synchronizing the two worlds together, if you haven't done that yet. Essentially - fake players. When a portal is in range of a player, add a fake player to the lists to receive packets, which then the fake player has a modified netty handler to repackage all of the packet's raw data with packet type and dimension number into a new packet and send them to all the players listening to that portal. This way - you capture absolutely everything, modded or otherwise. You re-feed the original packet through minecraft's normal packet system with that other portal dimension temporarily set as theWorld.

Additionally, being able to walk directly to another dimension should be possible just by hotswapping that dimension and the current theWorld, and invalidating all the chunks so they pull updates from the server. And of course, changing the player's location server side.

Yes, I know, it's all very hackish. But so was my original Linking Panels!


Currently, I'm working on my own video game project outside of minecraft. This, and work and school, has kept me out of the mindcraft loop for so long.

_________________
Bring me the blue pages!

Dynamic Link Renderers


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Sat Jun 04, 2016 12:43 pm 
Offline
Mystcraft Developer
User avatar

Joined: Sat Aug 25, 2012 9:33 pm
Posts: 3951
Hey! Great to see/hear from you! :D

Glad you are pleased with the result. :) I like the solutions you proposed here, and they mirror how I proposed solving the problems, so big thumbs up from me. :D
If you want to build that into LookingGlass I'd be all for! If you make/have a curse account I can make you an author of LookingGlass as well.

I'm not sure what the best workflow might be for adding this new stuff. If you want to make it as a separate branch on the main repo we can work on it together and then merge it in later. I'd be happy to help you improve your coding. :D Your code is very clever and solves things well, so that's already a big thing.

I actually some of what you mentioned here built in a separate project, and we can start with that as a base.

No worries on being out of the loop; I have been too.

_________________
I am the Mystcraft Dev.


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Sat Jun 04, 2016 7:40 pm 
Offline
Addon Developer
User avatar

Joined: Sun May 11, 2014 4:30 am
Posts: 149
My latest personal project has had me learn a lot about portal rendering, so I'll likely do just that.

Image

I started it recently, but it involves a house that's warped tardis style so all the rooms of different shapes are scrambled and put together... to prevent you from finding the exit. Horror/thriller - woo!

But what I learned from this, which may or may not be possible in minecraft, the best way to do portals is not with a render texture, and actually render directly to the screen. Using a farthest-to-current method, I draw quads over where the doorways are, and render everything in that room, then move to one closer. A shader attached to the doorway tells the renderer to skip drawing anything there, but it still depth-tests so nothing is drawn behind it either. Thus creating invisible portals that seamlessly blend in, regardless of screen resolution, with little-to-zero overhead, depending on the amount of clutter that is now automatically being culled do to the camera's projection.

Of course, the shader mod would partially break with this method. But it would be partially broken anyway, unless you're doing the entire rendering process per doorway. Then the overhead would be that the shader mod x number of visible portals, which could get messy quick....

_________________
Bring me the blue pages!

Dynamic Link Renderers


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Sat Jun 04, 2016 8:01 pm 
Offline
Wiki Admin
User avatar

Joined: Tue Sep 18, 2012 5:27 pm
Posts: 3817
The shader likely involves the stencil buffer. Which I don't think Minecraft can take advantage of.
Or at least, I have yet to see anyone use it.

_________________
[WARNING: This user is sometimes blunt and confrontational. Please don't take it personally.]
[Current Mood: Agravated, Git:¹ Very high probability of being unintentionally hostile. I'm a nice guy, honest.]

¹http://xkcd.com/1597/


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Sat Jun 04, 2016 9:00 pm 
Offline
Addon Developer
User avatar

Joined: Sun May 11, 2014 4:30 am
Posts: 149
I'm actually unsure. Unity has some specific code that I can't seem to find in other languages, specifically ColorMask 0, which tells it not to render anything. Unity's specific stencil mask had a load of problems, specifically should-be-occluded geometry behind the portal but within the same room would occasionally flash and show through. So I had to leave that method behind, which ended up being easier in the long run, because a stencil shader would have had to have every object have a customized renderer. Not needed in this case.

Code:
Shader "Custom/PortalShader" {
   SubShader{
      Tags{ "RenderType" = "PortalMask"  "Queue" = "Geometry-50" }
      //Lighting Off
      Blend One Zero
      pass {
         ZWrite On
         ZTest LEqual

         ColorMask 0
      }
   }
}


In minecrafts case, the most likely solution would be to have a render texture that matches the same size as the player's screen, then just write to it where portals are with the correct shape. All portals would then reference the same rendertexture instance, and would be UV mapped to match aspect. The issue then, is if you have overlapping portals and odd angles. So maybe more than one, if an area had already been written to that frame.

_________________
Bring me the blue pages!

Dynamic Link Renderers


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Sun Jun 05, 2016 9:11 pm 
Offline
Mystcraft Developer
User avatar

Joined: Sat Aug 25, 2012 9:33 pm
Posts: 3951
Draco18s wrote:
The shader likely involves the stencil buffer. Which I don't think Minecraft can take advantage of.
Or at least, I have yet to see anyone use it.

If you've seen my Slidercraft video, you've seen me use it.

Though I like the "render to a screen texture" approach and overlaying that.

Either way, the trick is to render from the player's current relative perspective relative to the target location, yes. I have that working fine. :D
The stencil buffer solution is iffy in Minecraft, simply because it's not originally present in the rendering pipeline. Adding it can throw some interesting curve balls, especially when more than mod tries to (there are a few other mods which do).
So I'd prefer rendering the portal perspective to a texture (of about the screen resolution) and then splicing that in place. That would be a good improvement over the stencil buffer solution I have.

In general, there is only one real issue in the rest of the solution, and that's caused by the slice plane required to not render the intervening space between the player and the portal "other side." It results in blocks and entities being sliced in half. The easiest fix is probably to not render anything (dead portal) if blocks cover any of the other side. Entity slicing is less of an issue.

I think the Slidercraft mod code is up on Bitbucket under a private repo. If you have an account there, shadow, I can give you access and you can take a look. :D I also recommend looking at the Slidercraft videos.

_________________
I am the Mystcraft Dev.


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Mon Jun 06, 2016 12:58 am 
Offline
Wiki Admin
User avatar

Joined: Tue Sep 18, 2012 5:27 pm
Posts: 3817
xcompwiz wrote:
Draco18s wrote:
The shader likely involves the stencil buffer. Which I don't think Minecraft can take advantage of.
Or at least, I have yet to see anyone use it.

If you've seen my Slidercraft video, you've seen me use it.


Well then. I haven't seen said video. :P

_________________
[WARNING: This user is sometimes blunt and confrontational. Please don't take it personally.]
[Current Mood: Agravated, Git:¹ Very high probability of being unintentionally hostile. I'm a nice guy, honest.]

¹http://xkcd.com/1597/


Top
 Profile  
 
 Post subject: Re: Hey!
PostPosted: Mon Jun 06, 2016 3:16 am 
Offline
Addon Developer
User avatar

Joined: Sun May 11, 2014 4:30 am
Posts: 149
xcompwiz wrote:
Draco18s wrote:
The shader likely involves the stencil buffer. Which I don't think Minecraft can take advantage of.
Or at least, I have yet to see anyone use it.

If you've seen my Slidercraft video, you've seen me use it.

Though I like the "render to a screen texture" approach and overlaying that.

Either way, the trick is to render from the player's current relative perspective relative to the target location, yes. I have that working fine. :D
The stencil buffer solution is iffy in Minecraft, simply because it's not originally present in the rendering pipeline. Adding it can throw some interesting curve balls, especially when more than mod tries to (there are a few other mods which do).
So I'd prefer rendering the portal perspective to a texture (of about the screen resolution) and then splicing that in place. That would be a good improvement over the stencil buffer solution I have.

In general, there is only one real issue in the rest of the solution, and that's caused by the slice plane required to not render the intervening space between the player and the portal "other side." It results in blocks and entities being sliced in half. The easiest fix is probably to not render anything (dead portal) if blocks cover any of the other side. Entity slicing is less of an issue.

I think the Slidercraft mod code is up on Bitbucket under a private repo. If you have an account there, shadow, I can give you access and you can take a look. :D I also recommend looking at the Slidercraft videos.


If we want to support portals which you can walk through, entities will have to be drawn twice - one on either side. This would be an interesting challenge, as animations and position all have to be synchronized. It might be possible to just alternate the position of the entity during rendering....

For block clipping, as this is an API, we should offer different versions of a portal placement. One that returns if placement fails or not, and one that is capable of actually clearing blocks.

I just set up a bitbucket account! You can find me here: https://bitbucket.org/shadowking97/

_________________
Bring me the blue pages!

Dynamic Link Renderers


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group  
Design By Poker Bandits