I have a minecraft 1.9 modpack created with this mod . now I have opti fine installed unfortunately now the textures very buggy . there is a solution to this problem or do I have Optifine leave out ?

Minecraft 1.9
Forge : 12.16.0.1797
Chisel & Bits : 9.7
Optifine : 1.9_HD_U_A4_pre
-or- : 1.9_HD_U_A5_pre

Other mods :
Additional banner
BetterAchievments
Bioments O'Planty
duability Show
Ender Crops
Horse upgrade
JourneyMap
Just Enough Items
Leon's Simple teleporter
More Player Models
Morpheus
Progrssive Automation
VeinMiner

Seems like optifine is interfering with C&B's geometry rendering properly.

Optifine probably doesn't support the Forge 1.9 rendering pipeline properly yet, either that or its not respecting the vertex format that C&B is reporting, either way There is not much I can do if I want to keep the current feature set..

i think optifine should be prio 1
if your mod works with optifine you will get twice the downloads
just saying

@heanz The problem is that people shouldn't need to make their mods work with Optifine. It has a ton of rendering hacks that do things in a way modders don't and shouldn't expect (because it'd never happen if Optifine wasn't installed). It's fine that people want higher FPS on a low end machine, but they are using a mod that completely replaces the rendering system, so they shouldn't expect much help from me modders that use/alter the rendering system in a sane way.

I finally have had some time to look into this some, it is indeed what I thought it was, optifine is ignoring C&B's custom vertex format, there is no solution for this, at least on my end. But...

If you install optifine C&B will disable custom vertex formats, this means that at minimum C&B cannot generate glowing faces ( bits that glow in the dark without emitting light )

I honestly hate having to break my mod to accommodate optifine, but if people insist on using the two mods with one another its about all i can do.

At least the mod will be playable.

Maybe we should just stop crying about this and throw away OptiFine. You convinced me ^^

Hmm I'm still having the issue with the latest version in 1.9. Optifine seems to have a issue tracker now so I will mention it.

Forge adds a new model rendering (pipeline), Optifine is built on the vanilla model rendering.
Currently OptiFine disables the Forge rendering pipeline, because it breaks all model related OptiFine features (shaders, connected textures, AA, AF, better grass, better snow, custom colors, etc).
Further discussion: sp614x/optifine#60

@whitestarx0312 - Your seeing the same issue as the first issue on the top of this thread? Or something else?

I wasn't seeing any immediately broken blocks when I was testing things the other day. Are you sure your using C&B 9.11?

@sp614x Does this include the DrawBlockHighlightEvent? Seems that there might be an issue with that along with Custom VertexFormats.

@AlgorithmX2 Okay I am testing with just C&B 9.11 and Optifine and the issue seems to be fine. However, I am getting a render issue with the Chisel mod blocks. I apologize, I had assumed this was the same issue because I've been having render issues with C&B for a while.
The issue is actually only happening with C&B 9.11 when I try to chisel blocks from this chisel mod.

Screens:http://imgur.com/m2pdJtK
Chisel: http://tinyurl.com/osl4v6j
(Using Chisel Chisel-MC1.9-0.0.4.13)

I assume this is something on their end since Chisel is such an early alpha. Sorry again for the messed up report.

The problem with chisel is unrelated, Chisel-Team/Chisel#138

@AlgorithmX2 Custom vertex formats may be problematic with shaders as they use extended formats with additional fields (normal, midTexCoord, tangent, blockId).
Blocks and items should generally use DefaultVertexFormats.BLOCK and ITEM to avoid conflicts with shaders.
The DrawBlockHighlight event is fixed in preview B2.

Yeah, I can see that, I'm using ITEM as a basis, and adding DefaultVertexFormats.TEX_2S, of course this only matters if the forge pipeline is in place to handle DefaultVertexFormats.TEX_2S properly.

Plus if you adding those extra fields, I have nothing calculating them up front during the baking process, which just causes more confusion.

Not sure what options there are, if there are any.

Vanilla ITEM format:

    ITEM.addElement(POSITION_3F);
    ITEM.addElement(COLOR_4UB);
    ITEM.addElement(TEX_2F);
    ITEM.addElement(NORMAL_3B);
    ITEM.addElement(PADDING_1B);

Shaders ITEM format:

VertexFormatElement.EnumType.FLOAT, VertexFormatElement.EnumUsage.POSITION, 3
VertexFormatElement.EnumType.UBYTE, VertexFormatElement.EnumUsage.COLOR, 4
VertexFormatElement.EnumType.FLOAT, VertexFormatElement.EnumUsage.UV, 2
// inserted
VertexFormatElement.EnumType.SHORT, VertexFormatElement.EnumUsage.PADDING, 2
// moved
VertexFormatElement.EnumType.BYTE, VertexFormatElement.EnumUsage.NORMAL, 3
VertexFormatElement.EnumType.BYTE, VertexFormatElement.EnumUsage.PADDING, 1
// mc_midTexCoord
VertexFormatElement.EnumType.FLOAT, VertexFormatElement.EnumUsage.PADDING, 2
// at_tangent
VertexFormatElement.EnumType.SHORT, VertexFormatElement.EnumUsage.PADDING, 4
// mc_Entity
VertexFormatElement.EnumType.SHORT, VertexFormatElement.EnumUsage.PADDING, 4

The shaders code fills the missing fields before sending the data to the GPU.

I generate my format like this,

VertexFormat VERTEX_FORMAT = new VertexFormat();

....

for ( final VertexFormatElement element : DefaultVertexFormats.ITEM.getElements() )
{
    VERTEX_FORMAT.addElement( element );
}

VERTEX_FORMAT.addElement( DefaultVertexFormats.TEX_2S );