Jump to content

Recommended Posts

Posted

Hi, i think adding the hook in my title would be helpful to modders trying to draw something to the screen when they cant use the tile entity special renderer.

 

Currently there are two relevant hooks which are useful when you want to render to the screen, onRenderTick.pre and onRenderTick.post, and while they're useful, sometimes they're not enough.

 

For example if i render something to the screen during onRenderTick.pre, it will not show up on the screen, since the screen is cleared after the hook.

And if i render something in onRenderTick.post, it will render over the GUI (when they render the gui they don't use depth so you cant draw "behind" it).

 

Rendering using the tile entity special renderer is obviously the best solution to this since yoy can render pretty much whatever you want in there? but i can't use it in my case.

 

I'm making a "portal" mod, similar to iChun's "doors", which means i have to render the whole screen again. I do this by calling "renderWorld" and using the stencil buffer to mask out what i don't need. But i can't call renderWorld from inside the tile entity special renderer, it raises an exception about the vertexbuffer already drawing.

So i have to render from outside of tile entity special renderer and currently i am doing it from onRenderTick.post which causes me to draw over the GUI.

If there was a hook in place after the screen was cleared and the camera position was set, i would be able to draw what i want without drawing over the GUI.

 

I would be happy to hear any suggestions/opinions if you have them, especially about getting the rendering from inside the tile entity special render to work, because then i won't need the hook.

 

Writng from my phone so sorry about typos.

 

Posted (edited)

Thanks! I think that would solve my drawing over the GUI problem.

 

Edit: i still think having a hook after camera setup and before world render would be useful in general for working with the stencil buffer since it's is easier to do and less taxing on the gpu when you don't have to depth check against existing terrain.

Edited by LRocket
Posted

I think adding this event deserves further consideration.

 

Like i've said before, i've implemented drawing my portals before the GUI render happens but now i face another issue, which i think also needs this event.

 

everything that's rendered through my portal has to "fight" with what already been rendered by the game beforehand.

here is a screenshot of how it looks:

U9MXQpP.png

 

 

see how the diamond blocks on the ground are Z-fighting with the grass.

The diamond blocks are actually behind the portal, the village that you see  through the portal should have overwritten them entirely.

 

Why this didn't happen before, when i was rendering after the GUI is drawn, is because after the GUI was drawn, minecraft clears the whole depth buffer, so there were no depth values to anything when rendering the portal.

 

in my case, i can't clear the whole depth buffer before drawing the portal because if there are several portals on screen, and i clear the depth after drawing each one, the portals being drawn second and after, will override the world, they would always be drawn on top even if there are blocks in front of them that should have been hiding them from view, they will just render over it.

 

The problem is that i haven't found a way (not sure if there even is one) to clear the depth buffer of just a single part of the screen (the portal).

 

but if i could draw the portals before the world gets drawn, i wouldn't have to worry about this.

i would just draw my portals on a clear screen, assign a correct depth value from them, and then just let minecraft render normally and because of the depth values i put, everything should render correctly.

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.