Re: Installing Deadline for Softimage 2012
Hey David, I never had any problems with installing deadline since 2011... Python is inside SI already so no need to install anything else Python related. One and only thing needed is to copy SubmitXSIToDeadline.py into your Softimage/Application/Plugins folder and that is it. Absolutely nothing else needed. See if that works On Wed, May 22, 2013 at 1:05 AM, David Rivera activemotionpictu...@yahoo.com wrote: Hello. Anyone had had experience installing Deadline for softimage? i´ve followed this: http://www.thinkboxsoftware.com/deadline-5-softimage#Integrated_Submission_Script_Setup And I still can´t get the dialogue up on the Render module RenderSend to Deadline after setting up preferences for Python on softimage 2012. I believe Python is already installed on softimage 2012, because I see the option python from the scripts preferences. Hence, I opened up a script dialogue in python, and dragged and dropped the .py script that comes for installing on (applications)/softimage/application/plugins I restart softimage, but still I don´t see the dialogue. If anyone could lend me a hand with this, I´d appreciate it a lot. Thanks. David R.
RE: Mill 98 Human
OMG. Very emotional piece, and great technical info. It'd be nice to see a screenshot of the facial rig J So basically, the hair was based upon XSI Hair, and Melena was used to create the final look? Melena is great, it's a shame that it is discontinued. I am very interested in the muscle rig as well, I've seen the weightmap is animated during the walk cycle. It's some kind of stressmap? Amazing piece, I hope one day Mill will make a tutorial book... Cheers Szabolcs PS. Videos like this makes me consider leaving games industry to the VFX... From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Peter Agg Sent: Tuesday, May 21, 2013 11:34 PM To: softimage@listproc.autodesk.com Subject: Re: Mill 98 Human Just to add to what Jimmy nicely rounded up: the facial animation rig was pretty much all done with envelope deformers rather than blend shapes. Chimp lips are surprisingly flexible so having the deformers being driven by curves was certainly the way to go with that. The eyelids were also controlled with nulls looking at curves so the animators could define pretty much exactly what kind of shape they wanted - there's a lot of nice, subtle movement in them which is pretty much all down to their keen eyes and decision-making, really. Not much of it was automated so they did a really nice job - pretty much everything you see was something they chose to move, I just gave them the option! Throw on a few sticky controls in key areas for secondary movement and you've pretty much got it as far as the control rig went. Then off it went to Vince's muscle system (though by that stage I unfortunately had to head back to the UK office, so I never got to see the cool stuff in action). On 21 May 2013 22:05, jimmy gass ji...@nervegass.net wrote: No strand caching. We wanted to save our self the extra step, since there were already like 5 stages of cache and sim. So the strands were left live. To get Motion blur to behave properly, I just made a compound at the front of the entire system, that calculated the strand velocity and stored that every frame, but then set it back to what it was the frame before at the beginning of the sim to keep the behavior right. Basically just forcing the velocities for the rendered to do what it needs to do. That node has become quite popular here for that purpose.
Re: Mill 98% Human
We had this too - we used end on frame setting in the end to get as close as possible! S. On 21/05/2013 22:17, Steven Caron wrote: ok, thanks. we tried strand velocity but had issues with underlying geometry being blurred differently. On Tue, May 21, 2013 at 2:05 PM, jimmy gass ji...@nervegass.net mailto:ji...@nervegass.net wrote: No strand caching. We wanted to save our self the extra step, since there were already like 5 stages of cache and sim. So the strands were left live. To get Motion blur to behave properly, I just made a compound at the front of the entire system, that calculated the strand velocity and stored that every frame, but then set it back to what it was the frame before at the beginning of the sim to keep the behavior right. Basically just forcing the velocities for the rendered to do what it needs to do. That node has become quite popular here for that purpose.
Re: Setting and Manipulating Keys Very slow in Referenced Model
I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen
[OT]? add GPL to code
Hello everyone, I was just wondering if anyone has added GPL to their code, and how the practice is. I looked at how they have done in the blender python scripts. So I need to add that block to each file? Anyone experienced in this sort of thing? regards stefan -- *Stefan Andersson | Digital Janitor **| Generalist for hire * blog http://sanders3d.wordpress.com | showreelhttp://www.youtube.com/watch?v=qVb8yvxZcss| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| Instagram http://instagram.com/sanders3d_ | cell: +46-73-6268850 | skype:sanders3d
Re: Setting and Manipulating Keys Very slow in Referenced Model
That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: [OT]? add GPL to code
If you're distributing, since you never pay for comments, just add it in every file. If you're not distributing just avoid caring altogether :p On Wed, May 22, 2013 at 6:38 PM, Stefan Andersson sander...@gmail.comwrote: Hello everyone, I was just wondering if anyone has added GPL to their code, and how the practice is. I looked at how they have done in the blender python scripts. So I need to add that block to each file? Anyone experienced in this sort of thing? regards stefan -- *Stefan Andersson | Digital Janitor **| Generalist for hire * blog http://sanders3d.wordpress.com | showreelhttp://www.youtube.com/watch?v=qVb8yvxZcss| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| Instagram http://instagram.com/sanders3d_ | cell: +46-73-6268850 | skype:sanders3d -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: Setting and Manipulating Keys Very slow in Referenced Model
Yep you are right Raff - but at that time we did not have any asset system going, ask Simon - he and I had the brunt of that. S. On 22/05/2013 09:51, Raffaele Fragapane wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com mailto:sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S.
Re: Setting and Manipulating Keys Very slow in Referenced Model
We do live referencing here as we don't have much for versioning control at this small studio. Its worked fine for us so far as our rigs are pretty simple and eventually development stops for them on a project. Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. We also don't have enough coordinators to keep track of what shot gets what rig, or the development man power to update our pipeline. Tiny shop in Singapore, very difficult to find talented developers. Until then I've written a bunch of delta cleaning scripts that can solve 90% of our issues, and what was most important for us, was that we are very careful about how we import referenced models so that no unnecessary information gets written to the delta. So if a rig change does happen, the delta wont freak out and break the rig. Basically via scripting, I create an empty referenced model, populate the paths for the rig resolutions, add an empty delta, set the proper settings, disabling the evil ones, and then finally setting the active resolution. I have found this technique to be absolutely essential to making sure our deltas don't store any extra nonsense in them that would eventually clash with a rig change. Otherwise if the animator simply did a vanilla import referenced model this referenced model would have a delta on it thats fully enabled, and it would immediately store a bunch of useless crap under stored expressions/stored positions that would eventually cause the rig to explode when we did the next rig update. Aside from that, when something bad happens, I run one of 3 delta cleaners if necessary, but to be honest it hasnt happened much in a very long time. I am very open minded, but i also know the animators at this company very well. If I gave them a local model pipeline they would bring this studio to its knees and I would be out of a job very quickly On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: Mill 98% Human
It is spectacular, great work . Thanks for sharing the details! Interesting especially to hear how you have used the old hair to groom - I also find the ICE hair tools coming short in that respect. Morten Den 21. maj 2013 kl. 22:41 skrev jimmy gass ji...@nervegass.net: Thanks everyone. The hair was nothing revolutionary. It was using the Melena set up to convert the XSI hair to curves, then the curves to strands. It wasnt fast. It's just a lot easier to groom that way, using the built in hair system. Especially using a lowrez hair set up and copy styles to a highrez set up. So that is what you saw on the behind the scenes. The basic groom was combed the old school way, then layers of ICE manipulations on top of that to get more variation, color dynamics etc. Dave Barosin helped in getting the hair dynamics to work with a pretty ingenious set up. Vince built the muscle setup which I'm not really able to comment on too much. He handed a cache of that geometry over to me, and I had a skin simulation stage that is basically a verlet set up that conforms to the muscles. It was used mostly for the body, but was also used sparingly on the face. (the stuff you see in the behinds the scenes is an embarrassingly old test scene, but you can see the verlet wrinkles) The face was largely done with maps to drive deformation at render time. Based on the compression and stretch of the underlying geometry. Rendered in Arnold. With Keven Ives and Thomas Bardwell handling most of the shading and lighting.
Re: [OT]? add GPL to code
well I'm adding it to a public bitbucket repo, so I guess I'll have to add it to each file. regards stefan On Wed, May 22, 2013 at 10:52 AM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: If you're distributing, since you never pay for comments, just add it in every file. If you're not distributing just avoid caring altogether :p On Wed, May 22, 2013 at 6:38 PM, Stefan Andersson sander...@gmail.comwrote: Hello everyone, I was just wondering if anyone has added GPL to their code, and how the practice is. I looked at how they have done in the blender python scripts. So I need to add that block to each file? Anyone experienced in this sort of thing? regards stefan -- *Stefan Andersson | Digital Janitor **| Generalist for hire * blog http://sanders3d.wordpress.com | showreelhttp://www.youtube.com/watch?v=qVb8yvxZcss| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| Instagram http://instagram.com/sanders3d_ | cell: +46-73-6268850 | skype:sanders3d -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- *Stefan Andersson | Digital Janitor **| Generalist for hire * blog http://sanders3d.wordpress.com | showreelhttp://www.youtube.com/watch?v=qVb8yvxZcss| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| Instagram http://instagram.com/sanders3d_ | cell: +46-73-6268850 | skype:sanders3d
Re: Setting and Manipulating Keys Very slow in Referenced Model
Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. I'd start with some off the shelf version control software to do half of the work for you (perforce, maybe svn etc.), a rather simple database on top of this and some UI usually does the job for most cases where assets are not too complex and relatively lightweight, ie. mesh/rig character type assets. What I am saying is it doesn't really take much to get a system like this going and benefits can be potentially really big. Sorry for being bit off topic. On 22 May 2013 10:00, Enrique Caballero enriquecaball...@gmail.com wrote: We do live referencing here as we don't have much for versioning control at this small studio. Its worked fine for us so far as our rigs are pretty simple and eventually development stops for them on a project. Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. We also don't have enough coordinators to keep track of what shot gets what rig, or the development man power to update our pipeline. Tiny shop in Singapore, very difficult to find talented developers. Until then I've written a bunch of delta cleaning scripts that can solve 90% of our issues, and what was most important for us, was that we are very careful about how we import referenced models so that no unnecessary information gets written to the delta. So if a rig change does happen, the delta wont freak out and break the rig. Basically via scripting, I create an empty referenced model, populate the paths for the rig resolutions, add an empty delta, set the proper settings, disabling the evil ones, and then finally setting the active resolution. I have found this technique to be absolutely essential to making sure our deltas don't store any extra nonsense in them that would eventually clash with a rig change. Otherwise if the animator simply did a vanilla import referenced model this referenced model would have a delta on it thats fully enabled, and it would immediately store a bunch of useless crap under stored expressions/stored positions that would eventually cause the rig to explode when we did the next rig update. Aside from that, when something bad happens, I run one of 3 delta cleaners if necessary, but to be honest it hasnt happened much in a very long time. I am very open minded, but i also know the animators at this company very well. If I gave them a local model pipeline they would bring this studio to its knees and I would be out of a job very quickly On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- -- Michal http://uk.linkedin.com/in/mdoniec
Re: Setting and Manipulating Keys Very slow in Referenced Model
Hey Michal, Your definitely right. Its something we should look into -E On Wed, May 22, 2013 at 7:05 PM, Michal Doniec doni...@gmail.com wrote: Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. I'd start with some off the shelf version control software to do half of the work for you (perforce, maybe svn etc.), a rather simple database on top of this and some UI usually does the job for most cases where assets are not too complex and relatively lightweight, ie. mesh/rig character type assets. What I am saying is it doesn't really take much to get a system like this going and benefits can be potentially really big. Sorry for being bit off topic. On 22 May 2013 10:00, Enrique Caballero enriquecaball...@gmail.comwrote: We do live referencing here as we don't have much for versioning control at this small studio. Its worked fine for us so far as our rigs are pretty simple and eventually development stops for them on a project. Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. We also don't have enough coordinators to keep track of what shot gets what rig, or the development man power to update our pipeline. Tiny shop in Singapore, very difficult to find talented developers. Until then I've written a bunch of delta cleaning scripts that can solve 90% of our issues, and what was most important for us, was that we are very careful about how we import referenced models so that no unnecessary information gets written to the delta. So if a rig change does happen, the delta wont freak out and break the rig. Basically via scripting, I create an empty referenced model, populate the paths for the rig resolutions, add an empty delta, set the proper settings, disabling the evil ones, and then finally setting the active resolution. I have found this technique to be absolutely essential to making sure our deltas don't store any extra nonsense in them that would eventually clash with a rig change. Otherwise if the animator simply did a vanilla import referenced model this referenced model would have a delta on it thats fully enabled, and it would immediately store a bunch of useless crap under stored expressions/stored positions that would eventually cause the rig to explode when we did the next rig update. Aside from that, when something bad happens, I run one of 3 delta cleaners if necessary, but to be honest it hasnt happened much in a very long time. I am very open minded, but i also know the animators at this company very well. If I gave them a local model pipeline they would bring this studio to its knees and I would be out of a job very quickly On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- -- Michal http://uk.linkedin.com/in/mdoniec
Delete particles based on U value
Hi there ! I'm emiting particles from curve. I'd like to emit more particle at the beginning of the curve and less at the end of the curve. Since I cannot plug the the U value in the Rate port of the emitter, I think I should create a Delete rule based on particle IDs. So that I delete more particles closer to the U end (0) and and delete less particle that are closer to the U begining (1) value of the curve. I think, I should do it with a random on the ID, and probably some Fcurve... But so far, I can't have it working... Any idea ? Thanks !
Aw: Delete particles based on U value
On top of my head: Get Self.emitlocation - Get PointU - FCurve - Test Random Probability - Delete Point - Execute on Emit Gesendet:Mittwoch, 22. Mai 2013 um 13:13 Uhr Von:olivier jeannel olivier.jean...@noos.fr An:softimage@listproc.autodesk.com Betreff:Delete particles based on U value Hi there ! Im emiting particles from curve. Id like to emit more particle at the beginning of the curve and less at the end of the curve. Since I cannot plug the the U value in the Rate port of the emitter, I think I should create a Delete rule based on particle IDs. So that I delete more particles closer to the U end (0) and and delete less particle that are closer to the U begining (1) value of the curve. I think, I should do it with a random on the ID, and probably some Fcurve... But so far, I cant have it working... Any idea ? Thanks !
Re: Delete particles based on U value
filter by probability multiplied by a linearly interpolated curve U of 0 - 1 et viola! :) On 22 May 2013 13:13, olivier jeannel olivier.jean...@noos.fr wrote: Hi there ! I'm emiting particles from curve. I'd like to emit more particle at the beginning of the curve and less at the end of the curve. Since I cannot plug the the U value in the Rate port of the emitter, I think I should create a Delete rule based on particle IDs. So that I delete more particles closer to the U end (0) and and delete less particle that are closer to the U begining (1) value of the curve. I think, I should do it with a random on the ID, and probably some Fcurve... But so far, I can't have it working... Any idea ? Thanks !
Re: Aw: Delete particles based on U value
Exactly ! ...Damn the compound was already existing ! Thank's Leo, thank's Rob :) Le 22/05/2013 13:31, Leo Quensel a écrit : On top of my head: Get Self.emitlocation - Get PointU - FCurve - Test Random Probability - Delete Point - Execute on Emit *Gesendet:* Mittwoch, 22. Mai 2013 um 13:13 Uhr *Von:* olivier jeannel olivier.jean...@noos.fr *An:* softimage@listproc.autodesk.com *Betreff:* Delete particles based on U value Hi there ! I'm emiting particles from curve. I'd like to emit more particle at the beginning of the curve and less at the end of the curve. Since I cannot plug the the U value in the Rate port of the emitter, I think I should create a Delete rule based on particle IDs. So that I delete more particles closer to the U end (0) and and delete less particle that are closer to the U begining (1) value of the curve. I think, I should do it with a random on the ID, and probably some Fcurve... But so far, I can't have it working... Any idea ? Thanks !
Re: [OT]? add GPL to code
If you are using a library, just add a GPL license to that folder or something like that. One piece of GPL code in a project tends to make the whole project GPL. I'd recommend keeping it very simple and just put a LICENSE.TXT file at the root of the whole project and append the various licenses together with a mention where each project came from. Updating per-file licenses is a pain in the ass. Best regards, -ben On Wed, May 22, 2013 at 6:36 AM, Stefan Andersson sander...@gmail.com wrote: well I'm adding it to a public bitbucket repo, so I guess I'll have to add it to each file. regards stefan On Wed, May 22, 2013 at 10:52 AM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: If you're distributing, since you never pay for comments, just add it in every file. If you're not distributing just avoid caring altogether :p On Wed, May 22, 2013 at 6:38 PM, Stefan Andersson sander...@gmail.com wrote: Hello everyone, I was just wondering if anyone has added GPL to their code, and how the practice is. I looked at how they have done in the blender python scripts. So I need to add that block to each file? Anyone experienced in this sort of thing? regards stefan -- Stefan Andersson | Digital Janitor | Generalist for hire blog | showreel | twitter | LinkedIn | Instagram | cell: +46-73-6268850 | skype:sanders3d -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- Stefan Andersson | Digital Janitor | Generalist for hire blog | showreel | twitter | LinkedIn | Instagram | cell: +46-73-6268850 | skype:sanders3d -- Best regards, Ben Houston Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom http://Exocortex.com - Passionate CG Software Professionals.
Re: Mill 98% Human
Awesome! Not only the CG but everything was amazing. And thanks for sharing details ! Can I ask how many people and months did it take? M.Yara
Re: Mill 98% Human
That is beautiful stuff. -- Best regards, Ben Houston Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom http://Exocortex.com - Passionate CG Software Professionals.
Re: Mill 98% Human
Ha! That's because Jimmy Gas is way too modest. Awesome work guys! Eric On Tue, May 21, 2013 at 5:14 PM, Ajit Menon xsia...@gmail.com wrote: When Jimmy says it was nothing, that usually means he only built about 20 custom ICE compounds or so to do his bidding... On Tue, May 21, 2013 at 5:05 PM, jimmy gass ji...@nervegass.net wrote: No strand caching. We wanted to save our self the extra step, since there were already like 5 stages of cache and sim. So the strands were left live. To get Motion blur to behave properly, I just made a compound at the front of the entire system, that calculated the strand velocity and stored that every frame, but then set it back to what it was the frame before at the beginning of the sim to keep the behavior right. Basically just forcing the velocities for the rendered to do what it needs to do. That node has become quite popular here for that purpose. -- Ajit Ajit Menon | CGI artist www.ajitmenon.com Success is not found in what you have achieved, but rather in WHO you have become. - Larry Bertlemann -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work
Re: Mill 98% Human
Impressive work. With the quality of The Mill, as usual. Congratulations! *Javier Vega* www.zao3d.com Visita mi blog: http://blog.zao3d.com móvil: *616 64 73 57* 08922-Santa Coloma de Gramenet (Barcelona) 2013/5/22 Eric Lampi ericla...@gmail.com Ha! That's because Jimmy Gas is way too modest. Awesome work guys! Eric On Tue, May 21, 2013 at 5:14 PM, Ajit Menon xsia...@gmail.com wrote: When Jimmy says it was nothing, that usually means he only built about 20 custom ICE compounds or so to do his bidding... On Tue, May 21, 2013 at 5:05 PM, jimmy gass ji...@nervegass.net wrote: No strand caching. We wanted to save our self the extra step, since there were already like 5 stages of cache and sim. So the strands were left live. To get Motion blur to behave properly, I just made a compound at the front of the entire system, that calculated the strand velocity and stored that every frame, but then set it back to what it was the frame before at the beginning of the sim to keep the behavior right. Basically just forcing the velocities for the rendered to do what it needs to do. That node has become quite popular here for that purpose. -- Ajit Ajit Menon | CGI artist www.ajitmenon.com Success is not found in what you have achieved, but rather in WHO you have become. - Larry Bertlemann -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work
Blog/tutorial: Import/export of custom ICE attributes with Exocortex Crate/Alembic
Hi all, We've been so busy updating Exocortex Crate/Alembic that we really haven't posted much on this list about it. But I figured this recent feature additional might be of interest. We now support export and importing of custom ICE attributes on just about any Softimage primitive (meshes, point clouds, curves, etc.). Mauricio Vines just wrote up a blog post / tutorial on it here if it is of interest: http://exocortex.com/blog/crate_custom_attribute_softimage -- Best regards, Ben Houston Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom http://Exocortex.com - Passionate CG Software Professionals.
Re: custom operators and changing topology
Hi Songqiong sadly I'm still on 2012.SAP Ran On Tue, May 21, 2013 at 10:11 PM, Songqiong Yang songqiong.y...@autodesk.com wrote: Hi Ran, Which Softimage version are you using? Since 2013 SP1, there're two new C++ APIs introduced, to allow the creation of paramdef with a specified classification. 1. Factory::CreateParamDef CreateParamDef http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Factory.html#a3badfe123fc78a4353347e7c2de0d270 (const CString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataType http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassification http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, const CString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.htmlin_name, const CString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmin, constCValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, CStatus http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CStatus.html *pst=0) 2. CustomProperty::AddParameter AddParameter http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CustomProperty.html#a3cd8cb29aea12aad508cfc2d623dc836 (const CString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataType http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassification http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, constCString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_name, const CString http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.htmlin_suggestedmin, const CValue http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, Parameter http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Parameter.html io_parameter) Thanks, Joany From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi Sent: Wednesday, May 22, 2013 8:00 AM To: softimage@listproc.autodesk.com Subject: Re: custom operators and changing topology what is your debuger saying? --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos 2013/5/22 Matt Lind ml...@carbinestudios.commailto: ml...@carbinestudios.com Scripting and C++ are not 1:1. It might not be necessary to set parameter classification to 'siClassifTopo' in C++. I don't know the answer. Matt 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 ran sariel Sent: Tuesday, May 21, 2013 3:21 PM To: softimage Subject: Re: custom operators and changing topology Thank you Matt the issue is not defining the data type, the problem I'm facing is trying to let softimage treat my customOperator as one that is changing topology. one of the advice I found online was defining the first parameters on that operator as siClassIfTopo, that
Re: Setting and Manipulating Keys Very slow in Referenced Model
I totally agree with Raff. Versionned reference is the way to go. We don't have it here either and it's already an issue on some projects. I am not happy with animators creating local copy of the rigs, but I'm not with them all day long to check how they work. I discovered they were doing that, I told them it's wrong... Cleaning controllers and keyable parameters is my solution too for now... On 22 May 2013 04:09, Enrique Caballero enriquecaball...@gmail.com wrote: Hey Michal, Your definitely right. Its something we should look into -E On Wed, May 22, 2013 at 7:05 PM, Michal Doniec doni...@gmail.com wrote: Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. I'd start with some off the shelf version control software to do half of the work for you (perforce, maybe svn etc.), a rather simple database on top of this and some UI usually does the job for most cases where assets are not too complex and relatively lightweight, ie. mesh/rig character type assets. What I am saying is it doesn't really take much to get a system like this going and benefits can be potentially really big. Sorry for being bit off topic. On 22 May 2013 10:00, Enrique Caballero enriquecaball...@gmail.comwrote: We do live referencing here as we don't have much for versioning control at this small studio. Its worked fine for us so far as our rigs are pretty simple and eventually development stops for them on a project. Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. We also don't have enough coordinators to keep track of what shot gets what rig, or the development man power to update our pipeline. Tiny shop in Singapore, very difficult to find talented developers. Until then I've written a bunch of delta cleaning scripts that can solve 90% of our issues, and what was most important for us, was that we are very careful about how we import referenced models so that no unnecessary information gets written to the delta. So if a rig change does happen, the delta wont freak out and break the rig. Basically via scripting, I create an empty referenced model, populate the paths for the rig resolutions, add an empty delta, set the proper settings, disabling the evil ones, and then finally setting the active resolution. I have found this technique to be absolutely essential to making sure our deltas don't store any extra nonsense in them that would eventually clash with a rig change. Otherwise if the animator simply did a vanilla import referenced model this referenced model would have a delta on it thats fully enabled, and it would immediately store a bunch of useless crap under stored expressions/stored positions that would eventually cause the rig to explode when we did the next rig update. Aside from that, when something bad happens, I run one of 3 delta cleaners if necessary, but to be honest it hasnt happened much in a very long time. I am very open minded, but i also know the animators at this company very well. If I gave them a local model pipeline they would bring this studio to its knees and I would be out of a job very quickly On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane raffsxsil...@googlemail.com wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to move/key. Worked fine and it is not so difficult to write the tools to do a model update. Also one BIG plus to this method against referencing is that you avoid surprises when something changes in the rig that affects animation and it gets auto updated in a reference, THAT has happened to me before, largely due to the nature of the overlapping schedules we work with in SA. S. On 22/05/2013 04:48, Enrique Caballero wrote: Jeremie, I considered letting them animate in local mode but i decided that the risks outweighed the benefits. I am just 100% uncomfortable with trusting the animators with Local models. They will start deleting objects and changing heirarchy. So instead I stripped down the rig of unecessary stuff. I took all the cloth controls away and seperated it into a different rig, and then aggressively cut down the amount of keyable params. Its at least manageable now. Are you really comfortable letting the animators animate local models? I don't think I could ever let it happen -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
Re: Setting and Manipulating Keys Very slow in Referenced Model
Just to make sure I understand the terminology... when you say 'versionned' referencing, do you mean a workflow that uses controlled 'resolutions'? -Tim C. On 5/22/2013 11:30 AM, Jeremie Passerin wrote: I totally agree with Raff. Versionned reference is the way to go. We don't have it here either and it's already an issue on some projects. I am not happy with animators creating local copy of the rigs, but I'm not with them all day long to check how they work. I discovered they were doing that, I told them it's wrong... Cleaning controllers and keyable parameters is my solution too for now... On 22 May 2013 04:09, Enrique Caballero enriquecaball...@gmail.com mailto:enriquecaball...@gmail.com wrote: Hey Michal, Your definitely right. Its something we should look into -E On Wed, May 22, 2013 at 7:05 PM, Michal Doniec doni...@gmail.com mailto:doni...@gmail.com wrote: Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. I'd start with some off the shelf version control software to do half of the work for you (perforce, maybe svn etc.), a rather simple database on top of this and some UI usually does the job for most cases where assets are not too complex and relatively lightweight, ie. mesh/rig character type assets. What I am saying is it doesn't really take much to get a system like this going and benefits can be potentially really big. Sorry for being bit off topic. On 22 May 2013 10:00, Enrique Caballero enriquecaball...@gmail.com mailto:enriquecaball...@gmail.com wrote: We do live referencing here as we don't have much for versioning control at this small studio. Its worked fine for us so far as our rigs are pretty simple and eventually development stops for them on a project. Eventually we might do versioned referencing but it would require some asset tracking tools that we just don't have. We also don't have enough coordinators to keep track of what shot gets what rig, or the development man power to update our pipeline. Tiny shop in Singapore, very difficult to find talented developers. Until then I've written a bunch of delta cleaning scripts that can solve 90% of our issues, and what was most important for us, was that we are very careful about how we import referenced models so that no unnecessary information gets written to the delta. So if a rig change does happen, the delta wont freak out and break the rig. Basically via scripting, I create an empty referenced model, populate the paths for the rig resolutions, add an empty delta, set the proper settings, disabling the evil ones, and then finally setting the active resolution. I have found this technique to be absolutely essential to making sure our deltas don't store any extra nonsense in them that would eventually clash with a rig change. Otherwise if the animator simply did a vanilla import referenced model this referenced model would have a delta on it thats fully enabled, and it would immediately store a bunch of useless crap under stored expressions/stored positions that would eventually cause the rig to explode when we did the next rig update. Aside from that, when something bad happens, I run one of 3 delta cleaners if necessary, but to be honest it hasnt happened much in a very long time. I am very open minded, but i also know the animators at this company very well. If I gave them a local model pipeline they would bring this studio to its knees and I would be out of a job very quickly On Wed, May 22, 2013 at 4:51 PM, Raffaele Fragapane raffsxsil...@googlemail.com mailto:raffsxsil...@googlemail.com wrote: That's only an issue with live referencing, which is a pretty bad way to go about it. Versioned referencing will not hold any surprises as you control when a rig reaches what shots. It's a matter of asset management, not of referencing VS localized. If anything localizing takes a liberty away from you, it doesn't ADD security :) On Wed, May 22, 2013 at 6:36 PM, Sandy Sutherland sandy.mailli...@gmail.com mailto:sandy.mailli...@gmail.com wrote: I did - and we locked everything that was not supposed to
Re: Setting and Manipulating Keys Very slow in Referenced Model
Tim - it would be a system that controls VERSIONS of rig models for e.g., they would be tested, then passed on to become the 'current' version, which would then update the references. Basically to avoid say a rigger just writing out the model that is used by a bunch of animators, possibly adding some 'feature' or changing a hierarchy or whatever that then breaks the animation in the scene on the reference model. S. On 22/05/2013 17:40, Tim Crowson wrote: Just to make sure I understand the terminology... when you say 'versionned' referencing, do you mean a workflow that uses controlled 'resolutions'? -Tim C.
Re: Setting and Manipulating Keys Very slow in Referenced Model
Thus you make it so they have no choice but to use the approved method by only allowing motion to be checked in from ref models or only allowing importing of the models via a scene assembler UI. :D Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 12:30 PM, Jeremie Passerin wrote: I totally agree with Raff. Versionned reference is the way to go. We don't have it here either and it's already an issue on some projects. I am not happy with animators creating local copy of the rigs, but I'm not with them all day long to check how they work. I discovered they were doing that, I told them it's wrong... Cleaning controllers and keyable parameters is my solution too for now...
Re: Setting and Manipulating Keys Very slow in Referenced Model
Gotcha. Just making sure the vocab was clear. Yeah that's just asset management then... I have to say we don't have a good system in place for asset versioning either (also a small shop with real constraints), but it's something we're aware that we need. -Tim On 5/22/2013 11:55 AM, Sandy Sutherland wrote: Tim - it would be a system that controls VERSIONS of rig models for e.g., they would be tested, then passed on to become the 'current' version, which would then update the references. Basically to avoid say a rigger just writing out the model that is used by a bunch of animators, possibly adding some 'feature' or changing a hierarchy or whatever that then breaks the animation in the scene on the reference model. S. On 22/05/2013 17:40, Tim Crowson wrote: Just to make sure I understand the terminology... when you say 'versionned' referencing, do you mean a workflow that uses controlled 'resolutions'? -Tim C. -- 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 /Confidentiality Notice: This email, including attachments, is confidential and should not be used by anyone who is not the original intended recipient(s). If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Magnetic Dreams, Inc cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Magnetic Dreams, Inc or one of its agents./
RE: custom operators and changing topology
I'm on 2013 SP1, but those new methods are not shown in the SDK manuals. I think they were added in 2014. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Songqiong Yang Sent: Tuesday, May 21, 2013 10:12 PM To: softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology Hi Ran, Which Softimage version are you using? Since 2013 SP1, there're two new C++ APIs introduced, to allow the creation of paramdef with a specified classification. 1. Factory::CreateParamDef CreateParamDefhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Factory.html#a3badfe123fc78a4353347e7c2de0d270 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.htmlin_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmin, constCValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, CStatushttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CStatus.html *pst=0) 2. CustomProperty::AddParameter AddParameterhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CustomProperty.html#a3cd8cb29aea12aad508cfc2d623dc836 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, constCStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.htmlin_suggestedmin, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, Parameterhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Parameter.html io_parameter) Thanks, Joany From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi Sent: Wednesday, May 22, 2013 8:00 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: custom operators and changing topology what is your debuger saying? --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos 2013/5/22 Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com Scripting and C++ are not 1:1. It might not be necessary to set parameter classification to 'siClassifTopo' in C++. I don't know the answer. Matt 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 ran sariel Sent: Tuesday, May 21, 2013 3:21 PM To: softimage Subject: Re: custom operators and changing topology Thank you Matt the
Re: Mill 98% Human
Awesome work guys! Thanks for sharing :)
RePosition a Texture without moving the UV island
How can I reposition a texture map without moving the UV island to position it. Looking for a node and I know it has to exist :) ::Christopher
Colliding Expression?
Can you prevent a linked expression from colliding with another object ? I have a linked expression on a object but it collides with the other object, when it goes to far, the object with the expression is the slave (child of a parent), can a condition statement accomplish this and if so how would it be written ? Current Expression; l_fcv( this.kine.local.posz )
Re: RePosition a Texture without moving the UV island
You don't need any extra node: Image Advanced Tab UV Remap On Wed, May 22, 2013 at 2:23 PM, Christopher christop...@thecreativesheep.ca wrote: How can I reposition a texture map without moving the UV island to position it. Looking for a node and I know it has to exist :) ::Christopher -- -- IMPRESSUM: PiXABLE STUDIOS GmbH Co.KG, Sitz: Dresden, Amtsgericht: Dresden, HRA 6857, Komplementärin: Lenhard Barth Verwaltungsgesellschaft mbH, Sitz: Dresden, Amtsgericht: Dresden, HRB 26501, Geschäftsführer: Frank Lenhard, Tino Barth IMPRINT: PiXABLE STUDIOS GmbH Co.KG, Domicile: Dresden, Court of Registery: Dresden, Company Registration Number: HRA 6857, General Partner: Lenhard Barth Verwaltungsgesellschaft mbH, Domicile: Dresden, Court of Registery: Dresden, Company Registration Number: HRB 26501, Chief Executive Officers: Frank Lenhard, Tino Barth -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Setting and Manipulating Keys Very slow in Referenced Model
Hi Enrique. I repro the issue in 2013SP1 QFE1 x64 with your test scene sent to support. The keying issue is nonexistent in 2014 x64 with your test scene but the f-curve editing issue is still there. Also, I tested my own gear character and things are fine with gear and ref models. I recreated a character keyset on your scene where I included all rotation and all translation on all controllers. Making it heavier than usual and things still seem to go a lot more smoothly when keying or editing. You may have omitted a very critical step in your pipeline: As you may know, 'Key all keyable' is the worst option to use because it will key all the parameters sr+t unless you edit them in bunches in the keyable parameters editor under (KP/L). At the end, inside the keying panel (KP/L), if we take the finger bones as an example, only rotation should be present if you use this option'Key all keyable'. I personally use 'character key set' method for blocking then go with marked params... Key sets are good because you can interactively see what you are keying in one list by selecting the (two keys icon on bottom right)inspect plus when you open the fcurve editor it reflects all keys in the char key set. If you have omitted this, then you're looking at 3x more data that has to be processed. Without this due diligence, the entire scene bogs down because you're dealing with too much data and this probably gets compounded with reference models. The real time playback will also suffer. Tips: Only include controllers in the keying list. There are a big pile of nulls that are being keyed unnecessarily in your scene. Also, the little man icon objects, don't include that either. Most likely someone may be using key all keyable and this may be bogging things down. To be on the safe side: I would go to the model level and lock what you don't want the animators to animate like all the scaling on all controllers and things like translation on controllers meant to be rotated such as finger bones. Subsequent scenes will profit from this, I don't know about current ones though. What does everyone else do to keep things from being keyed in ref model situations in a production environment? Manny Papamanos SI and Mobu support From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Crowson Sent: Wednesday, May 22, 2013 1:07 PM To: softimage@listproc.autodesk.com Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model Gotcha. Just making sure the vocab was clear. Yeah that's just asset management then... I have to say we don't have a good system in place for asset versioning either (also a small shop with real constraints), but it's something we're aware that we need. -Tim On 5/22/2013 11:55 AM, Sandy Sutherland wrote: Tim - it would be a system that controls VERSIONS of rig models for e.g., they would be tested, then passed on to become the 'current' version, which would then update the references. Basically to avoid say a rigger just writing out the model that is used by a bunch of animators, possibly adding some 'feature' or changing a hierarchy or whatever that then breaks the animation in the scene on the reference model. S. On 22/05/2013 17:40, Tim Crowson wrote: Just to make sure I understand the terminology... when you say 'versionned' referencing, do you mean a workflow that uses controlled 'resolutions'? -Tim C. -- 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.comhttp://www.magneticdreams.com tim.crow...@magneticdreams.commailto:tim.crow...@magneticdreams.com Confidentiality Notice: This email, including attachments, is confidential and should not be used by anyone who is not the original intended recipient(s). If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Magnetic Dreams, Inc cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Magnetic Dreams, Inc or one of its agents. attachment: winmail.dat
Re: RePosition a Texture without moving the UV island
The UV remap expands or shrink a texture image, I want to essentially add another level to adjust the UV coordinates, not modify the existing texture map which is what UV Remap does. I know this is not what I want because I gave it a test run before asking the question and once again for clarity when you told me to use UV Remap. If I move my UV map, I jeopardize my other Texture Map, or Vise Versa causing I never ending loop of the same problem. If I can add a second layer, leaving the UV island exactly where it is in the TE and manipulate a specific texture map in the position I want, then I'd have the control I want, otherwise the UV Remap is repositioning the Image Map, without actually moving the UV island. ::Christopher Orlando Esponda wrote: You don't need any extra node: Image Advanced Tab UV Remap On Wed, May 22, 2013 at 2:23 PM, Christopher christop...@thecreativesheep.ca mailto:christop...@thecreativesheep.ca wrote: How can I reposition a texture map without moving the UV island to position it. Looking for a node and I know it has to exist :) ::Christopher -- IMPRESSUM: PiXABLE STUDIOS GmbH Co.KG, Sitz: Dresden, Amtsgericht: Dresden, HRA 6857, Komplementärin: Lenhard Barth Verwaltungsgesellschaft mbH, Sitz: Dresden, Amtsgericht: Dresden, HRB 26501, Geschäftsführer: Frank Lenhard, Tino Barth IMPRINT: PiXABLE STUDIOS GmbH Co.KG, Domicile: Dresden, Court of Registery: Dresden, Company Registration Number: HRA 6857, General Partner: Lenhard Barth Verwaltungsgesellschaft mbH, Domicile: Dresden, Court of Registery: Dresden, Company Registration Number: HRB 26501, Chief Executive Officers: Frank Lenhard, Tino Barth -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Setting and Manipulating Keys Very slow in Referenced Model
What does everyone else do to keep things from being keyed in ref model situations in a production environment? We used to use parameter locking until we discovered that it doesn't always work for parameters in referenced models. A number of built-in Softimage tools don't function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state. We don't use character key sets because that would force us to create a character key set for every asset in the game the animators touch. If the rigger forgets to insert a parameter into the keyset, then the animator can't work until the rigger can update the key set. Since other artists touch the rigs for different reasons, such as FX artists inserting their effects into the rig hierarchy, that's a lot of maintenance. Our custom simulation tools have over 400 parameters per emitter, and sometimes an individual rig can contain up to 15 emitters (rare, but it happens). That's too much to maintain without being bitten by human error. Currently we remove the Keyable and KeyableNonVisible parameter flags for parameters that shouldn't be keyed. This too is a bit high maintenance, but it's more acceptable if something goes wrong. For example, in the case of a character keyset, only parameters in the keyset can be keyed. If the rigger forgets to add a parameter to the set, the parameter cannot be keyed. If using 'keyable' flag on parameters, most parameters default to keyable being active. Therefore, if the rigger forgets to remove the keyable flag the parameter is still keyable allowing animators to work. It's just a matter of when they key something that wasn't intended to be keyed that we can go in and quickly isolate the problem and fix it. In both cases there is human error involved leading to undesired results, but using keyable parameter flags results in less time spent on troubleshooting when things go wrong. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Manny Papamanos Sent: Wednesday, May 22, 2013 2:25 PM To: softimage@listproc.autodesk.com Subject: RE: Setting and Manipulating Keys Very slow in Referenced Model Hi Enrique. I repro the issue in 2013SP1 QFE1 x64 with your test scene sent to support. The keying issue is nonexistent in 2014 x64 with your test scene but the f-curve editing issue is still there. Also, I tested my own gear character and things are fine with gear and ref models. I recreated a character keyset on your scene where I included all rotation and all translation on all controllers. Making it heavier than usual and things still seem to go a lot more smoothly when keying or editing. You may have omitted a very critical step in your pipeline: As you may know, 'Key all keyable' is the worst option to use because it will key all the parameters sr+t unless you edit them in bunches in the keyable parameters editor under (KP/L). At the end, inside the keying panel (KP/L), if we take the finger bones as an example, only rotation should be present if you use this option'Key all keyable'. I personally use 'character key set' method for blocking then go with marked params... Key sets are good because you can interactively see what you are keying in one list by selecting the (two keys icon on bottom right)inspect plus when you open the fcurve editor it reflects all keys in the char key set. If you have omitted this, then you're looking at 3x more data that has to be processed. Without this due diligence, the entire scene bogs down because you're dealing with too much data and this probably gets compounded with reference models. The real time playback will also suffer. Tips: Only include controllers in the keying list. There are a big pile of nulls that are being keyed unnecessarily in your scene. Also, the little man icon objects, don't include that either. Most likely someone may be using key all keyable and this may be bogging things down. To be on the safe side: I would go to the model level and lock what you don't want the animators to animate like all the scaling on all controllers and things like translation on controllers meant to be rotated such as finger bones. Subsequent scenes will profit from this, I don't know about current ones though. What does everyone else do to keep things from being keyed in ref model situations in a production environment? Manny Papamanos SI and Mobu support From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Crowson Sent: Wednesday, May 22, 2013 1:07 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model Gotcha. Just making sure the vocab was clear. Yeah that's just asset management then... I have
Re: Colliding Expression?
I gave a condition expression a whirl, expressions is good for constant motion, not sure if I can feed in a static object kinematics to a expression condition, maybe can't be done, unless I do this in ICE. ::Christopher Christopher wrote: Can you prevent a linked expression from colliding with another object ? I have a linked expression on a object but it collides with the other object, when it goes to far, the object with the expression is the slave (child of a parent), can a condition statement accomplish this and if so how would it be written ? Current Expression; l_fcv( this.kine.local.posz )
Re: Setting and Manipulating Keys Very slow in Referenced Model
Could you elaborate with some examples of tools that fail? I haven't experienced this myself so I'm wondering which ones they are and which ones to look out for. Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 5:43 PM, Matt Lind wrote: We used to use parameter locking until we discovered that it doesn't always work for parameters in referenced models. A number of built-in Softimage tools don't function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state.
RE: Setting and Manipulating Keys Very slow in Referenced Model
I'll have to wait for somebody to experience it again before I can specify in great detail. Usually in the area of enveloping and cluster tools. I complained a bit about in the past, so maybe some things got fixed. It was a big problem in 7.5. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Wednesday, May 22, 2013 2:50 PM To: softimage@listproc.autodesk.com Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model Could you elaborate with some examples of tools that fail? I haven't experienced this myself so I'm wondering which ones they are and which ones to look out for. Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 5:43 PM, Matt Lind wrote: We used to use parameter locking until we discovered that it doesn't always work for parameters in referenced models. A number of built-in Softimage tools don't function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state.
Re: Setting and Manipulating Keys Very slow in Referenced Model
I know one case: If you put an expression on the View Visibility, and use H to hide the object, Render Visibility rightfully toggles off, but if you tap again, it won't come back on. Remove the expression from ViewVis and it'll hide and unhide correctly again. On Wed, May 22, 2013 at 5:49 PM, Eric Thivierge ethivie...@hybride.comwrote: Could you elaborate with some examples of tools that fail? I haven't experienced this myself so I'm wondering which ones they are and which ones to look out for. Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 5:43 PM, Matt Lind wrote: We used to use parameter locking until we discovered that it doesn’t always work for parameters in referenced models. A number of built-in Softimage tools don’t function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state.
Re: Setting and Manipulating Keys Very slow in Referenced Model
Forgot to say, it's the same deal if you lock the param value. (Rightclick on the green square, Locks, Param Value) On Wed, May 22, 2013 at 6:23 PM, Alan Fregtman alan.fregt...@gmail.comwrote: I know one case: If you put an expression on the View Visibility, and use H to hide the object, Render Visibility rightfully toggles off, but if you tap again, it won't come back on. Remove the expression from ViewVis and it'll hide and unhide correctly again. On Wed, May 22, 2013 at 5:49 PM, Eric Thivierge ethivie...@hybride.comwrote: Could you elaborate with some examples of tools that fail? I haven't experienced this myself so I'm wondering which ones they are and which ones to look out for. Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 5:43 PM, Matt Lind wrote: We used to use parameter locking until we discovered that it doesn’t always work for parameters in referenced models. A number of built-in Softimage tools don’t function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state.
RE: custom operators and changing topology
Hi Matt, We didn't update docs for service pack release. You can see their introduced version is v11.1(2013) in 2014 sdk manual. 11.1 means 2013 SP1. Thanks, Joany Original message From: Matt Lind ml...@carbinestudios.com Date: To: softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology I’m on 2013 SP1, but those new methods are not shown in the SDK manuals. I think they were added in 2014. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Songqiong Yang Sent: Tuesday, May 21, 2013 10:12 PM To: softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology Hi Ran, Which Softimage version are you using? Since 2013 SP1, there’re two new C++ APIs introduced, to allow the creation of paramdef with a specified classification. 1. Factory::CreateParamDef CreateParamDefhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Factory.html#a3badfe123fc78a4353347e7c2de0d270 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.htmlin_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmin, constCValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, CStatushttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CStatus.html *pst=0) 2. CustomProperty::AddParameter AddParameterhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CustomProperty.html#a3cd8cb29aea12aad508cfc2d623dc836 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, constCStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.htmlin_suggestedmin, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, Parameterhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Parameter.html io_parameter) Thanks, Joany From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ahmidou Lyazidi Sent: Wednesday, May 22, 2013 8:00 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: custom operators and changing topology what is your debuger saying? --- Ahmidou Lyazidi Director | TD | CG artist http://vimeo.com/ahmidou/videos 2013/5/22 Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com Scripting and C++ are not 1:1. It might not be necessary to set parameter classification to ‘siClassifTopo’ in C++. I don’t know the answer.
RE: custom operators and changing topology
For the record, SDK updates like this are pretty important. I would like to request the docs be updated with reach release whether it be a main release, service pack, or subscription advantage pack. In this particular scenario, if I had to write the custom topology operator, I would be following the 2013 SP1 documentation only to encounter errors from improper use (because SDK doesn’t match the manuals), or would pull out hair wondering why my operator is behaving in a flakey manner. It’s important the documentation be matched with the software we’re using. Thank you. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Songqiong Yang Sent: Wednesday, May 22, 2013 5:21 PM To: softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology Hi Matt, We didn't update docs for service pack release. You can see their introduced version is v11.1(2013) in 2014 sdk manual. 11.1 means 2013 SP1. Thanks, Joany Original message From: Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com Date: To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology I’m on 2013 SP1, but those new methods are not shown in the SDK manuals. I think they were added in 2014. Matt From: softimage-boun...@listproc.autodesk.commailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Songqiong Yang Sent: Tuesday, May 21, 2013 10:12 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: RE: custom operators and changing topology Hi Ran, Which Softimage version are you using? Since 2013 SP1, there’re two new C++ APIs introduced, to allow the creation of paramdef with a specified classification. 1. Factory::CreateParamDef CreateParamDefhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1Factory.html#a3badfe123fc78a4353347e7c2de0d270 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.htmlin_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmin, constCValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_suggestedmax, CStatushttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CStatus.html *pst=0) 2. CustomProperty::AddParameter AddParameterhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CustomProperty.html#a3cd8cb29aea12aad508cfc2d623dc836 (const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_scriptname, CValue::DataTypehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html#ad8ed01ff3ff3d8e19db4d2818bb6 in_type, siParamClassificationhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/namespaceXSI.html#a8f0a8fe3a0669ff112ec8be6075c9f92 in_classification, INT in_capabilities, constCStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_name, const CStringhttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CString.html in_description, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_default, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_min, const CValuehttp://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_cpp/classXSI_1_1CValue.html in_max, const
PyQtForSoftimage: Input Method Hints working okay for QLineEdits?
I'm working with some QLineEdits, trying to set them to digits only via the Input Method Hints, but they're still accepting other characters when I run the tool in Soft. Is that not what the ImhDigitsOnly hint is supposed to do? Using Soft 2014. -- 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: Installing Deadline for Softimage 2012
Did you try installing the submitter plug via Deadline Monitor? You should try it with Script/Install Integrated Submission Scripts tool, and select your Softimage You can find it on Deadline Monior From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Mirko Jankovic Sent: Wednesday, May 22, 2013 6:59 PM To: David Rivera; softimage@listproc.autodesk.com Subject: Re: Installing Deadline for Softimage 2012 Hey David, I never had any problems with installing deadline since 2011... Python is inside SI already so no need to install anything else Python related. One and only thing needed is to copy SubmitXSIToDeadline.py into your Softimage/Application/Plugins folder and that is it. Absolutely nothing else needed. See if that works On Wed, May 22, 2013 at 1:05 AM, David Rivera activemotionpictu...@yahoo.commailto:activemotionpictu...@yahoo.com wrote: Hello. Anyone had had experience installing Deadline for softimage? i´ve followed this: http://www.thinkboxsoftware.com/deadline-5-softimage#Integrated_Submission_Script_Setup And I still can´t get the dialogue up on the Render module RenderSend to Deadline after setting up preferences for Python on softimage 2012. I believe Python is already installed on softimage 2012, because I see the option python from the scripts preferences. Hence, I opened up a script dialogue in python, and dragged and dropped the .py script that comes for installing on (applications)/softimage/application/plugins I restart softimage, but still I don´t see the dialogue. If anyone could lend me a hand with this, I´d appreciate it a lot. Thanks. David R.
Re: PyQtForSoftimage: Input Method Hints working okay for QLineEdits?
Or you could use the QDoubleValidator? http://pyqt.sourceforge.net/Docs/PyQt4/qdoublevalidator.html
Re: Setting and Manipulating Keys Very slow in Referenced Model
Hey Manny, Thanks for looking into it. Im going to send you a video later today showing you just how slow it is. Its more than just having too many parameters set to keyable. Your point about limiting the keyable parameters is 100% true and I should have locked several of them out. But with that said, this rig does not have that many parameters or objects in it to account for the 6 second delay that I experience on every system at this company. With that said. I have found something interesting. Last night while we chatted, I tried the scene on my laptop at home, and the issue was largely gone. This makes no sense to me as I have done heavy testing here with the workgroup disconnected and a vanilla softimage and gear install. And had the 6 second delay. I now think it might have to do with our system configurations here, I am looking into it. Thanks for the help, Please don't close this ticket yet. The problem is larger than just too many keyable parameters -Enrique On Thu, May 23, 2013 at 6:24 AM, Alan Fregtman alan.fregt...@gmail.comwrote: Forgot to say, it's the same deal if you lock the param value. (Rightclick on the green square, Locks, Param Value) On Wed, May 22, 2013 at 6:23 PM, Alan Fregtman alan.fregt...@gmail.comwrote: I know one case: If you put an expression on the View Visibility, and use H to hide the object, Render Visibility rightfully toggles off, but if you tap again, it won't come back on. Remove the expression from ViewVis and it'll hide and unhide correctly again. On Wed, May 22, 2013 at 5:49 PM, Eric Thivierge ethivie...@hybride.comwrote: Could you elaborate with some examples of tools that fail? I haven't experienced this myself so I'm wondering which ones they are and which ones to look out for. Eric Thivierge === Character TD / RnD Hybride Technologies On 22/05/2013 5:43 PM, Matt Lind wrote: We used to use parameter locking until we discovered that it doesn’t always work for parameters in referenced models. A number of built-in Softimage tools don’t function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state.
Re: RePosition a Texture without moving the UV island
If all you are applying is a 2D offset, that is EXACTLY what you can do the way people have specified, and as it's done in the image node, it can be done per image channel without requiring a change in image OR UVs, as it affects their pairing. This comes across as you not having quite tried hard enough before dismissing, honestly. Give it another shot. On Thu, May 23, 2013 at 1:41 PM, Christopher christop...@thecreativesheep.ca wrote: I tried both method, the results are, well, disappointing to say the least. My solution is simply to move the texture image in Ps to where I want it placed on the UV template. My whole point was to eliminate the process of having to load Ps to do this, either that or an ICE/shader solution. ::Christopher
