UpdateWorld RenderWord
Blitz3D Forums/Blitz3D Programming/UpdateWorld RenderWord
| ||
| One of the most frustrating things in life is that my learning process is based on trial and error. In the video I show a simple problem, which is solved by putting the code in the correct place, referring to the position and movement of the camera in relation to the sphere. My question is, what happens in between UpdateWorld and RenderWorld, why the problem is solved in that place? |
| ||
| As I understand it, When UpdateWorld is called, the collisions and animations are processed. Renderworld is what draws the camera view to the backbuffer - however, I know that certain things are also established on a renderworld call - such as with Terrains. It seems most 'logical' to me, to move everything and process motion etc. BEFORE calling UpdateWorld since collisions should be checked AFTER you've moved something. Ideally, UpdateWorld should come just before RenderWorld otherwise you risk trying to reposition entities AFTER they've collided (On Collision (UpdateWorld) Blitz automatically adjusts posititions - or stops the entity movement in that direction etc) |
| ||
| it's related to the colliders implementation Let's simplify the entity and collision system by thoose simple structur :
Type Entity
Field pos.Vector
Field Collider.TCollider
End Type
Type TCollider
Field LastPos.Vector
End Type
What UpdateWorld does is tracing a vector between the last stored position from the @Collider and the current position of the entity @pos. the function then try to find an other collider which would be intersecting at any time between the two positions of the two frames (the current and the previous) Finally, if a collision occures, the response is applyed and the current position @pos is updated, and the @LastPos is replaced by the new current position (so as the next UpdateWorld can trace a new vector from previous frame to current frame ... etc ...) Now, imagine you do the UpdateWorld between the RenderWorld and the Flip : Repeat MoveEntity entity, 0,0,1 ; at this point, the entity can be intersecting another collider but the "good" position will be applyed on UpdateWorld RenderWorld() ; the entity is rendered ... but due to the previous movement, it renders an entity that can be intersecting because collisions are not computed yet. ; the image of the 3D to be shown on the screen is computed at this stage UpdateWorld() ; now the entity is repositionned so it does not intersect anymore with other entities ... ; but the new position won't be visible because the Flip don't care about objects, it only cares about the buffer which are kind of images ; -> and this is image is already drawn, waiting for the flip to be shown. ; So, the next renderworld that will care about this UpdateWorld is on the next frame ... and as the next frame will also have the MoveEntity it will be be in late for the next loop too. Flip ; the frame drawn here is computed by RenderWorld with the collision not applyed, or applyed from the previous frame (the frame from the previous loop) So, to resume, you're always late in the collision from a loop and the collisions rendered on screen can show entities that are interesecting with others for a short distance. By the way, the animations works the same. If you do the UpdateWorld after the renderworld, the animations rendered are in late from 1 frame, |
| ||
| Thanks You friends :) |
| ||
| Great explanation, I also learn by trial and error. |
| ||
It amazes me the number of coders who writes :Updateworld() Renderworld() without understanding what is going on in each function... Updateworld() is a senseless function imo, it should be split in 2 different functions : updatecollisions() (or updatecollidersdetectcollisionsrepositioncolliders()) and updateanimations() (or updatejointsandskinnedvertices()) these things have nothing to do together... anyway, i suggest to use updateworld() this way : ;depending on input and ai, update the state of each entity ;depending on the state of each entity, turn move animate the entities (and colliders) ;updateworld() ;update the colliders, detect the collisions, reposition the colliders, animate the joints/skinnedvertices ;check which colliders have been involved in a collision, depending on the result, update the state of the entities (or destroy them) and to troll a little, let me quote a great coder : Sorry? You've removed UpdateWorld? Then you've removed the workhorse of Blitz3D that does all the calculations. Check the code structure of any of the examples that come with Blitz3D. :P (to be fair it was a long time ago, so it is forgivable ;)) |
   |