Scene Graph

Post reply
2 favourites
From the Asset Store
Destruction Scene Elements
$10 USD
3D Rendered, High Resolution elements to create an apocalytic scene or war zone
sbucci's avatar
sbucci

  • If I understand correctly, the goal is to have the scene graph work live in the editor, correct? Does that mean it will work with the timeline as well? it would make animation SOOOO much easier

  • Jerbens Yes, because it is a rather large feature we decided on working on the runtime first, so we could get something out to the public as soon as possible. After the new feature becomes stabilised in the runtime we will start working on the editor tools.

    There will be specialised UI to be able to setup structures in the editor. I imagine there will be some extra work to integrate timelines, like being able to add all the instances in a graph to a timeline at the same time, instead of one by one.

    Asides from that, I have a feeling it is just going to play very nicely with timelines. Modifying a parent instance through a timeline will automatically affect all of it's children if it has any.

  • Thanks eleanorjmorel

    Interesting I got similar results.

    I wonder if this gonna be permanent or it will be updated, I hope they will balance it up to the level of the Containers or Faster ))

  • Nice benchmark - like bunnymark for scene graphs - would like to reproduce it in some other engines if I get some spare time. I got around 37,000 objects on a Ryzen 3600 - which seems very good.

    The CPU Profiler results makes sense to me. I would have expected performance at least on par with your 'forEach' method, hopefully somewhat faster without the event overhead, and that's what we see with 'PickParent'. I'm guessing 'PickChild' is slower than 'PickParent' because it probably involves array access or something, i.e. parent UID is probably stored in a normal variable because there can only be one parent, but there can be multiple children so their UIDs are probably stored in an array. Performance seems pretty close to containers already, considering the optimizations they could have done for the static contents in a container.

  • Only 50% of parents have a child, so the difference is looping through 100% parents for 50% child, vs looping through 50% child for 50% parents. I made it this way because it suits my needs and is what I want to do with it, the for each is also looping through 50% child for 50% parents.

    So technically it is an improvement over for each, which is good !! I can work with this

    edit note: the pick with container loops through 100% Sprite with 100% sprite3

  • Only 50% of parents have a child, so the difference is looping through 100 parents for 50 child, vs looping through 50 child for 50 parents. I made it this way because it suits my needs and is what I want to do with it, the for each is also looping through 50 child for 50 parents.

    So technically it is an improvement over for each, which is good !! I can work with this

    Ah I missed that part sorry. My results below with event sheet modified so every parent has a child. So still a slight overhead for picking children vs picking parents, but a more sensible difference.

  • To understand why this matters and to give you some perspective, I'm not sure if you've seen my code before but it looks like this in my project https://www.strawberrypunch.com/

    because even taking the smallest amount of code like in the project I shared and converting it into conditions like this

    just adding one simple condition makes performance much worse

    because while less expressions are used, it has to loop through every sprite object twice, once to make it move, and a second time to check the condition for being outside and put it back at the beginning, instead of doing all of the operations at once.

    This is why I want better picking not limited to containers, because once a game starts to get as complex as mine, can you imagine the performance hit if all of those conditions i have in my actions were condition blocks, it would be a slog and my game wouldn't even be possible.

    That'S why I was so excited by this Scene graph thing, to make my code more modular and easy to use, loop through a smaller amount of children and apply to their parent, instead of looping through all of the parents to see if a "child exists"/"condition is met" like i have to do now

  • Kind of wondering if scripting might be optimal for performance in this.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Looks like your javascript is being slowed by looking up the viewport coordinates every loop. Store them in a variable before the loop and javascript becomes the faster option. 

    const Spritetest = runtime.objects.Sprite.getAllInstances()
const Spritetest3 = runtime.objects.Sprite3.getAllInstances()
const viewport = runtime.layout.getLayer(0).getViewport()
var vl = viewport.left
var vr = viewport.right
var slength = spritetest.length

for (i = 0; i < slength; i++){
	Spritetest[i].x = Spritetest[i].x + Spritetest3[i].instVars.speed;	
	if (Spritetest[i].x > vr -16 ) {
		Spritetest[i].x = vl + 16 + (Spritetest[i].x - vr -16 ) 
	}
}

  • No you forgot to define i (the loop variable) so your example doesn't loop.

    Doing what you said doesn'T make a difference

  • Haha sorry, don't know how that line got deleted, I'll try to blame my cat for always stepping on my insert key. It did cross my mind briefly that it seemed too much of an improvement...

  • Will you also add whether we can Zordering or not, and on top or bottom of the parent?

  • You can tell if a parent has children, and how many it has, but should it be able to say if it has a specific object as a child?

    "Is object a child"

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)