Sure ! :D
It only works with local parameters of an object (I renamed the method
accordingly) that's enough for me right now. I would need to check what it
looks like when the driver is not a local parameter.
Also I made the collection unique because one parameter might be involved
several time on the same expression.
Thanks again Alan, it really nice to get this performance !
def getExpressionsDrivenByLocalParameter( obj, param="posx" ):
stack = xsiUtils.DataRepository.GetConnectionStackInfo(
obj.Parameters(param) )
expressions = xsiFactory.CreateObject("XSI.Collection")
expressions.Unique = True
xmlRoot = etree.fromstring(stack)
for xmlCnx in xmlRoot.findall('connection'):
if xmlCnx.find('type').text == 'out' and xmlCnx.find('localparameter') is
not None and xmlCnx.find('localparameter').text == param:
item = xmlCnx.find('object').text
if item.endswith('.Expression'):
expressions.AddItems(item)
return expressions
On 30 July 2012 11:42, Alan Fregtman <[email protected]> wrote:
> Care to share your modifications? :)
>
>
> On Mon, Jul 30, 2012 at 2:38 PM, Jeremie Passerin <[email protected]>wrote:
>
>> Really nice guys thanks a lot for the inputs !
>>
>> Just one note on Alan's code. His current method returns all the
>> expression driven by an object not by a specific parameter.
>> I had to slightly adapt the code to get the specific local parameter I'm
>> looking for !
>>
>> really happy, this is so fast now !
>>
>>
>>
>> On 29 July 2012 16:49, jo benayoun <[email protected]> wrote:
>>
>>> Alan, you're opening a new interesting way. :)
>>>
>>> Alok, DOD is not a pattern but a paradigm as OOP. If you have the time
>>> to take a look deeper at it, you will understand what I am saying when I
>>> reject any ideas concerning further querying on the data.
>>>
>>> I don't remember where I've read this (and I regret), someone was
>>> publishing simple profiling results of regular python code and was
>>> highlighting that 70 perc of the ressources were exclusively consumed by
>>> dictionaries and this tends to grow because people are more and more
>>> seduced by the convenience of those objects.
>>> By replacing those by simpler data structures or other mechanisms, speed
>>> performances have been improved considerably as well as CPU and memory
>>> usage (something like 2 times faster if I remember correctly).
>>> I am really worried when reading "They may have more memory
>>> requirements, but these days, it really is not a problem." because this
>>> is clearly for me an excuse for developers to do code and not good code.
>>> Personally, I don't consider educational material even from Google
>>> engineers as a reference as it's educational.
>>> And yes, I am capable of beating appending on hash table in worst case
>>> with a single linked list. Look at Python C implementation to see how they
>>> resolve collisions.
>>>
>>> But even considering the query as important, nothing avoid you to pass
>>> parameter by parameter to the function to control the flow of your code.
>>> Like that no need of any further querying.
>>> I've done some other tests today and friday and I am surprised that your
>>> function produce wrong results on some models (I didn't find the why yet).
>>> But still, considering everything which has been said, here is what I
>>> got as last results on my machine at home for a model with still thousand
>>> of expressions and launching a search for 11 parameters of the same ppg.
>>> (some of those parameters are driving custom operators, that's why there is
>>> only 4 expressions).
>>>
>>> # INFO : jerems took 16.2187956328 and find 4 expressions.
>>> # INFO : mine took 1.33966050716 and find 4 expressions.
>>> # INFO : aloks took 12.9062194445 and find 0 expressions.
>>> # INFO : alans took 0.297864204575 and find 4 expressions.
>>>
>>> Anyways, I think we have all our own way of coding and I respect that.
>>> It's always a pleasure to share with you!
>>> =)
>>> -- Jo
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2012/7/29 Eric Thivierge <[email protected]>
>>>
>>>> Good stuff Alan. Thanks for the tip. Must not be reading the docs as
>>>> thoroughly as I should. :)
>>>>
>>>>
>>>> --------------------------------------------
>>>> Eric Thivierge
>>>> http://www.ethivierge.com
>>>>
>>>>
>>>> On Mon, Jul 30, 2012 at 8:33 AM, Alan Fregtman <[email protected]
>>>> > wrote:
>>>>
>>>>> If you ever looked at how to parse the operator stack you must've seen
>>>>> the doc page for *ConstructionHistory*:
>>>>>
>>>>> http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/index.html?url=si_om/ConstructionHistory.html,topicNumber=si_om_ConstructionHistory_html
>>>>>
>>>>> Third paragraph under Description:
>>>>> *"The construction history is one example of the more general concept
>>>>> of "Connection Stack", see
>>>>> DataRepository.GetConnectionStackInfo<http://download.autodesk.com/global/docs/softimage2012/en_us/sdkguide/si_om/DataRepository.GetConnectionStackInfo.html>
>>>>> for
>>>>> details."*
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jul 29, 2012 at 6:02 PM, Eric Thivierge
>>>>> <[email protected]>wrote:
>>>>>
>>>>>> Black magic! I've never even heard of that object. :(
>>>>>>
>>>>>> --------------------------------------------
>>>>>> Eric Thivierge
>>>>>> http://www.ethivierge.com
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 30, 2012 at 7:32 AM, Alan Fregtman <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> *You're all forgetting the ConnectionStack.* It tells you what's
>>>>>>> connected under the hood. *No need to scan through all expressions
>>>>>>> in the scene!*
>>>>>>>
>>>>>>>
>>>>>>> import xml.etree.ElementTree as ET
>>>>>>> def getExpressionsDrivenByParameter( param ):
>>>>>>> stack = XSIUtils.DataRepository.GetConnectionStackInfo(param)
>>>>>>>
>>>>>>> expressions = XSIFactory.CreateObject('XSI.Collection')
>>>>>>> xml = ET.fromstring(stack)
>>>>>>> for conn in xml.findall('connection'):
>>>>>>> if conn.find('type').text == 'out':
>>>>>>> item = conn.find('object').text
>>>>>>> if item.endswith('.Expression'):
>>>>>>> expressions.AddItems(item)
>>>>>>>
>>>>>>> return expressions
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It took 4.5s on my laptop to find 10,752 expressions that were
>>>>>>> pointing to one single parameter. Fast enough for ya? :) -- In a less
>>>>>>> ludicrous use case, it's pretty much instant.
>>>>>>>
>>>>>>> -- Alan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 28, 2012 at 11:51 AM, Alok Gandhi <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi Jeremy,
>>>>>>>>
>>>>>>>> I missed this first time but to make it more elegant you (not a
>>>>>>>> speed up) you can even do:
>>>>>>>> def getExpressionsDrivenByParameter( param ):
>>>>>>>> return PARAM_EXPR_DICT.get(param.FullName)
>>>>>>>>
>>>>>>>> which is exactly the same as before but cleaner code,
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
