I’m working on a psychology study using VR to assess reaction times. As such, I’d really like reaction time resolution ~1-2ms or less.
I’m using enhanced input to detect a button press. This is linked to get accurate real time node. But I haven’t been able to find out if the get real time node is triggered immediately on button-press, or if it will only trigger at the 60Hz frame-rate limit (~16.67ms increments).
Does anyone know for sure if the connected subsequent nodes (particularly get accurate real time) fire immediately, or will they only fire at the frame rate?
Unreal Engine (or any game engine) is not suited for that kind of precision. You need as few layers as possible between actuation and read if you are going for that kind of precision. Even the keystroke length will matters in such scenario.
Now if you are going for funzies
Sequential nodes are executed immediately / in the same frame unless there is a delayed execution node (one with a little clock at the corner). At any point you can get the system’s time by using the Now() node but I wouldn’t really bet money on its accuracy.
P.S. Actually your best course of action is to aim for much, much lower accuracy.
I’ve got a back-up plan to assess reaction times but it’s requiring a fair few moving parts!
I’ll try both this way and the back-up, and see whether they correlate very well!
While dZh0 is absolutely right, I believe your question is a bit poorly worded.
Sequential nodes are indeed executed immediately, however the event itself (input button press) is not triggered right away on button press. It is triggered whenever the engine decides to process user input, which happens once per frame.
So the answer to this would be no.
In UE, input is pretty much the first thing processed in a frame. Input events are triggered there. Then, animations are updated, actors are ticked, physics are computed (those are done in parallel), then once everything is in place the scene in rendered, and if FPS is capped (or Vsync or whatever), it waits a few ms before starting the next frame.
If you need something more precise, but still integrated within your UE project, you can leverage C++ to run a separate thread at high frequency and constantly poll the button state. Reading the time and logging stuff from a separate thread should be fine, but keep in mind if you try to run blueprints from there without using a callback you will likely run into issues. Blueprints generally expect to be ran of the main thread. Running a callback on the main thread will also induce an additional delay.
Also keep in mind that there is a delay between the moment you show something on screen (in code), and the moment it appears on screen. Not only for the same reasons stated above, but also due to various settings (buffered frames, FPS cap, monitor refresh rate and response time..).
You’ve broken this down into bits I understand a bit more, thats great. I’ll investigate how easy it would be to use C++ to poll for the inputs on one button, hopefully it’s not too complicated!
