Re: Plant Factory
is it Realistic to ask for an ICE version of every third party ware that comes out ? don't get me wrong it sounds like an ideal solution and I think it would be awesome, but is it actually doable ? On 30 May 2013 11:17, olivier jeannel olivier.jean...@noos.fr wrote: Unless, in a few weeks I'd have an emergency film that include plants everywhere, I'd wait for Creation Flora. Le 30/05/2013 09:06, Eugen Sares a écrit : Not bad at all, although a some native ICE version would be ideal, with parameter tweaking, animation and all. (Don't know how you feel, but I always roll my eyes when it comes to stand-alone applications. Not just another, mostly crappy, interface.) Fabric engine plants...? Nice how you can draw a tree with a spline. Impressive, yet not too hard to implement, I believe, since practically every tree generator supports curves/splines for the trunks/branches, you just would have to add some interactive tool for drawing them. In fact, Softimage already has a curvesketch, yet how would you integrate that into a live ICE graph? ICE nurbs(curves)... when will they come...? Am 30.05.2013 07:21, schrieb Stephen Davidson: examples of Plant Factory integrated within MAYA, 3DsMAX and SOFTIMAGE shown here: http://www.theplantfactory-tech.com/index.php?post/2013/03/25/The-Plant-Factory-Technology-in-Your-3D-Application On Wed, May 29, 2013 at 11:44 PM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: Ow... Good times ? On 30 May 2013 05:28, Stephen Davidson magic...@bellsouth.net wrote: quoted from their site: Plants created using The Plant Factory technology can be exported to any 3D Application using multiple export formats such as FBX, 3DS, OBJ, etc. On Wed, May 29, 2013 at 11:23 PM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: I know, they say it will come as stand alone and as a plugin for other applications, but they don't mention which ones, same goes for supported file formats... On 30 May 2013 05:19, Daniel Kim danielki...@gmail.com wrote: That looks great @_@ but no info for price On Thu, May 30, 2013 at 3:08 PM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: Has anyone seen this yet ? it looks delightful ! http://www.theplantfactory-tech.com/index.php?category/Feature-Video http://www.youtube.com/watch?v=FgSxH4GdJcMfeature=youtu.be -- --- Daniel Kim Animation Director Professional 3D Generalist http://www.danielkim3d.com --- -- Best Regards, * Stephen P. Davidson** **(954) 552-7956 *sdavid...@3danimationmagic.com *Any sufficiently advanced technology is indistinguishable from magic* - Arthur C. Clarke http://www.3danimationmagic.com -- Best Regards, * Stephen P. Davidson** **(954) 552-7956 *sdavid...@3danimationmagic.com *Any sufficiently advanced technology is indistinguishable from magic* - Arthur C. Clarke http://www.3danimationmagic.com
Re: Plant Factory
In this link, there is some info about support for rigging and vertex/point caching (MDD style). http://www.theplantfactory-tech.com/index.php?post/2013/03/25/The-Plant-Factory-Technology-in-Your-3D-Application That should be enough to add collision support or modification of pointpositions in ICE, depending on individual needs and levels of refinement? Cheers, tim On 30.05.2013 13:39, Sebastien Sterling wrote: is it Realistic to ask for an ICE version of every third party ware that comes out ? don't get me wrong it sounds like an ideal solution and I think it would be awesome, but is it actually doable ? On 30 May 2013 11:17, olivier jeannel olivier.jean...@noos.fr mailto:olivier.jean...@noos.fr wrote: Unless, in a few weeks I'd have an emergency film that include plants everywhere, I'd wait for Creation Flora. Le 30/05/2013 09:06, Eugen Sares a écrit : Not bad at all, although a some native ICE version would be ideal, with parameter tweaking, animation and all. (Don't know how you feel, but I always roll my eyes when it comes to stand-alone applications. Not just another, mostly crappy, interface.) Fabric engine plants...? Nice how you can draw a tree with a spline. Impressive, yet not too hard to implement, I believe, since practically every tree generator supports curves/splines for the trunks/branches, you just would have to add some interactive tool for drawing them. In fact, Softimage already has a curvesketch, yet how would you integrate that into a live ICE graph? ICE nurbs(curves)... when will they come...? Am 30.05.2013 07:21, schrieb Stephen Davidson: examples of Plant Factory integrated within MAYA, 3DsMAX and SOFTIMAGE shown here: http://www.theplantfactory-tech.com/index.php?post/2013/03/25/The-Plant-Factory-Technology-in-Your-3D-Application On Wed, May 29, 2013 at 11:44 PM, Sebastien Sterling sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com wrote: Ow... Good times ? On 30 May 2013 05:28, Stephen Davidson magic...@bellsouth.net mailto:magic...@bellsouth.net wrote: quoted from their site: Plants created using The Plant Factory technology can be exported to any 3D Application using multiple export formats such as FBX, 3DS, OBJ, etc. On Wed, May 29, 2013 at 11:23 PM, Sebastien Sterling sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com wrote: I know, they say it will come as stand alone and as a plugin for other applications, but they don't mention which ones, same goes for supported file formats... On 30 May 2013 05:19, Daniel Kim danielki...@gmail.com mailto:danielki...@gmail.com wrote: That looks great @_@ but no info for price On Thu, May 30, 2013 at 3:08 PM, Sebastien Sterling sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com wrote: Has anyone seen this yet ? it looks delightful ! http://www.theplantfactory-tech.com/index.php?category/Feature-Video http://www.youtube.com/watch?v=FgSxH4GdJcMfeature=youtu.be -- --- Daniel Kim Animation Director Professional 3D Generalist http://www.danielkim3d.com --- -- Best Regards, * Stephen P. Davidson** **(954) 552-7956 tel:%28954%29%20552-7956 * sdavid...@3danimationmagic.com mailto:sdavid...@3danimationmagic.com /Any sufficiently advanced technology is indistinguishable from magic/ - Arthur C. Clarke http://www.3danimationmagic.com -- Best Regards, * Stephen P. Davidson** **(954) 552-7956 tel:%28954%29%20552-7956 * sdavid...@3danimationmagic.com mailto:sdavid...@3danimationmagic.com /Any sufficiently advanced technology is indistinguishable from magic/ - Arthur C. Clarke http://www.3danimationmagic.com
Re: Looking for Autodesk high-res logos
Anything large enough for desktop backgrounds? :) Eric Thivierge === Character TD / RnD Hybride Technologies On 30/05/2013 7:53 AM, Marc-Andre Carbonneau wrote: Ya I did try it. the only version that came out are the big 288px! ;) It's ok, someone from Autodesk emailed me what I needed. Merci Xavier, MAC *From:*softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Xavier Lapointe *Sent:* 29 mai 2013 22:32 *To:* softimage@listproc.autodesk.com *Subject:* Re: Looking for Autodesk high-res logos Have you tried drag n dropping a smaller version of the logos in images.google.com http://images.google.com? It'll search for similar images in all format .. maybe you can get lucky (no pun intended) and find a higher res by tweaking the search options. Cheers
Re: Plant Factory
Ah... yes... I always wanted to use my iPad for proper work... /s So a desktop version isn't there? Shame, as it looks nice. Rob \/-\/\/ On 30-5-2013 15:29, Alan Fregtman wrote: Anyone with an ipad, have you guys tried the TreeSketch app? It works really well, it's free, it's tactile and it saves to fbx. https://vimeo.com/27366282 https://itunes.apple.com/us/app/treesketch/id421230117?mt=8 I'm sure the feature sets are different, but drawing trees is really nice with this app. On Thu, May 30, 2013 at 9:01 AM, Eugen Sares sof...@mail.sprit.org mailto:sof...@mail.sprit.org wrote: Is it realistic... I don't know, why not. People created hair or feather systems already, and there are numerous experiments with ICE strands for plants/trees. Isn't that the whole idea of ICE anyway... being relatively quick with things like that (given the necessary skills)? Of course, if there's no luxury version, we'll have to stick to the import-it-all workflow, like the last 10 years. If it's really simple and headache-free (UVs, shaders...), it might be allright for 95% of the cases. Growth animations would be something you couldn't do that way, though - a rare case maybe. Reminds me of Maya's PaintFX tools... how long has those been around? 13 years? Still nothing comparable in SI, is there. Go for gold, or for compromises... what's better? Am 30.05.2013 13:50, schrieb Tim Leydecker: In this link, there is some info about support for rigging and vertex/point caching (MDD style). http://www.theplantfactory-tech.com/index.php?post/2013/03/25/The-Plant-Factory-Technology-in-Your-3D-Application That should be enough to add collision support or modification of pointpositions in ICE, depending on individual needs and levels of refinement? Cheers, tim On 30.05.2013 13:39, Sebastien Sterling wrote: is it Realistic to ask for an ICE version of every third party ware that comes out ? don't get me wrong it sounds like an ideal solution and I think it would be awesome, but is it actually doable ? On 30 May 2013 11:17, olivier jeannel olivier.jean...@noos.fr mailto:olivier.jean...@noos.fr mailto:olivier.jean...@noos.fr mailto:olivier.jean...@noos.fr wrote: Unless, in a few weeks I'd have an emergency film that include plants everywhere, I'd wait for Creation Flora. Le 30/05/2013 09:06, Eugen Sares a écrit : Not bad at all, although a some native ICE version would be ideal, with parameter tweaking, animation and all. (Don't know how you feel, but I always roll my eyes when it comes to stand-alone applications. Not just another, mostly crappy, interface.) Fabric engine plants...? Nice how you can draw a tree with a spline. Impressive, yet not too hard to implement, I believe, since practically every tree generator supports curves/splines for the trunks/branches, you just would have to add some interactive tool for drawing them. In fact, Softimage already has a curvesketch, yet how would you integrate that into a live ICE graph? ICE nurbs(curves)... when will they come...? Am 30.05.2013 07:21, schrieb Stephen Davidson: examples of Plant Factory integrated within MAYA, 3DsMAX and SOFTIMAGE shown here: http://www.theplantfactory-tech.com/index.php?post/2013/03/25/The-Plant-Factory-Technology-in-Your-3D-Application On Wed, May 29, 2013 at 11:44 PM, Sebastien Sterling sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com mailto:sebastien.sterl...@gmail.com wrote: Ow... Good times ? On 30 May 2013 05:28, Stephen Davidson magic...@bellsouth.net mailto:magic...@bellsouth.net mailto:magic...@bellsouth.net mailto:magic...@bellsouth.net wrote: quoted from their site: Plants created using The Plant Factory technology can be exported to any 3D Application using multiple export formats such as FBX, 3DS, OBJ, etc. On Wed, May 29, 2013 at 11:23 PM, Sebastien Sterling
CrowdFX actor target speed
Hello list. Using 2013 doing some crowd stuff. Got 4 actors and simulating about 10,000 people. If I set a target speed directly in the particle simulation tree on the simulation crowd the actors behave and try to achieve that target speed. However adding a randomize to vary the speed (Min 10, Max 28) causes 2 of my actors to go into a run and the other two to be pretty much static - nowhere near their min speed of 10. There is no animation on the randomize. Tried blowing away the randomize node and starting with that again but same result. Used turbulize but same result. Changes the seed of the simulation cloud. Everything seems to have the same result. Removing the actors that are misbehaving means that the remaining 2 actors populate the whole sim and the same issue arises but this time with one running and the other being static. I can't see that there's any instruction to tell the 0,1,2 or 3rd actor to behave any differently. Any thoughts people?! Cheers Jonny
Re: Looking for Autodesk high-res logos
Want to play a prank on your workmates? Eric Thivierge ethivie...@hybride.com hat am 30. Mai 2013 um 15:31 geschrieben: Anything large enough for desktop backgrounds? :) Eric Thivierge === Character TD / RnD Hybride Technologies On 30/05/2013 7:53 AM, Marc-Andre Carbonneau wrote: Ya I did try it. the only version that came out are the big 288px! ;) It’s ok, someone from Autodesk emailed me what I needed. Merci Xavier, MAC From: softimage-boun...@listproc.autodesk.com mailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com ] On Behalf Of Xavier Lapointe Sent: 29 mai 2013 22:32 To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Looking for Autodesk high-res logos Have you tried drag n dropping a smaller version of the logos inhttp://images.google.com ? It'll search for similar images in all format .. maybe you can get lucky (no pun intended) and find a higher res by tweaking the search options. Cheers
Re: CrowdFX actor target speed
Not to worry It seems a full shutdown and a rebuild of that section of the tree has solved the problem If we weren't mid-job it would seem from other posts that a 2014 switch over would solve some other textural issues on the farm but we're getting there! *-- * *Jonny Grew Ltd * *www.Jonnygrew.com* *http://vimeo.com/jonnygrew/showreel2013*http://vimeo.com/jonnygrew/showreel2013 *07855 212722* Jonny Grew Limited is registered in **England** and Wales. Company number:07735521 VAT number: 122713057 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Jonny Grew Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. * * On 30 May 2013 15:01, Jonny Grew jonny.g...@gmail.com wrote: Hello list. Using 2013 doing some crowd stuff. Got 4 actors and simulating about 10,000 people. If I set a target speed directly in the particle simulation tree on the simulation crowd the actors behave and try to achieve that target speed. However adding a randomize to vary the speed (Min 10, Max 28) causes 2 of my actors to go into a run and the other two to be pretty much static - nowhere near their min speed of 10. There is no animation on the randomize. Tried blowing away the randomize node and starting with that again but same result. Used turbulize but same result. Changes the seed of the simulation cloud. Everything seems to have the same result. Removing the actors that are misbehaving means that the remaining 2 actors populate the whole sim and the same issue arises but this time with one running and the other being static. I can't see that there's any instruction to tell the 0,1,2 or 3rd actor to behave any differently. Any thoughts people?! Cheers Jonny
RE: CrowdFX actor target speed
Are you using the default settings for the anticipation settings? Ie a high anticipation factor and low anticipation contrast can create overly aggressive collision avoidance which would cause your actors to stall and try to change direction. Also what happens if you force the fixed minimum speed of 10 across all actors via the simulate collision avoidance node.Do they all show this same slow behavior? Do they go into and out of this behavior if you jiggle the target speed high and low during the simulation? jeff From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jonny Grew Sent: Thursday, May 30, 2013 10:02 AM To: softimage@listproc.autodesk.com Subject: CrowdFX actor target speed Hello list. Using 2013 doing some crowd stuff. Got 4 actors and simulating about 10,000 people. If I set a target speed directly in the particle simulation tree on the simulation crowd the actors behave and try to achieve that target speed. However adding a randomize to vary the speed (Min 10, Max 28) causes 2 of my actors to go into a run and the other two to be pretty much static - nowhere near their min speed of 10. There is no animation on the randomize. Tried blowing away the randomize node and starting with that again but same result. Used turbulize but same result. Changes the seed of the simulation cloud. Everything seems to have the same result. Removing the actors that are misbehaving means that the remaining 2 actors populate the whole sim and the same issue arises but this time with one running and the other being static. I can't see that there's any instruction to tell the 0,1,2 or 3rd actor to behave any differently. Any thoughts people?! Cheers Jonny
RE: CrowdFX actor target speed
some other textural issues on the farm I had big headaches with this as well till someone on this list was kind enough to point out the need and supply a node to force the texture attribute to update each frame Looking forward to trying out the improved 2014 crowd myself jeff From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jonny Grew Sent: Thursday, May 30, 2013 10:38 AM To: softimage@listproc.autodesk.com Subject: Re: CrowdFX actor target speed Not to worry It seems a full shutdown and a rebuild of that section of the tree has solved the problem If we weren't mid-job it would seem from other posts that a 2014 switch over would solve some other textural issues on the farm but we're getting there! -- Jonny Grew Ltd www.Jonnygrew.comhttp://www.Jonnygrew.com http://vimeo.com/jonnygrew/showreel2013 07855 212722 Jonny Grew Limited is registered in England and Wales. Company number:07735521 VAT number: 122713057 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Jonny Grew Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. On 30 May 2013 15:01, Jonny Grew jonny.g...@gmail.commailto:jonny.g...@gmail.com wrote: Hello list. Using 2013 doing some crowd stuff. Got 4 actors and simulating about 10,000 people. If I set a target speed directly in the particle simulation tree on the simulation crowd the actors behave and try to achieve that target speed. However adding a randomize to vary the speed (Min 10, Max 28) causes 2 of my actors to go into a run and the other two to be pretty much static - nowhere near their min speed of 10. There is no animation on the randomize. Tried blowing away the randomize node and starting with that again but same result. Used turbulize but same result. Changes the seed of the simulation cloud. Everything seems to have the same result. Removing the actors that are misbehaving means that the remaining 2 actors populate the whole sim and the same issue arises but this time with one running and the other being static. I can't see that there's any instruction to tell the 0,1,2 or 3rd actor to behave any differently. Any thoughts people?! Cheers Jonny
RE: CrowdFX actor target speed
I do what Adam said...but before I make sure the ice projection is calculated correclty (not bypassed by those evil ice optimizations) by using the attached compound at the very end of in the first icetree on each actor_copies mesh. It's really simple, it ensures the attribute is set by using it inside a null equation that get/set point positions. Here it is in case you have trouble. Thanks to Fabricio Chamon for sending this in the original thread - it was a life saver, really :) I shudder to think how many rebuilds I did trying to get these to render. This seemed to fix it in a snap. I know the feeling well. Live and learn I guess Best Jeff From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jonny Grew Sent: Thursday, May 30, 2013 2:48 PM To: softimage@listproc.autodesk.com Subject: RE: CrowdFX actor target speed Cheers for your reply, Jeff. I'll try and look out that previous thread with the update every frame setup for the texture problems-it would certainly speed things up rather than local renders! That many actors rendering with mental ray ain't quick! Wish we were using Arnold! As for the speed issue I realised it was my cock-up. Somewhat of a school-boy error. We had a previous issue so I rebuilt the scene but dropped a randomize around value rather than a randomize by range then couldn't see the wood for the trees! Whooops! What a knob! Cheers Jonny On May 30, 2013 4:31 PM, Jeff McFall jeff.mcf...@sas.commailto:jeff.mcf...@sas.com wrote: some other textural issues on the farm I had big headaches with this as well till someone on this list was kind enough to point out the need and supply a node to force the texture attribute to update each frame Looking forward to trying out the improved 2014 crowd myself jeff From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jonny Grew Sent: Thursday, May 30, 2013 10:38 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: CrowdFX actor target speed Not to worry It seems a full shutdown and a rebuild of that section of the tree has solved the problem If we weren't mid-job it would seem from other posts that a 2014 switch over would solve some other textural issues on the farm but we're getting there! -- Jonny Grew Ltd www.Jonnygrew.comhttp://www.Jonnygrew.com http://vimeo.com/jonnygrew/showreel2013 07855 212722 Jonny Grew Limited is registered in England and Wales. Company number:07735521 VAT number: 122713057 This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Jonny Grew Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. On 30 May 2013 15:01, Jonny Grew jonny.g...@gmail.commailto:jonny.g...@gmail.com wrote: Hello list. Using 2013 doing some crowd stuff. Got 4 actors and simulating about 10,000 people. If I set a target speed directly in the particle simulation tree on the simulation crowd the actors behave and try to achieve that target speed. However adding a randomize to vary the speed (Min 10, Max 28) causes 2 of my actors to go into a run and the other two to be pretty much static - nowhere near their min speed of 10. There is no animation on the randomize. Tried blowing away the randomize node and starting with that again but same result. Used turbulize but same result. Changes the seed of the simulation cloud. Everything seems to have the same result. Removing the actors that are misbehaving means that the remaining 2 actors populate the whole sim and the same issue arises but this time with one running and the other being static. I can't see that there's any instruction to tell the 0,1,2 or 3rd actor to behave any differently. Any thoughts people?! Cheers Jonny Force Attribute Eval.xsicompound Description: Force Attribute Eval.xsicompound
Re: Slow Reading / Writing Envelope.Weights.Array
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 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
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 ethivie...@hybride.com 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
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 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): ''' \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 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
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 ethivie...@hybride.com 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 ethivie...@hybride.com 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
Use numpy : http://www.numpy.org/ On Thu, May 30, 2013 at 4:42 PM, Eric Thivierge ethivie...@hybride.comwrote: 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 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): ''' \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 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
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 ethivie...@hybride.com 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 ethivie...@hybride.com 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 ethivie...@hybride.com 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
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 ethivie...@hybride.comwrote: 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 ethivie...@hybride.comwrote: 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 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): ''' \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 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
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: Looking for Autodesk high-res logos
Easy prank for a pipeline guy or TD with sufficient privileges: 1. Find the splashscreen for Maya, 2. Save as BMP somewhere, 3. Before launching Soft, sneak in the env var XSI_SPLASH pointing to that filepath. *Oh god! Why is it opening Maya?! N* ;p On Thu, May 30, 2013 at 10:11 AM, Eric Thivierge ethivie...@hybride.comwrote: Uhm... no. I have no idea what you're talking about. :P Eric Thivierge === Character TD / RnD Hybride Technologies On 30/05/2013 10:09 AM, Thomas Volkmann wrote: Want to play a prank on your workmates? Eric Thivierge ethivie...@hybride.com ethivie...@hybride.com hat am 30. Mai 2013 um 15:31 geschrieben: Anything large enough for desktop backgrounds? :) Eric Thivierge === Character TD / RnD Hybride Technologies On 30/05/2013 7:53 AM, Marc-Andre Carbonneau wrote: Ya I did try it. the only version that came out are the big 288px! ;) It’s ok, someone from Autodesk emailed me what I needed. Merci Xavier, MAC *From:* softimage-boun...@listproc.autodesk.com [ mailto:softimage-boun...@listproc.autodesk.comsoftimage-boun...@listproc.autodesk.com] *On Behalf Of *Xavier Lapointe *Sent:* 29 mai 2013 22:32 *To:* softimage@listproc.autodesk.com *Subject:* Re: Looking for Autodesk high-res logos Have you tried drag n dropping a smaller version of the logos in images.google.com? It'll search for similar images in all format .. maybe you can get lucky (no pun intended) and find a higher res by tweaking the search options. Cheers
Re: Slow Reading / Writing Envelope.Weights.Array
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 ethivie...@hybride.comwrote: 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 http://www.magoo3dstudios.com/
RE: Python Multiprocessing in Softimage
Outside of ICE, the SDK is not thread safe. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann Sent: Thursday, May 30, 2013 3:34 PM To: softimage@listproc.autodesk.com Subject: Python Multiprocessing in Softimage Hi List, i tried to optimize performance of a scripted operator i wrote, by adding multithread-support. So i got a Test-Script working fine in Sublime-Text, but as soon as i try to run is from inside Softimage's ScriptEditor or in a ScriptedOperator it breaks. It gives me this error: # PicklingError: Can't pickle class '__ax_main__.Worker': it's not found as __ax_main__.Worker Cant find any results in Google, but maybe someone here know how to do it PS: No, in this case i cant go to ICE and do my stuff there. ;-)
Re: Python Multiprocessing in Softimage
Hmm... ok, thanks Is it possible to write a multiThreaded CustomOperator in C++ ? I already build a simpler version of my ScriptedOp in C, so i might just make it multiThreaded ;-) But first it would be nice to know if Softimage could handle this Am 31.05.2013 00:36, schrieb Matt Lind: Outside of ICE, the SDK is not thread safe. Matt
Re: Slow Reading / Writing Envelope.Weights.Array
On Thu, May 30, 2013 at 6:35 PM, Alok Gandhi alok.gan...@modusfx.comwrote: 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: Python Multiprocessing in Softimage
Outside of ICE, the SDK is not thread safe. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann Sent: Thursday, May 30, 2013 3:43 PM To: softimage@listproc.autodesk.com Subject: Re: Python Multiprocessing in Softimage Hmm... ok, thanks Is it possible to write a multiThreaded CustomOperator in C++ ? I already build a simpler version of my ScriptedOp in C, so i might just make it multiThreaded ;-) But first it would be nice to know if Softimage could handle this Am 31.05.2013 00:36, schrieb Matt Lind: Outside of ICE, the SDK is not thread safe. Matt
Re: Python Multiprocessing in Softimage
Hey Vincent, multithreading is different of multiprocessing... short long story, multithreading is about running many threads in the same memory space (so shared memory and so use of patterns such as mutex, semaphore,...) while multiprocessing is about running different external processes (all having their own memory space)... It becomes tedious when you want to share data then across those different processes as they don't share a common memory space, Python designers achieve this by simply pickling the datas you want to share (and so you have to be sure they are pickable) and saving them somewhere in memory or on disk (where processes known where to look for). multiprocessing is a powerful concept equivalent in theory to pipes or even co-routines. As Matt said, the sdk is not thread-safe, so forgetting about multithreading is a good rule to follow, while I wouldnt even think about multiprocessing to access scene graph components. To boost your operator, review and be sure your code is optimized (thats just all what it takes 90% of the cases) ! if this is still too slow, move to Cpp... --jon 2013/5/30 Matt Lind ml...@carbinestudios.com Outside of ICE, the SDK is not thread safe. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Vincent Ullmann Sent: Thursday, May 30, 2013 3:43 PM To: softimage@listproc.autodesk.com Subject: Re: Python Multiprocessing in Softimage Hmm... ok, thanks Is it possible to write a multiThreaded CustomOperator in C++ ? I already build a simpler version of my ScriptedOp in C, so i might just make it multiThreaded ;-) But first it would be nice to know if Softimage could handle this Am 31.05.2013 00:36, schrieb Matt Lind: Outside of ICE, the SDK is not thread safe. Matt
Re: Python Multiprocessing in Softimage
Even without considering all the good points brought up insofar, the GIL in Python (CPy at least) makes multithreading live, in general, somewhere between downright impossible and not worth trying. Depending on the process your only option might be to manage the threading yourself inside a cpp op, or you might have no options at all if you too frequently have to halt and listen to something (going between Soft's own callbacks, event loop and so on). ICE, on the other hand, is a bit blackboxed but ultimately very comfortable and efficient at threading in some scenarios. So if you want to parallelize simply because you work on a very large set of points or something like that, then writing it in ICE form (as in an ICE node) would most likely be both the easiest and the safest way. -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: MiaMaterialAdv not writing to framebuffer after override ?
? Vladimir Jankijevic wrote: I created an arc on the left side of a motorcycle, toggled on the buttons I want to to react to the emotion from the Mia_Material_Adv leather, those buttons are not showing up in the emotion ? If I toggle the buttons I want to react to the emotion on a vehicle by vehicle basis, the buttons get reacting to the emotion, it appears that the arc is preventing the buttons to be reacting to the emotion ? On Wed, May 29, 2013 at 8:31 PM, Christopher christop...@thecreativesheep.ca mailto:christop...@thecreativesheep.ca wrote: I created an override on the background partition of a pass, toggled on the channels I want to to write to the framebuffer from the Mia_Material_Adv shader, those channels are not showing up in the framebuffer ? If I toggle the channels I want to write to the framebuffer on a object by object basis, the channels get written to the framebuffer, it appears that the override is preventing the channels to be written to the framebuffer ? ::Christopher -- --- Vladimir Jankijevic Technical Direction Elefant Studios AG Lessingstrasse 15 CH-8002 Zürich +41 44 500 48 20 www.elefantstudios.ch http://www.elefantstudios.ch ---
