What's new in modded minecraft today?

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord

88VoidMiner88

New Member
Jul 29, 2019
67
0
0
TESRs are indeed not helpful for performance, but you are wrong in saying that it is within the power of the developer to control the resultant performance loss. Even an empty TESR has a significant overhead, and when rendering actual ModelRenderer objects (read: the boxes that comprise all entity and most TileEntity models) it is up to Minecraft to do the rendering, where, among other things, it makes the lovely decision to recalculate lighting on every single polygon.
What if you made alternate models for your blocks for those who complain
But....
The new models are just cubes with a name :p
 
  • Like
Reactions: Fixided

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
WayofTime @WayofTime · 22h
Next major update for Blood Magic is scheduled for a beta release on Monday

WayofTime @WayofTime · 9h


WayofTime @WayofTime · 9h
Here, have another!


[URL='https://twitter.com/WayofTime'] WayofTime @WayofTime · 5h
Pro tip: look in the top-right corner. pic.twitter.com/VzhZcjQiho

BvlREteCcAEWktt.png:large

BvlRErACIAA7ErT.png:large

[/URL]
 

NJM1564

New Member
Jul 29, 2019
2,348
-1
0
[And in simi-vinilla news.]
"Bucket is discontinued." Says it's primary developer team.
"They have forgot that Bucket is now owned by mojand." Says mojang. "And it will continue".

Edit: The fallowing is a link to an article with more details. And this whole post will be copied to the red thread for the lols comments to fallow.
http://www.pcgamer.com/2014/08/21/m...tries-to-end-development-but-mojang-steps-in/
 
Last edited:
  • Like
Reactions: Fixided

buggirlexpres

Relatable Gamer
Trusted User
Retired Staff
Nov 24, 2012
3,937
7,362
663
she/her
twitter.com
Last edited:

buggirlexpres

Relatable Gamer
Trusted User
Retired Staff
Nov 24, 2012
3,937
7,362
663
she/her
twitter.com
I was speaking in a manner popularized in world war era news reals. That's how I thought it. That's how I wrote it.
And lo and behold I attracted a grammar nazi.
How apropos.
Lol sorry about the grammar comment. I was irritated at other things at the time. :p
So, ignore the grammar part of that.
 

Paul17041993

Active Member
Mar 17, 2013
90
17
33
Australia
www.vectrobe.net
I can't really agree with this. The reason it's slow is because these are actively rendering components, being implemented in a game which was designed primarily for static blocks. You'll note that the class which allows for this has a particular name: TileEntitySpecialRenderer. Special being the key word. This is for special circumstances, where a block, for some reason, has a real-time 3d animation. A good use of this is a chest lid opening, or a piston extending/retracting. Vanilla Minecraft has very few instances of using a TESR, which is the point.

A TESR is not influenced by chunk updates because it's actively rendering every tick regardless of whether the chunk is updating. And let's face it, the OpenGL version has very little impact here compared to the CPU strain caused by all of this extra overhead of trying to render these objects. Render lists are pretty fast, particularly for the very basic geometry and texturing involved in almost any mod addition.

For 3d blocks which remain static and have no model animation, but still have a custom renderer, this can hurt performance during chunk updates as you mentioned. But in this case the modder is almost entirely in control of how efficient their code is to render their particular block, rather than relying on Minecraft's native methods of pulling textures for each individual face and computing lighting values and all of that CPU-intensive stuff. That doesn't mean they're going to be any faster, though, depending on what they do.

The bottom line is that anything other than static blocks are going to hurt performance, and there's no practical way around that in a game of this type. Tile entities alone weren't even made to be used as much as they are. When you stack special renderers on top, you can't hope for it to end well when you get as many fancy 3d mods and multiparts and everything that some of these packs have today.

this is reasonably true, but its mainly the lack of shaders and at least some threading in the NBT updating that amplifies it, modern games use whats known as hardware-instancing, of which any 'special' objects can use a custom set of shaders and the data for each is stored in a buffer in VRAM, GPU renders whats needed at it's own pace and the detail of each object can be virtually anything within reason, to update the data for the objects just involves a buffer update which isn't expensive at all even in large amounts.

this is exactly how games like skyrim can render over 10,000 objects over a massive terrain with little CPU load (80% of the CPU load is just updating and firing events for everything in the world), that being said I will admit it's not easy for a novice to implement such a pipeline, but it's not exactly hard either.

the really simple solution though is just to add mesh rendering, you still have to do a lot of CPU work but it'll still be a multitude faster as tiles won't need to do vertex manipulation each time (1 VBO draw call vs a vertex array copy-through each frame).
 
  • Like
Reactions: Fixided

FyberOptic

New Member
Jul 29, 2019
524
0
0
this is reasonably true, but its mainly the lack of shaders and at least some threading in the NBT updating that amplifies it, modern games use whats known as hardware-instancing, of which any 'special' objects can use a custom set of shaders and the data for each is stored in a buffer in VRAM, GPU renders whats needed at it's own pace and the detail of each object can be virtually anything within reason, to update the data for the objects just involves a buffer update which isn't expensive at all even in large amounts.

this is exactly how games like skyrim can render over 10,000 objects over a massive terrain with little CPU load (80% of the CPU load is just updating and firing events for everything in the world), that being said I will admit it's not easy for a novice to implement such a pipeline, but it's not exactly hard either.

the really simple solution though is just to add mesh rendering, you still have to do a lot of CPU work but it'll still be a multitude faster as tiles won't need to do vertex manipulation each time (1 VBO draw call vs a vertex array copy-through each frame).

You're absolutely right, all of those things would speed rendering up. But it just wouldn't work for this game. I spent a considerable amount of time writing a voxel engine of my own a while back, thinking I could do a better job adding various features after the fact compared to how Mojang added them as they went along. Turned out, about the only major improvements I added was RGB lighting (16 possible values per color channel), and I offloaded much of the block face lighting calculations into a shader. But other than that, I came to realize that Mojang had made a lot of pretty decent choices to the point that I was effectively cloning it. Though I won't pretend to be an expert either, so someone else would have probably been capable of better.

The thing is, the chunk segment (16 of which being stacked vertically in a chunk) has to be capable of being updated. You can certainly render this chunk segment to a VBO and dump that into the video card, but as soon as the chunk updates, you have to regenerate and upload it all over again. And generating a chunk is the most expensive part, not so much the rendering of it. You might think that you could only re-render the specific blocks that updated into the VBO to avoid doing the whole thing, but what if the block doesn't have the same number of vertices as it did last time? It's a very real possibility. Or maybe the block is completely gone now. This is the same reason why a mesh doesn't really work. There's already so much computation that goes into just rendering them as individual block faces. You'd need to start doing occlusion culling and/or other expensive operations per chunk segment face. Not to mention, due to the way you use UV coordinates to specify block face textures from a large atlas, a mesh just wouldn't work, unless you also generated a special texture to go with the mesh as well, which would be a bit crazy.

There may really be a way to make a much more efficient dynamic voxel engine, but so far we haven't really seen anyone implement one very well to prove it. It's pretty amazing how well this one even works.
 

DZCreeper

New Member
Jul 29, 2019
1,469
0
1
But other than that, I came to realize that Mojang had made a lot of pretty decent choices to the point that I was effectively cloning it. Though I won't pretend to be an expert either, so someone else would have probably been capable of better.

The problem is that they have proven historically they make bad choices regarding performance.

Case 1: OpenGL V1.2. Enough said.

Case 2: Multi-threading a bunch of stuff only in 1.8, increasing FPS by silly amounts for people with dual core or greater chips. Could have happened a lot earlier.

Case 3: Removing void fog only in 1.8. Apparently they ticked every air block to enable this function. I actually said "What the fuck?" out loud when I read this one on Reddit.

From 1.7.10 even running Fastcraft, 1.8 snapshots have doubled my FPS on my dual core Intel chip. On my quad core AMD chip its tripled.
 

DZCreeper

New Member
Jul 29, 2019
1,469
0
1

dmillerw

New Member
Jul 29, 2019
255
0
0
I find this one somewhat dubious. Previous to 1.7, air was not even a block, and the fog is an OpenGL render artifact with no in-world counterpart.
I believe it was the actual particles that required some amount of extra ticking

Code:
public void doVoidFogParticles(int p_73029_1_, int p_73029_2_, int p_73029_3_)
    {
        byte b0 = 16;
        Random random = new Random();

        for (int l = 0; l < 1000; ++l)
        {
            int i1 = p_73029_1_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            int j1 = p_73029_2_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            int k1 = p_73029_3_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            Block block = this.getBlock(i1, j1, k1);

            if (block.getMaterial() == Material.air)
            {
                if (this.rand.nextInt(8) > j1 && this.provider.getWorldHasVoidParticles())
                {
                    this.spawnParticle("depthsuspend", (double)((float)i1 + this.rand.nextFloat()), (double)((float)j1 + this.rand.nextFloat()), (double)((float)k1 + this.rand.nextFloat()), 0.0D, 0.0D, 0.0D);
                }
            }
            else
            {
                block.randomDisplayTick(this, i1, j1, k1, random);
            }
        }
    }
 
  • Like
Reactions: xbony2 and Fixided

FyberOptic

New Member
Jul 29, 2019
524
0
0
The problem is that they have proven historically they make bad choices regarding performance.

I still will honestly back what I said that OpenGL version hasn't mattered that much for this game, unless someone knows something I don't. Minecraft is still a CPU-bottlenecked game, and while it does render a lot of vertices, it's optimized with render lists, using textures that all come off of mostly a single atlas to avoid texture swaps. And they were able to use ARB for a lot of things that weren't native to that old version anyway, which is part of why OpenGL is nice.

Threading can help and I'm glad they're trying to break up some of the work, but anyone who's ever done work with threading knows what a nightmare it can be so I honestly don't blame them for putting it off this long. Sometimes it can even be just as bad or worse for performance if you end up with tasks still waiting for others to complete often. But yeah, overall, it's a good thing and I agree it's about time. I guess we'll have to see in real world scenarios if it's for the better.

With the void fog thing, you and me both possibly "what the fucked" at the same time. As Reika said, after air became an actual block is when I assumed this suddenly became a problem. But I'd have to dig through 1.6.4 to see more about how it used to work to know for sure, since it's not exactly something I ever had much reason to look at.

1.7.10 runs pretty decent for my older machine, though I haven't seen as dramatic of an improvement as others have said in the 1.8 snapshots. They said something about skipping rendering as often, which seemed to possibly be represented by how slow gravity for mobs ended up there at one point. I'm curious to know more when we can really dig into it.
 
  • Like
Reactions: Fixided

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
I believe it was the actual particles that required some amount of extra ticking

Code:
public void doVoidFogParticles(int p_73029_1_, int p_73029_2_, int p_73029_3_)
    {
        byte b0 = 16;
        Random random = new Random();

        for (int l = 0; l < 1000; ++l)
        {
            int i1 = p_73029_1_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            int j1 = p_73029_2_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            int k1 = p_73029_3_ + this.rand.nextInt(b0) - this.rand.nextInt(b0);
            Block block = this.getBlock(i1, j1, k1);

            if (block.getMaterial() == Material.air)
            {
                if (this.rand.nextInt(8) > j1 && this.provider.getWorldHasVoidParticles())
                {
                    this.spawnParticle("depthsuspend", (double)((float)i1 + this.rand.nextFloat()), (double)((float)j1 + this.rand.nextFloat()), (double)((float)k1 + this.rand.nextFloat()), 0.0D, 0.0D, 0.0D);
                }
            }
            else
            {
                block.randomDisplayTick(this, i1, j1, k1, random);
            }
        }
    }
Where is that code from?
 
  • Like
Reactions: Fixided

Vauthil

New Member
Jul 29, 2019
1,491
-14
1
While this is all terribly interesting and I enjoy reading it because it satisfies my inner wonk, could you guys maybe start a thread elsewhere and go through it all there? This isn't a discussion thread, it's a news and updates thread.
 

SatanicSanta

New Member
Jul 29, 2019
4,849
-3
0
You can now prove how much of a damn you do not give!

Santa's Toys 0.3 for Minecraft 1.7.10!
  • NEW: Logo image!
  • NEW: mcmod.info file!
  • NEW: Block of Damn Giving
  • TWEAK: The unlocalized names defined in the ItemInfo class weren't being used.
  • FIX: Removed unused language registry stuff from ItemHandler.
Here's the Block of Damn Giving:
http://puu.sh/b2J2N/f53bf4f50c.png
http://puu.sh/b2J2x/142ea8bfcf.png

Yes, it's ugly. I figured it would really go against the theme of the block to put much effort into it :p