What is the best option for better performance using the Archimedes Plugin?

Help and Feedback Building Support
,
#1

Hi all,

I was wondering which would be perform better and cause the least amount of lag in my game. I have been using the Archimedes plugin to generate the curves along my paths, but was just curious as to which option is better for performance.

Archimedes has multiple options of how you want the parts to align, this topic is between whether Inside or Outside would be better.

Outside:

image
image713Ɨ560 23.6 KB

This leaves a gap between the two parts, which I would then use the GapFill plugin to fill the gap. This looks perfect as it is filled in with the perfect sized parts, but my concern is how it tends to fill each gap with 4 parts, which can result in a lot of parts if used repeatedly.

This other option is Inside:
image
This looks slightly worse, as it has that ā€˜flickeringā€™ texture (Where the solid blue is inside the blue outline) where the two parts are inside of each other, but I donā€™t think itā€™s detrimental to the look of any game to have this issue, especially if itā€™s going to increase performance.

Am I right in assuming that using the Inside method, despite the flickering textures, would provide better performance, as it is essentially 1/5 of the original amount of parts? Or would the performance difference be negligible? As of now, using the outside and GapFill method, I have about 4500 parts in the paths, which I could see increasing to somewhere around 5000-6000 by the time its finished.

Obviously, as there will still be a lot of path pieces with the Inside method, this will come with a lot of flickering textures but I do not know how this affects performance of users, especially on lower end devices.

Thank you all in advance for your advice! :).

#2

if you use the ā€œinsideā€ option you can union the 2 parts to remove the flickering texture.

1 Like
#3

Thanks, that is a good suggestion to remove the flickering effect, it does leave me with a question of will this negatively affect performance, as it will essentially be a very big union if all of the path pieces are unioned together. I know union hitboxes can perform strangly if they consist of many parts as well, so this could be a potential issue that comes with it as well. Thanks again :slight_smile:

#4

it will probably run better than a bunch of parts (at least at loading time)
at worst it will run just as good.

Another thing you can do is union it, export it as an OBJ, and import it as a Mesh.

#5

Thanks again for your response. Like I mentioned above, I think the more parts that become part of the union, the less accurate the collision box becomes around the object so I may then experience behaviour with paths that isnā€™t really wanted, thatā€™s why I thought leaving it as parts would be the best idea but wondered how much of a performance impact the flickering of textures would have over at least double the amount of parts (2000 extra).

Exporting it to a mesh and then back in could be a good idea, but limits my ability to change them down the line quickly if I only need to adjust one of the parts. I also may go over the triangle limit with the meshes, and they will then import with very strange shapes that are not intended.

Once again, thanks for your responses and help, Iā€™m just trying to weigh up the positive and negatives of the approaches you have suggested, so it will work as desired and with the best performance possible :).

#6

You can change the collision box of a union or a mesh.
Just go to Collision Fidelity, and set it to PreciseConvexDecomposition
This will make the collision box (almost) the same shape as the union or mesh.

#7

Ok, it sounds like using the Inside option is probably best, and then unioning them (or at least sections of the paths) to stop the majority of the texture problems. I may look at exporting to mesh and importing back in for more optimization, once Iā€™ve finished all the modifications, or may just leave it if it runs ok. Thank you for your help, itā€™s been very helpful :).