I also had two times the error "Unity Error > Error PlanetNomads.Data.DB.PowerConnector: ActiveBlock not exists"
I do not remember what I was doing at that time with the save. It was not the original save anymore.
In both cases, at that moment, I had the feeling that the errors should have been visible more than 3, respectively 2 times.
As in this thread: https://forum.planet-nomads.com/thre...els-like-1-fps I've noticed that FPS drop in Unity 2018 does not start by splitting grid, but by dropping the newly released part on the other part. There were a lot of particles wrongly fired during grid split, but it caused only temporary slowdown and it is fixed for next release.
While connected to grounded part, there is not much physics involved, but when very massive non-grounded grid falls on a grounded one, there seems to remain some hidden forces or oscillations, because physics gets busy. Then, when you move 100m away the thing, grid gets freezed and FPS goes to normal values. When you return back, it is slow again. Also save/load does not help. I think, that mass of the grid is so big, that it generates big forces that prevents physics engine from making the grid sleep even it's actual speed is zero or nearly zero. There is much to investigate still.
In my case, save/load fixed the low fps behavior.
The massive non-grounded grid possibly had smaller non-grounded grid above. At least in one save.
Also if the colliding planes are not parallel, the fps doesn't drop. I assumed first that a cotan(0) is the reason of the fps drop.
Glad to hear you can reproduce things I cannot.
Therefore I entrusted the "ghost buster" position to you now.
- - - Updated - - -
In some cases, the reaction is bigger than the action.
The massive non-grounded grid, when falling into the water, was staying there several seconds and then it was jumping out once more.
Some kind of collisions generate a greater reaction.
If such a case happens when the massive non-grounded grid is trapped between the grounded one and smaller non-grounded grids, then it may never come to rest.
You're right that it okay when it does not drop flat. I personally assume, that there are too many colliders in grid rigidbody and physics tries to find sweet spot for all of them but small floating point differences or other errors makes it impossible.
It is also interesting that same save loaded in Unity 5.4 has good FPS while in 2018 it does not.
Maybe Unity 2018 is doing a better job to restore the initial state, which, in this case, is an inconvenient one.
I am not sure about the real reason. But the fact is, that there is massive rigidbody with many individual colliders, and most of them are laying on another grounded (kinematic) rigidbody with many individual colliders. In Unity 5.4 the top rigidbody goes to sleep, but in Unity 2018 it does not. Probably there are some jittering forces that wakes it up all the time, so engine must calculate millions of collisions each frame instead of keeping the things sleeping.
I noticed two people have this problem on steam now.
So I thought I will try this:
It didn't worked.Originally Posted by Menzagitat
In Unity 5.4 I got a 3fps drop as soon as I activated the hover jack.
After reload, the ship was a ghost.
In Unity 2018, after load, it was not a ghost but the low fps issue occurred.
Here is the save file.
save_758.zip
As far as I know the ship should be in one piece and no collisions should be there.
Erdenstern found some time ago a workaround for the ghost ship problem.
https://steamcommunity.com/app/50405...02373011428973
The 2km distance is important. Beacons must vanish from the compass bar.
I tested and it works.
This means the load sequence is different, robust against this bug, when we approach structures in the world.
The same steps could be used for normal saves too, maybe?
Now I can extend on this comment with the following educated guess:
The many individual colliders are not aligned perfectly to each-other before the grid touches the other surface.
This happens while the grid is being created. Somehow the physics act upon the grid while it is partially created - I proved that by moving the grounded block to the first position.
Once the splitting process is finished, the resulting grids will have the individual colliders a bit shifted from each-other, just like the "ghost base" used to have it. Maybe even vibrating like joints pulled apart.
If the individual colliders touch, a collision happens between them. Such collisions cause the high forces which make the "jumping grids", the so called "over-reactive physics".
In this case the planes are parallel and a jump cannot be triggered - but the forces are there.
Also, on the ghost building collider we saw that we always slide, there was no resting as the mathematical condition to enter sleep state cannot be fulfilled – the shifted colliders prevent the actors to reach the place where the sleep can be allowed.
A solution to be tried would be, to protect the grids from the physics while splitting the grids: before the routine starts to make them grounded (kinematic) and when the process is finished to remove the kinematic property from that first block which was added to the new grids. Also the original grid must get such a flag if it doesn't have one already. Such a transaction might be advised somewhere in the API or on forums?
Posting Permissions
Reply With Quote