Hi,
A quick and simple question. Is there any way to increase the game speed, so that everything just happens faster? I was doing a solar-system-like simulation and with the regular game time speed I cannot really simulate anything.
Any ideas?
I guess my slow motion tutorial might help, but instead of decreasing, increase? https://www.youtube.com/watch?v=8m3xCqBwk7E
2 Likes
I already know about Global Time Dilation component, however, it manages to increase game speed to about x20 of the base game speed.
With a solar system I would need a several thousand times increase in game speed. I know it cannot be done normally with time dilation, because of performance, but would there be any way to e.g. decrease the number of calculated engine iterations in a time unit in order to achieve the same performance with a game speed somehow (most probably not with Global Time Dilation Component) increased for example 5000 times?
I also thought about changing the math/physics algorithms regarding system bodies’ movement, so that they would create an illusion of being simulated quicker, but what I find troublesome is that most of them are still tightly connected with UE4 physics engine and thus such forced faster simulation is unlikely.
How exactly are you simulating the system?
I’ve done this.
You lose accuracy when doing it the way I did it though.
I had a function that calculated the orbit of my planets every tick. When I needed to speed up time I multiplied the delta time with my speed up… as I said, this way comes with the cost of lost accuracy since it makes bigger chunks of time pass, and the planets move in bigger steps.
For complex systems with large bodies this can be destructive. That’s why a game like KSP does it differently. It has major bodies “on rails”, the position is not calculated, it is basically a just a static algorithm, not looking at gravity, but just a mathematical representation of their orbit, and then it takes the timestamp and you have the position. This keeps the large important bodies on track.
The accuracy loss on the spaceships is less important since they have very little deviation because of the strong force applied by the bigger bodies. This is probably a compromise you have to strike, depending on the game you’re making.
Thank you for your responses 
It is done half physically and half with raw mathematics.
The physical part is simply the fact that the bodies have the Simulate Physics property on. Gravity is disabled for them so that they do not fall down freely.
The math part is about calculating instantaneous vectors of velocities (v0+aΔt) and accelerations (GM/r^2e) in a delta time where v0=initial speed of a body (which after every iteration is updated), a=acceleration of a body, G=(Gravitational constant)*(many coefficients scaling the real world units to smaller UE4 ones), M=mass of a central attractor, r=distance between the attractor and a body, e=unit vector determining the acceleration direction.
That is really helpful info, but unfortunately my calculations do not predict the orbit outcomes and it would be hard to change everything now. Also I think that it would be hard to implement in my model, because it is designed so that sometimes there occur some random collisions between bodies in the solar system which could make calculating orbits heavier performance-wise than using a physical collision with an addition of some kinematic vector maths.
I was thinking about one solution. I could do a multiplication on all of the parameters used in kinematic calculations. Because when to think about it, wouldn’t it be the same outcome as speeding up time if the velocity is multiplied by something and the acceleration is multiplied by (something)^2? As the distance travelled by an object is given by the simple equation s=v0t+(at^2)/2 then if we take a certain time t1 and a certain time t2=t1/(2^n), where n=exponent determining the time speed-up (the speed-up values would be the powers of 2), it becomes certain that in order to make the s2=s1, v0_2 must equal v0_12^n and a2=a12^(2n). This will result in the same distances covered in different time periods.
But the thing is here that the physical simulation regarding collisions etc. will still occur in the base game speed. Is there any fix for that?
All that math is way over my head, but, now that you mention physics collisions happening in base game speed it reminds me of a post at AnswerHub(or forum maybe) about physics not working properly with time dilation. I’ll post here if i find it.
If you multiply all your variables, you’ll break everything.
You only need to multiply your delta seconds value(I’m assuming you are already using this number to make sure your planets/bodies move smoothly no matter the framerate).
Isn’t multiplying delta seconds the same as multiplying variables?
I mean I already use delta seconds to calculate instantaneous vectors, so basically if I multiply delta seconds I will also multiply the variables.
Well… if you choose to multiply a vector one place, delta time another, and start mixing and matching all your different variables… it’s going to get messy.
You should only multiply ONE of your variables in the calculations with this time dilation variable. And ONLY if ALL the variables in your calculations are multiplied by one another all through the chain.
And you’ll have a division in there somewhere as well. If you multiply the denominator you’ll get a different result than if you multiply the numerator…
If you multiply more than one variable through your calculation with the time dilation variable, you’ll break it… it is math, it will **** you up if you think you’re smarter than it.
there would be no logical reason to choose a variable to multiply other than time. It is time you want to fool around with, so that is where you should multiply. The result may be the same if you find another place to put it, but it will make no sense.
I will try it with delta time then and see what happens. The system was hitherto working properly, but the simpler a BP is the better
There appear two other problems then.
- When delta is increased bodies will have greater velocities and therefore greater momenta. Thus when they collide the momentum exchange will be augmented by the value of delta time. Momenta will be decreased when delta time is decreased resulting in real-world values. Will it work properly then if the delta time affects the variables in the final output when every other calculation is done or is this whole concept misleading and might result in unrealistic physical behaviour?
- Yesterday I was also hit by another serious problem. I didn’t think enough about the concept and here are the results. A planet in a solar system moves relatively slowly. In fact, relatively extremely slowly. I start with a planet and the attractor (the sun) aligned in the X axis and the planet initial linear velocity parallel to the Y axis is set to 0.0003. The value is an approximation derived from our solar system and more precisely - from Earth and Sun. The average speed of Earth is about 30000m/s and the distance from Earth to Sun is 1.510^11m. I changed it to 10^11m to make the numbers simpler. In the UE4 scene the distance between the body and the sun is 10m (1000UE units). The speed in UE must be therefore 10^10 times smaller what gives us previously mentioned 0.0003cm/s (UEUnit/s). And what is the value of acceleration of the body? Well, taking the formula GM/r^2 it is about 3.6710^(-10)m/s what in UE4 is technically 0. The objects simply do not move then.
And this is the second problem. I was thinking about making a delay which would make the engine wait until the values are large in enough to properly compute, but the value of such delay is too unpredictable.
I was also thinking about getting the time dilated by default, but the first problem must be 100% resolved first.
If your delta time affects your velocity, you’re doing something wrong.
You should do your calculations on the bodies, calculate the forces, etc… update the velocity vector of your object(s). Then move your object(s) that vector, multiplied by the delta time. The result will be that if the vector has a length of 100 units, you will end with a move around 3.3 units if your framerate is capped at 30fps. (30 frames per second will make delta time 0.033, 3.3% of the move vector will be 3.3 units).
The result will then be that with a time dilation of 2, you should move 6.6 units… or 330 units at time dilation 100.
If this is not the case, your calculations are not set up correctly, at least as I see it.
I’ll be happy to take a look if you want me to.
Sorry I misunderstood you. You were saying about moving the objects strictly in a mathematical fasion. But what I do not understand is how would you like then to also simulate collisions, bounces or splitting a body to smaller pieces? I think that calculating a distance to be covered might not be enough and this is why I wanted to implement a more physical model. Basically what I am doing right now is (I didn’t have access to a PC today so I it remained the same as yesterday):
- Calculate instantaneous acceleration of an object
- Multiply it by the square of time dilation coefficient
- Multiply it by event tick delta time
- Get the previous instantaneous velocity (var IniVelocity)
- Multiply it by the dime dilation coefficient
- Get the sum of 3. and 5.
- Set the physics linear velocity of an object to 6.
- Set IniVelocity to a value of 6. but without any time dilation multiplication, so that next time when the loop starts it will get a non-augmented previous velocity value to compute with.
This enables me to mathematically move objects without any loss regarding physical interactions.
This was my first idea I came up with when starting the project. Do you have any other so that the objects remain fully physical in space?
Sorry if I accidentally misunderstood your concept once more
I don’t understand why you use the square of the time dilation in one place, and then just the time dilation another place.
But I have to admit I made a mistake in my example to you.
I took a look at my old example and I multiplied the acceleration applied each tick with the time dilation variable as well.
We’re almost doing the same thing, but I still don’t understand the square of time dilation.
As for handling the collision, you could do it with some overlapping spheres and then calculate the energy transfer and the new directions based on their vectors… but for splitting etc, I’m not sure what I would do.
It is from a fundamental kinematic equation s=v0t+(at^2)/2, s=distance, v0=initial speed, t=time, a=acceleration.
If you want to get the same distance covered in different time periods you need to change the velocity and the acceleration. Of course, we get a diophantine equation then, but we need this one most characteristic solution based on the values from previous tick.
So we could for example get an initial velocity of 100m/s, acceleration of 50m/s^2 and time of 2s. It gives us a distance of 300m.
Now let’s speed up things two times. To do that we need to cover the same distance of 300m but in twice shorter time period, 1s.
If we get the velocity and multiply it by 2 and the acceleration by 2 we get a distance of 250m. This is not the same distance as we get before, so something is wrong.
The thing is that in the formula the acceleration is multiplied by the square of time, not by time to the power of one like velocity. This is the reason why the acceleration must be multiplied by square of the number of times the time was dilated in order to preserve the initial distance that needs to be covered in shorter time.
Now if we multiply velocity by 2 and acceleration by 4 we get the result of 300m which is exactly what we wanted to get.
A simple another numerical example with the same values, but with four times speed-up:
1x time: 300=1002+(502^2)/2
4x time: 300=v0.5+(a0.5^2)/2=(notice that the time in acceleration fraction has now became 8 times smaller the it was in 1x time)=0.5v+0.25a/2
The solution which we want for this diophantine equation is v=400m/s and a=800m/s^2. The acceleration at 1x was 50m/s^2 and at 4x it is 800m/s^2. It was increased by 16 times, which is 4^2, so the acceleration must be multiplied by the square of time dilation.
I always say that if there is something already in the engine then don’t try to create your version of it, but simply use what the engine provides. UE4 has a powerful PhysX engine which allows for very realistic physical interactions (including splitting a destructible mesh) between objects and implementing these interactions myself will firstly take a lot of time and secondly will be most likely far worse than UE4 engine.
This is really the base reason why I mix maths and PhysX here.
Well… I think we went in over my head on this. I don’t follow you anymore, my brain breaks.
But I can say one thing though… mixing your own speedup with engine speeds and trying to speed that up, that will be hard. 
I wish I could be of more assistance, best of luck.
You really were of assistance. I found some bugs and implemented another functionality when analyzing in response to your comment
I think I will get the whole game speed thing to work eventually.
And do you or anybody have the solution for those float values I talked about in post #11? I can’t figure out how to make it move so slowly without more precision which is not possible, because UE4 world coordinate system is based on floats not doubles. Any ideas?
There is also a different problem that is something very frustrating. I can’t get the velocity even below 0.2, because that is considered as a value with which the engine can turn a body to sleep mode. Even when I turn the Sleep Family to SF Sensitive it zeros itself immediately when the value is below 0.15. Is there any way to tweak this or should I quit the physics stuff already?
I don’t know the scope of your game, but it seems you’re not using all the engine has to offer when it comes to size. 10 meters is 1000 units as you say, the engine can handle 800000 units with good precision I believe it is. So step it up a notch size wise if possible, you could step up the size around 400 times and still be within maximum landscape size(which is what I use to judge what the engine can handle).
Also, since you’re using PhysX to do your physics, you really needs more size for it to work properly I think… the physics calculations often suffer when you make them too small.
After the x coordinate reaches something around 260000 the object simply disappears when I hit Play. It is not like it is not rendered. It is destroyed, because it isn’t visible even in the scene outliner. If I move it below 250000 it starts to work again.
So in my case the limit is around 260000.
If I move the object to 200000 it is 200 times more than it was in the beginning. That means that the velocity of the planet would be increased from 0.0003 to 0.06. Unforunately, this is also the value which triggers sleep mode on my object (see my edit previous post - I edited it when you were typing it seems ).
A value which should not trigger sleep mode would appear when the object was moved about 1000000 from the center. But as I said before my limit is 260000.