Re: Slow Reading / Writing Envelope.Weights.Array

2013-06-03 Thread Jeremie Passerin
woow ! Pretty cool Jo ! I wish I could do python like that. That would
speed up some of my tools ;-)


On 1 June 2013 20:22, Eric Thivierge  wrote:

> Yes the performance of the Array property. Interacting with it is
> abysmally slow on meshes with large point counts and large number of items
> used in its envelope. Thanks for the thorough examples exploring the other
> aspects. Should be good stuff to take a look at and learn from.
>
> Eric T.
>
>
> On Sat, Jun 1, 2013 at 10:18 PM, jo benayoun  wrote:
>
>> Hey Eric,
>> I must confess that I am quite confused by this thread as I can't figure
>> out what this is really about...
>>
>> * performance of the Array property?
>>
>
>
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-06-01 Thread Eric Thivierge
Yes the performance of the Array property. Interacting with it is abysmally
slow on meshes with large point counts and large number of items used in
its envelope. Thanks for the thorough examples exploring the other aspects.
Should be good stuff to take a look at and learn from.

Eric T.


On Sat, Jun 1, 2013 at 10:18 PM, jo benayoun  wrote:

> Hey Eric,
> I must confess that I am quite confused by this thread as I can't figure
> out what this is really about...
>
> * performance of the Array property?
>




Eric Thivierge
http://www.ethivierge.com


Re: Slow Reading / Writing Envelope.Weights.Array

2013-06-01 Thread jo benayoun
Hey Eric,
I must confess that I am quite confused by this thread as I can't figure
out what this is really about...

* performance of the Array property?

  >>> env_weights = envelope.Weights.Array  # 7.18513235319

  This is something on which we don't really have control over... well,
seems like we're doomed with that =( ...


* fastest way to turn ((D1P1, D1Pn), ..., (DnP1, DnPn)) into [P1D1, PnDn,
..., PnD1, PnDn]?

  XSI man with local sub refinement (81331 vtx, 126 defs)

  not much better...
  >>> w1 = [weights[j][i] for i in range(len(weights[0])) for j in
range(len(weights))]  # 8.70612062111
  >>> w2 = list(itertools.chain.from_iterable(itertools.izip(*weights)))
  # 5.21891196087
  >>> assert(w1 == w2)

  >>> w3 = itertools.chain.from_iterable(itertools.izip(*weights)))
 # 0.0

  ...way better! Actually, timing this kind of meaningless (no context)
operations is quite boring and useless...
  As I don't see the point of those alone:

  >>> [list(x) for x in weights] # turning a tuple of tuples into a tuple
of lists?
  >>> map(list, weights)

  Timing the algorithms is much funnier...

* using numpy?

  Considering the Array property is half responsible of the slowness, not
sure how numpy would help... eventhough,
  the XSI man example could I think be considered as a worst-case scenario
as this is not common to see so much
  dense meshes rigged.  But even if we are meeting those cases once in a
while, I think a few seconds are worth
  than introducing dependencies on an external library such as numpy as it
is quite inappropriate to talk about it
  in such context (we are not talking about arrays of gigabytes of
datas...).


In 90% of the cases, just refactoring the code will give ya the boost you
need! before considering numpy or other languages, try to refactor the
code...

Using the code Jeremie posted above and the XSI man example:

I am getting (jeremie's):
  -- all points
  envelope.Weights.Array:  7.24001892257 # half of getWeights
  get_weights: 14.6793240571
  average_weights: 97.3035831834
  list(weights):   1.6430682
  total:   113.65285342
  -- xrange(200, 5000) points
  envelope.Weights.Array:  7.13410343853 # half of getWeights
  get_weights: 16.3542267175
  average_weights: 9.32082265267
  list(weights):   1.5987448828
  total:   27,322880867

refactored:
  -- all points
  envelope.Weights.Array:  7.17315390541
  get_weights: 7.17847566392 # no more waste here
  average_weights: 12.0701456704
  list(weights):   4.16878212485
  total:   23.4396892319 ~5X faster
  -- xrange(200, 5000) points
  envelope.Weights.Array:  7.03594689191 # no more waste here
  get_weights: 7.16215152683
  average_weights: 5.33362318853
  list(weights):   3.63788132247
  total:   16,1539661472 ~2X faster

...with my configuration! this is just to demonstrate my point, not trying
to figure out who has the longest... =)

In Jeremie's, the design is quite limited and performances will be worst in
a library where the function may be re-used many times within the same
process.
You basically just get the weights, do the operation and write out
(everytime).

In the code below, you 're only keeping a generator on the stack (no actual
datas -> less memory) which will be passed along functions (in that case
though we had to unroll it for computing the averages), and the design let
you apply multiple operations to the weights before even setting back the
envelope.Weights.Array property (kinda of ICE pattern) without affecting
performances and even improving them...

  def get_weights(envelope):
  """Get envelope weights.
  ((D1P1, D1Pn), ..., (DnP1, DnPn)) -> [D1P1, D1Pn, ..., DnP1, DnPn]
  """
  weights = envelope.Weights.Array
  return itertools.chain.from_iterable(itertools.izip(*weights))

  def average_weights(envelope, weights, points=all):
  """Compute average of given points.
  takes and returns:
  [P1D1, P1Dn, ..., PnD1, PnDn]
  """
  deformer_count = envelope.Deformers.Count

  if points is all:
  points_count =
envelope.Parent3DObject.ActivePrimitive.Geometry.Points.Count
  points = xrange(points_count)
  else:
  points_count = len(points)
  points = frozenset(points)

  #  Compute the average by summing up all weights of points.
  weights = tuple(weights)  #  flatten it (we have to in this case)
  averages = [sum(weights[p * deformer_count + d] for p in points) /
points_count
  for d in
xrange(deformer_count)]

  # groupby pattern
  weights_per_point = itertools.izip(*([iter(weights)] *
deformer_count))

  enum = enumerate(weights_per_point)
  it = ((i in points and averages or w) for (i, w) in enum)
  return itertools.chain.from_iterable(it)

  

Re: Slow Reading / Writing Envelope.Weights.Array

2013-06-01 Thread Bartosz Opatowiecki

W dniu 2013-05-31 15:29, Eric Thivierge pisze:

I really seems the slowness is simply accessing envelopeOp.Weights.Array.

Indeed, you are right.


Bartek Opatowiecki


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Raffaele Fragapane
The trick to that is numpy.asarray(aWeights) ;)


On Sat, Jun 1, 2013 at 1:15 PM, Eric Thivierge  wrote:

> It's very dense geo probably no where near the gorgo though. It's just the
> Softimage default xsi man armored. The body mesh local subdivided and
> fetching from there.
>
> In my previous posts it's simply the data fetch that is taking 6 seconds.
> The other processes aren't taking too long regardless. I was surprised
> because I remember the interaction on the dinos with your tools.
> On May 31, 2013 8:00 PM, "Raffaele Fragapane" 
> wrote:
>
>> You should use numpy regardless, because all operations you will need to
>> work on after you pull will be A TON faster. So start from there.
>> As for the time it takes, what's the size of the table we're talking
>> about? The data fetching stage for the HR Gorgo (the only one I tested when
>> I refactored the weight handling tools) was shy of two seconds. You know
>> the boxes and assets :)
>>
>> You working with a heavier meshes and deformer counts than that?
>> That was a straight fetch and cast to numpy.
>>
>>
>> On Fri, May 31, 2013 at 8:44 AM, Eric Thivierge wrote:
>>
>>>
>>> On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi wrote:
>>>
 Maybe you can still get some optimization using numpy, I think. Throw
 your weights array directly into numpy. It is worth a try at least.
>>>
>>>
>>> I'll give it a shot tomorrow. :)
>>>
>>> 
>>> Eric Thivierge
>>> http://www.ethivierge.com
>>>
>>
>>
>>
>> --
>> Our users will know fear and cower before our software! Ship it! Ship it
>> and let them flee like the dogs they are!
>>
>


-- 
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Eric Thivierge
It's very dense geo probably no where near the gorgo though. It's just the
Softimage default xsi man armored. The body mesh local subdivided and
fetching from there.

In my previous posts it's simply the data fetch that is taking 6 seconds.
The other processes aren't taking too long regardless. I was surprised
because I remember the interaction on the dinos with your tools.
On May 31, 2013 8:00 PM, "Raffaele Fragapane" 
wrote:

> You should use numpy regardless, because all operations you will need to
> work on after you pull will be A TON faster. So start from there.
> As for the time it takes, what's the size of the table we're talking
> about? The data fetching stage for the HR Gorgo (the only one I tested when
> I refactored the weight handling tools) was shy of two seconds. You know
> the boxes and assets :)
>
> You working with a heavier meshes and deformer counts than that?
> That was a straight fetch and cast to numpy.
>
>
> On Fri, May 31, 2013 at 8:44 AM, Eric Thivierge wrote:
>
>>
>> On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi wrote:
>>
>>> Maybe you can still get some optimization using numpy, I think. Throw
>>> your weights array directly into numpy. It is worth a try at least.
>>
>>
>> I'll give it a shot tomorrow. :)
>>
>> 
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Raffaele Fragapane
You should use numpy regardless, because all operations you will need to
work on after you pull will be A TON faster. So start from there.
As for the time it takes, what's the size of the table we're talking about?
The data fetching stage for the HR Gorgo (the only one I tested when I
refactored the weight handling tools) was shy of two seconds. You know the
boxes and assets :)

You working with a heavier meshes and deformer counts than that?
That was a straight fetch and cast to numpy.


On Fri, May 31, 2013 at 8:44 AM, Eric Thivierge wrote:

>
> On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi wrote:
>
>> Maybe you can still get some optimization using numpy, I think. Throw
>> your weights array directly into numpy. It is worth a try at least.
>
>
> I'll give it a shot tomorrow. :)
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>



-- 
Our users will know fear and cower before our software! Ship it! Ship it
and let them flee like the dogs they are!


RE: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Matt Lind
Have you tried a GridData object?  It would abstract the problem away from 
Python and be flexible enough to pass around between commands written in 
various languages.  I usually use the GridData object because it simplifies 
coding and has a few methods specifically for working with column data making 
it easier to manipulate weight values per deformer.  You do give up some speed 
compared to other available methods in the other languages, but in your 
situation the GridData might perform faster than anything available in Python.

The snippet below runs in Jscript in about 4 seconds on my 5-year old computer. 
 Will probably run faster on yours.

// JScript
function main()
{
var oObject = Selection(0);

var oEnvelope = oObject.Envelopes(0);

// Get weight values from envelope
var oWeightData = XSIFactory.CreateGridData();
oWeightData.Data = oEnvelope.Weights.Array;

// Modify the weight values for the first deformer
var aWeightValues = new Array( oEnvelope.Weights.Count );
oWeightData.SetColumnValues( 0, aWeightValues );

// Update the envelope with modified weight values
oEnvelope.Weights.Array = oWeightData.Data;
}






From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge
Sent: Friday, May 31, 2013 6:29 AM
To: softimage@listproc.autodesk.com
Subject: Re: Slow Reading / Writing Envelope.Weights.Array

This takes even longer ~ 14 seconds. I really seems the slowness is simply 
accessing envelopeOp.Weights.Array.

Any devs paying attention that could confirm that this is just a slow call? 
Would doing these operations in C++ be the only way to speed them up?

# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

envelopeOp = sel(0).Envelopes(0)
weightsTuple = envelopeOp.Weights.Array
weights = [weightsTuple[j][i] for i in xrange(len(weightsTuple[0])) for j in 
xrange(len(weightsTuple))]

timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your code."

log(msg)
# =




Eric Thivierge

===

Character TD / RnD

Hybride Technologies


On 31/05/2013 3:00 AM, Bartosz Opatowiecki wrote:
Also:
def getWeights(envelopeOp):
 weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j in 
range(len(weightsTuple))]

xrange should be more efficient than range



Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Eric Thivierge
I don't necessarily need to pass them back to Python honestly so this is 
probably the plan for now.


 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 31/05/2013 1:09 PM, Steven Caron wrote:
ya, if performance is key i would use cpp or vb and make a command... 
but you might run right back into issues passing the data back into 
python.



On Fri, May 31, 2013 at 6:29 AM, Eric Thivierge 
mailto:ethivie...@hybride.com>> wrote:


Would doing these operations in C++ be the only way to speed them up?





Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Steven Caron
ya, if performance is key i would use cpp or vb and make a command... but
you might run right back into issues passing the data back into python.


On Fri, May 31, 2013 at 6:29 AM, Eric Thivierge wrote:

>  Would doing these operations in C++ be the only way to speed them up?
>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Alan Fregtman
Here's another way to read weights. Not sure if it's faster. Probably not.

xsi = Application
obj = xsi.Selection(0)
envCls = obj.ActivePrimitive.Geometry.Clusters(0)
envProp = envCls.Properties(0)
# Envelope ICE attrs:# EnvelopeWeights, EnvelopeWeightsPerDeformer,
EnvelopeDeformerIndices, NbDeformers

data = envProp.GetICEAttributeFromName("EnvelopeWeights").DataArray2D
indices = envProp.GetICEAttributeFromName("EnvelopeDeformerIndices").DataArray2D
nbdef = envProp.GetICEAttributeFromName("NbDeformers").DataArray[0]print
"Deformer count: %s" % nbdef
for i,val in enumerate(zip(indices, data)):
idx, val = val
print "Point #%s indices:(%s) - values:(%s)" % (i,idx,val)


Beware that letting it print everything may be a terrible idea with a lot
of points. :p May wanna put in a "if i > 100: break" line in there.





On Fri, May 31, 2013 at 10:50 AM, Martin  wrote:

> Have you tried VBScript?
> I usually do my envelope related scripts in VBScript because it is way
> faster than JScript (my main scripting language).
>
> VBScript
> selection(0).Envelopes(0).Weights.Array
>
> is faster than
>
> JScript
> new VBArray( selection(0).Envelopes(0).Weights.Array )
>
> and way way more faster than
>
> JScript
> selection(0).envelopes(0).Weights.Array.toArray()
>
> I don't use Python, but in my tests, Python has been the slowest of the
> three when dealing with envelopes, subcomponent arrays and a bunch of loops.
>
> M.Yara
>
>
> On Fri, May 31, 2013 at 10:29 PM, Eric Thivierge 
> wrote:
>
>>  This takes even longer ~ 14 seconds. I really seems the slowness is
>> simply accessing envelopeOp.Weights.Array.
>>
>> Any devs paying attention that could confirm that this is just a slow
>> call? Would doing these operations in C++ be the only way to speed them up?
>>
>>
>> # Python
>> # =
>> from platform import system as OStype
>> from time import clock
>>
>> xsi = Application
>> log = xsi.LogMessage
>> sel = xsi.Selection
>>
>> start_time = clock()
>>
>> envelopeOp = sel(0).Envelopes(0)
>> weightsTuple = envelopeOp.Weights.Array
>> weights = [weightsTuple[j][i] for i in xrange(len(weightsTuple[0])) for j
>> in xrange(len(weightsTuple))]
>>
>>
>> timeTaken = clock() - start_time
>>
>> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
>> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
>>
>> log(msg)
>> # =
>>
>>
>> Eric Thivierge
>> ===
>> Character TD / RnD
>> Hybride Technologies
>>
>>
>> On 31/05/2013 3:00 AM, Bartosz Opatowiecki wrote:
>>
>> Also:
>>
>>  def getWeights(envelopeOp):
>>weightsTuple = envelopeOp.Weights.Array
>>  return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j
>> in range(len(weightsTuple))]
>>
>> xrange should be more efficient than range
>>
>>
>>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Bartosz Opatowiecki

What do you mean by "high point count / high deformer count meshes." ?

Bartek Opatowiecki

W dniu 2013-05-31 15:29, Eric Thivierge pisze:
This takes even longer ~ 14 seconds. I really seems the slowness is 
simply accessing envelopeOp.Weights.Array.


Any devs paying attention that could confirm that this is just a slow 
call? Would doing these operations in C++ be the only way to speed 
them up?


# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

envelopeOp = sel(0).Envelopes(0)
weightsTuple = envelopeOp.Weights.Array
weights = [weightsTuple[j][i] for i in xrange(len(weightsTuple[0])) 
for j in xrange(len(weightsTuple))]


timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your code."

log(msg)
# =
  
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
  
On 31/05/2013 3:00 AM, Bartosz Opatowiecki wrote:

Also:

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j 
in range(len(weightsTuple))]


xrange should be more efficient than range






Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Martin
Have you tried VBScript?
I usually do my envelope related scripts in VBScript because it is way
faster than JScript (my main scripting language).

VBScript
selection(0).Envelopes(0).Weights.Array

is faster than

JScript
new VBArray( selection(0).Envelopes(0).Weights.Array )

and way way more faster than

JScript
selection(0).envelopes(0).Weights.Array.toArray()

I don't use Python, but in my tests, Python has been the slowest of the
three when dealing with envelopes, subcomponent arrays and a bunch of loops.

M.Yara


On Fri, May 31, 2013 at 10:29 PM, Eric Thivierge wrote:

>  This takes even longer ~ 14 seconds. I really seems the slowness is
> simply accessing envelopeOp.Weights.Array.
>
> Any devs paying attention that could confirm that this is just a slow
> call? Would doing these operations in C++ be the only way to speed them up?
>
>
> # Python
> # =
> from platform import system as OStype
> from time import clock
>
> xsi = Application
> log = xsi.LogMessage
> sel = xsi.Selection
>
> start_time = clock()
>
> envelopeOp = sel(0).Envelopes(0)
> weightsTuple = envelopeOp.Weights.Array
> weights = [weightsTuple[j][i] for i in xrange(len(weightsTuple[0])) for j
> in xrange(len(weightsTuple))]
>
>
> timeTaken = clock() - start_time
>
> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
>
> log(msg)
> # =
>
>
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
>
> On 31/05/2013 3:00 AM, Bartosz Opatowiecki wrote:
>
> Also:
>
> def getWeights(envelopeOp):
>   weightsTuple = envelopeOp.Weights.Array
>  return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j in
> range(len(weightsTuple))]
>
> xrange should be more efficient than range
>
>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Eric Thivierge
This takes even longer ~ 14 seconds. I really seems the slowness is 
simply accessing envelopeOp.Weights.Array.


Any devs paying attention that could confirm that this is just a slow 
call? Would doing these operations in C++ be the only way to speed them up?


# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

envelopeOp = sel(0).Envelopes(0)
weightsTuple = envelopeOp.Weights.Array
weights = [weightsTuple[j][i] for i in xrange(len(weightsTuple[0])) for 
j in xrange(len(weightsTuple))]


timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your code."

log(msg)
# =

 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 31/05/2013 3:00 AM, Bartosz Opatowiecki wrote:

Also:

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j 
in range(len(weightsTuple))]


xrange should be more efficient than range




Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-31 Thread Bartosz Opatowiecki

Also:

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j in 
range(len(weightsTuple))]


xrange should be more efficient than range

W dniu 2013-05-31 00:44, Eric Thivierge pisze:


On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi > wrote:


Maybe you can still get some optimization using numpy, I think.
Throw your weights array directly into numpy. It is worth a try at
least.


I'll give it a shot tomorrow. :)


Eric Thivierge
http://www.ethivierge.com




Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Xavier Lapointe
Or our lovely RunSnakeRun (cProfile like Bartosz mentioned):

http://www.vrplumber.com/programming/runsnakerun/


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Bartosz Opatowiecki

Hi Eric,

Why don't you use cProfile module to find slowest part of that code ?
Also KCacheGrind is cool if you like visual feedback.

Bartek Opatowiecki

W dniu 2013-05-31 00:44, Eric Thivierge pisze:


On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi > wrote:


Maybe you can still get some optimization using numpy, I think.
Throw your weights array directly into numpy. It is worth a try at
least.


I'll give it a shot tomorrow. :)


Eric Thivierge
http://www.ethivierge.com




Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge
On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi wrote:

> Maybe you can still get some optimization using numpy, I think. Throw your
> weights array directly into numpy. It is worth a try at least.


I'll give it a shot tomorrow. :)


Eric Thivierge
http://www.ethivierge.com


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Alok Gandhi
Maybe you can still get some optimization using numpy, I think. Throw your 
weights array directly into numpy. It is worth a try at least.

Sent from my iPhone

On 2013-05-30, at 4:59 PM, Eric Thivierge  wrote:

> Thanks Alok,
> 
> I do not think that the slowness is from converting the tuple to lists more 
> that the access time to the Weights.Array is slow as I see the slowness (~5 
> seconds) when I don't even convert it.
>  
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>  
> On 30/05/2013 4:56 PM, Alok Gandhi wrote:
>> Use numpy : http://www.numpy.org/
>> 
>> 
>> On Thu, May 30, 2013 at 4:42 PM, Eric Thivierge  
>> wrote:
>>> Well all my code is doing is creating a list of lists from the weights 
>>> array nothing more.
>>> 
>>> Should I consider this speed not slow then? When running various tools that 
>>> use this call to the weights array it seems extremely slow. Am I just being 
>>> impatient or on meshes with this density and number of deformers is it to 
>>> be expected? Should I accept it or look for other ways to speed it up?
>>> 
>>> Opinions welcome.
>>> 
>>>  
>>> Eric Thivierge
>>> ===
>>> Character TD / RnD
>>> Hybride Technologies
>>>  
>>> On 30/05/2013 4:38 PM, Jeremie Passerin wrote:
 just tested your scenario... got the same result here :D
 Actually your code is faster than mine 
 
 
 On 30 May 2013 13:21, Eric Thivierge  wrote:
> Thanks Jeremie,
> 
> I was referencing your code when I ran into the slowness to see if we are 
> doing anything different and we aren't really.
> 
> As a test I'm grabbing the XSI Man Armored and selecting the body mesh 
> and doing a local subdiv refinement with a setting of 2 then freezing 
> modeling. Then running the following code with the body mesh selected:
> 
> # Python
> # =
> from platform import system as OStype
> from time import clock
> 
> xsi = Application
> log = xsi.LogMessage
> sel = xsi.Selection
> 
> start_time = clock()
> 
> weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]
> 
> timeTaken = clock() - start_time
> 
> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
> 
> log(msg)
> # =
> 
> It's taking around 6 seconds for me.
> 
> 
>  
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>  
> On 30/05/2013 4:05 PM, Jeremie Passerin wrote:
>> Writting to the envelope array is usually pretty fast for me... what's 
>> taking time (in my case) is doing all the normalization of values... 
>> 
>> This is how I read my weights : 
>> 
>> def getWeights(envelopeOp):
>>  
>> 
>> weightsTuple = 
>> envelopeOp.Weights.Array
>> 
>> return [weightsTuple[j][i] for i 
>> in range(len(weightsTuple[0])) for j in range(len(weightsTuple))]
>> 
>> This is an example of how I set the weights (average weights) :
>> 
>> def averageWeights(envelopeOp, points=None):
>> 
>>   '''
>> 
>>   \remarks
>>   set the weights of given 
>> points to the average weights of given points
>> 
>>   \param
>>   envelopeOp Envelope Operator - 
>> the envelope operator.
>> 
>>   \param
>>   points List of Integer - Index 
>> of vertices to average.
>> 
>>   '''
>> 
>> 
>>   deformerCount = 
>> envelopeOp.Deformers.Count
>> 
>>   weightsTuple = 
>> envelopeOp.Weights.Array
>> 
>>   weights = 
>> getWeights(envelopeOp)
>>  
>> 
>>   if points is None:
>> 
>>   points = 
>> range(mesh.ActivePrimitive.Geometry.Points.Count)
>>  
>> 
>>   a = [0] * deformerCount
>> 
>>   for pointIndex in points:
>> 
>>   for def_index in 
>> range(deformerCount):
>> 
>>   a[def_index] +=  
>> weightsTuple[def_index][pointIndex]
>> 
>> 
>>  

Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Jens Lindgren
I just tried these examples myself.
Got 4.5 seconds with Erics example and 4.6 seconds with map(). Using Soft
2014 on Windows 8.
It took longer time to subdivide the mesh.

/Jens


On Thu, May 30, 2013 at 11:14 PM, Eric Thivierge wrote:

> Same time for me. 6 seconds.
>
>
>  Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
> On 30/05/2013 5:02 PM, Alan Fregtman wrote:
>
>> map(list, sel(0).Envelopes(0).Weights.**Array)
>>
>
>
>


-- 
Jens Lindgren
--
Lead Technical Director
Magoo 3D Studios 


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Alan Fregtman
Weird. Maybe it's cause I'm on Linux?



On Thu, May 30, 2013 at 5:14 PM, Eric Thivierge wrote:

> Same time for me. 6 seconds.
>
>
>  Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
> On 30/05/2013 5:02 PM, Alan Fregtman wrote:
>
>> map(list, sel(0).Envelopes(0).Weights.**Array)
>>
>
>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge

Same time for me. 6 seconds.

 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 30/05/2013 5:02 PM, Alan Fregtman wrote:

map(list, sel(0).Envelopes(0).Weights.Array)





Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Alan Fregtman
You can convert it much faster with:

weights = map(list, sel(0).Envelopes(0).Weights.Array)


In my box here at work it went from 17.81 seconds down to 7.9s with the
line above.



On Thu, May 30, 2013 at 4:59 PM, Eric Thivierge wrote:

>  Thanks Alok,
>
> I do not think that the slowness is from converting the tuple to lists
> more that the access time to the Weights.Array is slow as I see the
> slowness (~5 seconds) when I don't even convert it.
>
>
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
>
> On 30/05/2013 4:56 PM, Alok Gandhi wrote:
>
> Use numpy : http://www.numpy.org/
>
>
> On Thu, May 30, 2013 at 4:42 PM, Eric Thivierge wrote:
>
>>  Well all my code is doing is creating a list of lists from the weights
>> array nothing more.
>>
>> Should I consider this speed not slow then? When running various tools
>> that use this call to the weights array it seems extremely slow. Am I just
>> being impatient or on meshes with this density and number of deformers is
>> it to be expected? Should I accept it or look for other ways to speed it up?
>>
>> Opinions welcome.
>>
>>
>> Eric Thivierge
>> ===
>> Character TD / RnD
>> Hybride Technologies
>>
>>
>>   On 30/05/2013 4:38 PM, Jeremie Passerin wrote:
>>
>> just tested your scenario... got the same result here :D
>> Actually your code is faster than mine
>>
>>
>> On 30 May 2013 13:21, Eric Thivierge  wrote:
>>
>>>  Thanks Jeremie,
>>>
>>> I was referencing your code when I ran into the slowness to see if we
>>> are doing anything different and we aren't really.
>>>
>>> As a test I'm grabbing the XSI Man Armored and selecting the body mesh
>>> and doing a local subdiv refinement with a setting of 2 then freezing
>>> modeling. Then running the following code with the body mesh selected:
>>>
>>> # Python
>>> # =
>>> from platform import system as OStype
>>> from time import clock
>>>
>>> xsi = Application
>>> log = xsi.LogMessage
>>> sel = xsi.Selection
>>>
>>> start_time = clock()
>>>
>>> weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]
>>>
>>> timeTaken = clock() - start_time
>>>
>>> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
>>> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
>>>
>>> log(msg)
>>> # =
>>>
>>> It's taking around 6 seconds for me.
>>>
>>>
>>>
>>> Eric Thivierge
>>> ===
>>> Character TD / RnD
>>> Hybride Technologies
>>>
>>>
>>>   On 30/05/2013 4:05 PM, Jeremie Passerin wrote:
>>>
>>> Writting to the envelope array is usually pretty fast for me... what's
>>> taking time (in my case) is doing all the normalization of values...
>>>
>>> This is how I read my weights :
>>>
>>> def getWeights(envelopeOp):
>>>   weightsTuple = envelopeOp.Weights.Array
>>>  return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j
>>> in range(len(weightsTuple))]
>>>
>>>  This is an example of how I set the weights (average weights) :
>>>
>>> def averageWeights(envelopeOp, points=None):
>>>  '''
>>>  \remarks set the weights of given points to the average weights of
>>> given points
>>>  \param envelopeOp Envelope Operator - the envelope operator.
>>>  \param points List of Integer - Index of vertices to average.
>>>  '''
>>>
>>>  deformerCount = envelopeOp.Deformers.Count
>>>  weightsTuple = envelopeOp.Weights.Array
>>>  weights = getWeights(envelopeOp)
>>>   if points is None:
>>>  points = range(mesh.ActivePrimitive.Geometry.Points.Count)
>>>   a = [0] * deformerCount
>>>  for pointIndex in points:
>>>  for def_index in range(deformerCount):
>>>  a[def_index] +=  weightsTuple[def_index][pointIndex]
>>>
>>>  for pointIndex in points:
>>>  for def_index in range(deformerCount):
>>>  weights[pointIndex*deformerCount + def_index] =
>>> a[def_index]/len(points)
>>>   envelopeOp.Weights.Array = weights
>>>
>>>
>>> On 30 May 2013 12:58, Eric Thivierge  wrote:
>>>
 Anyone know if there is a way to speed up reading and writing speeds to
 the Weights Array for envelopes? It's extremely slow on high point count /
 high deformer count meshes.

 I'm using Python but I'm not sure if that is the reason for the
 slowness. Anyone else already do some testing or have any findings that may
 help?

 I'm writing some common tools that many have already done such as
 normalizing weights, pruning, symmetrizing, etc.

 Any experiences confirming this slowness or experiences where it is
 exponentially faster in other languages are welcome too.

 Thanks,

 --
  Eric Thivierge
 ===
 Character TD / RnD
 Hybride Technologies



>>>
>>>
>>
>>
>
>
>  --
>
>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge

Thanks Alok,

I do not think that the slowness is from converting the tuple to lists 
more that the access time to the Weights.Array is slow as I see the 
slowness (~5 seconds) when I don't even convert it.


 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 30/05/2013 4:56 PM, Alok Gandhi wrote:

Use numpy : http://www.numpy.org/


On Thu, May 30, 2013 at 4:42 PM, Eric Thivierge 
mailto:ethivie...@hybride.com>> wrote:


Well all my code is doing is creating a list of lists from the
weights array nothing more.

Should I consider this speed not slow then? When running various
tools that use this call to the weights array it seems extremely
slow. Am I just being impatient or on meshes with this density and
number of deformers is it to be expected? Should I accept it or
look for other ways to speed it up?

Opinions welcome.

  
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
  


On 30/05/2013 4:38 PM, Jeremie Passerin wrote:

just tested your scenario... got the same result here :D
Actually your code is faster than mine


On 30 May 2013 13:21, Eric Thivierge mailto:ethivie...@hybride.com>> wrote:

Thanks Jeremie,

I was referencing your code when I ran into the slowness to
see if we are doing anything different and we aren't really.

As a test I'm grabbing the XSI Man Armored and selecting the
body mesh and doing a local subdiv refinement with a setting
of 2 then freezing modeling. Then running the following code
with the body mesh selected:

# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]

timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else
"milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your
code."

log(msg)
# =

It's taking around 6 seconds for me.


  
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
  


On 30/05/2013 4:05 PM, Jeremie Passerin wrote:

Writting to the envelope array is usually pretty fast for
me... what's taking time (in my case) is doing all the
normalization of values...

This is how I read my weights :

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in
range(len(weightsTuple[0])) for j in range(len(weightsTuple))]

This is an example of how I set the weights (average weights) :

def averageWeights(envelopeOp, points=None):
'''
\remarksset the weights of given points to the average
weights of given points
\paramenvelopeOp Envelope Operator - the envelope operator.
\parampoints List of Integer - Index of vertices to average.
'''

deformerCount = envelopeOp.Deformers.Count
weightsTuple = envelopeOp.Weights.Array
weights = getWeights(envelopeOp)
if points is None:
points = range(mesh.ActivePrimitive.Geometry.Points.Count)
a = [0] * deformerCount
for pointIndex in points:
for def_index in range(deformerCount):
a[def_index] +=  weightsTuple[def_index][pointIndex]

for pointIndex in points:
for def_index in range(deformerCount):
weights[pointIndex*deformerCount + def_index] =
a[def_index]/len(points)
envelopeOp.Weights.Array = weights


On 30 May 2013 12:58, Eric Thivierge mailto:ethivie...@hybride.com>> wrote:

Anyone know if there is a way to speed up reading and
writing speeds to the Weights Array for envelopes? It's
extremely slow on high point count / high deformer count
meshes.

I'm using Python but I'm not sure if that is the reason
for the slowness. Anyone else already do some testing or
have any findings that may help?

I'm writing some common tools that many have already
done such as normalizing weights, pruning, symmetrizing,
etc.

Any experiences confirming this slowness or experiences
where it is exponentially faster in other languages are
welcome too.

Thanks,

-- 
 Eric Thivierge

===
Character TD / RnD
Hybride Technologies











--




Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Alok Gandhi
Use numpy : http://www.numpy.org/


On Thu, May 30, 2013 at 4:42 PM, Eric Thivierge wrote:

>  Well all my code is doing is creating a list of lists from the weights
> array nothing more.
>
> Should I consider this speed not slow then? When running various tools
> that use this call to the weights array it seems extremely slow. Am I just
> being impatient or on meshes with this density and number of deformers is
> it to be expected? Should I accept it or look for other ways to speed it up?
>
> Opinions welcome.
>
>
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
>
> On 30/05/2013 4:38 PM, Jeremie Passerin wrote:
>
> just tested your scenario... got the same result here :D
> Actually your code is faster than mine
>
>
> On 30 May 2013 13:21, Eric Thivierge  wrote:
>
>>  Thanks Jeremie,
>>
>> I was referencing your code when I ran into the slowness to see if we are
>> doing anything different and we aren't really.
>>
>> As a test I'm grabbing the XSI Man Armored and selecting the body mesh
>> and doing a local subdiv refinement with a setting of 2 then freezing
>> modeling. Then running the following code with the body mesh selected:
>>
>> # Python
>> # =
>> from platform import system as OStype
>> from time import clock
>>
>> xsi = Application
>> log = xsi.LogMessage
>> sel = xsi.Selection
>>
>> start_time = clock()
>>
>> weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]
>>
>> timeTaken = clock() - start_time
>>
>> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
>> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
>>
>> log(msg)
>> # =
>>
>> It's taking around 6 seconds for me.
>>
>>
>>
>> Eric Thivierge
>> ===
>> Character TD / RnD
>> Hybride Technologies
>>
>>
>>   On 30/05/2013 4:05 PM, Jeremie Passerin wrote:
>>
>> Writting to the envelope array is usually pretty fast for me... what's
>> taking time (in my case) is doing all the normalization of values...
>>
>> This is how I read my weights :
>>
>> def getWeights(envelopeOp):
>>   weightsTuple = envelopeOp.Weights.Array
>>  return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j
>> in range(len(weightsTuple))]
>>
>>  This is an example of how I set the weights (average weights) :
>>
>> def averageWeights(envelopeOp, points=None):
>>  '''
>>  \remarks set the weights of given points to the average weights of
>> given points
>>  \param envelopeOp Envelope Operator - the envelope operator.
>>  \param points List of Integer - Index of vertices to average.
>>  '''
>>
>>  deformerCount = envelopeOp.Deformers.Count
>>  weightsTuple = envelopeOp.Weights.Array
>>  weights = getWeights(envelopeOp)
>>   if points is None:
>>  points = range(mesh.ActivePrimitive.Geometry.Points.Count)
>>   a = [0] * deformerCount
>>  for pointIndex in points:
>>  for def_index in range(deformerCount):
>>  a[def_index] +=  weightsTuple[def_index][pointIndex]
>>
>>  for pointIndex in points:
>>  for def_index in range(deformerCount):
>>  weights[pointIndex*deformerCount + def_index] = a[def_index]/len(points)
>>   envelopeOp.Weights.Array = weights
>>
>>
>> On 30 May 2013 12:58, Eric Thivierge  wrote:
>>
>>> Anyone know if there is a way to speed up reading and writing speeds to
>>> the Weights Array for envelopes? It's extremely slow on high point count /
>>> high deformer count meshes.
>>>
>>> I'm using Python but I'm not sure if that is the reason for the
>>> slowness. Anyone else already do some testing or have any findings that may
>>> help?
>>>
>>> I'm writing some common tools that many have already done such as
>>> normalizing weights, pruning, symmetrizing, etc.
>>>
>>> Any experiences confirming this slowness or experiences where it is
>>> exponentially faster in other languages are welcome too.
>>>
>>> Thanks,
>>>
>>> --
>>>  Eric Thivierge
>>> ===
>>> Character TD / RnD
>>> Hybride Technologies
>>>
>>>
>>>
>>
>>
>
>


--


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge
Well all my code is doing is creating a list of lists from the weights 
array nothing more.


Should I consider this speed not slow then? When running various tools 
that use this call to the weights array it seems extremely slow. Am I 
just being impatient or on meshes with this density and number of 
deformers is it to be expected? Should I accept it or look for other 
ways to speed it up?


Opinions welcome.

 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 30/05/2013 4:38 PM, Jeremie Passerin wrote:

just tested your scenario... got the same result here :D
Actually your code is faster than mine


On 30 May 2013 13:21, Eric Thivierge > wrote:


Thanks Jeremie,

I was referencing your code when I ran into the slowness to see if
we are doing anything different and we aren't really.

As a test I'm grabbing the XSI Man Armored and selecting the body
mesh and doing a local subdiv refinement with a setting of 2 then
freezing modeling. Then running the following code with the body
mesh selected:

# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]

timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your code."

log(msg)
# =

It's taking around 6 seconds for me.


  
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
  


On 30/05/2013 4:05 PM, Jeremie Passerin wrote:

Writting to the envelope array is usually pretty fast for me...
what's taking time (in my case) is doing all the normalization of
values...

This is how I read my weights :

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0]))
for j in range(len(weightsTuple))]

This is an example of how I set the weights (average weights) :

def averageWeights(envelopeOp, points=None):
'''
\remarksset the weights of given points to the average weights of
given points
\paramenvelopeOp Envelope Operator - the envelope operator.
\parampoints List of Integer - Index of vertices to average.
'''

deformerCount = envelopeOp.Deformers.Count
weightsTuple = envelopeOp.Weights.Array
weights = getWeights(envelopeOp)
if points is None:
points = range(mesh.ActivePrimitive.Geometry.Points.Count)
a = [0] * deformerCount
for pointIndex in points:
for def_index in range(deformerCount):
a[def_index] +=  weightsTuple[def_index][pointIndex]

for pointIndex in points:
for def_index in range(deformerCount):
weights[pointIndex*deformerCount + def_index] =
a[def_index]/len(points)
envelopeOp.Weights.Array = weights


On 30 May 2013 12:58, Eric Thivierge mailto:ethivie...@hybride.com>> wrote:

Anyone know if there is a way to speed up reading and writing
speeds to the Weights Array for envelopes? It's extremely
slow on high point count / high deformer count meshes.

I'm using Python but I'm not sure if that is the reason for
the slowness. Anyone else already do some testing or have any
findings that may help?

I'm writing some common tools that many have already done
such as normalizing weights, pruning, symmetrizing, etc.

Any experiences confirming this slowness or experiences where
it is exponentially faster in other languages are welcome too.

Thanks,

-- 
 Eric Thivierge

===
Character TD / RnD
Hybride Technologies










Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Jeremie Passerin
just tested your scenario... got the same result here :D
Actually your code is faster than mine


On 30 May 2013 13:21, Eric Thivierge  wrote:

>  Thanks Jeremie,
>
> I was referencing your code when I ran into the slowness to see if we are
> doing anything different and we aren't really.
>
> As a test I'm grabbing the XSI Man Armored and selecting the body mesh and
> doing a local subdiv refinement with a setting of 2 then freezing modeling.
> Then running the following code with the body mesh selected:
>
> # Python
> # =
> from platform import system as OStype
> from time import clock
>
> xsi = Application
> log = xsi.LogMessage
> sel = xsi.Selection
>
> start_time = clock()
>
> weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]
>
> timeTaken = clock() - start_time
>
> units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
> msg = "It took "+str(timeTaken)+" "+units+" to process your code."
>
> log(msg)
> # =
>
> It's taking around 6 seconds for me.
>
>
>
> Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
>
> On 30/05/2013 4:05 PM, Jeremie Passerin wrote:
>
> Writting to the envelope array is usually pretty fast for me... what's
> taking time (in my case) is doing all the normalization of values...
>
> This is how I read my weights :
>
> def getWeights(envelopeOp):
>   weightsTuple = envelopeOp.Weights.Array
>  return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j in
> range(len(weightsTuple))]
>
>  This is an example of how I set the weights (average weights) :
>
> def averageWeights(envelopeOp, points=None):
>  '''
>  \remarks set the weights of given points to the average weights of given
> points
>  \param envelopeOp Envelope Operator - the envelope operator.
>  \param points List of Integer - Index of vertices to average.
>  '''
>
>  deformerCount = envelopeOp.Deformers.Count
>  weightsTuple = envelopeOp.Weights.Array
>  weights = getWeights(envelopeOp)
>   if points is None:
>  points = range(mesh.ActivePrimitive.Geometry.Points.Count)
>   a = [0] * deformerCount
>  for pointIndex in points:
>  for def_index in range(deformerCount):
>  a[def_index] +=  weightsTuple[def_index][pointIndex]
>
>  for pointIndex in points:
>  for def_index in range(deformerCount):
>  weights[pointIndex*deformerCount + def_index] = a[def_index]/len(points)
>   envelopeOp.Weights.Array = weights
>
>
> On 30 May 2013 12:58, Eric Thivierge  wrote:
>
>> Anyone know if there is a way to speed up reading and writing speeds to
>> the Weights Array for envelopes? It's extremely slow on high point count /
>> high deformer count meshes.
>>
>> I'm using Python but I'm not sure if that is the reason for the slowness.
>> Anyone else already do some testing or have any findings that may help?
>>
>> I'm writing some common tools that many have already done such as
>> normalizing weights, pruning, symmetrizing, etc.
>>
>> Any experiences confirming this slowness or experiences where it is
>> exponentially faster in other languages are welcome too.
>>
>> Thanks,
>>
>> --
>>  Eric Thivierge
>> ===
>> Character TD / RnD
>> Hybride Technologies
>>
>>
>>
>
>


Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge

Thanks Jeremie,

I was referencing your code when I ran into the slowness to see if we 
are doing anything different and we aren't really.


As a test I'm grabbing the XSI Man Armored and selecting the body mesh 
and doing a local subdiv refinement with a setting of 2 then freezing 
modeling. Then running the following code with the body mesh selected:


# Python
# =
from platform import system as OStype
from time import clock

xsi = Application
log = xsi.LogMessage
sel = xsi.Selection

start_time = clock()

weights = [list(x) for x in sel(0).Envelopes(0).Weights.Array]

timeTaken = clock() - start_time

units = ["seconds" if OStype() is "Windows" else "milliseconds"][0]
msg = "It took "+str(timeTaken)+" "+units+" to process your code."

log(msg)
# =

It's taking around 6 seconds for me.

 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies
 


On 30/05/2013 4:05 PM, Jeremie Passerin wrote:
Writting to the envelope array is usually pretty fast for me... what's 
taking time (in my case) is doing all the normalization of values...


This is how I read my weights :

def getWeights(envelopeOp):
weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j 
in range(len(weightsTuple))]


This is an example of how I set the weights (average weights) :

def averageWeights(envelopeOp, points=None):
'''
\remarksset the weights of given points to the average weights of 
given points

\paramenvelopeOp Envelope Operator - the envelope operator.
\parampoints List of Integer - Index of vertices to average.
'''

deformerCount = envelopeOp.Deformers.Count
weightsTuple = envelopeOp.Weights.Array
weights = getWeights(envelopeOp)
if points is None:
points = range(mesh.ActivePrimitive.Geometry.Points.Count)
a = [0] * deformerCount
for pointIndex in points:
for def_index in range(deformerCount):
a[def_index] +=  weightsTuple[def_index][pointIndex]

for pointIndex in points:
for def_index in range(deformerCount):
weights[pointIndex*deformerCount + def_index] = a[def_index]/len(points)
envelopeOp.Weights.Array = weights


On 30 May 2013 12:58, Eric Thivierge > wrote:


Anyone know if there is a way to speed up reading and writing
speeds to the Weights Array for envelopes? It's extremely slow on
high point count / high deformer count meshes.

I'm using Python but I'm not sure if that is the reason for the
slowness. Anyone else already do some testing or have any findings
that may help?

I'm writing some common tools that many have already done such as
normalizing weights, pruning, symmetrizing, etc.

Any experiences confirming this slowness or experiences where it
is exponentially faster in other languages are welcome too.

Thanks,

-- 
 Eric Thivierge

===
Character TD / RnD
Hybride Technologies







Re: Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Jeremie Passerin
Writting to the envelope array is usually pretty fast for me... what's
taking time (in my case) is doing all the normalization of values...

This is how I read my weights :

def getWeights(envelopeOp):
 weightsTuple = envelopeOp.Weights.Array
return [weightsTuple[j][i] for i in range(len(weightsTuple[0])) for j in
range(len(weightsTuple))]

This is an example of how I set the weights (average weights) :

def averageWeights(envelopeOp, points=None):
'''
\remarks set the weights of given points to the average weights of given
points
\param envelopeOp Envelope Operator - the envelope operator.
\param points List of Integer - Index of vertices to average.
'''

deformerCount = envelopeOp.Deformers.Count
weightsTuple = envelopeOp.Weights.Array
weights = getWeights(envelopeOp)
 if points is None:
points = range(mesh.ActivePrimitive.Geometry.Points.Count)
 a = [0] * deformerCount
for pointIndex in points:
for def_index in range(deformerCount):
a[def_index] +=  weightsTuple[def_index][pointIndex]

for pointIndex in points:
for def_index in range(deformerCount):
weights[pointIndex*deformerCount + def_index] = a[def_index]/len(points)
 envelopeOp.Weights.Array = weights


On 30 May 2013 12:58, Eric Thivierge  wrote:

> Anyone know if there is a way to speed up reading and writing speeds to
> the Weights Array for envelopes? It's extremely slow on high point count /
> high deformer count meshes.
>
> I'm using Python but I'm not sure if that is the reason for the slowness.
> Anyone else already do some testing or have any findings that may help?
>
> I'm writing some common tools that many have already done such as
> normalizing weights, pruning, symmetrizing, etc.
>
> Any experiences confirming this slowness or experiences where it is
> exponentially faster in other languages are welcome too.
>
> Thanks,
>
> --
>  Eric Thivierge
> ===
> Character TD / RnD
> Hybride Technologies
>
>
>


Slow Reading / Writing Envelope.Weights.Array

2013-05-30 Thread Eric Thivierge
Anyone know if there is a way to speed up reading and writing speeds to 
the Weights Array for envelopes? It's extremely slow on high point count 
/ high deformer count meshes.


I'm using Python but I'm not sure if that is the reason for the 
slowness. Anyone else already do some testing or have any findings that 
may help?


I'm writing some common tools that many have already done such as 
normalizing weights, pruning, symmetrizing, etc.


Any experiences confirming this slowness or experiences where it is 
exponentially faster in other languages are welcome too.


Thanks,

--
 
Eric Thivierge

===
Character TD / RnD
Hybride Technologies