I know that you have stated that optifine is not supported but the latest version released on the 17th October (OptiFine_1.10.2_HD_U_D1) works pretty well. Many of our players need to use optifine to run the All the Mods modpack as it has 150+ mods and whilst AE is not included in the pack yet, it will be once we feel that it is ready (and we get your permission of course) then we can remove Refined Storage and Correlated Potentialistics.

Anyway as it stands there are only some rendering issues with certain parts of the textures. Images below, feel free to close this, it was more of a FYI, and a heads up about Optifine if you weren't already aware.

Oz

Edit: RFtools also has an issue

did you report this also to optifine in any way ?

We usually do not support Optifine.

But just looking at the missing parts, it is clearly missing our custom uv lightmap rendering, because that is not supported by vanilla itself. Not sure, if we can really fix it. At least not without some insight about what optifine changes within the vanilla rendering.

Also regarding the permission. There is non for AE. If in doubt, just look at our FAQ. To be honest I personally would never ever consider adding any mod to modpack, if requires some permission. Because essentially the author states that they do not wish anyone to play with there mod. So why even bother making it.

Thanks yueh,

ill submit this to optifine and see what they say. Interestingly, the RFTools teleporters also do not render the blue and yellow circles with optifine either.

Not sure if that is related. But with the animation it looks like RFTools uses a similar system like we. Just that theirs merges a normal texture and a animated one, while we merge a normal texture with a custom lightmap one. So only the panels glow and not the full block including the border.

So I changed the way we create the fullbright quads, and made the switch to one of the default vertex formats. But I'd be somewhat careful with the effect. I tested it quickly with Optifine, and at the very least the faces now show up, although the fullbright effect at night is gone.
This change needs some testing, but at a quick glance still seemed to work for me without Optifine.

@ozhound Hm, it didn't quite look that irritating when I tested it, actually. so I wonder what settings are different for you. The controller did animate for me as well, it just didnt glow at night.

those screens are definately 1 preview version of optifine behind
the custom uv maps have been fixed but what is this thing with the warped textures that look like cables?!

I forgot a second spot where we do the UV Maps using a custom vertex format... testing a fix right now

@ozhound Can you try the latest nightly (4b607d8) and see if it fixes the corrupted vertices for you? I tried it locally and it looks better. Still, no "glow at night" for Optifine users, but at least the rest should look functional.

And just a bit of ranting: It's very annoying that Optifine doesn't work in my dev environment, and that Optifine doesn't provide Dev builds. Actually testing this shit is horrible without having the ability to debg into it :(

you can deobfuscate it to get it running in dev env
https://github.com/octarine-noise/simpledeobf

Still having to build that stuff by yourself is annoying. Also Optifines disables a good portion of the Forge rendering pipeline, especially the part we depend on.

Ah, Github ate my reply heh.
Yeah, consider that Optifine is one of the mods most prone to Mod incompatibilities. So providing an easy way for devs to actually test against it would be beneficial to Optifine the most.
And regarding that "tutorial": I still have to include a custom ASM Tweaker in my code to make it work, and the command-line it presents doesn't work with the latest release of that deobf tool. So... no dice.

oh how unfortunate, this project was linked by the @sp614x to include his code into dev env

maybe @sp614x can shade a bit more light on this :)

@shartte I have just got around to testing this with 5b4c3c and the terminals and me controller are working now but there are still weird issues. I havent heard at all from the Optifine Dev so either he is ignoring it or just hasnt looked into it yet.

PS this wouldn't be a massive issue if WAILA reported the channels used on the Smart / Dense cables.

Did the Network tool ever report channels in use on a cable? maybe that could be a good thing in place of WAILA.

@sp614x Thanks for the clarification. Minecraft modding is still a mess :|

It's unfortunate that Optifine is closed source and Forge hasn't adopted a more active approach to improving the broken mess that is Minecraft rendering. I personally have played a lot with Optifine in the past, and greatly enjoyed it, but the mod incompatibilities often stand in the way.
I tried the solution mentioned above for generating the mappings, but the latest release on that repo doesnt support the command line options in the example.

Related to this issue in particular: we are abusing VertexFormat.BLOCK to pre-set the UV[1] coordinates for the lightmap. I am not sure myself why this works, but this way we were able to explicitly set the brightness of quads to arbitrary values to achieve a "fullbright" effect at night. The fullbright effect is missing from Optifine, but at least it's no longer showing up as completely broken. Before, we were manually extending the ITEM vertex format with the VertexElement for TEX_2S.

OptiFine is not built on the Forge platform, it is only compatible with the obfuscated Forge classes.
It uses MCP class mappings which are most probably not identical to the Forge's mappings, so a DEV OptiFine build is not going to work in a DEV Forge environment.
The only solution so far is to deobfuscated the OptiFine classes with the Forge mappings which should produce a Forge compatible version (as shown above).

@shartte ill give this a test run as soon as the server is empty and I can update it. maybe a good 12 hrs from now though (as im going to bed), thanks for the epic work everyone.

This isn't related to this issue as it seems to be fixed now, but that black outline of carts in all your screen shots @ozhound what is that? I have it in a 1.10 pack I'm making and don't know what causing it.

Gentlemen, it all looks really good now.

I think we can close this off.

Thanks for your persistence.

Oz

@sp614x Is there a way to set the lightmap coordinates in a quad in such a way that Optifine would respect it during building a rendering-chunk? To fix the obvious corruptions I've removed those hacks, but having that functionality restored for Optifine users would be great.

The "fullbright" effect looks strange to me: http://i.imgur.com/fIo1acE.png
I would expect the block to illuminate at least 2-3 blocks around it. About half of the side pixels are lit, so it should emit light at about 50%. The correct lighting could look like this: http://i.imgur.com/Dmv8zIx.png

The lightmap coordinates are calculated based on the current lighting model (flat, smooth, ao level, etc) and the light levels of the surrounding blocks. The block model can not force the lightmap coordinates.
The classic way for "fullbright" models is to make the block emit light. Then it will have the correct lightmap coordinates AND the blocks around it will also be lit, which looks natural. Otherwise having one bright model in a pitch-black room can look very strange.

Is there a download link for AE2 1.10.2?

can look very strange

that is the desired effect, having only parts of the pixels glow not the whole texture
like having only those 2 pixels of the diskdrives glowing that indicate the status of the drives

https://camo.githubusercontent.com/318cbcc5dd7154935f4152ca9098964f5893056b/68747470733a2f2f646c2e64726f70626f7875736572636f6e74656e742e636f6d2f752f393131373239382f4145322f74756e6e656c6f66646f6f6d2e706e67

like a glowing texture that is bright enough to see clearly in the dark but dim enough to not illuminate surrounding blocks

The lightmap coordinates in the vertex data are 0,0 by default.
The BlockModelRenderer can be extended to check if the lightmap coords in the vertex data are non-zero and use them instead of the calculated ones.
This may or may not conflict with some other mods.

Download for nightlies (1.10) can be found here: https://github.com/AppliedEnergistics/Applied-Energistics-2#nightly-builds

Yeah, I am unsure about a good way to proceed for this. It's almost a miracle that our intial approach worked at all in Forge. I might go ahead and see if they are receptive to a patch that provides an actual extension point for this.

Do you think making that check conditional on VertexFormat=BLOCK would make sense? If I am not mistaken, MC bakes all models for VertexFormat=ITEM, then copies their vertexData, which happens to be the same size, and overwrites the space that was previously used by the 3 byte vertex normal with the lightmap coordinates. We are already "faking" it by baking our fullbright quads with vertex format BLOCK, which for some unknown reason, at least causes it to partially work in Forge.

I agree this could be true for the controller.
But in case of the disk drives and terminals, I think the desired effect is more like this: https://blogdotinsanegenius.files.wordpress.com/2014/10/night.jpg

^^^^
exactly what i meant :)

Created a test version which checks if the lightmap coordinates are set in the vertex data. Seems to work in vanilla, but not with Forge. Most probably Forge is using non-zero lightmap coordinates as default.

Yeah I will take another look at this. For Forge without Optifine, I will go back to our initial way of doing things (having normal + lightmap data).
@sp614x Does Optifine have any form of API where we could expose custom vertex formats and/or tell it to reuse the lightmap data for just those formats? I'll also try the previous approach with custom vertex formats with Optifine without shaders, but in that case the quads were just invisible previously.

Oh and thanks for clarifying why the lightmap actually works with Forge, it's just not really obvious from the code and I don't think it's documented anywhere. I'll really have to take a look at the vanilla pipeline at some point to get a better understanding of what has actually changed for Forge.

Forge explicitly supports passing lightmap data as a part of the model, it's not a miracle, it's the intended way.
With vanilla, all models are baked into the same format - BLOCK, which isn't good enough if you want to have correct lighting for things that are not axis-aligned; with forge, the format is abitrary, and stored in the BakedQuad, with ITEM being the default one used - since it has the normal data, and there's no need for the lightmap data until the actual lighting is applied. If mods need to pass that data, they can use a format with both a normal and a lightmap spot - which is what you did initially.
I suspect that Optifine relies on quads always being either in BLOCK or ITEM formats, or at least on having them the length 24, which is not true in forge anymore. Though it's easily checkable.

OptiFine currently disables the Forge lighting pipeline as it breaks way too many OptiFine features.
I tried to work around the lighting pipeline, but there are many problems. Some Forge changes are needed to make this possible: MinecraftForge/MinecraftForge#3091.

A fixed vertex format is only required when shaders are enabled. The shaders use extended vertex formats derived from the default ITEM and BLOCK formats. The default formats are updated and BakedQuad automatically translates the vertex data so that it matches the extended formats. This only works for ITEM and BLOCK formats. Any custom formats will not work with shaders.