I've committed now so it goes into 2.78, but will add some unit tests still.
With an AMD Radeon R9 380 using the AMDGPU-PRO drivers on Linux, this patch is causing the BMW scene to render almost 20% faster. That's quite strange but I couldn't find any render regressions.
I don't find XML fun to work with, plus it's either quite a code-duplicate to have xml_read_shader_graph() available on tests or involves some deeper code refactoring to get code shared across standalone application and unit tests. Don't feel like doing bigger refactoring of this area at this moment since ideally we'll need to lay down some common API for that so we don't glue unit tests to just XML reader.
What do you think about using XML for specifying the graph? I think it would be relatively simple to extract xml_read_shader_graph() so it can be used here, and eventually we should be able write such XML files as well making it easier to generate more complicated tests, and tests covering other types of nodes.
Remove some unintended changes.
Refactored to make folding logic easier to follow, at least in my opinion this
is easier to read and verify to be correct.
@Brecht Van Lommel (brecht), slop is coming from Blender's guarded alloc. Here it's basically, difference between how much memory you really use and how much the system allocated you for your request. So foe example, if you need only one extra float attribute allocating in chunks of sizeof(ShaderClosure) might cause quite some wasted memory. So the question here: how much it's a real issue and how does this affect on overall memory consumption?
@Campbell Barton (campbellbarton) I used Curve decimate. I just mentioned dissolve in the post from Jul 9. because you proposed to use dissolve and I wanted to show the shortcomings. I can make a report for it on the tracker if you want.
Tested again on CPU and CUDA, looks good.
Updated diff with the wrong branch..
Fix OpenCL issues, hopefully ready to commit now.
Actually I am not sure if this is the way to go, because movie makers and me have this problem:
10 days with no update, closing due to lack of information to investigate, can reopen if we get more information about the specific setup this error happens in.
10 days without reply, let's assume this problem was fixed.
You can also test with File > Load Factory Settings to see if any non-default Blender setting or addon is causing problems, and check if you changed any settings in the Wacom drivers that might have an effect on Blender.
For OSL I agree we can render twice.
simple fix for operator error, removed from menu, not sure why that failed, but original design was to run this modal from the panel.
added :change tabs category to addons preferences, imo this should be mandatory for all panel addons.
Still needs fixes for OpenCL.
Apart from possible code style tweak, lgtm.
- Add DNA_struct_elem_find check
- Cleanup: Remone unused code
- Cleanup: Rename property is_closed to draw_cyclic
- Change operator thickness_apply to use only active layer
- Cleanup: Fix comment
- Fix missing pie menu changes after rename arrange parameter in previous commit
About change color, this operator must change all layers, not only active. What you propose, change the name of the operator?
The reason to create the join y mainly due fill. For example, if you draw a comic human face and the strokes are not continuous (for artistic reasons), if you don't join with invisible lines you cannot fill. The join speed up a lot the filling process.
- Rename AnimStoreRNA -> PathResolvedRNA, remove length member
I've added a second .zip (bug_report_2.zip) that contains a revised version of the add-on used for showcasing the bug that adds a section under the Object panel so you try setting keyframes for custom properties within PropertyGroup/CollectionPropertys of Objects as well as PoseBones (it works for Objects, but not for PoseBones).
Some more changes, my previous comment still applies.
Second round of (partially really rough) review. Some more notes:
- Join OP: I'm not really convinced about this operator. What is the benefit of having 2 strokes joined? If it's just for having them share some settings (thickness, color, etc), wouldn't a copy_settings operator make more sense? For duplicating there's still GPENCIL_OT_duplicate_move. Also note that this breaks the 1 stroke == 1 continuous line idea, making operations such as cyclic_toggle and select_linked behave glitchy.
- Color OPs: These currently apply to all layers. Either they should affect only the active one, or they should be moved to a different place (speaking about stroke_lock_color and palette_lock_layer).
- @Joshua Leung (aligorith), noticed some functions, esp. in BKE_gpencil.h don't use the conventional prefix. Is that intentional? (Would propose to cleanup after branch landed)
Hmm. I went to builder.blender.org and 2.77 is the latest build version. What am I missing?
Fri, Jul 29
For sake of archives...
Thanks will update and commit! :)
This is also affected by the type of Twisting used by your path - but yes, all in all this is instability we cannot really fix with current constraint design. Thanks for the report anyway.
Add expand_doit calls in readfile.c to match linking fixes in rB8e004062612e.
Update diff file
- Rename close operator and rewrite to use cyclic drawing instead of inserting new points
- Cleanup: Use editable_gpencil_layer context iterator in join strokes operator
- Cleanup: Use editable_gpencil_layer context iterator in flip strokes operator
- Fix error when joining strokes in different layers
- Cleanup: Rename and recode arrange stroke operator
- Fix compiling Blenderplayer
- Use GHash in GP merge OP to avoid O(n^2) lookups
- Cleanup: Unused var
- Cleanup stroke_cyclic_toggle OP
- Minor UI Cleanup
- Use ED_ prefix for externally used editor functions
- Hide layer colors in dope sheet
- Add Join&Copy button to UI panel
- Minor (uberpicky) optimization to new GPencil freeing functions