Cadiboo

Yes it can be done, It's a bit complicated though. I believe it will involve custom TextureStitching, custom ModelLoading (maybe custom Model Parsing? I've never heard of FBX models before) and likely custom Model Rendering (likely directly interacting with the BufferBuilder). If you're using these models just because they're easy to create take a look at http://blockbench.net.

You sure? your gradle output has a space here \/ ColonyMaintenance TunnelWorldGenerator.java:23: error: class & no space here \/ ColonyMaintenanceTunnelWorldGenerator If thats just a logging error try making a new file with a different name, see if that fixes it (WorldGeneratorColonyMaintenanceTunnel? ColonyUtilityTunnelWorldGenerator? ColonyMaintenanceTunnelWorldGen?)

SORRY FOR NECROING AN OLD THREAD! If anyone wants examples of how to use DefaultVertexFormats.BLOCK look at net.minecraft.client.renderer.BlockFluidRenderer or If anyone wants examples of how to use DefaultVertexFormats.POSITION_TEX look at net.minecraft.client.renderer.ItemRenderer or RenderTileEntityAlchemicArray.java If anyone wants examples of how to use DefaultVertexFormats.POSITION_TEX_COLOR look at net.minecraft.client.renderer.RenderGlobal or ClientUtil.java Examples for everything except block are pretty easy to find with your IDE's search

If you want to brute force it, you can! Your a programmer, automate it! You might want to take a look at my implementation here (I call the function in my main mod class) you should only use this if your recipes aren’t exponentially large, otherwise you should use oreDictionary/ the Tag system/ a custom IRecipe. Your case seems to be at the edge of what should be done so you can choose whatever you think best suits your code & intentions

Do you have a hidden character somewhere in either of those names? They appear to be identical but as both gradle & eclipse are complaining I suggest you look into it.

Yeah, after reading the end credits about ascending to another level of reality or whatever you “die”. Is the rest of your gameplay after this the “afterlife”? Did Mojang intend to add something else after you leave the end but didn’t get around to it? It would be interesting to know why you die and don’t just change dimension. For all that fanciful-ness I think it’s probably just to make you spawn back at your spawn point, rather than near the end portal.

Can you tell us what your trying to achieve? We will probably be able to help, but you redacted your original question so no one who happens to read this (and might know an answer) will be able to help

Pretty much nothing honestly, I’ve been reading over it a lot recently and, correct me if I’m wrong, it basically just determines if the block is a block or a fluid. if it’s a block it then passes it to BlockModelRenderer (which passes it to Forge’s optimised renderer - look at ForgeBlockModelRenderer). if it’s a fluid then it passes it to BlockFluidRenderer. (The code in here is still technica but not as absolutely impenetrable as Forges block renderer is (to me at least)) this answer is based heavily on my own “research” and experience. Please feel free to ask about specific parts of the code

By increased I assume you mean that how often the entity updates is increased but the actual updateFrequency variable is decreased? Or have I been writing my code wrong this entire time? I assume that the update handler is something like if (time % frequency == 0) update();

Look at how vanilla does it in the debug screen. I assume they do something like blockstate = Minecraft#selectedThing (can’t remember its name, it’s a ray trace result) for (PropertyKey : blockstate.getPropertyKeys()) { String = PropertyKey.toString() + “=“ + blockstate.getPropertyValue(PropertyKey).toString(); }

What do you mean? It’s certainly easier & allows vanilla to better handle your item, and allows you to override vanilla’s items but no it’s not exactly necessary - you are able to replicate the vanilla behaviour without replicating it, but for example the tooltips that vanilla puts on swords won’t appear and you’ll have to implement them yourself. For code maintainability you should probably extend vanilla because a) if vanilla changes something you will know about and can change it b) knowing something _is_ (extends) something else is better than knowing something _should be_ (replicates the functionality of) something else

Sorry yeah, I should have been more specific the size of the selected box that is rendered can be as large as you want, the bounding box that is used determine when that box is rendered is limited to 1x1.5x1 (I assume that box is the collisionBoundingBox or the normal boundingBox). The solution is to use blocks around it that return the same renderBoundingBox as your block (this may require a TileEntity but only if you use the same type of surrounding blocks for multiple different types of structures)

The selection box can be as big as you want. JSON models (I don’t know about other models) have a 3x3x3 size limit (at least according to BlockBench - I haven’t tried manually making larger models), so if your block/structure is smaller than 3x3x3 you don’t need a TESR, and can just put a scaling factor into your model’s GUI Transform.

It’s a vanilla thing, the player technically dies - you want PlayerRespawnEvent & check that the Boolean hasConqueredEnd is true

If you want to render fluids use Minecraft.getMinecraft().getBlockRendererDispatcher()#fluidRenderer (Its private you'll have to use reflection)

Do you know anywhere that has concepts or code that I need to draw with DefaultVertexFormats.BLOCK with the BufferBuilder? Because I simply cannot find anywhere in vanilla code (Stepped through it with the debugger - everything seems to get handed to Forge's pipeline which appears to somehow not use the BufferBuilder). Edit - Forge's pipeline appears to add the vertexes to BufferBuilder directly with addVertexData and putPosition, rather than with BufferBuilder#pos()#color()#tex()#endVertex(); which is how I'd like (and only know how to) do it.

Start modding on 1.12.2 to learn how to do it, then update to 1.13 when it comes out

They didn't. You said "Start a new project". Someone made their own game with their own renderer.

Its not exactly - If you watch the video its a clip of development of a game that uses Marching Cubes to make their voxel terrain render smoothly - Exactly the same thing as I'm doing to MC

I found this youtube clip https://www.youtube.com/watch?v=Yek5Fu1cX7I I'm trying to do this, but it probably won't get accepted (The way about going about the actual rendering inside the event is very technical & not straight forward) hence my questions about ASM. Also am I allowed change protected Vanilla Minecraft methods to public in a PR?

I can see a use-case where someone wants to modify how terrain is rendered but not with the same rendering algorithm that I use. This is basically just a cancelable & block-exclusive version of RenderWorldLastEvent

Do you think anyone else will ever want to change how a chunk renders?

I've had to copy & paste pretty much the entirety of Minecraft's rendering code (10 11 12 classes so far) just to add 2 hooks (Events) in RenderGlobal & BlockRenderDispatcher which is exactly 5 lines of modified code, should I learn ASM or make a PR to forge?

Yeah, right now its client side only - I want to recreate the original NoCubes before I add any features. Obviously I'll change this once I start adding stuff. Thanks for pointing it out though!

I was massively overthinking this aha, thanks so much @jabelar for your comment on some old thread that I was reading for no reason about how Minecraft.renderGlobal is public. What I've done is massively overkill but I've just made a new RenderGlobal called ModRenderGlobal that is an exact copy of RenderGlobal (with all the methods and variables changed to public). I also had to make a copy of ViewFrustum because of it having a package method required by my RenderGlobal. Here is my final code @EventHandler public void init(final FMLInitializationEvent event) { try { Minecraft.getMinecraft().renderGlobal = new ModRenderGlobal(Minecraft.getMinecraft()); LOGGER.info("Successfully replaced Minecraft's RenderGlobal"); } catch (final Throwable throwable) { LOGGER.error("Failed to replace Minecraft's RenderGlobal"); // This should only happen rarely (never honestly) - so printing the Stack Trace shoudn't spam any logs throwable.printStackTrace(); // TODO: throw the throwable? Maybe, keep it commented out for now // throw throwable; } } Which can be reduced to @EventHandler public void init(final FMLInitializationEvent event) { Minecraft.getMinecraft().renderGlobal = new ModRenderGlobal(Minecraft.getMinecraft()); } And here is the final result - I'll probably post my results of the actual rendering here if I get it to work Thanks everyone for their help!