Is the 3D Physics of Unity deterministic across different platforms, like Android and IOS?
I saw the 2D physics is not (acros different platforms):
https://support.unity3d.com/hc/en-us/articles/360015178512-Determinism-with-2D-Physics
"However, for your application, you might want strict determinism. As
such, you would need to know whether Box2D can produce identical
results on different binaries and different platforms. Generally,
Box2D cannot do this. The reason is that different compilers and
different processors implement floating point math differently, which
affects the results of the simulation."
But I saw the 3D physics maybe is?
https://docs.unity3d.com/ScriptReference/Physics.Simulate.html
"To achieve deterministic physics results, you should pass a fixed
step value to Physics.Simulate every time you call it. Usually, step
should be a small positive number. Using step values greater than
0.03 is likely to produce inaccurate results."
https://blogs.unity3d.com/pt/2018/11/12/physics-changes-in-unity-2018-3-beta/
In the article above says:
Enhanced determinism PhysX guarantees the same simulation result when
all the inputs are exactly the same."
So in theory it is possible, but in reality (you know dealing with physics across different platforms, like Android, IOS and others) is very complex.
I'd like to know from someone how tried to implement this in 2019, if this is possible nowadays?
So if it is deterministic, what should I put in code to achieve this?
PhysX, used in Unity3D is not deterministic. However, there is a new physics package in unity 2018.3, that in theory does what you need
https://docs.unity3d.com/Packages/com.unity.physics#0.0/manual/index.html
Related
So I have been trying to use the power of compute shaders to speed up the process of generating simplex noise for my map terrain generation in unity. The problem is that for the game to work it requires everything to be deterministic in order to prevent desync in its lockstep simulation. To do this I need to use some sort of fixed point math in order to avoid the nondeterministic mess that is floats :( . Wondered if anyone could help with this as can't seem to figure out how to achieve this in a reasonable run time
There is a fixed datatype you can use in shaders. Its value ranges from -2.0 to 2.0, stepping at exactly 1/256th. This should do it.
If the range does not work for you you'll have to make do with integers, which aren't supported on older platforms (even though they are emulated using floating points internally, which is not what you want).
See https://docs.unity3d.com/Manual/SL-DataTypesAndPrecision.html
i have implemented a full fingerprint solution in my application.
Offline phase: I can create multiple observation points and calibrate them with the mean rssi values of all the beacons in the room.
Live phase: Here I compare the actual values with the database values to get the closest position.
Now I've read that the inclusion of a particle filter can improve the accuracy of the fingerprint solution.
Does anybody know how and why can I implement this?
I assume you can use them together as complementary solutions to each other, since I'm not aware of an approach that combines both of them practically.
Here is a nice paper about using particle filters with BLE, it does discuss other approaches as well including Fingerprinting.
To comment on your question, I know that particle filters will work better when there is line of sight between the observer and beacons. On the other hand, your current solution should work with better accuracy when there is no line of sight and especially when you are already using a database to map beacon distances to your observations.
What I would do as an "extension" is to use both methods side by side, and take advantage of the database when inside known locations depending on line of sight. For example you can use particle filter inside small rooms with less obstacles, otherwise you can put a threshold for your estimation and compare it with your database value and switch to Fingerprinting when inside more obsolete or larger indoor areas.
I was wondering how a mechanical stop can be modeled most efficiently.
I do a hydraulic simulation with a controlled hydraulic cylinder in OpenModelica. For the hydraulic cylinder I use the sweptVolume model from the Modelica Standard Library.
What bugs me about this model is that there is no mechanical stop if the piston reaches the bottom of the cylinder.
I tried several ideas with no good result. I tried to reset the displacement of the piston to zero, if it hits the bottom, via an if-expression. But this is not really a good option due to the fact that the volume is calculated using the piston's displacement.
I then tried to introduce a force that equals the force applied to the piston, if the piston hits the stop. This option didn't work either, because in this case the pressure inside the cylinder can not be calculated.
The third try was to use the MSL model of MassWithStopAndFriction linked to the translational flange of the sweptVolume model, but this model seems to be broken for me.
Now I count on you as a competent community to bring in some more ideas for me to test.
Depending on your application, you may deploy the Hydraulics library? The library aims to model (compressible) fluid power systems and contains cylinders with end-stops. Its scope is different than the Fluid package you are using.
Using when and/or if statements for this task, I'd strongly discourage from experience. You may get one cylinder to work, but using that in a larger system will definitely get you into numerical problems. Have a look at the Mechanics package and analyse if the ElastoGap can be of any use to you.
OpenAL makes use of HRTF algorithms to fake surround sound with stereo headphones. However, there is an important dependency between HRTF and the shape of the users head and ears.
Simplified, this means: If your head / ears differ too much from the standard HRTF function they have implemented, the surround sound effect fades towards boring stereo.
I haven't yet found a way to adjust the various factors contributing to the HRTF algorithm, such as head diameter, pinna / external ear size, ear-to-ear distance, nose length and other important properties influencing the HRTF.
Is there any known way of setting these parameters for best surround sound experience?
I don't believe you can alter the HRTF in OpenAL. You certainly couldn't do it by putting in parametric values such as nose or pinna size. The only way to find out your HRTF is to put some very tiny, very accurate microphones in your ears, go into an anechoic chamber and take frequency response measurements at every angle around your head. Obviously this is time consuming, expensive and impractical. It would be fantastic to be able to work out your HRTF from measuring your head, but unfortunately acoustics isn't that deterministic and your ear is very sensitive to inaccuracies as you pointed out. I think the OpenAL HRTF is based on some KEMAR dummy head measurements (these perhaps?).
So, I think the short answer is that you can't alter the HRTF for OpenAL. Because HRTF is such a complex function that your ear is so sensitive to, there's no accurate way to approximate it with parametric values.
You might be able to make a "configuration game" out of optimizing the HRTF. I've been looking for an answer to the question if any of the virtual surround headsets or soundcards allow you adjust them to fit your personal HRTF.
Idea: You vary the different HRTF variables and play a sound. The user has to close his eyes and move the mouse into the direction he thought the sound came from. You measure how right he was.
You could use something like a thin plate spline or statistical curve fitting to plot the accuracy results and sample different regions of the multidimensional HRTF space to optimize the solution. This would be a kind of "brute force" method to find a solution that is not necessary accurate, but as good as the user has patience to optimize his personal HRTF.
According to a readme in the OpenALSoft sourcecode it uses a 32-sample convolution filter and you can create using custom HRTF samples.
It looks like it is now possible. I stumbled upon this comment which describes how to use hrtf_tables for approximations of your own ears. Google is showing me results for something called hrtf-paths as well but I'm not sure what that is.
Traditional physics simulation in games or graphics industry was basically discrete.
But engines nowadays such as box2d or bullet3d implement continuous physics simulation. I know basic principles of discrete simulation, but I have no idea about continuous simulation. That's magical to me, and using magic is hard and dangerous. So I want to make the magic into tools by understanding them.
So I want to know:
(1) What are the basic ideas and implementation principles of these continuous physics simulations? (2) Could the idea be generalized to other kind of discrete simulation? Please let me understand this!
I know only what I've read in this document, which certainly has better information and better references than are worth simply repeating here.
Nonetheless, it sounds like the collision detection is what's continuous. Consider a bullet (coincidence?). If you simulate it with ∆t = 1/30 s, there's a pretty high probability that it'll be 5m in front of you at one timestep and 5m behind you at the next. From what I understand, a continuous physics engine would treat the bullet as a ray which intersects me precisely at the time that I die. It sounds like this method solves directly for when and where collisions will occur. I suspect the algebra for rotating and translating bodies gets complex, but if you really want to explore that, there seem to be some PhD theses referenced.
I hope that's not too obvious and condescending, but the document looks to have the relevant references. Good luck!