Convert bConstraintTypeInfos from static array to listbase conversion #30903

New Issue

Dan Eicher · 2012-04-11T01:29:03+02:00

Dan Eicher commented

2012-04-11 01:29:03 +02:00

%%%Instead of using:

static bConstraintTypeInfo *constraintsTypeInfo[NUM_CONSTRAINT_TYPES];

use:

ListBase constraintsTypeInfoList;

with all the fun stuff that makes it work.

99.99% functionally the same, the only change is CTI_PYTHON doesn't show up in the generated EnumPropertyItem list since it's a) broken and b) will be shortly made to work again.%%%

%%%Instead of using: static bConstraintTypeInfo *constraintsTypeInfo[NUM_CONSTRAINT_TYPES]; use: ListBase constraintsTypeInfoList; with all the fun stuff that makes it work. 99.99% functionally the same, the only change is CTI_PYTHON doesn't show up in the generated EnumPropertyItem list since it's a) broken and b) will be shortly made to work again.%%%

Dan Eicher commented

2012-04-11 01:29:03 +02:00

Changed status to: 'Open'

Joshua Leung commented

2012-04-11 08:04:12 +02:00

%%%Originally, I was almost poised to reject this, but after reading the patch, I think it could be workable with a few tweaks :)

My main concerns are:

The speed hit we get as a result of using ListBase vs array AND performing a check on each item everytime we do a lookup. Admittedly, this is probably a very small value and there are far more areas of Blender which suffer from this already. But, given that bones may typically have about 3 constraints each and there being some 600-700 of these, then I'm curious if there's any speed hit for such rigs.
I'm not really a fan of opening up access to the list of constraint typeinfo via the BKE_constraint header.... yet
What's your plan for PyConstraints? :)%%%

%%%Originally, I was almost poised to reject this, but after reading the patch, I think it could be workable with a few tweaks :) My main concerns are: 1) The speed hit we get as a result of using ListBase vs array AND performing a check on each item everytime we do a lookup. Admittedly, this is probably a very small value and there are far more areas of Blender which suffer from this already. But, given that bones may typically have about 3 constraints each and there being some 600-700 of these, then I'm curious if there's any speed hit for such rigs. 2) I'm not really a fan of opening up access to the list of constraint typeinfo via the BKE_constraint header.... yet 3) What's your plan for PyConstraints? :)%%%

Campbell Barton commented

2012-04-13 08:02:22 +02:00

%%%why not just re-allocate the array (for py constraints)%%%

Dan Eicher commented

2012-04-13 12:29:35 +02:00

%%%1) The speed hit we get as a result of using ListBase vs array AND performing a check on each item everytime we do a lookup. Admittedly, this is probably a very small value and there are far more areas of Blender which suffer from this already. But, given that bones may typically have about 3 constraints each and there being some 600-700 of these, then I'm curious if there's any speed hit for such rigs.

Eh, didn't know they did that... and here I was thinking that it might be a little tricky to figure out which constraints needed to be updated if one was un/re-registered.

Probably be easiest to just realloc the array like Campbell suggested (with a little magic for changed/removed types) so the only real slowdown would be looking up non-built in types -- which would be a lot slower anyway having to go through the python interpreter.

I'm not really a fan of opening up access to the list of constraint typeinfo via the BKE_constraint header.... yet

Yeah, it's pretty pointless unless you need to access it for something like making a dynamic enum of constraints for the UI or adding new types to the list.

What's your plan for PyConstraints? :)

Really depends on how well this goes over...

The basic plan is just take the RenderEngine code and make it work since it pretty much solves all the difficult problems already.%%%

%%%1) The speed hit we get as a result of using ListBase vs array AND performing a check on each item everytime we do a lookup. Admittedly, this is probably a very small value and there are far more areas of Blender which suffer from this already. But, given that bones may typically have about 3 constraints each and there being some 600-700 of these, then I'm curious if there's any speed hit for such rigs. Eh, didn't know they did that... and here I was thinking that it might be a little tricky to figure out which constraints needed to be updated if one was un/re-registered. Probably be easiest to just realloc the array like Campbell suggested (with a little magic for changed/removed types) so the only real slowdown would be looking up non-built in types -- which would be a lot slower anyway having to go through the python interpreter. 2) I'm not really a fan of opening up access to the list of constraint typeinfo via the BKE_constraint header.... yet Yeah, it's pretty pointless unless you need to access it for something like making a dynamic enum of constraints for the UI or adding new types to the list. 3) What's your plan for PyConstraints? :) Really depends on how well this goes over... The basic plan is just take the RenderEngine code and make it work since it pretty much solves all the difficult problems already.%%%

Dan Eicher commented

2014-03-22 19:45:59 +01:00

Removed subscriber: @dna-7

Campbell Barton commented

2015-04-03 13:49:10 +02:00

Changed status from 'Open' to: 'Archived'

Campbell Barton closed this issue

2015-04-03 13:49:10 +02:00

Campbell Barton commented

2015-04-03 13:49:10 +02:00

We can always apply this but seems its not really needed/important.

closing.

We can always apply this but seems its not really needed/important. closing.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Convert bConstraintTypeInfos from static array to listbase conversion #30903