[1.10] Wires do not render under certain conditions

[mezz]

In the screenshots I take one step and the wire stops rendering. If I turn around so that the other connector is in view, the wire will start rendering again. My best guess is that having my back to the connector culls it and the wire stops rendering as well. I can't seem to make the wire disappear when both connectors are in view. This happens for all cables, just walk between two connectors with a wire overhead. For one of the directions you walk, the wire will stop rendering about halfway between the connectors.

[mindforger]

attach a log please

[mezz]

I was able to reproduce with just IE.

Forced Crashlog (same one as the other issue): https://gist.github.com/mezz/508381d8d1d101edc39dc5f6786d20d1

[BluSunrize]

@mindforger tip: Mezz is Forgecraft crew. When he reports an error, he's good with it. =P Also, yeah, known issue, seen it plenty on tlove's stream

[mindforger]

yeah i know but if he doesn't attach logs, why should other do it then ... all a thing of equal treatment and beeing an exampole IMHO .. sorry for the bold undertone :P

[ShadowDrakken]

Just a thought here, but is this even a fixable issue?

I think this comes from some of vanilla's optimizations that happened in 1.8 and again in 1.9 where it's culling render of blocks and entities that are outside the player's view. The same behavior has been showing up for EnderIO's travel anchors, and I suspect it's the render culling there too; I use Chunk Animator so when I'm inside and can't find the travel anchor I want, I step outside and watch the travel anchor as it renders and suddenly it works correctly.

Great for speed, not so great for rendering things that cross into the culled area...

[KnightMiner]

Its possible to fix, TE's can tell the game the area they render in. The issue is coming up with a practical fix that is dynamic enough to work in this case.

[BluSunrize]

Wire's are not rendered by TE ;) They are baked models, hence why culling might indeed be the reason for this issue.

[malte0811]

This happens with any model extending over the block, certainly in 1.8+, I don't know about 1.7. When you place a crusher on the edge of a chunk, stand on top of it in the chunk not containing the master and slowly move from looking down to looking horizontally into the chunk not containing the master block, the crusher will vanish at some point. This is far more obvious with wires since their model is a lot bigger than the block. I am pretty certain that this is happening because the chunk the rendering connector (wires are rendered by one of the connectors, not both) or the multiblock master is in stops rendering. And I don't think there is much that can be done about that. It would probably be possible to make each connector render the half of the wire it is connected to, but that wouldn't really fix the issue, just reduce it...

[ShadowDrakken]

Each connector rendering half of the wire sounds like a good compromise though. It should resolve the majority of cases since the wires do have a range limit baked in. And at least you'd be able to tell where the wire is going even when it visually cuts off halfway.

[malte0811]

@BluSunrize, what do you think about each connector rending half of a wire? Should I implement it on 1.8.9 (since there is probably going to be a new release due to my assembler derp)?

[BluSunrize]

Try if that actually works first, or it it just looks weird, with a half shown wire. I don't wanna PR something that looks half baked (excuse the pun)

[BluSunrize]

Woops, didn't mean to close this

[ShadowDrakken]

Here's an idea, though I'm not sure how feasible or what limitations exist in the renderer:

Each connector renders half the wire, but overlapping a short distance. The part that overlaps, but not the rest of the wire, uses alpha transparency so the wire appears to fade away when the other half is missing, but looks normal when both halves are visible.

You could even have the transparent portion come to a point to help the effect and prevent z-fighting.

[mindforger]

this would also make an awesome optical effect when the last half rendered cable fades or "fogs out"

[malte0811]

Works quite well, just have to deal with some z-fighting now. @BluSunrize Once this is done, should I make an additional 1.10 PR or do you want to port that yourself? EDIT: And the z-fighting is fixed now as well

[mezz]

Interesting idea, but to be honest I think the fading looks very strange.

[KnightMiner]

Would it work if you just had both connectors render the full wire? If you overlap them perfectly, no one would notice there are two

[malte0811]

Having both connectors render the complete wire would be possible, but there are 2 problems:

1. If I render 2 quads in the same place, I'll get z-fighting. I can prevent this by shifting one quad a tiny bit, but it isn't really a clean sollution and it doesn't fix 2.
2. That would double the amount of quads per connection. One connection has (without my PR) 17_8=136 quads. With my PR it has 136+2_8=152 quads because of the transparent bits. But if I was to render the whole wire from each connector a connection would have 2*136=272 quads and while that isn't that much, it might still impact performance with a lot of wires badly enough for people to complain about.

[mindforger]

@malte0811 did you test your wires rendering with one connector in a dark spot and the second in a well lit spot? just to be sure it doesn't get ugly when you render from 2 very different light levels :)

[malte0811]

I didn't test that, if it does not work it may well be unfixable with the baked model system since I don't seem to have much control over lighting. I will try different light levels later today.

[mindforger]

yeah i thought i might share this thought as i was remembering an issue with lighting somewhere down the line and to avoid issues in the first place :)

[malte0811]

With PR: Without PR: Without PR and without blocks around the right connector: As you can see, there are lighting issues in both the old and the new system. I am currently trying to find out if there is any way to fix them, but as I said this may be unfixable.

[ShadowDrakken]

At least the wires look cool moving from dark to light areas, despite the rendering issues :)

One way I can think to possibly fix the lighting issue would be to render the wire in segments, one per world block it occupies... you could possibly use a tessellator for that... but I'm sure that kind of change to the wire render would be opening up a whole new can of worms

[mindforger]

"you could possibly use a tessellator for that" as far as i understand that would kill the intention of the model bakery and for the block wise approach, you would have to make the blocks "something else" than AIR, which would make them occupy actual space as far as i understand ...

PS the fading from one wire to the other doesn't look as half as bad as i had thought of :) :+1: for the solution

PPS when you can achieve an alpha blend, can you also achieve an gamma blend using the render information of the target connector?

[BluSunrize]

we are NOT moving back to tesselating this. It stays in baked models and vertexbuffers. this actually still looks nicer than the TESR bullshit I had at the start of 1.10. Without malte's transition to baked models, we'd be far worse off.

[BluSunrize]

@malte0811 is that black wire stuff happenign on latest 1.10? With teh wires moved to the ITEM vertex format?

[malte0811]

The screenshots are on latest 1.8 master and on the branch I PR'ed. I don't know about 1.10. (I assume that's what you wanted to know?).

[malte0811]

So, I just has a fun hour figuring out MC's lighting code and the lighting issues seem to be impossible to fix. The system simply assumes that any vertex is in the blocks directly around the block being rendered (From what I understand, since this is a lot of undocumented code full of magic numbers), which naturally does not work for wires. And from what I learned when implementing the fluorescent tubes, it is completely impossible to make quads ignore light (If that was possible it would have been possible to manually apply lighting to the quads).

[mindforger]

quads with custom lighting is probably possible, there was an interesting issue about porting AE2 over to 1.10 and make the controller animation glow in the night, honestly i have no f***\ idea if this gets anywhere near your issue but you made me remeber something about quads having different light level for the same block in this issue

found it https://github.com/AppliedEnergistics/Applied-Energistics-2/issues/2306 but they were talking about glowing effects, so maybe nope :(

[malte0811]

From what I can see in the code this is exactly what I am looking for. The only problem is this. Reflecting into classes used for reflection to be able to do more insane reflection seems pretty hacky and those lines seem to be the main trick. I will try to plug that code into wire rendering on a separate branch, Blu can decide whether he wants it when he comes back.

[mindforger]

i am glad it helped, you just triggered some memory cells in my brain by using quads and lighting in the last sentence --- "auch ein blindes huhn findet mal ein korn" --- is there even an english translation for that? :)

[malte0811]

Got manual lighting working! The way I am doing this is completely different from what the AE people did since their code does not work for dynamic models, but their solution definitely put me on the right track. My solution is based on using a custom BakedQuad class that has some special code to bypass the lighting transformers, but it isn't too bad, just some reflection to read a private value.

[Elix-x]

since their code does not work for dynamic models

Well, yeah. We made UVL loader to be able to configure it from JSONs. All the reflection hellness is there just for that. The lighting magic is vertex transformer that adds lightmap element to quads' format. That's it. :wink:

[KnightMiner]

If all you are doing is reading the data you could easily use an access transformer.

[malte0811]

@KnightMiner I tried that, but ATs don't seem to work on forge classes.

[Elix-x]

@KnightMiner then you don't know all operations involved. And yes, ATs don't work on forge classes.

@malte0811 while this is possible solution, the cause is probably different. And solution should be much simplier.

[malte0811]

Lighting works as well as it will probably ever work if the wire is in a single chunk or crosses a single chunk boundary. If it crosses more boundaries, lighting won't update unless the connector rendering the bit of wire that needs an update gets a chunk update. I also improved where the wires are split, making the whole thing a lot harder to notice. As before, basically perfect if the wire crosses a single chunk boundary, otherwise still pretty good. The commit is on a separate branch and pretty much ignores Blu's codestyle, if he approves I will make a second/third commit fixing code style and add it to the PR.

[mezz]

Any news on this? Has it been fixed already or is there still work being done on it?