@Campbell Barton (campbellbarton), could you take a look, too? It seems like you know the subject well (T52827)

Hello, I tested with most of my files using bgl and it worked fine for me. I had only 1 file to test with bge.texture and bgl however. But this sounds ok to me.

I undo some of my changes. It may be best to leave the original Buffer structure untouched.

I added Tristan Porteries (panzergame), Ulysse Martin (youle) from the UPBGE team. I think the have more experience in this kind of things.

It really makes sense bgl.Buffer to have a Buffer Protocol.
I made some changes to the code.

Hi guys .. having issue when I enable 'Amaranth Toolset' .. any solution here??
Error code :

I added code that updated the node.mute value however, nothing happens. I'm guessing it is that the problem above still exists?

Is this the way to set that property? https://docs.blender.org/api/current/bpy.types.Node.html?highlight=mute#bpy.types.Node.mute

Is there any plan to work on this because this would be extremely useful.

Maybe I've got the wrong idea but the impression I got was that this change to PointerProperty was useful because it allowed search boxes to be more specific than just materials, objects, node trees etc... I can't think of any reason the user would ever need a search box that allows selecting of all node tree types but it would be useful to only allow a specific type of node group.

Ok… still, don’t think that was a good idea, like, at all… ID types are not virtual stuff like operators or render engines, they are data, stored in Blender file, they are kind of root of everything in Blender, so faking their subclassing in py sounds like a nice can of worms to me… Would have been so much cleaner to have registrable NodeTreeType classes instead! Anyway…

@Bastien Montagne (mont29), isn't it how custom node trees are supposed to work? You kind of subclass there.
Would be nice to at least prevent crashes, perhaps.

@Sergey Sharybin (sergey) yes, but… wait… since when is it valid to subclass an ID type? Subclassing ID types in Python… who ever allowed such an evil scheme? :((((((

@Bastien Montagne (mont29), is it something related on recent ID custom properties implemented for 2.79?

pfff… no actually, you nailed to point @Brecht Van Lommel (brecht)! I probably need to wake up a bit more here :(

@Bastien Montagne (mont29), didn't see your reply before I commented, if you think there's a bug here will let you handle it.

This is normal. Single precision floats only have 6-7 digits of precision, so for large numbers like in the last column there will be loss of precision. Python uses double precision but for Blender itself this would have a significant performance / memory impact.

Wooo… ugly! :/

This isn't supported https://docs.blender.org/api/blender_python_api_current/info_gotcha.html#strange-errors-using-threading-module

hi @Mikhail Rachinskiy (alm)
the use of duplicate class names has been restricted, we plan to, after 2.79 release, to address these issues.
please note these issues will not be in 2.79 release but are in nightly builds.
it's good to be aware of this issue, i'm trying to keep addons repo clean for 2.79 release, then come in and fix all the issues in nightly, whilst not polluting addons master with fixes that might be conflicting with release.
not closing the task as we may for future ref.

Thanks, so I guess we can consider the initial issue as fixed.

I tested the following:
retested script on blender 2.79 from nightly buildbot.
BMESH fails -- get incorrect mesh ( mesh ends up with large, non-manifold hole ).
CARVE works, no crash on OSX.

Please always try the latest build from our buildbot.

Can get the script to work in 2.76b, but not in 2.77a.

Should be resolved by the previous commit.