Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice
  2. Ever participated in one our Game Jams? Want pointers on your project? Our Evangelists will be available on Friday to give feedback. Come share your games with us!
    Dismiss Notice

GameObject Tweening: Prove of concept using Native Arrays.

Discussion in 'Data Oriented Technology Stack' started by Antypodish, Dec 12, 2018.

  1. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,289
    For any one who may be interested in topic. (Just the prove of concept)

    So I was thinking recently, how I could approach tweening solutions, between GameObjects and ECS.
    I have seen posts for example
    ECS-Tween: A very simple tweening system using ECS that works with GameObjects
    as well as Hybrid demos.

    But I wasn't convinced, is a good solution for my application. Hence I decided to work on mine.

    The concept is, that I only utilize RigidBodies and Colliders of the Classic OOP Physics, while rendering part, is done on ECS side using entities.




    The way how I approached it, is by using NativeArrays as medium, between two realms.
    So firstly at creation of block entities, I generate basics data, for which, first entity is related to RigidBody, the other entities store relative position and rotation to the RigidBody.
    Then I generate in Classic OOP dictionary, which matches entity index, to the GameObject.

    • OOP side has form of listener, which waits for commands, stored in native arrays. Is basically if condition, in FixedUpdate, checking if the command count is greater than 0. I never dispose arrays.
    • OOP also has one updater method, which sends every FixedUpdate position and rotation of the RigidBody (only), if requested from ECS. Same principle on arrays.
    • ECS side listens to changes in native array, and executes rendering of cubes, calculating relative offset etc.

    That way, I can send for example command, for adding force. Or adding more blocks etc.

    The main reason I didn't want to use default approach, using Game Object Entity Component, as I do expect have many rendering objects. But not necessary need as many colliders. So I can store in pool as spare, to reuse when needed.

    Is hard to say regarding performance. I hope for good. But I will yet need to do stress testing.

    But either way I wanted prove the concept that decoupling two worlds can be done, using merely Native Arrays.


    If have any thought, please drop in.
     
  2. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,289
    Last edited: Dec 15, 2018
    FlightOfOne and GliderGuy like this.
unityunity