translocator center render glitch (kinda fixed)

[treechain]

Hi, I am playing on the FTB Continuum modpack v.1.1.0 in full screen windowed and I found a graphical glitch with the center of the item translocator. When I place the translocator down the center is clear. Picking it up and placing it back down doesn't correct it and relogging to the server doesn't fix it. Every once in a while when I go out of viewing range and come back in the center of the buttons will be floating above by 4-5 blocks and offset by 8 blocks or so. My buddy and I both saw the center missing. We both restarted our packs and now I can see the centers but he can't. Just thought I would report this in hope that this can be replicated and isn't just a one off thing for the server I am playing on.

[covers1624]

Something in your world is breaking the renderer, if you can narrow down anything more that would be really helpful..

[treechain]

That went quicker than expected....the answer to this is the casting channel from tinkers when it has fluid in it. If the channel is empty the translocator is fine, but as soon as a fluid is rendered inside the channel the translocator render breaks. I tested both creosote oil and water. I also tested different ways of putting fluid into the channel. I also tested this in a new creative world. Is this something you want me to report to the tinkers dev? or is it something that you'll take care of?

[covers1624]

Interesting, ill take a look myself tomorrow, ill let you know if you should contact tinkers.

[Kuktar]

I am having this issue also. I don't have any casting channels near my translocators.

[Kuktar]

[covers1624]

You actually do over to the right, Proximity doesn't matter, only that the casting channel is in your field of view. Gonna ping @bonii-xx as this seems to be an issue with tinkers, i suspect the casting channels aren't resetting a translation on the FastTESR buffer, other than that there is nothing on translocator's end that could cause this, they are standard FastTESR's.

[Kuktar]

Oh ya I suppose I do have 1 like 10 blocks away. Thank you! Do you like steak?

On Thu, Jun 28, 2018, 23:47 covers1624 notifications@github.com wrote:

You actually do over to the right, Proximity doesn't matter, only that the casting channel is in your field of view. Gonna ping @bonii-xx https://github.com/bonii-xx as this seems to be an issue with tinkers, i suspect the casting channels aren't resetting a translation on the FastTESR buffer, other than that there is nothing on translocator's end that could cause this, they are standard FastTESR's.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TheCBProject/Translocators/issues/41#issuecomment-401263967, or mute the thread https://github.com/notifications/unsubscribe-auth/AXOX3h4ve1KMwUjWmsdya-xYGDw8NTYpks5uBc10gaJpZM4UhG3z .

[Kuktar]

Breaking the casting channel did resolve the issue. I love your mod. it deserves great tasting steak donations!

[bonii-xx]

cc @KnightMiner

[KnightMiner]

As I recall, the translation is reset in the core fast TESR logic, otherwise this would have caused issues with our own fast TESRs. I can specifically reset it to 0 but I'd be surprised if that is what broke it.

Can you point me to your fast TESR code? All I can find is the crafting grid render which uses a normal TESR.

[covers1624]

Its a little complicated as its half spread across FMP, and FMP allows parts to be both a standard TESR and a Fast TESR at the same time. But here is the actual code in Translocators that handles FastTESR, https://github.com/TheCBProject/Translocators/blob/master/src/main/java/codechicken/translocators/part/TranslocatorPart.java#L428 https://github.com/TheCBProject/Translocators/blob/master/src/main/java/codechicken/translocators/client/render/RenderTranslocator.java#L88

[KnightMiner]

So its not a standard FastTESR. Why on earth would you need a FastTESR and a regular at the same time? The only difference is a FastTESR saves creating additional tesselators, which if you are already creating them in a normal TESR is a moot point.

Anyways, if you are relying on the translation being at 0,0,0 when you start rendering, why can't you just run your equivalent of BufferBuilder::setTranslation(0,0,0) at the start of your FastTESR? Every FastTESR I have ever seen begins with a setTranslation call as all it does is set an absolute value. I can set it back to 0 at the end but that seems pretty useless as the next FastTESR will just move it again as soon as it starts.

Edit: I should also point out that the Forge animation TESR, which is cited as the fast TESR example, does not reset the translation, so you should be getting issues with more than just Tinkers as not resetting the translation is considered valid in Forge code.

[Kuktar]

I had never seen the word tesselation until this post.

I was moving my tinkers stuff to a different chunk and boom my client crashed. Is it weird the crash was do to tesselation?

https://pastebin.com/v1CNs6dm

That's the crashlog specific to the crash mentions tinkers.

On Fri, Jun 29, 2018, 07:22 KnightMiner notifications@github.com wrote:

So its not a standard FastTESR. Why on earth would you need a FastTESR and a regular at the same time? The only difference is a FastTESR saves creating additional tesselators, which if you are already creating them in a normal TESR is a moot point.

Anyways, if you are relying on the translation being at 0,0,0 when you start rendering, why can't you just run your equivalent of BufferBuilder::setTranslation(0,0,0) at the start of your FastTESR? Every FastTESR I have ever seen begins with a setTranslation call as all it does is set an absolute value. I can set it back to 0 at the end but that seems pretty useless as the next FastTESR will just move it again as soon as it starts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TheCBProject/Translocators/issues/41#issuecomment-401369408, or mute the thread https://github.com/notifications/unsubscribe-auth/AXOX3tQnNeARLRVRh2qvKB9oQeyG6gD1ks5uBjgcgaJpZM4UhG3z .

[KnightMiner]

That crash is unrelated to this issue. Not everything to do with the tessellator makes it the same issue.

[Kuktar]

Thanks. I was just wondering.

On Fri, Jun 29, 2018, 11:51 KnightMiner notifications@github.com wrote:

That crash is unrelated to this issue. Not everything to do with the tessellator makes it the same issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TheCBProject/Translocators/issues/41#issuecomment-401442574, or mute the thread https://github.com/notifications/unsubscribe-auth/AXOX3j6qzOcSTNhtxCWnYnn4PDp5b0uUks5uBncUgaJpZM4UhG3z .

[covers1624]

The reason I allow parts to be fast and standard at the same time is simple, that are multiparts, each one has different needs, a translocator for instance renders the base to the chunk buffer, the particle arc directly with gl, and the insert with a fast tesr, there is absolutely not a moot point when it comes to fmp, a saved draw call is a saved draw call and it all adds up. Anyway, I'll fix this my end when I get up.