thpsX

- => General THPS(X) => Topic started by: Degenerator on January 13, 2019, 06:44:46 pm

Title: TIP: Memory Usage of CAP/Park Editor, Random CRASHES and other userful tips
Post by: Degenerator on January 13, 2019, 06:44:46 pm
Hello people!

Since I started to host some games on THUG Pro with my parks, people ask me a lot how to put many objects in a big sized park (56x56, for example).

Here I will explain a lot of theories and things that are confirmed by me after testing a lot of possibilities on park editor to see why and when the game crashes after put a certain number of objects on park.

First of all, let's forget about the yellow memory consumption bar. Yes, it's so useless that I won't take it too serious. It's just cosmetical and doesn't show the real memory usage of the park. For example, when you put a single breakable crate, the consumption starts to raise up drastically. That is ridiculous. Don't be afraid if your memory bar is red, don't worry about it. This doesn't mean nothing and doesn't mean your park is about to crash the game. Another things will tell that, and I will show what things.

Anyway, that was my ultimate test on Create-A-Park to see if I can explain why your park crashes when you put a certain amount of pieces and test it. You can test that by yourself, if you have enough patient.

(https://i.imgur.com/ABSGArL.png)
https://i.imgur.com/ABSGArL.png

Raises (up)

Raisers are simple 1x1 blocks. I tested how many raisers I could put on my park. Result? 1000. If you trepass 1000 raisers, you game will instantly crash after test play.

Small BA Bench

A small 1x1 bench from Barcelona. After 1000 benchs, if you test play the game will crash.

Large BA Bench

A large 4x1 bench from Barcelona. After 500 benchs, if you test play the game will crash

Ancient Wall

A 2x3 wall with castle theme visual (not to be confused with Ancient Wall Mid, a 2x2 simple cube wall without grindable miniwalls on top of it). Here things start to be interesting. I could put only 105 walls, BUT the memory bar was far to be full. If I put +1, the game will crash after test play. Why? I will explain this later.

(https://i.imgur.com/HQWCO5T.png)
https://i.imgur.com/HQWCO5T.png

Long Quarterpipe

A 4x1 simple quarterpipe. You can put 500 on the park. 500+1 will cause the game to crash if you test the park.

Long Pool Quarterpipe

A 4x1 simple pool quarterpipe. You can put 250 on the park. 250+1 will cause the game to crash
if you test the park.

Lowers (down)

Lowers are the opposite of the raisers: is when you lower the terrain. The quantity that you can put in the park depends of the positions of the lowers and the variety of height of each lower. For example, if you have a uniform terrain lowered, you game won't crash, regardless of height, they just have to be uniform. Like this:

(https://i.imgur.com/f4cj6Hvg.png)
https://i.imgur.com/f4cj6Hvg.png

BUT, if you have variances in height for each lower, the memory will be consumed a lot. This has an explanation. When you lower the terrain, under the floor you will see some walls. Those walls are the real consumers of memory, not the lowers itself. So, the most uniform terrain you get, less walls will be applied under the floor. See:

(https://i.imgur.com/nYP7DBh.png)
https://i.imgur.com/nYP7DBh.png
Semi-uniform terrain. Above and below the floor.

(https://i.imgur.com/TVCXX5m.png)
https://i.imgur.com/TVCXX5m.png
Messed up terrain (just using lower). A lot of walls are created under the floor.

So, there isn't a exactly number of lowers that you can put. That number can vary depending of the distribution of the lowers in the park. But I think if 1000 walls under the floor are created, 1000+1 will crash the game on testplay just like raisers (not tested).


So, it's simple, the more pieces you place, more memory consumption you'll get, right?
Not really...

Another thing that I discovered is when you put 1000 raisers/500 long QP/105 Ancient Walls + any floor (except curbs) or non-wallridable/non-grindable/non-vertskatable/non-climbable object, you game won't crash.

Yes, you heard it right.

You can put water, lava, pit, tree (not the square grindable one), trashcan, funboxes, 1P, 2P, Horse, KotH, Flags, Gaps, Goals, Breakables, Windows etc. the many as you want, even with the objects listed before. Like I said, memory bar is useless. For example, it shows water piece consumption high, but it actually doesn't consume nothing.

So, the memory usage of the park is based on NODES. If your piece have any sort of node (grind, wallride, vert, climb), the memory will be consumed.

What is a node?

Nodes are some sort of entities that tell you what can be grindable/wallridable/vertskatable (QPs, for example).

(https://i.imgur.com/VJ0nAFW.jpg)
https://i.imgur.com/VJ0nAFW.jpg
Blender showing nodes from a QP. The red line is a rail node that shows that thing is grindable. The blue surface is a vert node that shows that faces act like QP. Credits for the photo: Sattan.

(https://i.imgur.com/ZypbDB4.png)
https://i.imgur.com/ZypbDB4.png
Proving that you can put every non-node piece after reaching the limit of pieces that have some sort of node. In this image, I put 1000 Small BA Benchs. +1 Object with node would crash, but since funboxes doesn't have nodes, I can put many as I want, including the "memory killer" funbox with boost. Actually, it's not a memory killer piece, but the yellow memory bar accuses it to be.

But how about Rail Placement?

Rails generated from Rail Placement are special pieces that actually contain nodes, but they don't consume memory. They most likely have a separated place on prk file just for them, and they are independent from normal pieces. So, if your park is crashing, probably the rails from Rail Placement aren't the problem. You can put 1000 raisers + a lot of those rails without problems.

Ok, but how can I know how close the park is to crash the game and how to avoid it?

You can simple save your map every time before testing IF you see that your park is already complex and it's dropping your framerate. Not always your framerate will indicate that, so be careful. If you test the park and the game immediately close, it's because you have to remove some pieces that have nodes (except rails from Rail Placement).

Another thing that can indicate that your map is close to crash your game is the time that you spend waiting for the test park. For example, I put 38x38 BA Trees on the park (1444 trees) and tested it. Took 0.5 sec to load the park and test it. 1000 small BA Benchs took 1,05 sec to load the testplay. 250 Large Pool QPs took 1,9 sec to load the park. But be careful, not sometimes this method can work. For example, 105 Ancient Walls took 0,98 sec to enter in the testplay, and I used only 105 pieces. If I used +1 piece with node, the game would crash.

Always (if you can) avoid complex pieces that have a lot of nodes. For example, ancient wall is a complex piece that have mini grindable walls on top of it. Each wall is grindable, and that makes the piece so complex that you can put only 105 of it on your park.

Exceptions

Obviously we know that pieces that don't have any sort of node can be placed without problems. But, in a hypothetical situation, when you put a lot of those non-node pieces (like 1500+), your game can crash randomly, yes. But it's not only in testplay. Your game can crash everywhere, like saving and loading a park, placing a new piece etc. So, don't think that is unlimited to put non-node pieces. Everything has a limit. For example, I tested 38x38 (1444 trees) and the game doesn't crash. But I tried to reach 40x40 trees sometimes and randomly the game crashed without even testing the park.

(https://i.imgur.com/hp2lJX9.png)
https://i.imgur.com/hp2lJX9.png
1444 trees placed and the game didn't crash.

Special Tip for Optimization

For this tip I recommend you to see my park called "Uptown". I used a very simple and effective technique that can optimize your park a lot and will avoid you to use lowers, because remember they create walls under the floor. This technique is drastically used on Park Editor from Skate 3 to make parks different and avoid the default themes that EA gave to players.

You can make your entire park floating. Since you can put "unlimited" floors, because they doesn't really affect the memory of the park, you can abuse this to make your park more optimized, making it above the default floor. The height above the default floor you want to use depends of what you want to create. For example, if you park will have big holes, you can make it 6-8 units above the default floor. But if want your park to have little variations of terrain or pools, you can make it 3-5 units above the default floor. Uptown was build 4 units above the default floor because I wanted to hide the ugly and repetitive default fences that surrounds the Create a Park (CAP) limits. Yes, creating a park can be difficult using this method, because you always have to raise floors to place objects floating, but it's a good way to avoid lowers and optimize your park.

Conclusion

Be careful. Just that.

When I was testing, I thought that the memory was consumed based on the geometry of the piece. Later I discovered that is something to do with nodes. Doesn't exist a perfect calculation to see how many nodes you have in your park, how much pieces you can put before your game can crash or something, but I think you can estimate how close your park is gonna crash your game, using the tips that I mentioned

Remember, those tips may help you to avoid at maximum possible random crashes, but it doesn't make your park 100% immune to it.
Title: Re: TIP: Memory Usage of CAP/Park Editor, Random CRASHES and other userful tips
Post by: Soaring_Wings on January 30, 2019, 07:32:52 pm
That is pretty cool. I'll take note of that the next time I make a map.