Re: [Pool] Any interest for a grease pencil tool?
I would pay 20 dollars if it worked like the Blender grease pencil for sure. http://www.youtube.com/watch?v=RwMS5Gc8GGg On Sat, Apr 13, 2013 at 6:13 AM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: production ready and version support ? i'd go 20$, but i would make it a package with something like production ready motion trails (like taro but prod tested, see Rray) even a small bundal of 4 animation essentials addons would be well received i expect ;) On 13 April 2013 04:21, Adam Sale adamfs...@gmail.com wrote: I'd go in the 5 - 15 dollar range for plugins like that. On Fri, Apr 12, 2013 at 6:08 PM, Steven Caron car...@gmail.com wrote: one with those features could earn a higher return, $50 is maybe still a little steep. not because i think the work will so easy it doesn't deserve $50 but to make sure it isn't too steep and dissuade people to buy it On Fri, Apr 12, 2013 at 5:57 PM, Miquel Campos miquel.cam...@gmail.comwrote: I am also interested, and pretty sure all the animators at Shed are also interested :) About Maya grease pencil. was one before but not free: http://zurbrigg.com/blue-pencil maybe was more than one .
Re: [Pool] Any interest for a grease pencil tool?
I agree with what Sebastien mentioned above. production ready and version support ? i'd go 20$, but i would make it a package with something like production ready motion trails (like taro but prod tested, see Rray) even a small bundal of 4 animation essentials addons would be well received i expect ;) Maybe have a look at tradigiTOOLS plugin for Maya http://funhouseinteractive.biz/tradigitools.html I've used that a lot and personally feel its got a bunch of good tools for animators in one place. Cheers, *-- Upinder Dhaliwal* www.upinderdhaliwal.com On Sat, Apr 13, 2013 at 5:51 PM, Dan Yargici danyarg...@gmail.com wrote: I would pay 20 dollars if it worked like the Blender grease pencil for sure. http://www.youtube.com/watch?v=RwMS5Gc8GGg On Sat, Apr 13, 2013 at 6:13 AM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: production ready and version support ? i'd go 20$, but i would make it a package with something like production ready motion trails (like taro but prod tested, see Rray) even a small bundal of 4 animation essentials addons would be well received i expect ;) On 13 April 2013 04:21, Adam Sale adamfs...@gmail.com wrote: I'd go in the 5 - 15 dollar range for plugins like that. On Fri, Apr 12, 2013 at 6:08 PM, Steven Caron car...@gmail.com wrote: one with those features could earn a higher return, $50 is maybe still a little steep. not because i think the work will so easy it doesn't deserve $50 but to make sure it isn't too steep and dissuade people to buy it On Fri, Apr 12, 2013 at 5:57 PM, Miquel Campos miquel.cam...@gmail.com wrote: I am also interested, and pretty sure all the animators at Shed are also interested :) About Maya grease pencil. was one before but not free: http://zurbrigg.com/blue-pencil maybe was more than one .
Re: How to make a deformer absolute ?
Primitive prim = (CRef)ctx.GetInputValue(0,0); PolygonMesh mesh(prim.GetGeometry(0,siConstructionModeAnimation)); CVertexRefArray outPoints = outMesh.GetVertices(); CVector3Array pos = outPoints.GetPositionArray(); I'm calling that block of code from inside of a customOperator, ok ? There is an Envelope Operator below. It has some bones so the mesh is being deformed by that bones. PolygonMesh - Secondary Shape Modeling - Animation - MyOperator - EnvelopeOperator - -Shape Modeling - Modeling How to get result of EnvelopeOperator as an Array of absolute vectors, from within MyOperator Update callback ? Actually pos is filled with zeroes. Hope, you get what I mean :) Thanks On Sat, Apr 13, 2013 at 3:04 AM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: If you transform the vectors by the global kine transform of the object they come from they will be in world space. Assuming you are reading from another object and getting its point positions (and those are local) and want their global coordinates the above step is what you need. If you want them in the space of another object then you will have to do the above and also multiply by the inverse of the object's global transform you want them to be in the space of. You can chain those two matrices outside the loop taking care of the pointpos vectors, as they are per object, to save some cycles. Unless you were asking for something else. On Sat, Apr 13, 2013 at 6:45 AM, Bartosz Opatowiecki b.opatowie...@gmail.com wrote: Actually it is false, because I got deformed vertices into my deformer any way. So anything I do inside my operator is relative to the previous operator in the stack... Instead, I want to get vertices in world space or in X3DObject space fed into my deformer. How can I do that ? W dniu 2013-04-12 22:33, Alan Fregtman pisze: Yeah, it should. You're reading from the Modeling stack, so the envelope didn't happen at that point. Then you're setting the positions, so anything between your operator and the Modeling marker might as well not exist because it's overridden by your data. On Fri, Apr 12, 2013 at 4:26 PM, Bartosz Opatowiecki b.opatowie...@gmail.com wrote: Hey, Lets forget about node transformations, only vertices are being deformed. If, within an update function I get a geometry like this: Primitive prim = (CRef)ctx.GetInputValue(0,0); PolygonMesh mesh(prim.GetGeometry(0,siConstructionModeModeling)); CVertexRefArray outPoints = outMesh.GetVertices(); CVector3Array pos = outPoints.GetPositionArray(); and put its data back: Primitive outPrim(ctx.GetOutputTarget()); PolygonMesh outMesh(outPrim.GetGeometry(0,siConstructionModeModeling)); CVertexRefArray outPoints = outMesh.GetVertices(); outPoints.PutPositionArray(pos); my output mesh should stay still even if envelope operator is below it. Am I right ? W dniu 2013-04-12 20:10, Alan Fregtman pisze: From what you said you're already setting the pointpositions (aka deforming), so you have *already* *taken over*. You can set the deformation to be absolute if your data is absolute and taking the object's transform into consideration. If you mean if you can disable operators downwards... no, you can't. On Fri, Apr 12, 2013 at 12:18 PM, Bartek Opatowiecki b.opatowie...@gmail.com wrote: Hi, I'm working on a customOperator which is deforimg a mesh. It is sitting at the top of an animation construction mode . I would like it to take over the deformation at some point and ignore entire construction stack below it. thanks, Bartek -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: Friday Flashback #115
I don't think it's that crazy to print books in low volume for a 3000$ product today, but iI recall it was quite a burden to have to finish the doc and the screenshots long in advance of shipping. i'm pretty sure those books quickly became stale and didn't include the new features but just the generalities that didn't change. you didn't get all the books for an upgrade. I think everyone dropped books firstly to shorten that release window and then to cut any extra expense. I recall there was an app that you could pay something like 200$ extra for printed manual, can't recall if that was us. On Saturday, April 13, 2013, Chris Chia wrote: Yes Matt. That was what I meant as I didn't know the price of XSI 1.0. Assuming if it was the price of the current Softimage, then those packaging and thick copies of printed docs would have constitute to a big portion of the cost price. On 13 Apr, 2013, at 11:32 AM, Matt Lind ml...@carbinestudios.comjavascript:; wrote: printing wasn't a huge concern in those days as the software sold for nearly $13,000 USD with about $200 going towards printing and manufacturing materials. The extra materials acted as a way to help justify the high cost of the software in the eyes of a pre-internet sales business climate. When people spend more, they expect more in the box.
shiffman for the win.. math tuts
https://vimeo.com/shiffman/videos great math explanations, mainly in Processing context but worth a look.
Re: [Pool] Any interest for a grease pencil tool?
Same, very helpful and will/must buy If not for Free. :-). Walt -- Diese Nachricht wurde von meinem Android Mobiltelefon mit 11 Mail gesendet. Ahmidou Lyazidi ahmidou@gmail.com schrieb: Hello guys, I'm thinking of making a grease pencil tool, but I would like to know if there is a real interest in it, and what would be a faire price for this kind of tool Thanks --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos
Re: shiffman for the win.. math tuts
Awesome!! Danke! /Thomas On 04/13/2013 03:13 PM, Sebastian Kowalski wrote: https://vimeo.com/shiffman/videos great math explanations, mainly in Processing context but worth a look.
Re: Modo's Deformation (Weight Containers)
I watched the video, interesting stuff, I'd like to see a comparison between what was shown in the video and Softimage, specifically what I liked in the Modo video was the sliding skin effect. Christopher Matt Lind Friday, April 12, 2013 11:19 PM Basically the guy took 24 minutes to explain a 2 minute concept. The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers' which are logical assignments of points to deformers. A different kind of weight map. The example shows an arm enveloped over 2 bones (3 joints). In Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. as you rotate the shoulder, the elbow and wrist would tag along for the ride via inheritance of the shoulder's transformation. If you rotate the elbow, the shoulder is unaffected, but the wrist moves because it inherit's the elbow's transformation. The point being the deformer has to reside in the location of the envelope deformation, and this can be inconvenient for thinking/viewing certain problems such as wanting to only rotate a deformer by a few degrees. in the case of the elbow, it may already be rotated to some arbitrary angle making adding/subtracting a few degrees difficult to visualize. In Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. they were scattered about wherever was convenient. This allowed the artist to work with the deformations in the local space of the deformer so if he wanted to say, limit envelope deformations to rotations of 10 degrees or less, the artist could easily see a 10 degree rotation and work with the deformer weights. think of it as compensation mode for vertices of an envelope. You apply the envelope to the defomers, but you can then offset the vertices where you want and maintain that relationship as metadata in the weight container. This allows the envelope to deform as desired, but not require the bones to be moving around with the envelope. Personally I don't find that useful in the general case, but maybe in a few rare niche cases it might have some benefit. The part I take issue with is not having bones in their usual places will make it difficult for animators to judge how the character is moving when adjusting keys. After all, you don't generally envelope a rig unless it's expected to be animated, so why disassociate the bones from the animator's perspective? The part of greater interest was pre-evaluation and post-evaluation events which gives the artist the opportunity to further modify the resulting deformation as each deformer is evaluated. The example given was not very good as it could be easily replicated using linked parameters to drive a lattice or some other easy control, but in more complex cases could be useful for sculpting the envelope deformation in very specific ways. You can replicate most of it in softimage using a different strategy than is typically used, but some of the more advanced stuff, such as compensation, would require a custom envelope operator or ICE. Matt From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron [car...@gmail.com] Sent: Friday, April 12, 2013 6:53 PM To: softimage@listproc.autodesk.com Subject: Re: Modo's Deformation (Weight Containers) i want to watch it, but the speed is killing me... anyone care to summarize the feature(s)? Marco Peixoto Friday, April 12, 2013 5:37 PM This seems really interesting and a new way of dealing with Envelope Weights: http://vimeo.com/63720234
Re: [Pool] Any interest for a grease pencil tool?
I'd be interested, I'd pay $25.00 :) Christopher wavo Saturday, April 13, 2013 10:20 AM Same, very helpful and will/must buy If not for Free. :-). Walt -- Diese Nachricht wurde von meinem Android Mobiltelefon mit 11 Mail gesendet.
Re: [Pool] Any interest for a grease pencil tool?
Any link for this tool ? On Apr 13, 2013 6:11 PM, Christopher christop...@thecreativesheep.ca wrote: I'd be interested, I'd pay $25.00 :) Christopher wavo w...@fiftyeight.com Saturday, April 13, 2013 10:20 AM Same, very helpful and will/must buy If not for Free. :-). Walt -- Diese Nachricht wurde von meinem Android Mobiltelefon mit 11 Mail gesendet. compose-unknown-contact.jpg
Regarding the new unfold pack feature
Hi, I'm testing out SI2014 and the Unfold Pack feature. I created a cylinder mesh with a cylinder projection and a sphere mesh with a spherical projection. I selected both, went into the texture uv editor and used the tools-Unfold/Pack command, went to the pack tab and hit pack. All good so far, it packed the two projections as expected into the UV range of 0..1 (== nice). I was using the Textured display and had set the noicon texture to the diffuse of the default material so I could see what was happening to the UVs before and after the pack. So at this point, I wanted to test changing the input projection transform to simulate how I expected to be using this feature. I rotated the cylinder projection just to make it change to something noticeably different. The visible texture UVs didn't change, which I wasn't surprised by because obviously the packing algorithm takes some work and wouldn't make sense to be running all the time on the inputs. What I was surprised by was that repacking didn't grab the modified projection UVs.. from what I can tell, once you use the pack, the original projection is no longer used (however deleting the projection deletes the UV set). Looking at the cylinder's Texture_Coordinates_AUTO cluster branch in the SDK explorer I see there is a ClsSetValuesOp with input and output ports hooked into the cylinder projection, but the cylinder projection isn't restored (== tracking cylinder projection transform) until I delete this operator. It's acting like it's ignoring the input projection once it's been packed the one time. This seems counterintuitive and not like how most of Softimage seems to work with the construction stack and propagation of changes to dependant objects via operator ports. Is there any way to modify the UVs that are set up by the projection (for example by rotating the cylinder projection in my case) and use Unfold Pack again? Or is this intended to be a onetime operator that I suppose you would generally freeze? I feel like I'm missing something here so please excuse any obvious oversights.. Thanks in advance for any tips on making the most of this feature. -Eric Cosky
Re: shiffman for the win.. math tuts
i hate math ;), but thats really good stuff ! Thanks for the link ! 2013/4/13 Thomas Volkmann li...@thomasvolkmann.com Awesome!! Danke! /Thomas On 04/13/2013 03:13 PM, Sebastian Kowalski wrote: https://vimeo.com/shiffman/**videos https://vimeo.com/shiffman/videos great math explanations, mainly in Processing context but worth a look.
Re: Modo's Deformation (Weight Containers)
(this may be a stupid assumption) i didn't exactly follow all the dude was saying, thx matt for the clarification, his examples where very abstract... would being able to disassociate parent hierarchy have any effect on gimble lock ? making it easier to evade ? On 13 April 2013 17:23, Marco Peixoto mpe...@gmail.com wrote: At first I thought that it was a simple Pose based Deformation like Secondary Shape Modeling, but its not. He says that Modo has now a very similar Weighting System that Pixar uses (he doesnt say that on the video but he did on the forums) and that video was to show what Hippodrome (ex Pixar character Modeler) will be teaching on its coming iBook Art of Moving Points: http://hippydrome.com/iBookExmpls.html On 13-04-2013 16:06, Christopher wrote: I watched the video, interesting stuff, I'd like to see a comparison between what was shown in the video and Softimage, specifically what I liked in the Modo video was the sliding skin effect. Christopher Matt Lind ml...@carbinestudios.com Friday, April 12, 2013 11:19 PM Basically the guy took 24 minutes to explain a 2 minute concept. The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers' which are logical assignments of points to deformers. A different kind of weight map. The example shows an arm enveloped over 2 bones (3 joints). In Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. as you rotate the shoulder, the elbow and wrist would tag along for the ride via inheritance of the shoulder's transformation. If you rotate the elbow, the shoulder is unaffected, but the wrist moves because it inherit's the elbow's transformation. The point being the deformer has to reside in the location of the envelope deformation, and this can be inconvenient for thinking/viewing certain problems such as wanting to only rotate a deformer by a few degrees. in the case of the elbow, it may already be rotated to some arbitrary angle making adding/subtracting a few degrees difficult to visualize. In Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. they were scattered about wherever was convenient. This allowed the artist to work with the deformations in the local space of the deformer so if he wanted to say, limit envelope deformations to rotations of 10 degrees or less, the artist could easily see a 10 degree rotation and work with the deformer weights. think of it as compensation mode for vertices of an envelope. You apply the envelope to the defomers, but you can then offset the vertices where you want and maintain that relationship as metadata in the weight container. This allows the envelope to deform as desired, but not require the bones to be moving around with the envelope. Personally I don't find that useful in the general case, but maybe in a few rare niche cases it might have some benefit. The part I take issue with is not having bones in their usual places will make it difficult for animators to judge how the character is moving when adjusting keys. After all, you don't generally envelope a rig unless it's expected to be animated, so why disassociate the bones from the animator's perspective? The part of greater interest was pre-evaluation and post-evaluation events which gives the artist the opportunity to further modify the resulting deformation as each deformer is evaluated. The example given was not very good as it could be easily replicated using linked parameters to drive a lattice or some other easy control, but in more complex cases could be useful for sculpting the envelope deformation in very specific ways. You can replicate most of it in softimage using a different strategy than is typically used, but some of the more advanced stuff, such as compensation, would require a custom envelope operator or ICE. Matt -- *From:* softimage-boun...@listproc.autodesk.com [ softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron [ car...@gmail.com] *Sent:* Friday, April 12, 2013 6:53 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Modo's Deformation (Weight Containers) i want to watch it, but the speed is killing me... anyone care to summarize the feature(s)? Marco Peixoto mpe...@gmail.com Friday, April 12, 2013 5:37 PM This seems really interesting and a new way of dealing with Envelope Weights: http://vimeo.com/63720234 compose-unknown-contact.jpg
Re: shiffman for the win.. math tuts
Check out https://www.khanacademy.org also. Good stuff. On Sat, Apr 13, 2013 at 6:13 AM, Sebastian Kowalski l...@sekow.com wrote: https://vimeo.com/shiffman/videos great math explanations, mainly in Processing context but worth a look. -- -Gene
Re: Softimage promo
is it me, or did all the max features look ..Mickey Mouse ? they didn't look like very useful or serious additions , with the exception of the little search box thing, which in fairness is a blessing for max (modifier list anyone ?), but nothing outside of this seemed to give max an edge. On 13 April 2013 00:34, Bradley Gabe witha...@gmail.com wrote: No problem. As we all know, emails can be easily misunderstood. =) ** What exactly did you mean by that comment, Ed? :-Z
Re: Softimage promo
3ds max users I know were vey excited with this release. Specially regarding small annoying things, with viewport performance enhancemants/dx11 in a close seccond. A direct quote: Man now I can maximize my viewport only hovering the mouse. No need to make it active! This wowed me a lot as an SI user ;-) Em 13/04/2013 13:57, Sebastien Sterling sebastien.sterl...@gmail.com escreveu: is it me, or did all the max features look ..Mickey Mouse ? they didn't look like very useful or serious additions , with the exception of the little search box thing, which in fairness is a blessing for max (modifier list anyone ?), but nothing outside of this seemed to give max an edge. On 13 April 2013 00:34, Bradley Gabe witha...@gmail.com wrote: No problem. As we all know, emails can be easily misunderstood. =) ** What exactly did you mean by that comment, Ed? :-Z
Re: Modo's Deformation (Weight Containers)
actually, this is not really new and is quite similar to the way envelopping is done for years in the in-house 3D package at R+H from what I remember. They had a complete different way to do rigging/skinning that I was used to see in other studios. I wouldn't be surprised, this feature is coming from one of those big. -- jon Le samedi 13 avril 2013, Sebastien Sterling a écrit : (this may be a stupid assumption) i didn't exactly follow all the dude was saying, thx matt for the clarification, his examples where very abstract... would being able to disassociate parent hierarchy have any effect on gimble lock ? making it easier to evade ? On 13 April 2013 17:23, Marco Peixoto mpe...@gmail.com wrote: At first I thought that it was a simple Pose based Deformation like Secondary Shape Modeling, but its not. He says that Modo has now a very similar Weighting System that Pixar uses (he doesnt say that on the video but he did on the forums) and that video was to show what Hippodrome (ex Pixar character Modeler) will be teaching on its coming iBook Art of Moving Points: http://hippydrome.com/iBookExmpls.html On 13-04-2013 16:06, Christopher wrote: I watched the video, interesting stuff, I'd like to see a comparison between what was shown in the video and Softimage, specifically what I liked in the Modo video was the sliding skin effect. Christopher Matt Lind Friday, April 12, 2013 11:19 PM Basically the guy took 24 minutes to explain a 2 minute concept. The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers' which are logical assignments of points to deformers. A different kind of weight map. The example shows an arm enveloped over 2 bones (3 joints). In Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. as you rotate the shoulder, the elbow and wrist would tag along for the ride via inheritance of the shoulder's transformation. If you rotate the elbow, the shoulder is unaffected, but the wrist moves because it inherit's the elbow's transformation. The point being the deformer has to reside in the location of the envelope deformation, and this can be inconvenient for thinking/viewing certain problems such as wanting to only rotate a deformer by a few degrees. in the case of the elbow, it may already be rotated to some arbitrary angle making adding/subtracting a few degrees difficult to visualize. In Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. they were scattered about wherever was convenient. This allowed the artist to work with the deformations in the local space of the deformer so if he wanted to say, limit envelope deformations to rotations of 10 degrees or less, the artist could easily see a 10 degree rotation and work with the deformer weights. think of it as compensation mode for vertices of an envelope. You apply the envelope to the defomers, but compose-unknown-contact.jpg
Re: Softimage promo
na the dx 11 is cool but its seems to becoming standardised, max was over due for some UI enhancements, view port switching was painful before, i remember that, but I was speaking more specifically about the larger features. which is ironic when you think about it, the little tweaks and fixes are more interesting then the key features discussed. On 13 April 2013 20:12, Gustavo Eggert Boehs gustav...@gmail.com wrote: 3ds max users I know were vey excited with this release. Specially regarding small annoying things, with viewport performance enhancemants/dx11 in a close seccond. A direct quote: Man now I can maximize my viewport only hovering the mouse. No need to make it active! This wowed me a lot as an SI user ;-) Em 13/04/2013 13:57, Sebastien Sterling sebastien.sterl...@gmail.com escreveu: is it me, or did all the max features look ..Mickey Mouse ? they didn't look like very useful or serious additions , with the exception of the little search box thing, which in fairness is a blessing for max (modifier list anyone ?), but nothing outside of this seemed to give max an edge. On 13 April 2013 00:34, Bradley Gabe witha...@gmail.com wrote: No problem. As we all know, emails can be easily misunderstood. =) ** What exactly did you mean by that comment, Ed? :-Z
Re: Modo's Deformation (Weight Containers)
It reminds me of weighting in Maya how each of the maps were separate...what a PITA! Maya had (and maybe still has --I haven't looked at 2014) the worst enveloping blech! On Sat, Apr 13, 2013 at 1:33 PM, jo benayoun jobenay...@gmail.com wrote: actually, this is not really new and is quite similar to the way envelopping is done for years in the in-house 3D package at R+H from what I remember. They had a complete different way to do rigging/skinning that I was used to see in other studios. I wouldn't be surprised, this feature is coming from one of those big. -- jon Le samedi 13 avril 2013, Sebastien Sterling a écrit : (this may be a stupid assumption) i didn't exactly follow all the dude was saying, thx matt for the clarification, his examples where very abstract... would being able to disassociate parent hierarchy have any effect on gimble lock ? making it easier to evade ? On 13 April 2013 17:23, Marco Peixoto mpe...@gmail.com wrote: At first I thought that it was a simple Pose based Deformation like Secondary Shape Modeling, but its not. He says that Modo has now a very similar Weighting System that Pixar uses (he doesnt say that on the video but he did on the forums) and that video was to show what Hippodrome (ex Pixar character Modeler) will be teaching on its coming iBook Art of Moving Points: http://hippydrome.com/iBookExmpls.html On 13-04-2013 16:06, Christopher wrote: I watched the video, interesting stuff, I'd like to see a comparison between what was shown in the video and Softimage, specifically what I liked in the Modo video was the sliding skin effect. Christopher Matt Lind Friday, April 12, 2013 11:19 PM Basically the guy took 24 minutes to explain a 2 minute concept. The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers' which are logical assignments of points to deformers. A different kind of weight map. The example shows an arm enveloped over 2 bones (3 joints). In Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. as you rotate the shoulder, the elbow and wrist would tag along for the ride via inheritance of the shoulder's transformation. If you rotate the elbow, the shoulder is unaffected, but the wrist moves because it inherit's the elbow's transformation. The point being the deformer has to reside in the location of the envelope deformation, and this can be inconvenient for thinking/viewing certain problems such as wanting to only rotate a deformer by a few degrees. in the case of the elbow, it may already be rotated to some arbitrary angle making adding/subtracting a few degrees difficult to visualize. In Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. they were scattered about wherever was convenient. This allowed the artist to work with the deformations in the local space of the deformer so if he wanted to say, limit envelope deformations to rotations of 10 degrees or less, the artist could easily see a 10 degree rotation and work with the deformer weights. think of it as compensation mode for vertices of an envelope. You apply the envelope to the defomers, but -- -=T=- compose-unknown-contact.jpg
Re: [Pool] Any interest for a grease pencil tool?
I think Thiago Costa already made one a while ago : http://thiagocosta.net/tc-sketch-v11-grease-pencil-for-xsi/ The link to the addon is dead, but lucky for us there's www.rray.de, just do a search for TC Sketch there. - Ronald On 4/13/2013 2:34, Ahmidou Lyazidi wrote: Hello guys, I'm thinking of making a grease pencil tool, but I would like to know if there is a real interest in it, and what would be a faire price for this kind of tool Thanks --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos
Re: [Pool] Any interest for a grease pencil tool?
You're right, well this is no longer a wish. What Thiago built could be 'enhanced' by a brush type thickness instead of bland curves. Christopher Toonafish Saturday, April 13, 2013 7:47 PM I think Thiago Costa already made one a while ago : http://thiagocosta.net/tc-sketch-v11-grease-pencil-for-xsi/ The link to the addon is dead, but lucky for us there's www.rray.de, just do a search for "TC Sketch" there. - Ronald Ahmidou Lyazidi Friday, April 12, 2013 8:34 PM Hello guys,I'm thinking of making a grease pencil tool, but I would like to know if there is a real interest in it, and what would be a faire price for this kind of toolThanks ---Ahmidou LyazidiDirector | TD | CG artisthttp://vimeo.com/ahmidou/videos
Re: Custom Documentation
You can set the .Help attribute in your registration method (I think it's .Help .. might be something else; look up the ppg examples) reg.Help = 'Path to your html help'
Re: Custom Documentation
AAAhhh, sorry Alok, just saw your reply. -__- On Sun, Apr 14, 2013 at 12:03 PM, Xavier Lapointe xl.mailingl...@gmail.comwrote: You can set the .Help attribute in your registration method (I think it's .Help .. might be something else; look up the ppg examples) reg.Help = 'Path to your html help' -- Xavier
testing 123
is this thing on? -- Signature *Tim Crowson */Lead CG Artist/ *Magnetic Dreams, Inc. *2525 Lebanon Pike, Building C. Nashville, TN 37214 *Ph* 615.885.6801 | *Fax* 615.889.4768 | www.magneticdreams.com tim.crow...@magneticdreams.com
Re: testing 123
nope ;) ...yes receiving loud and clear :) On Sat, Apr 13, 2013 at 10:06 PM, Tim Crowson tim.crow...@magneticdreams.com wrote: is this thing on? -- *Tim Crowson **Lead CG Artist* *Magnetic Dreams, Inc. *2525 Lebanon Pike, Building C. Nashville, TN 37214 *Ph* 615.885.6801 | *Fax* 615.889.4768 | www.magneticdreams.com tim.crow...@magneticdreams.com -- -=T=-
Re: Custom Documentation
Alright that works for some of what I need. So there is no way for compounds huh? On Sun, Apr 14, 2013 at 4:05 AM, Xavier Lapointe xl.mailingl...@gmail.comwrote: AAAhhh, sorry Alok, just saw your reply. -__- On Sun, Apr 14, 2013 at 12:03 PM, Xavier Lapointe xl.mailingl...@gmail.com wrote: You can set the .Help attribute in your registration method (I think it's .Help .. might be something else; look up the ppg examples) reg.Help = 'Path to your html help' -- Xavier
Re: Custom Documentation
I don't have xsi in front of me, but you can have a look if you right click/properties on your custom compound..
Re: Custom Documentation
Thanks for the suggestion Xavier, but that is the first place I checked. Unfortunately that functionality isn't there as far as I could see. Seems like kind of an oversight and also an easy to implement feature. On Sun, Apr 14, 2013 at 5:35 AM, Xavier Lapointe xl.mailingl...@gmail.comwrote: I don't have xsi in front of me, but you can have a look if you right click/properties on your custom compound..
Re: Custom Documentation
Oh my bad, I checked it again and there is indeed something there just not like I hoped. After putting in the URL you can right click on the compound and choose Open Netview on URL. It's unfortunate that one can't utilize the property page's help button, but this is definitely adequate. Thanks for the nudge in the right direction. On Sun, Apr 14, 2013 at 5:37 AM, Leonard Koch leonardkoch...@gmail.comwrote: Thanks for the suggestion Xavier, but that is the first place I checked. Unfortunately that functionality isn't there as far as I could see. Seems like kind of an oversight and also an easy to implement feature. On Sun, Apr 14, 2013 at 5:35 AM, Xavier Lapointe xl.mailingl...@gmail.com wrote: I don't have xsi in front of me, but you can have a look if you right click/properties on your custom compound..
Re: Modo's Deformation (Weight Containers)
Hey guys, Tim showed me this thread and I figured I would try to explain things a bit if I can. But first let me say I'm a big fan of XSI and the work you guys do, though I have never used it myself, my officemate does and i find it pretty awesome overall. OK... I'm going to start with going through Matt's mail and see if I can clarify things Basically the guy took 24 minutes to explain a 2 minute concept. Its true, I did take the long way around. My goal was to make sure that everyone... if they were complete newbies, or seasoned veterans could grasp things. I have been amazed at how hard the idea of abstracted weights has been for people so I took my time. I was also asked by Hippy to breakdown somethings in the way he wanted so there was some time there too. The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers' which are logical assignments of points to deformers. A different kind of weight map. You can assign a standard weight map to a deformer too, weight containers are just another method to do so. As Tim points out, a Weight Container is really more like a Weight Map Item (or Proxy) it allows you to feed them into deformers even when no points or weighting has been added to them. The key concept here is that with WCs you can build a complete rig with no mesh involved at all... load this into a scene and then just add the points you want to weight into the WCs and the deformation setup will work on them. Once you do add the points in them, you can adjust the weights like you would with any weight map. SNIPIn Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. SNIP In Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. SNIP Modo allows you to work in this traditional method too... add a set of joints, in a hierarchy, to a mesh through the bind command and all of the joints will be assigned a set of weight maps. You can then add or subtract weights like you are used too... if you add to one joint it will take away from another. The WC way of working is not the only way. Also there is no metadata on a Weight Container, as far as the system is concerned its just another weight map. Its just defined a bit differently and provides a more flexible approach to how weights, rigs are applied and created. The part I take issue with is not having bones in their usual places will make it difficult for animators to judge how the character is moving when adjusting keys. After all, you don't generally envelope a rig unless it's expected to be animated, so why disassociate the bones from the animator's perspective? I did not cover all the different ways to use Order of Operation (OOO) deformations with using a hierarchy... so let me try and clarify a bit. You can use a standard hierarchy of bones if you want with the OOO method (with or without using Weight Containers) you just need to tell your joints to pass their local transformations into the deformer (which is just setting on the joints themselves). So you could have your standard set of joints and the animator can have access to them in the way you describe there. There are also other ways to provide controls to animators that don't require the joints... more on that another time. Anyway, I didn't show local transformations in the video because I was trying to make the idea of OOO very clear. To show the joints moving in local space seemed like it would cause more confusion. The part of greater interest was pre-evaluation and post-evaluation events which gives the artist the opportunity to further modify the resulting deformation as each deformer is evaluated. This is THE most important part of modo's deformation pipeline... Order of Operation. Its something I was exposed to at Rhythm and Hues and it was a mind blowing, eye opening experience for me. When I saw that modo was tackling deformations in the same way I was very excited. I was also impressed that Luxology was able to come up with a way to provide the standard normalized approach to weighting in a OOO system (using normalization groups). Basically you can have your deformation cake and eat it too. The example given was not very good as it could be easily replicated using linked parameters to drive a lattice or some other easy control, but in more complex cases could be useful for sculpting the envelope deformation in very specific ways. That example was more illustrative of the issue at hand than a true practical case, that said, its how I would handle sculpt offsets for an elbow I was rigging too. I personally find it about as strait forward as you can get. I like having explicit point control over my shape. You can replicate most of it in softimage using a
Re: Modo's Deformation (Weight Containers)
Modo system is not hundred percent, quite different from Softimage. How come Modo can do sliding skin and it seems that Softimage method I need amount of time to setup, no walks in the park nothing ? :) Christopher Richard Hurrey Sunday, April 14, 2013 12:27 AM Hey guys, Tim showed me this thread and I figured I would try toexplainthings a bit if I can. But first let me say I'm a big fan of XSI and the work you guys do, though I have never used it myself, my officemate does and i find it pretty awesome overall.OK... I'm going to start with going through Matt's mail and see if I can clarify thingsBasically the guy took 24 minutes to explain a 2 minute concept.Its true, I did take the long way around. My goal was to make sure that everyone... if they were complete newbies, or seasonedveteranscould grasp things. I have been amazed at how hard the idea of abstracted weights has been for people so I took my time. I was also asked by Hippy to breakdown somethings in the way he wanted so there was some time there too.The main point is Modo can define the order in which deformers are evaluated to solve envelope weights, and envelope weights are assigned using 'weight containers'which are logical assignments of points to deformers. A different kind of weight map.You can assign a standard weight map to a deformer too, weight containers are just anothermethodto do so.As Tim points out, a Weight Container is really more like a Weight Map Item (or Proxy) it allows you to feed them into deformers even when no points or "weighting" has been added to them. The key concept here is that with WCs you can build a complete rig with no mesh involved at all... load this into a scene and then just add the points you want to weight into the WCs and the deformation setup will work on them. Once you do add the points in them, you can adjust the weights like you would with any weight map.SNIPIn Softimage you'd normally place the bones into a hierarchy and assign the weights to the joints. SNIPIn Modo, the weights were assigned to the individual bones via 'weight containers' (their version of a weight map), but the bones were not placed into a hiearchy. SNIPModo allows you to work in this traditional method too... add a set of joints, in a hierarchy, to a mesh through the "bind" command and all of the joints will be assigned a set of weight maps. You can then add or subtractweightslike you are used too... if you add to one joint it will take away from another. The WC way of working is not the only way.Also there is no "metadata" on a Weight Container, as far as the system is concerned its just another weight map. Its just defined a bit differently and provides a more flexible approach to how weights, rigs are applied and created.The part I take issue with is not having bones in their usual places will make it difficult for animators to judge how the character is moving when adjusting keys. After all, you don't generally envelope a rig unless it's expected to be animated, so why disassociate the bones from the animator's perspective?I did not cover all the different ways to use Order of Operation (OOO) deformations with using a hierarchy... so let me try and clarify a bit. You can use astandardhierarchy of bones if you want with the OOO method (with or without using Weight Containers) you just need to tell your joints to pass their local transformations into the deformer (which is just setting on the joints themselves). So you could have your standard set of joints and the animator can have access to them in the way you describe there. There are also other ways to provide controls to animators that don't require the joints... more on that another time.Anyway, I didn't show local transformations in the videobecauseI was trying to make the idea of OOO very clear. To show the joints moving in local space seemed like it wouldcausemore confusion.The part of greater interest was pre-evaluation and post-evaluation events which gives the artist the opportunity to further modify the resulting deformation as eachdeformer is evaluated. This is THE most important part of modo's deformation pipeline... Order of Operation. Its something I was exposed to atRhythmand Hues and it was a mind blowing, eye opening experience for me. When I saw that modo was tackling deformations in the same way I was very excited. I was also impressed that Luxology was able to come up with a way to provide the standard normalized approach to weighting in a OOO system (using normalization groups). Basically you can have your deformation cake and eat it too.The example given was not very good as it could be easily replicated using linked parameters to drive a lattice or some other easy control, but in more complex cases could be useful for sculpting the envelope deformation in very specific ways.That example was more illustrative of the issue at hand than a true
