Sign in to follow this  

Having two arrays in the scene ?

This topic is 1117 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I have a flat array for my scene which is not ordered parent-child so a parent can be after a child.

For the rendering never problem this array is used to render each component needed.

For the update if you update recursively you can have child updated twice if a parent is after a child.

The solution of this problem I found is to have one flat array not ordered and one array with all root.

One problem of this is if you have only root item in the array without children, you have 2 same array.

The render scene code uses the flat array and the update and save of the scene use the root array.

Is it a good solution or a better one exists and needs to be used ?

Thanks for the help

Share this post


Link to post
Share on other sites

Your post isn't very clear.

 

You have arrays of what? You have trees of what?

 

Modern systems transfer all the data like textures and vertex arrays and shaders over to the video card, then set a small number of parameters and instruct it to run a list of commands.  Then there is a single small transfer across the bus, and the card does all the work.  They also use the fact that certain operations on the card take more time and try to cluster them together. For example, changing textures and changing shaders takes time so they'll often batch up all the instances of an object and draw all of them so they only pay the cost once. Vertex arrays and textures will also be transferred once and then referred to by id forever after. 

 

The kind of lists and arrays you mention doesn't really sound like that.  They sound more like you are transferring the vertex arrays every frame. That is a burden on the bus and on memory, and should be avoided.

Share this post


Link to post
Share on other sites

Interesting what you said, but I spoke only of a basic scene with array of actor, my data are in component like all modern design but I don't do threading system actually.

I though the problem was clear, that's only question of the parent-child update and saving, since I use an array of actor not ordered, the rendering has 0 problem but update and save give problems.

The solution for the save load I found is to store an hierarchy based on index of the array to then on the load AddChild but using the array of root actor that can be avoided to store all root+children recursively, for the update of the scene update root+children recursively too.

The question is : Is it the good way to remove the problem ?

Edited by Alundra

Share this post


Link to post
Share on other sites
Sort your arrays so parents always precede children.

The cost of the sort is cheap, especially as they're just indices. Various approaches can ensure that the sort is implicit without actually performing a sort operation, e.g. by swapping the parent and child entry in the array when the relationship is formed if the parent is after the child. You really want to keep the array to be sorted parent-to-child with as small a distance as possible between parent and child; this means your update loop just iterates (not recurses) over the data once with children back-referencing parents' indices and the parents data is highly likely to still be in cache.

You can at the very least ensure parents come before children by swapping the parent and child data when the relationship is formed if the parent comes after the child (or just initially placing data in the proper order if you know the relationships ahead of time). An indirection table can allow your game objects to use stable ids/handles into this scene node system while allowing the scene node arrays to be reordered as needed.

Share this post


Link to post
Share on other sites

I would greatly take Sean's recommendation of listing parents before their children in cases when nodes needs to be organized in N-trees. The number of nodes is fixed per level, and finding and updating nodes is quick and trivial with bitwise functions.

Share this post


Link to post
Share on other sites

This topic is 1117 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this