Technical Question on WebGL Rendering

Discussion and feedback on Construct 2

Post » Mon Mar 24, 2014 8:43 pm

@Ashley or anyone who can effectively answer this question.

There was a discussion not to long ago about cloned objects, rendering he "same" image when they are different memory references. So I wanted to know some more technical question in regards to C2 rendering logic and a single sprite object with multiple instances.

I admit I could be fuzzy on this. So please bear with me :P

At the render time when C2 renders the object. The image is moved to the render pipeline. If there are numerous same instance of the Object then C2/WebGL makes 1 render call based on fill rate. So 1 call draws numerous images on the screen.

Now what if it's 1 sprite object, but with numerous frames or numerous animations. When rendering the 1 sprite object, but has numerous instances set at different frames; are all the frames image put into the pipe line. If so does WebGL/C2 only make 1 render call still because it's only 1 sprite object even though it is multiple instances set at different frames?
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Mon Mar 24, 2014 10:03 pm

Ashley can probably answer more precisely and you can find some more info on C2's renderer on Ashley's blog, but I can give some overview. Basically images are moved to video memory once and when rendering webgl is told which texture to use, the opacity and the quad's four corners' xy and uv coordinates. C2 uses sprite batching to group sprites with the same texture together and reduce the draw calls to lesstexture switching and sending bigger chunks of the quad vertices. Now as to your question I imagine if you had only two instances of one object and each had a different frame then that would be two draw calls. However on export C2 creates texture atlas' of the frames if it can, so then it may take only one call. To be more exact about a draw call, it is only done once per frame in webgl. Everything else is just sending info to webgl to use when the frame is drawn.
B
92
S
32
G
107
Posts: 5,280
Reputation: 69,971

Post » Mon Mar 24, 2014 11:07 pm

@R0J0hound
Thanks that clears a lot up. So I suppose then the part that could use some final clarification.

" However on export C2 creates texture atlas' of the frames if it can, so then it may take only one call. To be more exact about a draw call, it is only done once per frame in webgl. Everything else is just sending info to webgl to use when the frame is drawn."

So because C2 creates a texture atlas. Could or does this happen. Can the export receive better performance improvements if the atlas was larger. I'm wondering because would it be better to design a single sprite as an atlas sprite and then use invisible game objects to handle game logic.

I do get your point. If the sprite breaks the image into more memory blocks then that's more calls. Where as if the sprite were to drawn with more advanced UV coordinates off using a larger memory coordinates could reduce draw calls could improve performance.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Tue Mar 25, 2014 12:21 am

I'd imagine the performance would be better after exporting. It's hard to design for this since the texture atlas is done automatically and you're still bound by a maximum texture size.

To see if your idea would be faster you'd need to make a test either way and measure the performance. This is assuming that's where the bottleneck is at in your game. My machine is weak with html5/javascript so logic is often the bottleneck instead of rendering. Well I have a slow rendering issue as well since my graphics card is in driver limbo, so I'm hit by both sides.
B
92
S
32
G
107
Posts: 5,280
Reputation: 69,971

Post » Tue Mar 25, 2014 12:53 am

That seems to be the case. Going to have to do some kind of active performance test. I don't actually have a performance problem as of now. I'm just thinking that if this is the case where the export atlas can get better performance. Then that would have considerable changes in how the game should be structurally designed. Making a large change to fewer atlases later would be a big job. Where as designing around this from the start would save a lot of effort.

Well time to work on a test
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Tue Mar 25, 2014 1:15 am

In my tests I found that the order in which different sprites are created appears plays a part in the draw calls. Basically, it appears objects are rendered in the order of their UID's.

So, if you have 200 each of sprite A, B, and C, your draw calls can be higher if these objects are being created in such a way that their UID's are scattered (A,B,C,A,C,B, A...).

Whereas, if they are grouped together (A,A,A, etc...B,B,B, etc..., C, C, C, etc...), drawcalls are lower, since the engine is only having to switch textures a few times.

I did not test this extensively, and am a little distrustful of the draw call percentage in debugger to begin with, so take that all with a grain of salt...
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Mar 25, 2014 2:10 am

@TiAm
That's really interesting and that shouldn't be happening. Ashley mentioned before that a Sprite should be rendered as a whole. Though I have a question. Did that include Z-sorting and layers? I would assume z-sorting and layering would increase draw call in any circumstance.

All right so I did a simple render test. With unique but stable results. These are done with 1 sprite object. 10 objects are created providing creation allowed. Creation is allowed fps < 30 up to 100 time. The reason I chose this was because of how GPU handles rendering dips and how often and when they become extensive. This doesn't mean a MAX limit.

1. Performance is better if your UV size or in our case Texture sizes stick to the power of 2(2,4,8,16,32,64,128..)

2. On Preview (rounding to nearest 500)
1 Frame displayed on the object. Made it 11,500 after 10 tests.
Random Frame on object. 6000 after 10 tests.

3 On export
1 Frame displayed on object. Didn't test because this is about atlas testing on export.
Random Frame on object 9500 after 10 tests

Interestingly enough that on Export the performance increase by %45 where the GPU had less troubles.

However other factors I found out. When given the unreasonable usage of just constantly creating objects. C2 CPU will become over burden rather quickly. I suspect this has to do with the JS storage object. But it's not important because your not going to have 5000 objects on the screen. but it's interesting to know that C2 CPU usage will hit 100% before the GPU hit's limits.

So with this information. It might be best to actually create games based on the idea of an Atlas sprite object. Of course these will only count for sprites that live on the same layer.

My question is now answered. It is best to use Atlases as much as viably possible. So all widgets, small objects should share 1 object. And let robust stuff have there own sprites.

I appreciate everyone's input. I wouldn't mind Ashley's thoughts on the entire subject to.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Tue Mar 25, 2014 2:28 am

What do you mean by "So all widgets, small objects should share 1 object. And let robust stuff have there own sprites." ?

Sorry but it's 3:28 AM and i'm not sure if I understand this correctly :)
ImageImageImageImage
B
157
S
66
G
41
Posts: 2,599
Reputation: 34,825

Post » Tue Mar 25, 2014 2:59 am

I find that lot's of dev's use 1 object per game button, 1 object per bullet type, 1 object per enemy.... so on etc. In the end they have around 200 objects and at any one time they may have 50 different objects.

Where as if all the buttons, bullets... small stuff were in 1 Sprite used as an atlas using animations and frames. that would be better.

As for more robust stuff. Well if you have a player with 5 different animation types and many frames per animation. It might be easier for development reasons to to just have the player have there own entire object.

I have been enlightd towards mobile development. Even older hardware say an iPhone4 should be limited to 25apx draw calls. So of course if each of your objects on the screen is there own object then your going to hit and pass that fast.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Tue Mar 25, 2014 4:21 am

jayderyu wrote:I find that lot's of dev's use 1 object per game button, 1 object per bullet type, 1 object per enemy.... so on etc. In the end they have around 200 objects and at any one time they may have 50 different objects.

Where as if all the buttons, bullets... small stuff were in 1 Sprite used as an atlas using animations and frames. that would be better.


I cannot be sure but, wouldn't that be worse when not all objects are used at the same time?
Since the webgl renderer I think only load needed textures, doing that would force everything to be loaded at startup from what I understand
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 9 guests