WIP: Refactoring scene tree to make unordered set of unique pointers #605
Conversation
|
Please give a better PR name like |
aaryaag03
changed the title
| @@ -249,28 +249,27 @@ bool Scene::snatchChild(Scene* child) | |||
| } | |||
|
|
|||
| Unordered_set<Ptr<Scene>>& children = child->getParent()->getChildren(); | |||
| for (auto&& child_scene : children) | |||
| for (auto& child_scene : children) | |||
There was a problem hiding this comment.
is there a reason to use an lvalue reference instead of rvalue?
There was a problem hiding this comment.
This is the universal binder, not an rvalue reference. However, this line diff doesn't seem to change anything.
| auto it = m_ChildrenScenes.end(); | ||
| --it; | ||
| ScriptSystem::GetSingleton()->addEnterScriptEntity(&(*it)->getEntity()); | ||
| //aarya |
| void setFullName(String& name) { m_FullName = name; } | ||
| SceneSettings& getSettings() { return m_Settings; } | ||
| }; | ||
| #pragma once |
There was a problem hiding this comment.
fix this, your diff shouldn't be the entire file.
| { return l.Dot(r); }; | ||
| vector2["cross"] = [](const Vector2& l, const Vector2& r) | ||
| { return l.Cross(r); }; | ||
| sol::meta_function::addition, [](Vector2& l, Vector2& r) { return l + r; }, |
There was a problem hiding this comment.
Run a linter here to have this being the original, ideally your diff should only contain things which you've changed functionally or semantiaclly.
| @@ -51,7 +51,7 @@ class Scene | |||
| Entity m_Entity; | |||
|
|
|||
| Scene* m_ParentScene = nullptr; | |||
| Vector<Ptr<Scene>> m_ChildrenScenes; | |||
| Unordered_set<Ptr<Scene>> m_ChildrenScenes; | |||
There was a problem hiding this comment.
Why use an unordered set? What are the advantages of using one here?
There was a problem hiding this comment.
Basically, we needed O(1) addressing along with O(1) deletion. Based on this, the most ideal data structure seemed to be an unodered_set. O(1) deletion was needed because currently in many functions we loop over the complete vector which isn't necessary.
There was a problem hiding this comment.
@Bashar-Ahmed Is there any performance testing done to see if using a cache inefficient data structure but with a theoretically better complexity is performing better than a vector?
Also, do you want to save the order in which the children are added in a parent?
There was a problem hiding this comment.
No, as of now no performance testing has been done. Will have to look into it and get back to you. Also caching due to vector would've been minimal, if any, due to the fact that it was a vector of ptr, instead of the actual scenes. So when fetching the address,caching would be useful but when getting the object the caching wouldn't be effective. (Had a discussion regarding this with @sin3point14 ). Apologies if this approach is flawed, and do correct me.
As far as the order is concerned, we looked at this aspect and weren't able to find any viable usecase where saving the order of scenes would be necessary
There was a problem hiding this comment.
One way the order is important is when you need to iterate over the children to display them on the editor. Seeing the order of the children change as you make any changes in the scene hierarchy can get confusing.
|
I talked about a probably approach with archit which would need minimal
changes and should remove those pesky edge cases.
Only allow saving the root scene’s children and don’t allow 2 scenes of the
same path to be attached to the root. Ofc if you must attach 2 scenes of
the same path, you still can 2 make 2 empty scene children of the root and
add those 2 scenes as their children.
Since we serialise(afaik) all the children into the file of the direct root
children, saved scenes should only be treated as “templates” ie you can
instantiate them as child of some scene and then change the properties.
Saving the root child parent node(the node in the parent hierarchy which is
also a root child) will result in the scene of that root child to contain
all the data of this instantiated child scene. Another way to think about
this is that changing the contents of that child scene file would have no
effect on this attached instance, it lost all connections to its source
file and the moment it was attached as a non root child.
tldr: only allow saving of direct root child scenes ie root child scenes
are the only scenes who know their original file path and disallow multiple
root children from same path. This goes well with rootex philosophy of
everything can be uniquely identified with its file path.
…On Thu, 16 Feb 2023 at 8:48 PM, Twarit Waikar ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In rootex/framework/scene.h
<#605 (comment)>:
> @@ -51,7 +51,7 @@ class Scene
Entity m_Entity;
Scene* m_ParentScene = nullptr;
- Vector<Ptr<Scene>> m_ChildrenScenes;
+ Unordered_set<Ptr<Scene>> m_ChildrenScenes;
One way the order is important is when you need to iterate over the
children to display them on the editor. Seeing the order of the children
change as you make any changes in the scene hierarchy can get confusing.
—
Reply to this email directly, view it on GitHub
<#605 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKMII7OCZBWVPYSGHQWAFA3WXZALPANCNFSM6AAAAAAUM3ALIE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
No description provided.