Name: | Original | Edited | Optimized |
| bo_snowy_pine_2 | 22 | 24 | - |
| bo_portcullis_a | 8 | 154 | 76 |
| bo_tree_e_1 | 10 | 60 | 10 |
| bo_tree_e_2 | 13 | 70 | 12 |
| bo_tree_e_3 | 10 | 70 | 19 |
| bo_palm_a | 28 | 78 | 21 |
| bo_tree_a1 | 34 | 23 | - |
| bo_tree_11_a | 40 | 10 | - |
| bo_tree_9_a | 40 | 30 | - |
| bo_tree_10_a | 120 | 28 | 24 |
| bo_tree_12_a | capsules | 79 | capsules |
| bo_tree_12_b | capsules | 57 | capsules |
| bo_tree_12_c | capsules | 42 | capsules |
| bo_rock_e | 50 | 39 | - |
| bo_rock_h | 24 | 22 | - |
lookin nice, +1 hopefully spears can thrust through this gates too not only arrows ^^
I understand nothing of this, technically, but is there a chance these more detailed meshes will have an impact on performance?
I understand nothing of this, technically, but is there a chance these more detailed meshes will have an impact on performance?
Looking at the before's, I am mentally sighing at how the person in change were even allowed to stay at TaleWorlds. That is not even funny. Looks like 5 minute effort(in total).
It would be nice to reduce the number of faces as much as possible. Collision meshes is used to detect collision on CPU, which is slower then GPU. There is a lot of factor that may affect to performance. It need to find a balance between face count and perfomance. At least remove some useless faces.
P.S. just a thought...
Palm collision mesh has the biggest amount of faces among others (78), the smallest amount is 6 (lol!). Just to compare: collision meshes of destroyed walls (currently used in strategus) have 400 faces (from 100 to 1500 faces actually) and that's just a destroyed castle wall.
And there are a lot of native trees with 50+ faces (even some with 100+) so generally it won't change anything, I just made it a bit more accurate.
Name: | Original | Edited |
| bo_snowy_pine_2 | 22 | 24 |
| bo_portcullis_a | 8 | 154 |
| bo_tree_e_1 | 10 | 60 |
| bo_tree_e_2 | 13 | 70 |
| bo_tree_e_3 | 10 | 70 |
| bo_palm_a | 28 | 78 |
| bo_tree_a1 | 34 | 23 |
Nice initiative, though some of those collision meshes could use some optimalization. Repeatable use of trees with "high" collision poly count is bad for server performance, so try to find a balance between accurate representation of the mesh and performance.
Meow, it's impossible to kill CPU even with heavy tree maps. Open xtree_meshes_c, most of them have more than 50 faces, open xtree_meshes_b, some of them have hundreds of faces (checked the first one under the cursor - bo_tree_8_c, 240 faces, same for other xtree_meshes files. bo_tree_a02 has 126 faces in tree_f.brf and others, cba to paste here. Just have a look and then post such huges posts.
Most of trees in native .brf have more faces.
Also, which native trees have 50+ faces collision objects again?
Or did you just check the regular models and took the faces of those, then compared them to your collision objects?
So that part of my post was wrong, now answer the rest of it instead of ignoring it?
How much testing did you do?
I'm talking about collision meshes. The server doesn't need to render the normal meshes, only calculate collisions. Thus, keeping the collision meshes as low as possible is important. If some native tree collision meshes are bad for performance, it shouldn't be used as an excuse.
Well, sure can't be added without proper testing on a dedicated server.
Can't tell if performance changed with the new dedicated server software but that's not available to anyone at the moment anyway.
You can go ahead and ask a clan to use those on their training server or something then get people on it to test if the performance changes.
As in ask the server op if the cpu load is different from when the native collision objects were used with the same amount of players.
Try this on tree heavy maps.
K, then I'm out of this thread.
Laters.
Don't misunderstand us Dave, I'd like to add them. Just thought it would be nice to optimize them while you're at it. And sorry about being mistaken about the other trees, I'm using my phone so I couldn't check the brfs.
The new portcullis should be fun :D
Yeah, that looks a lot more reasonable.
Name: | Original | Edited | Optimized |
| bo_snowy_pine_2 | 22 | 24 | 24 |
| bo_portcullis_a | 8 | 154 | 153 |
| bo_tree_e_1 | 10 | 60 | 10 |
| bo_tree_e_2 | 13 | 70 | 12 |
| bo_tree_e_3 | 10 | 70 | 19 |
| bo_palm_a | 28 | 78 | 44 |
| bo_tree_a1 | 34 | 23 | 23 |
Name: | Original | Edited | Optimized |
| bo_tree_11_a | 40 | 10 | - |
| bo_tree_9_a | 40 | 30 | - |
| bo_tree_10_a | 120 | 28 | - |
| bo_tree_12_a | 280 | 79 | 60 |
| bo_tree_12_b | 200 | 57 | 40 |
| bo_tree_12_c | 200 | 42 | 37 |
Omfg, lol :D(click to show/hide)
Nice work but why arent the original models triangulated? (not like it matters, just looks weird) Also some of the new ones looks really messy, I think the polycount could be reduced much more
Tree 12 a. I think some of the messiness comes from that you show entire wireframe. I haven't really looked others cause I'm usin my phone
That's the screenshot of not optimized mesh. The optimized mesh has 19 less faces.(click to show/hide)
Outstanding work Dave. I'll add them in a couple of days.
Good stuff....makes me scared to see just how bad the collision meshes around weapons and people are. People always complain about "ghost reach" and now im really scared! :)Yeah I'd like to see the player collision mesh. Only thing I'm thinking is maybe the original tree collision meshes were larger than the model on purpose, like to prevent the player sides from visually clipping in to it. But hopefully not cause it'd be really nice to have these improved ones. Especially if they can also free up resources to increase server performance.