really bad framerate in glsl, semi-bad framerate in Multitexture (stip)

[ndee85]

really bad framerate in glsl, semi-bad framerate in Multitexture (stip)

[ndee85]

do you also use the latest version of stip? If not please update that too and see if it is still that bad.
I just tested it hier on my machine and I get 60fps which get locked by the vsync.
I will test this on another computer tomorrow and see the results there.

[blurymind]

I think i am. I cloned coa tools addon together with the example file stip today.
Is there anything else i can do to help diagnose the problem?

[blurymind]

Im on blender 2.76 btw

[ndee85]

try opening the console and see if any errors are printed while playback?

[blurymind]

When I run blender from terminal, I get these messages:

`./blender
connect failed: No such file or directory
Read new prefs: /home/owl/.config/blender/2.76/config/userpref.blend
found bundled python: /home/owl/INSTALL/BLENDER/blender-2.76b-linux-glibc211-x86_64/2.76/python
search for unknown operator 'MY_OPERATOR_OT_select_frame_thumb', 'MY_OPERATOR_OT_select_frame_thumb'
Registered Cutout Animation Tools with 14 modules
startup coa modal operator
read blend: /mnt/DATA/coa_tools/Sample Files/stip.blend
startup coa modal operator
areas don't share edge

`

This is in linux terminal, blender terminal does not give any messages

[ndee85]

Could it be that you had something else running in the background? I noticed that chrome or firefox can take up a lot of resources too. I tested it on my brothers computer yesterday. He has a midrange pc. It ran smoothly with 60 fps.

[alabd14313]

Please tell us about your OS, Graphics card and Blender version.

[blurymind]

I used it with all other software closed- still consistently bad framerate.
As said - its bad on both windows 7 and linux ubuntu wily.
I am on a 64 bit laptop, 4 gigs of ram, intel core duo, ati mobility radeon 4650 (1gb video ram).
Blender 2.76 from the blender website - nothing fancy.

I tried with both official ati drivers (on windows) and the open source ones (ubuntu). In both cases same lag.

I dont think that my specs are that bad because both spriter and godot play this sort of thing at 60fps.
Blender tends to give me much better framerate on actual 3d models.

For some reason stip and this addon are choking it to a halt when i hit the play button. I have no idea how to trace this bottleneck, but for now it makes the addon unusable for me.

[blurymind]

ok , I tested it on another laptop - windows 7 64, blender 2.77, 8gb ram, intel core i5, nvidia 550m,

Glsl is dropping frames and is laggy, eventhough blender registers it at 29/30 - very very laggy and slow.
Switching to multitexture I get a stable 30 fps, no lag, much faster/smoother and actually usable.
Unfortunately not my laptop, so..
This is definitely a GLSL problem with your addon. I don't understand - isnt glsl supposed to be faster?

[Kame7C0]

to make glsl faster try to disable color management in scene tab

On 21 March 2016 at 11:42, Todor Imreorov [email protected] wrote:

ok , I tested it on another laptop - windows 7 64, blender 2.77, 8gb ram,
intel core i5, nvidia 550m,

Glsl is dropping frames and is laggy, eventhough blender registers it at
29/30 - very very laggy and slow.
Switching to multitexture I get a stable 30 fps, no lag, much
faster/smoother.

This is definitely a GLSL problem with your addon. I don't understand -
isnt glsl supposed to be faster?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#10 (comment)

[blurymind]

disabled color management, still very slow on glsl

[blurymind]

Ok I managed to narrow it down even more- this is definitely a bug in the addon! When I disable coa tools addon in blender and open Stip - GLSL frame rate goes back to normal!

So something in the addon is causing a massive drop in framerate when in glsl mode.
Tested on two laptops - blender 2.76 and 2.77 - on windows and linux, nvidia and ati cards - all have this issue.

Are there any functions in the addon which run constantly in the background? Is anything specific to glsl in it?

[blurymind]

After testing it on the first laptop I am now certain that coa tools slows down playback massively in glsl. When coa addon is disabled, stip's animations run at normal time. When enabled , they run at about 20% with lots of lag and frame drop.

So the only way to use coa tools for me is to actually disable the addon whenever I need to preview my animations.

If it's running some background process, is it possible to tell it to stop it while blender is playing the animation? I wish there was a way to disable things one by one until we could find out where the bottleneck is.

[ndee85]

well.. it runs certain calculations in the background. like spritesheet calculations and stuff like that.
But I will see if I can somehow optimize that.

[ndee85]

@blurymind try to comment this lines out:
https://github.com/ndee85/coa_tools/blob/master/Blender/coa_tools/__init__.py#L140-L145
just put a # before them.
Then restart blender and see if there is any performance increase.

[ndee85]

you can also try to comment only line per line. from 142 - 145. And then please tell me which line makes the biggest framedrop.

[blurymind]

@ndee85 > I think we found it!
Commenting all the lines fixes all the lag issues and brings it to a stable 30 fps during playback!

uncommenting them back one by one:

• set_modulate_color(obj,context,obj.coa_modulate_color)-- takes about 12 frames per second from playback.
• set_z_value(context,obj,obj.coa_z_value)-- takes about 10 frames from the playback
• update_uv(bpy.context,obj)-- takes about 9 frames from the playback
• set_alpha(obj,bpy.context,obj.coa_alpha)-- takes about 17 frames from the playback and introduces the lag.

Strangely enough, commenting these lines does not have any effect on performance when in multitexture viewport mode. But multitexture mode gives me miserable 15 fps performance with or without the addon enabled.

I wonder if the update_sprites function gets disabled altogether when in multitexture. It runs in a way that does not affect performance in multitexture, but does in a big way in GLSL.

Is there perhaps a way to run the update_sprites function in a cheaper way? If I understand correctly coa tools runs it on each frame update. If it runs it on each loop (60^ fps?), perhaps a way to run it :

• depending on what animation framerate is set in blender
• only when an actual sprite update has happened instead of always.

I am not sure how it works, but would love to help figure out a way to optimize it!

[blurymind]

Ok here's another observation:

Uncommenting only:
https://github.com/ndee85/coa_tools/blob/master/Blender/coa_tools/__init__.py#L149-L150

gets me to 17 fps. I still lose 13 frames , but at least all the update functions work.
This seems to somehow be connected!

[alabd14313]

I confirm this lag.
May be a solution exists like fast preview. @abpy added a fast preview check box in tree addon that solved slow preview in a tree with a lot of bones and etc. I think it's method can solve this problem in coa tools, too.
improved-sapling-tree-generator
More details

[ndee85]

ok.. the calculations are needed to properly display all changes. But currently they always run on a sprite as soon as it has animation data. I will try to optimize it so such calculations only run if the values really change. Will have to look how to best solve this.

[blurymind]

If the addon only created the keyframes in the correct places instead of driving the changes, perhaps that would optimize things? For example if the user does a z-order change, the addon could simply add a keyframe where the user would add it to get the effect in blender if he wasnt using an addon. Z order, alpha, uv - you can do all those things by keyframing the actual object data directly instead of driving the changes

[ndee85]

@blurymind I would like to do that. And initially it was intended to be done that way. I have an update callback function for a property when it is changed. And if you change the value by hand, the update mehtod is run and calcs everything. But it seems to be a limitation of blender that an animation cannot trigger that update callback, which results in not having an update. Thats why I do it on a framechange.

[blurymind]

We could still do those things through the addon ui, it would just write the keyframes and let blender handle the changes on its own during playback. That would eliminate the need to use frame_change_post entirely

[ndee85]

@blurymind see post above. We wrote at the same time :)

[ndee85]

@blurymind
ok, I think I have found a working solution. I will create a second property for each property. (prop_name_last) where I store the last value. And I only make those calculations if the last value differs from the actual. That way I can make sure to run those calculations only when there is a change.

Now I am going to test it further, and can hopefully push the changes soon.

[blurymind]

Sounds good. Lets try it. :)
On 22 Mar 2016 09:05, "ndee85" [email protected] wrote:

@blurymind https://github.com/blurymind
ok, I think I have found a working solution. I will create a second
property for each property. (prop_name_last) where I store the last value.
And I only make those calculations if the last value differs from the
actual. That way I can make sure to run those calculations only when there
is a change.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#10 (comment)

[blurymind]

I just realized..The way it is now - after animating z order in coa tools, that animation is not going to work for users who dont have the plugin installed. Same for all the other update functions. If coa tools animated the object properties rather than driving them - the other advantage is that the produced blend file will work even if the addon is not installed on other people's machines.

[ndee85]

This will not be possible. I am doing more complex stuff than just driving one value. For spritesheet frame calculation I set the uv coords based on different values. This wouldn't be possible to key because there is some logic behind. Thats why the addon has to be installed and activated to run everything properly.

[ndee85]

@blurymind
ok. just pushed latest commits.
Please try out this new approach. Hopefully the framerate is better now.

Also please report back.

[blurymind]

I see. This is unfortunate :(
6bc059e
blender 2.68b:
The update has improved performance massively. From the previous 5 fps, now with the update I get 17-20 fps in GLSL.
It is still far from the stable 30 fps I get when I disable the addon (blender can get to 50 fps if I set the animation to 60fps and caps at 20fps with the addon enabled).

I wonder if there is a way to gain 10 more 👍

[blurymind]

Strangely enough now I get 20 fps in both multitexture and GLSL view mode. I would be willing to disable some of the features just to get a better framerate. 24 at least?

[blurymind]

blender 2.68b
Ok some more findings in the new version -
6bc059e
uncommenting things from 144-156 no longer earns any framerate increases. So is 160-161.

So we must be losing 10 frames elsewhere now?

This is getting very close to actually being usable for me! :) Good work, @ndee85

[blurymind]

Some more findings - using the addon with the new update on blender 2.77 makes a HUGE difference- so blender developers must have worked on increasing performance in the viewport too!

After the addon update.
blender 2.76b - 20 fps
blender 2.77 - 45-55 fps

This is on ubuntu 64 bit. I will test it on the other laptop tomorrow too.

[blurymind]

blender 2.77
I have now set framerate to 60 in order to see how far we can push coa tools.
Another finding - every time a z-order keyframe is triggered on stip's ear, it drops by 5-7 frames- jumping between 24 and 31 fps,
So any further optimizations would still go a long way in improving the workflow.

Even weirder- if I put keyframes on same ear with the z-ordering changes, on the alpha, my frame rate jumps between 26 and 39 fps.

Without any z-ordering or alpha keyframes, stip's animation runs between 45 and 56 fps.

[ndee85]

@blurymind
thanks for all the tests and infos. Good to hear this works much better in 2.77

From my side I cannot see any further optimizations at the moment, as for now the calculations are only done when needed.
When alpha of a sprite is changed I also need to refresh the scene otherwise the alpha changes won't be visible. When changing the location of a sprite this could happen too? I am not sure what blender does internally when the location of an object changes. Refreshing the scene drops the framerate which probably results in your jumping framerates.

As said, I don't think there is much room for further optimizations.
I would call this issue solved. :) What would you say?

[blurymind]

well, if I dont use z-ordering too much, I'd say that this gets me normal framerate now. When the coa-tools update keyframes decrease my framerate too much, I can also mute their channels.

I'd say mark this as solved and move on to more important stuff :)
From 5 fps to 45 fps, This is a massive gain in performance!

It would be good to keep a close eye on performance in the future too. If you find ways to improve it even further that is welcome too.