essentially, i have some very lightweight BP i want to fire at any moment, regardless of tick. this means ill often need to fire between frames, and because my project is very latency sensitive, the firing needs to be perfect timing wise (sub 1ms is preferred). i think the BP can run async as its just sending out midi so thats an option.
i took a look at the quartz system, but it looks like its for audio only (altho i could be wrong, in which case id love to hear how it could be used for something like this). if anyone has any ideas on what could work, that would be much appreciated.
I’ve never actually tested pooling at this type of level, but I would have thought actor pooling might be a good solution - you can spawn a pooled blueprint actor in around 0.01ms on my computer - check out the speed tests for the rdInst actor pooling:
thats… not exactly what im looking for. im more looking for a way to tick between frames.
Iv actually tried to just set tick rate in my actors to 0.001, but even that seems to default to my frame rate, which isnt what i want. i may have to just do this multi threaded, which im not totally sure how to tackle.
I already did a quick test with some multi threading stuff, but it was really buggy and didnt work at all.
Think all he did was use the timeline node as a lerp node. He can get same result using tick.
There have been a few posts about “ticking between frames”. Believe most if not all never find a solution. I mean, even if you could achieve this using another thread you’ll still hit a wall when waiting to sync. No?
yeah that was essentially my situation. timeline im quite sure will just use tick, so that wont work. i may be able to get away with using another thread as long as i never lock mutex (or keep it to a minimum). im just not sure how to handle the tick behavior of the thread without it becoming really messy and buggy.
If you’re willing to use a customized engine then you can integrate these changes into your own build. But keep in mind you’ll have to maintain these changes as well whenever you update engine versions. Depending on the number and scope of the changes and how many people work on your project this can take a significant amount of time that you don’t have to work on the game itself.
thats true. in the end i did actually manage to get something working. it wasnt super performant tho, and i was getting bottlenecks in other parts of my code, so i decided to scrap it. for now i guess im just going to have to live with the timing that currently exists.
to update this, i managed to do it through multi threading, but keeping the async thread synced with the main thread was very buggy and annoying. also not efficient at all for what it was doing, so eventually i just gave up and im living with the timing iv got.
