Using Chisels and Bits 11.1 for Minecraft 1.10 along with Forge 1986 and Optifine HD U B6 and Sildur's Vibrant Shaders I encounter an issue with bits: they will display fine if I chisel or build just a little bit, but if I modify a blockspace too much the whole block is rendered invisible with the shaders (turning them off and going back to normal vanilla lighting is fine, but the shaders render it invisible).
This might be a bug with OptiFine but I'm not sure, I'm not sure what's causing the issue (shaders or the Chisels and Bits mod).

Here's an example in GIF form: http://i.giphy.com/26BRGJvkgyNVpqBTW.gif

To my knowledge this was working fine pre-1.10 and I had to change 2 lines of code to get C&B to work on 1.10, also that optifine has no listed forge comparability, and came-out before 1.10 forge.

I'd give it a few days and a optifine release before looking into this any further.

Ok, thanks for the quick response! I'll wait until there's a post forge
OptiFine build and test then.
On Thu, Jun 23, 2016 at 8:32 PM AlgorithmX2 [email protected]
wrote:

To my knowledge this was working fine pre-1.10 and I had to change 2 lines
of code to get C&B to work on 1.10, also that optifine has no listed forge
comparability, and came-out before 1.10 forge.

I'd give it a few days and a optifine release before looking into this any
further.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#60 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AE2Mh_sG0zgvx1Btz9zJgoVYrSFFRchOks5qOyW3gaJpZM4I9WaX
.

OptiFine C1 for 1.10 should be compatible with Forge #2000

Not sure where to go from here, Everything that was in-place to enable compatibility seems to still be in place. Unfortunately there are no visible clues as to what might be going on, no rendering artifacts or other details, the block simply appears to be invisible.

I'm using BlockRendererDispatcher.getBlockModelRenderer().renderModel(....) to render my model to the Tessellator
then rendering the that into a display list, which is then called within the usual GL prep code to make sure that the texture and other things are all correct.

GL Configure is here
https://github.com/AlgorithmX2/Chisels-and-Bits/blob/5d94ca1d6a57e948701f88a72dbefb335a6092f9/src/main/java/mod/chiselsandbits/render/chiseledblock/tesr/ChisledBlockRenderChunkTESR.java#L525-L555

The rendering to tesselator logic is over here,
https://github.com/AlgorithmX2/Chisels-and-Bits/blob/adb0d2fb539c21f7799115b36c8f6f8a6e9f8ac5/src/main/java/mod/chiselsandbits/render/chiseledblock/tesr/ChisledBlockBackgroundRender.java#L137

Which is run from worker threads to build things in the background, and then returned to the main thread for upload to displaylist and final rendering.

Hopefully @sp614x can figure something out.. I'm stumped.

Tested with C1, still does the same thing ;(

Confirmed, the TESR based renderer is not resulting in any visible display.

The question is why....

for a work around see #7

Is the TESR renderer using a custom vertex format?

Nope, worldrenderer.begin( GL11.GL_QUADS, DefaultVertexFormats.BLOCK );

I've also confirmed that code is being called properly so its not a matter of some confusion about FastTESR/TESR

I've also confirmed that my code that disables my Custom Vertex format is currently working, So all my models are generating with DefaultVertexFormats.ITEM, that should probably have been pretty obvious however since the static render was working fine.

Uploading of the displaylist is done here,
https://github.com/AlgorithmX2/Chisels-and-Bits/blob/1.10/src/main/java/mod/chiselsandbits/render/chiseledblock/tesr/ChisledBlockRenderChunkTESR.java#L237

which is called via RenderWorldLastEvent

and the rendering itself is done from within the TESR which is called by renderTileEntityFast to remove overhead from caused by the normal TESR Method.
https://github.com/AlgorithmX2/Chisels-and-Bits/blob/1.10/src/main/java/mod/chiselsandbits/render/chiseledblock/tesr/ChisledBlockRenderChunkTESR.java#L497

How are you creating and rendering the display list?
The rest seems OK.

This looks ok.
Is it working differently with VBOs on/off?

No, i'm currently using display lists regardless of that setting. I also tried changing the "Use VBOs" setting to off in game to check, didn't change anything.

It should be tested with "VBO = OFF" to eliminate the possibility that shaders activate VBOs incorrectly

I already have tested with "Use VBOs" set to off as I mentioned above, unless changing them in-game wouldn't be an accurate test, it didn't need to reload the resources or anything it did seem to re-build the terrain however.

The chiseled block shadow is rendered correctly, so the geometry is there.
With internal shaders the block is visible, so the shader mode is working correctly.
It may be a problem with the current shader program or switching opaque/transparent mode.

It is being rendered in the wrong place (too late).
The RenderWorldLastEvent is fired at the very end when all layers, breaking block, etc, are rendered. Because of this it is using the wrong shader program and the render order is not correct.
When I move RenderWorldLastEvent to be fired between CUTOUT and WATER layers the TESR model appears, but the shadow is not shown anymore.

I don't understand how the TESR shadow appears, the shadow pass rendering is not calling RenderWorldLastEvent at all, so the shadow should be missing. But the shadow is there if the RenderWorldLastEvent is at the end and the TESR is missing.
When I move the RenderWorldLastEvent between CUTOUT and TRANSLUCENT the TESR appears, but the shadow is missing.
Are you also rendering tile entities?

Optimally the TESR model should be rendered together with the terrain in the correct layer (changing model requires chunk rebuild) or as a TileEntity (no chunk rebuild). Then the shaders should work properly.

The Tile Entities are actually rendered inline with the other Fast TESRs but the upload of the geometry into displaylists is occurring in the event, so I guess some GL State is being saved with that which is causing an issue? I could try moving the upload to the render path and see if that resolves the issue.

Ok, mission accomplished that fixes it.. I think it might have also improved the transition as well. I'm not seeing any immediate downsides to the change.

@Amaxter Please confirm that your no longer seeing an issue when using this build,
https://dl.dropboxusercontent.com/u/9117298/cb/anti-builds/chiselsandbits-11.4-pre6of.jar

Hopefully that should do it and we can close the issues, Thanks for your help @sp614x

Pleased to report that with my testing now with that build it works fine with shaders! Thank you so much sp614x and Algorithm!

Fantastic, I'll try to get an official build out with the fix in the next day or so.

Thanks again @sp614x

Ok, so unfortunately this change didn't really fix the issue; what it did was break the dynamic renderer and force everything to use the static renderer across the board.

So for the forcible future I suppose I'll just disable the dynamic renderer while optifine is installed, since even moving where the displaylists are uploaded doesn't seem to resolve the issue.

Does that mean shadows and stuff won't work?
On Sat, Jul 23, 2016 at 7:47 PM AlgorithmX2 [email protected]
wrote:

Ok, so unfortunately this change didn't really fix the issue; what it did
was break the dynamic renderer and force everything to use the static
renderer across the board.

So for the forcible future I suppose I'll just disable the dynamic
renderer while optifine is installed, since even moving where the
displaylists are uploaded doesn't seem to resolve the issue.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#60 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE2Mh8VD5DXereOL_Y7oHnCjFni5D_iuks5qYqgYgaJpZM4I9WaX
.

No, it means that c&b's asynchronous renderer will be disabled, which might cause block update lag.