tterrag1098
commented
6 years ago As far as I know, this is simply the cost of having higher-poly models (which CTM models are). CTM works by splitting each block face into 4 quadrants and assigning each quadrant a piece of the bigger texture. This means, unfortunately, that all blocks with CTM have 4x as many faces as normal blocks (if all sides are visible, 24 instead of 6). I have profiled the speed of our code again and again, and come to the conclusion that it is simply the smooth lighting code that runs slower due to there being more quads in the pipeline. If you can give me a profiler that points to some excessive source of lag in CTM I would happily fix it, as I would like this issue to be gone as much as you. But as it stands, there's not much that can be done.
Silver-Wulf
I was experiencing a bit of a frame stutter when breaking/placing blocks while making a spawn so I decided to do some research. I was led to this post https://www.reddit.com/r/feedthebeast/comments/5wkwby/sf3_lag_spikes_when_breaking_and_placing_blocks/ which led me to test whether blocks with connected textures caused the chunk containing them to be slow to refresh. Sure enough the stuttering was easily recreated even on my GTX 1080 by placing a large amount of a Chisel block that has connected textures in a single chunk and spamming break/place on a block in the same chunk (doesnt need to be the chisel block). I then tried the same process in another chunk using some random block from XTones that did not use any connected textures (may as well be stone) and I did not encounter the issue. I am using the latest release version of Chisel for 1.12.2.
Carpet is from chisel, the other block is a random block from another mod with no connected textures. Stone is used for breaking/placing and is not required to be touching either tested block.