grondag / acuity Goto Github PK

See grondag/Pyroclasm#4

In Continuum test world, after fixing #6 still see some similar artifacts that appear to be due to render chunk not uploading to GPU after sort.

I'm porting my Acuity Rendering API to Fabric because it offers a flexible toolchain and I don't want to wait for the big rendering changes in 1.14. The revised APIs for runtime, pipeline management and block rendering are now draft complete, and I'd welcome feedback from the Fabric dev community while I work on the implementation.

Technical Summary Here

API spec here.

You will be able to handle most rendering scenarios that would normally require a BlockEntityRenderer by implementing BlockEntityVertexProvider on your block model. Custom shaders are entirely optional and would be unnecessary to implement mods similar to CTM or Chisels and Bits.

Note that Acuity is not a modeling library. It assumes you already have vertex data with fully baked texture coordinates. Exotic Matter has advanced modelling features but is not yet ported to Fabric and is not meant to be a public API.

The implementation will include a handler for the Fabric Dynamic model API when it is complete, but that API will not provide access to all the features exposed by Acuity. Other mod authors are welcome and encouraged to build model APIs or libraries on top of Acuity.

Note the implementation is still a horrible broken mess. Vertex formats and thus shaders are changing from 1.12 to provide richer options, and many other bits are being refactored or forced to change due to 1.14. A working build of block rendering will probably take a couple more weeks and I'll be tracking down lighting bugs for some time after that.

For an illustration of what will be possible with the API, look at my 1.12 volcano mod. I've also uploaded a few screenshots of multi-layer rendering from 1.12 builds below (using Exotic Matter for the models.). The blocks pictured are not yet released. (Need to port Acuity and Exotic Matter first...)

Spotted in Continuum world. Looks easy to reproduce

When player movement forces new render sections to be loaded on the horizon, it appears the render sections very briefly render the content from their prior location.

EntityRenderer.renderWorldPass() can be streamlined when Acuity is enabled by skipping the render layers for CUTOUT and CUTOUT nipped (and the associated texture state changes) because cutout is handled in the solid pass via the fragment shader.

Deferring until 1.13 because ASM is non-trivial (and ASM will be a redo in 1.13) and most of the time the overhead is < 0.5ms per frame. However with heavy transfer/command throughput (Pyroclasm) this can spike to several milliseconds in some frames. Avoiding these calls may help reduce frame rate variation.

RenderGlobal.setupTerrain() performance during continuous high-volume chunk updates was improved by pre-computing and caching internal visibility information in each render chunk but the list of render infos in the view frustum is still rebuilt almost every frame. (Called "iteration" in profile results.)

The Mojang implementation isn't particularly slow or bad, but could probably squeeze a millisecond or two per frame out of it with simpler data structures, better LOR and/or more JIT-friendly code. Will be helpful for Pyroclasm.