[1.11.2] [Unsolved] FPS drop while placing custom rendered block.

[Kander16]

Hi,

 

Instead of explaining to you what the problem is, I'm going to show it in this little video and give more information afterwards:

https://www.youtube.com/watch?v=OA76IJWPYMM

So, I created a custom rendered block which is called a ripening rack. This block has a custom baked model, so I can place arbitrary sub-models on the ripening rack (E.g cheese).

The problem I have is that whenever I add another ripening rack inside the same chunk, the longer the game freezes than the previous ripening rack I placed.

E.g: When I place the 256th block it wil freeze for a while and then continues to run without any problems. But you don't notice anything if one or two ripening racks are being placed.

After I've placed 256 blocks of the ripening rack and the game-freeze is done, it acts normally. Nothing freezes anymore. I now it's a very complex model, it exists out of 528 quads. But I've put way to much effort in this model to give up now.

So, could someone help me with this please?

 

1. Why does this actually happen?

When I have many ripening racks inside a chunk, and place a ripening rack outside of that chunk (which doesn't contain any ripening racks), the game doesn't freeze.

2. What could I do to prevent this from happening?  

The rendering after the placement isn't a problem. Placing it is a problem.

 

Some code that you might want to take a look at (Okay, I could improve some things on that code. It would help, but it wouldn't solve it):

 

-  RipeningRackBakedModel: https://hastebin.com/zabaxivugo.java

 

EDIT: New RipeningRackBakedModel: https://pastebin.com/CkkCkLmE

 

- RipeningRackModel: https://hastebin.com/ecofopejod.java

 

If you need some more info, ask me!

Thank you very much to help out.

 

Edited June 23, 2017 by Kander16

[Kander16]

13 minutes ago, diesieben07 said:

You really should not just create a new array list every time. Compute the quads for every state once and cache them.

Every combination? There are 8 different slots, a boolean "block on top", 4 facings and 11 types of what could be in that slots.

That would be way to much I think.

[Kander16]

7 minutes ago, diesieben07 said:

That's why you would use a cache of maybe the last 50 combinations or so (experiment with this number).

Okay, guava's cache, right?

Edited June 20, 2017 by Kander16

[Jay Avery]

1 hour ago, Kander16 said:

Every combination? There are 8 different slots, a boolean "block on top", 4 facings and 11 types of what could be in that slots.

That would be way to much I think.

You don't have to compute them all when loading the models, just calculate them on the fly (as you currently do) but store the result in a cache (a map from the state to the list of quads). Then at the start of getQuads, add a check for whether your cache already contains the state, and if it does just return that instead of calculating anew.

[Kander16]

By the way, could it be that it's still not fast enough? Or do you think I would be doing something wrong with the cache then? (It's a lot faster but not so fast that I could consider it done)

Edited June 21, 2017 by Kander16

[Matryoshika]

27 minutes ago, Kander16 said:

By the way, could it be that it's still not fast enough?

Hmm?
This way of caching IBakedModels is done on the fly. It cannot be any faster. It literally checks "Do I have this? If yes, reuse. No? Ok, calculating it now, and now I got it"
 

How are you determining the "speed" of the caching?

 

Oh, and with you should be able to store quite the amount of different List<BakedQuad>'s in memory. The way it is being rendered now, explicitly only puts them in memory if they have to be drawn. So unless the player goes through each single permutation in a single sitting, the client will never have all the models in memory.

[Kander16]

On 2017-6-21 at 4:51 PM, Matryoshika said:

Hmm?
This way of caching IBakedModels is done on the fly. It cannot be any faster. It literally checks "Do I have this? If yes, reuse. No? Ok, calculating it now, and now I got it"
 

How are you determining the "speed" of the caching?

 

Oh, and with you should be able to store quite the amount of different List<BakedQuad>'s in memory. The way it is being rendered now, explicitly only puts them in memory if they have to be drawn. So unless the player goes through each single permutation in a single sitting, the client will never have all the models in memory.

 

Okay, so this is the new BakedModel code: https://pastebin.com/CkkCkLmE

 

Could you maybe take a look at it? Could be that I'm missing something / doing something wrong.

Otherwise, are there more options I could try to improve performance without remoddeling my model?

Why does it even reload all the quads every time I place/break a block in the same chunk?

It's not like my models needs to change when I do that. Only when something in the slots change or another block is placed on top of the ripening rack. But then I would manually tell the block to change model.

 

Thanks!

Edited June 23, 2017 by Kander16

[Kander16]

Hello?

 

This is what the console prints, even when I use the cache (if I remove or place a block in that same chunk): 

 

[18:12:43] [Client thread/WARN]: Something's taking too long! 'root.gameRenderer.level.terrain_setup.rebuildNear.build near' took aprox 110.59864 ms
[18:12:43] [Client thread/WARN]: Something's taking too long! 'root.gameRenderer.level.terrain_setup.rebuildNear' took aprox 110.84558 ms
[18:12:43] [Client thread/WARN]: Something's taking too long! 'root.gameRenderer.level.terrain_setup' took aprox 111.868795 ms
[18:12:43] [Client thread/WARN]: Something's taking too long! 'root.gameRenderer.level' took aprox 114.511115 ms
[18:12:43] [Client thread/WARN]: Something's taking too long! 'root.gameRenderer' took aprox 115.475238 ms
[18:12:43] [Client thread/WARN]: Something's taking too long! 'root' took aprox 119.817526 ms

 

The rest of the log is just the same, so I'm not going to put the whole log in here.

[Kander16]

Okay, so I tried to fill a whole chunk with a custom model from vanilla minecraft (fences), and it had the same problem. The problem was a little bit less noticable because the model isn't as complex as mine. So is there a way that I don't need to re-render all my ripening racks at once when I place/break my ripening rack?

The only ripening racks that need to change model are the ripening racks that changes their state. But most of the ripening racks re-render even when no state changes are done to the ripening rack.

 

Thanks for helping. Hope I get this solved, there has been put much effort into the model.

[Jay Avery]

1 hour ago, Kander16 said:

But most of the ripening racks re-render even when no state changes are done to the ripening rack.

That suggests that the cache isn't working properly. Set breakpoints in getQuads and see whether models are being correctly retrieved from the cache when they're already present - or why they're not being retrieved if they should.

[Kander16]

24 minutes ago, Jay Avery said:

That suggests that the cache isn't working properly. Set breakpoints in getQuads and see whether models are being correctly retrieved from the cache when they're already present - or why they're not being retrieved if they should.

I think the cache is working properly. When the cache doesn't contain a specific model, it will call "getQuadsForCache" to get the new quads of the model. I have System.out.println("Creating new entry..."); in my getQuadsForCache method. So when there's something new to put in the cache "Creating new entry..." will appear on the log. Since I've placed a 256 of those ripening racks and "Creating new entry..." only comes up 1 time, I think the cache works properly.

 

Maybe is the list of the quads too big? One ripening rack holds 528 quads. If I have one chunk, that means it needs to get 2.162.688 quads at the same time when placing / breaking a block.

 

So what I mean is that getQuads is called whenever I place/break a block inside the same chunk. Is it possible to only call getQuads when the state of the ripening rack actually changes? I think that would make a lot of difference. But I'm not sure of that of course.

Edited June 23, 2017 by Kander16

[Kander16]

So there's no solution for this? Hopefully someone could help me with this.