Can Actor be rendered during running OnUpdate, not yet finished?

Scripting
#1

I made a camera controller, which updates its position and orientation separately inside a single OnUpdate(), by using LookAt() to set the new orientation with its new position.

But testing it made strange flashings of drawn frames(orientation jumps) while moving the camera. I thought that the frame is not rendered with Actor attributes until the OnUpdate() is finished (because OnUpdate is meant to be called ‘per frame’), so at first a little confused.

And I found this in the document.

‘This means that update, fixed update, and a draw might be desynchronized and not called in the same order.’
(Script events | Flax Documentation)

Is this means that the rendering sequence is independant from logic update loop, and frame can be drawn at any time in midst of a single OnUpdate method?
Is it unsafe to update Actor properties multiple times(i.e. A→A*→A** to set A**) or separately(i.e. orientation / position) to avoid glitches, even inside the single call of update method?

#2

I saw this initially too. This was prior to me implementing my curved lerps (similar to ‘tweening’) to smooth transitions. Once I did that I have not seen it again. To be honest I have no idea how it stopped but has to do with how granular the ‘motion delta’ is between frames. With lerps the delta is very small per frame. Maybe that is why?

An adder question to this is what happens when Flax is pushed hard to a ~25ms CPU frame (delta). Unity chugs like serious ale drinker. :rofl: UE4 chugs too but handles struggling CPU frames better. Flax so far is very fast so will take some serious doing to get it chugging but what happens? No idea. :smiley:

1 Like
#3

If your jitter invisible by splitting frame deltas into much smaller ones by lerping,
it is hard to avoid with the case of sequential calculation, which has far different value in midst of method.
I feel I’d better not using actor itself as a result container, and should try change the logic to calculate whole Transform from the copy and overwrite it at once.

#4

The problem is, there is much more things in actor itself considering the position.

i.e I need to check camera frustum - terrain collision to avoid ground clippings (like water surface effect) by near plane of camera. It might be very ‘dirty’ to calculate completely outside of actor.

I think somethings need to be compromised, if screen blitting can be performed during the midst of Update()…

image
image1920×1075 42.2 KB

(This image is only can be seen by flashing, because the camera location is immediately fixed right after setting the ‘collidable value’)

#5

Please don’t take this as argument and it is obvious you have skills from other posts. You have my respect. I have mostly stayed out of the forums since my terrain findings posts. I was very excited for Flax (still am but privately).

What you are asking is already working as designed (from my experimentation). It is a little different than other engines but once understood it works well. I had to make some design changes but all in all it was a good thing to do. Remember that the CPU Frame and GPU Frame are almost never in sync. It is actually rare that they are. So having the rendering frame tied explicitly to the CPU frame is a poor design decision (see the PS5 engineering video below). I think Flax has some game experience behind it (with some of the error popups you can see where Flax came from) even though there are no real projects.

My ‘lerp’ math is not a LERP function. It is a frame to frame delta addition math then scaled 0.000 to 100.000% (meaning no automated memory allocation). This gives the CPU granularity of 0.000001 per CPU frame and I can add a dampening formula to this to change the curve. With Flax (it seems) as long as having a good 3 to 6 decimal granularity on moving objects (camera and others) happens smoothly. There is also memory loading happening, obviously, with the caching system with light and shadow mapping (DDGI). Are there bugs? Not sure. Maybe yes. I know what fixed the movement issue in Flax (transforms have good granularity in Flax). Slightly different than Unity 5.4 to 5.6.7…I just did a comparison based upon your secondary posting. Unity most definitely renders differently than Flax. Maybe this is one reason Flax seems so fast.

I have found a few things that Flax needs internal work (especially the Normal Maps). I know I will have to fix them. I like Flax but also realize that with the fast changing pace of this engine keeps me on the fence.

This is a very good video with Mark Cerny with how the PS5 is designed (4 years ago). This includes all the internal details as to why and how the CPU and GPU frame happens and the issues. He speaks cleanly and is super smart. He is the lead designer/engineer of the PS5. Just watch it. It will help with this question.

#6

I agree with your point and it is completely right to maintain rendering and update loop saparately.

I just wanted to make ‘sure’ what is can be expected and what is indetermined. As you say, by the engine design.

If the blitting operation is running in another thread than the logic loop, it will have rather overhead to ‘ensure timing’ to be after the certain task of logic loop. If not, it will be natural to be expected ‘xxx is coming after xxx’ things.

I was wonder the design is meant to be the certain sequence or not, and thats why I’ve thinking about the ‘workarounds’ more in latter of this thread. I tried to offer the most simple and minimal cases for the posts possible, and codes/ideas explained is ‘to reproduce/to get the point’ and was not for making the actual game.

I understand your precise interpolation must be not the simple lerp call (which ‘imitates’ the quadratic easing and inevitably makes Zeno situation), in fact at the beginning the frame deltas were showed up to say just ‘moving things, but not atomic’.

#7

Thanks for your explanation. You have the habit of asking deep questions. :joy: I wish I could post more replies to others. I am not even sure my advice is good advice on this one. Simply a way to work around what appears to be by design. This is the only place to talk about this stuff with Flax and even then, it is mostly us reverse engineering Flax to see these things.

I am continuing in UE5 for the time being. Some things are a pain but I am working around them, mostly. My Tile Tech is proving useful in Flax though (requires no terrain). I don’t have to worry about this stuff in UE5/Unity. All of this is mostly managed via handoffs to the black void. :joy: Simply need to manage the draw calls and memory budget. Somehow prevent gamer modders from adding 8k textures for an apple. :rofl:

Flax seems to be much more deliberate on a lot of things I have not expected. As to this topic though I think Flax taught me something, maybe a light bulb moment. It seems engine designers have some different ideas on how to approach things. It was interesting in Flax to have to change my design (not a lot) to deliberately not worry about the normal hand offs. I discovered this exact topic, which is why I replied, when converting/adapting my Unity weather system to Flax and discovering some strange anomalies (the camera was the first one).

Small example, the star/sun has incremental rotation and angle. When I change it every frame (Update) strange artifacts appear in Flax. I am always using DDGI, why not. When I adapted the rotation and angle adjustments to a span range, when the script accumulates a couple of degrees, I then quickly LERP/Delta/Tween from the previous static position to the new static position. It happens quickly but smoothly and Flax handles it fine. Unity and UE4/5 do not have this issue.

The long winded part of this is for Flax specifically I had to make certain manually that the Update always happens prior to the rendering by making sure the math only changes in the update. Some mental gymnastics here but works. I do worry this will bite me later though.

Thanks for the thoughtful topic questions. :+1: