Re: Survey - how would you do this?
that's based on WINE for OSX. you can go ahead and try it yourself. On Monday, February 17, 2014, Angus Davidson angus.david...@wits.ac.za wrote: Hi Brent Very well explained thank you. I do agree that because of the overall crappiness of Windows COM has got a bad rep. Unfortunately its very hard for most people to know where one begins and the other ends and in the end the overall perception is the one that sticks. On a slightly unrelated note I was patching my wifes GuildWars 2 and instead of downloading the whole data file I just copied it from my mac install to her windows one. Seems that GW2 is pretty much running in emulation mode using Transgaming Cider. For those of you who may have played GW2 know its very graphics intensive and I comfortable get 45-60fps on max settings. Anyone know if the way Softimage is put together would preclude it from coming to the Mac using this type of technology rather then rewriting it ? Kind regards Angus
Re: Survey - how would you do this?
Just had an image of a horse with an embedded wacom. Yup that’s going to be hard to unsee. From: Mirko Jankovic mirkoj.anima...@gmail.commailto:mirkoj.anima...@gmail.com Reply-To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 8:11 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? really nice, first jump into thread Luc-Eric and question is like oh ditch SI what do you wanna use next (*cough* Maya *cough*) But as someone else mentioned... there is old saying... Every gypsy brags about his horse not sure how it sounds in English but should get across... On Fri, Feb 14, 2014 at 4:42 AM, Sebastien Sterling sebastien.sterl...@gmail.commailto:sebastien.sterl...@gmail.com wrote: You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: Below: -Original Message- 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 Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company
Re: Survey - how would you do this?
Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.zawrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. /span/font/td /tr /table
Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Luc-Eric, you can try as you want, but you are inside AD, so you are biased as much as me when I was speaking about Softimage as an Autodesk employee or speaking about Creation Platform as a Fabric employee. I'm sure you not saying you were making dishonest pro-fabric posts when you were getting paychecks from Fabric. Anyways, I'm stating verifiable facts, not making board statements about something being better Everyone is biased to the things they know best, clients or employees. You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk.
Re: Survey - how would you do this?
You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk. Your last sentence is really rude Luc-Eric. Btw I still don't know why they fired me :). They just told me they needed to fire peoples... My guess was that I was not good in C++ COM ;). On Fri, Feb 14, 2014 at 7:09 AM, Luc-Eric Rousseau luceri...@gmail.comwrote: On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Luc-Eric, you can try as you want, but you are inside AD, so you are biased as much as me when I was speaking about Softimage as an Autodesk employee or speaking about Creation Platform as a Fabric employee. I'm sure you not saying you were making dishonest pro-fabric posts when you were getting paychecks from Fabric. Anyways, I'm stating verifiable facts, not making board statements about something being better Everyone is biased to the things they know best, clients or employees. You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk.
Re: Survey - how would you do this?
And about your comparaison with Fabric. You just forget that it is a small team of human crafting their product. How can you compare that to Bifrost/Whatever AD projects and speak about those theoretical futur products on your own ! I just don't get the point on bashing a startup when working in a large company. Are you scared by what they are doing maybe ? I will stop the flames here. On Fri, Feb 14, 2014 at 7:20 AM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk. Your last sentence is really rude Luc-Eric. Btw I still don't know why they fired me :). They just told me they needed to fire peoples... My guess was that I was not good in C++ COM ;). On Fri, Feb 14, 2014 at 7:09 AM, Luc-Eric Rousseau luceri...@gmail.comwrote: On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Luc-Eric, you can try as you want, but you are inside AD, so you are biased as much as me when I was speaking about Softimage as an Autodesk employee or speaking about Creation Platform as a Fabric employee. I'm sure you not saying you were making dishonest pro-fabric posts when you were getting paychecks from Fabric. Anyways, I'm stating verifiable facts, not making board statements about something being better Everyone is biased to the things they know best, clients or employees. You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk.
Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 11:15 PM, Emilio Hernandez emi...@e-roja.com wrote: Sorry to jump into this masters discution, but don't we have PyQT in Softimage also? You can download a plugin, but it's never going to be a built-in feature you can assume is there and working. But most importantly, the Maya UI is native Qt, so you have access to it all through PySide, intermix Mel and Pyside. There are no boundaries between Maya UI and QT and PySide. couldn't find a way to transfer a simple UV from one mesh to another. So I went and dug into Creative Crash to find a script... This is off topic, but what was wrong with Mesh-Transfer Attrbutes?
Re: Survey - how would you do this?
You are not doing yourself a favor, Luc-Eric. Quite an unprofessional cheap shot. On 14.02.2014 13:09, Luc-Eric Rousseau wrote: On Thu, Feb 13, 2014 at 9:44 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Luc-Eric, you can try as you want, but you are inside AD, so you are biased as much as me when I was speaking about Softimage as an Autodesk employee or speaking about Creation Platform as a Fabric employee. I'm sure you not saying you were making dishonest pro-fabric posts when you were getting paychecks from Fabric. Anyways, I'm stating verifiable facts, not making board statements about something being better Everyone is biased to the things they know best, clients or employees. You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk.
Re: Survey - how would you do this?
Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.zamailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.commailto:luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.commailto:car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. /span/font/td /tr /table table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans
Re: Survey - how would you do this?
Unfortunately it will be Softimages achilles heel if they don't find a way off of it (which is unlikely given the very small dev team) COM doesn't scale the way new 3d apps require. To many bottlenecks. It's moot, but COM is fine, it's no more or less scalable than C++. Firefox is entirely built with a cross platform clone of COM, called XPCOM. The problem is that we made XSI only for a Windows NT-only future. The mainwin decision was meant to be something temporary until SGI died out. It's not just COM, it's a 100% windows sdk app. On Fri, Feb 14, 2014 at 8:42 AM, Angus Davidson angus.david...@wits.ac.za wrote: Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;)
Re: Survey - how would you do this?
Instead of bashing people / other products you may want to spend more time welcoming the other technologies and applauding the technology they are coming up with. You'll be doing less damage to how you and AD is perceived. Super unprofessional. Eric T. On 2/14/2014 7:09 AM, Luc-Eric Rousseau wrote: You're a bit of a special case in the bias departement, imho, given that you were fire from Autodesk.
Re: Survey - how would you do this?
(sneaks in) And speaking of constrains. To constrain to a point on a mesh in Maya, you need to have UV's! and watch out. If you constrain to a point that in the UV is in two different coordinates... ciao... BTW if you need to constraint to a point on a mesh in Maya, you can use clusters without the mesh needing to have UVs. http://www.terencejacobson.com/hyperRealMeshParent.mel That script is an example, really nice for getting things like the 'doritos' effect in Maya without doing too much under-the-hood stuff. However if you do not require the clusters to deform in parallel with other deformers (skinClusters, blendshapes what have you) then the relative attribute in the cluster should allow for most types of object-to-point-on-mesh constraints. And yes, the default point-to-poly constraint is rubbish. :P As far as transferrring UVs go...did the Transfer Attributes tool not work out? I know it's not really as flexible as GATOR, but usually for 99% of cases where topology is identical it should work out fine. However I use Diamant Tools regularly when I need to project details/UVs from mesh to mesh where the topology isn't the same for whatever reason. Hopefully that helps out if you need to tackle these specific problems again! (sneaks out) Yours sincerely, Siew Yi Liang On 2/13/2014 8:15 PM, Emilio Hernandez wrote: Sorry to jump into this masters discution, but don't we have PyQT in Softimage also? And now that Luc-Eric jumped in... Ok, Maya is more customizable, and better for Devs to integrate it into a pipeline and bla, bla, bla. Because out of the box sorry but... p I am a novel in Maya and I am using it because I need to, not because I am convinced of using it. And the more I use it, the more I love Softimage. I couldn't find a way to transfer a simple UV from one mesh to another. So I went and dug into Creative Crash to find a script... A script for this, a script for that. The only thing I want to thank Maya is that I started scripting again... Thank god I have two monitors to have the script editor open with I don't know how many tabs. Or why not. I can have a lot of buttons clogging more my workspace with nice Maya icons. I don't have time to start getting creative to draw an icon for each additional script I write to do a simple task... And speaking of constrains. To constrain to a point on a mesh in Maya, you need to have UV's! and watch out. If you constrain to a point that in the UV is in two different coordinates... ciao... So yes maybe when you have an army of Devs scripting and scripting. You can have awsome custom tools... But when you have a small studio or you are freelance, for me Maya is no go. So instead of spreading the word on how good is Maya compared to Softimage to try to convince us to switch platforms, because Maya is more customizable. We want a descent upgrade of Softimage. Not only a super camera switcher. What is the fear of Autodesk? That if you guys start making real improvements on Softimage the Maya industry standard farce will fall? Sorry but I am really pissed off of how Autodesk is handling Softimage. The best thing you can do is put it on sale so that people who really cares, will take Softimage to the next level instead of burying it in Asia. But this will hardly happen. Softimage in some other hands will be a very strong contender to Maya 2014-02-13 20:49 GMT-06:00 Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.com mailto:ml...@carbinestudios.com wrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com mailto:softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com mailto:ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical
Re: Survey - how would you do this?
As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.za mailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com mailto:luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com mailto:car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University
RE: Survey - how would you do this?
Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. From: Ben Rogall [xsi_l...@shaders.moederogall.com] Sent: 14 February 2014 07:45 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.zamailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.commailto:luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.commailto:car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may
Re: Survey - how would you do this?
Absolutley. The Foundry has been doing things the way it should be. A 3d dedicated app was the only missing link in their film/vfx chain. And with Modo, they closed the round trip. I can see Nuke displaying a Modo scene interactively doing all the lighiting, rendering and compositing, beeing send to Hiero to be dispalyed with the rest of the feature. Something that Softimage started a long time ago when DS was capable of reading a Softimage scene... and 15 years later, finally The Foundry discovered the black thread. Something that Autodesk and had in his hands. With all that technology and amazing dev teams. Instead of after acquiring Softimage and say Hey lets create something new that will have the best of both worlds, they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix. 2014-02-14 11:57 GMT-06:00 Angus Davidson angus.david...@wits.ac.za: Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. -- *From:* Ben Rogall [xsi_l...@shaders.moederogall.com] *Sent:* 14 February 2014 07:45 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don't find a way off of it (which is unlikely given the very small dev team) COM doesn't scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.com softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.com softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM
Re: Survey - how would you do this?
Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
RE: Survey - how would you do this?
It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman Sent: Friday, February 14, 2014 11:57 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
Re: Survey - how would you do this?
Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman *Sent:* Friday, February 14, 2014 11:57 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
Re: Survey - how would you do this?
Hi Angus Yep, I just wanted to make the point that someone was able to do that on top of COM. I'm fond of Modo too, especially for modeling and the Luxology people seem really reasonable. I was doing some rendering in Modo too, but then Redshift came along. On 2/14/2014 11:57 AM, Angus Davidson wrote: Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. *From:* Ben Rogall [xsi_l...@shaders.moederogall.com] *Sent:* 14 February 2014 07:45 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.za mailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com mailto:luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com mailto:car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge
Re: Survey - how would you do this?
Does anyone know how open modo is ? i guess that will be the next step for luxologic/foundery, to open it out, and make pipe integration a priority. On 14 February 2014 21:41, Ben Rogall xsi_l...@shaders.moederogall.comwrote: Hi Angus Yep, I just wanted to make the point that someone was able to do that on top of COM. I'm fond of Modo too, especially for modeling and the Luxology people seem really reasonable. I was doing some rendering in Modo too, but then Redshift came along. On 2/14/2014 11:57 AM, Angus Davidson wrote: Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. -- *From:* Ben Rogall [xsi_l...@shaders.moederogall.com] *Sent:* 14 February 2014 07:45 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don't find a way off of it (which is unlikely given the very small dev team) COM doesn't scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.com softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.com softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans
RE: Survey - how would you do this?
Hi Ben I take your point on COM. Do you know if the Mac / Linux versions use Com wrappers or recreate the functionality in a different way. Must admit I was blown away by the redshift alpha. Unfortunately I dont have regular access to the GPUs that really make it shine. I think a lot depends on what happens with the 2015 release of Softimage. (which should be soonish). A lot of folks felt very burned by what they got last year, and have very grudgingly paid their subs for this year. If its not a very solid affirmation of Softimage getting the love it deserves people are not going to pay top dollar for very little in return again. The VFX economy is not in great shape. People just cant be taking those kind of chances going forward. Once that happens Softimage is effectively dead as a product from a sales point of view. Personally I hope Autodesk finally realizes how stupid they are being and actually puts the right number of resources to work on Softimage. Realistically I suspect I have more chance of getting a mac version ;( Autodesk mishandling of Softimage is not likely to move many people to Maya. Once trust is broken with a company it tends to include their whole offering. so they will need to go somewhere. Once that happens the renderer companies will follow. I am a bit more optimistic about external renderer's finding their way to Modo, Octane and Thea are already there or on their way. Once Modo market share increases it will become more attractive to plug your renderer into. Personally Arnold for me would be awesome as I have access to far more CPU rendering power. From: Ben Rogall [xsi_l...@shaders.moederogall.com] Sent: 14 February 2014 10:41 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Hi Angus Yep, I just wanted to make the point that someone was able to do that on top of COM. I'm fond of Modo too, especially for modeling and the Luxology people seem really reasonable. I was doing some rendering in Modo too, but then Redshift came along. On 2/14/2014 11:57 AM, Angus Davidson wrote: Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. From: Ben Rogall [xsi_l...@shaders.moederogall.commailto:xsi_l...@shaders.moederogall.com] Sent: 14 February 2014 07:45 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.zamailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj
RE: Survey - how would you do this?
Watch the video here: http://www.wildstar-online.com/en/news/#page1 At various times you’ll see asteroid belts of various radius, density, and orbital speed. We needed to create a dense asteroid belt for a closeup. We don’t do photo-real. The emotional effect from shape and movement is more important as the game is largely based on a comic book style. Take a peek at the screenshots and other media for more examples. From a technical point of view, since this asteroid belt must perform in a real time environment, must be optimal in use of resources. The challenge was this asteroid belt had to be created by a junior artist with no technical skills and done in rapid fashion unsupervised. The question is how do you instruct such a person to create the asteroid belt to get the task done quickly ( 30 minutes), effectively, and with minimal risk against immediate and long term objectives related to pipeline. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman Sent: Friday, February 14, 2014 12:19 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. 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 Rob Chapman Sent: Friday, February 14, 2014 11:57 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
Re: Survey - how would you do this?
As far as I know it's COM based for all three. There is very little that needs to be changed to compile a plugin for Mac vs Windows. As a freelancer, I'm in the opposite situation regarding renderers. It's so easy to upgrade or add gpu's with Redshift and get great improvements in render power. Ben On 2/14/2014 3:32 PM, Angus Davidson wrote: Hi Ben I take your point on COM. Do you know if the Mac / Linux versions use Com wrappers or recreate the functionality in a different way. Must admit I was blown away by the redshift alpha. Unfortunately I dont have regular access to the GPUs that really make it shine. I think a lot depends on what happens with the 2015 release of Softimage. (which should be soonish). A lot of folks felt very burned by what they got last year, and have very grudgingly paid their subs for this year. If its not a very solid affirmation of Softimage getting the love it deserves people are not going to pay top dollar for very little in return again. The VFX economy is not in great shape. People just cant be taking those kind of chances going forward. Once that happens Softimage is effectively dead as a product from a sales point of view. Personally I hope Autodesk finally realizes how stupid they are being and actually puts the right number of resources to work on Softimage. Realistically I suspect I have more chance of getting a mac version ;( Autodesk mishandling of Softimage is not likely to move many people to Maya. Once trust is broken with a company it tends to include their whole offering. so they will need to go somewhere. Once that happens the renderer companies will follow. I am a bit more optimistic about external renderer's finding their way to Modo, Octane and Thea are already there or on their way. Once Modo market share increases it will become more attractive to plug your renderer into. Personally Arnold for me would be awesome as I have access to far more CPU rendering power. *From:* Ben Rogall [xsi_l...@shaders.moederogall.com] *Sent:* 14 February 2014 10:41 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Hi Angus Yep, I just wanted to make the point that someone was able to do that on top of COM. I'm fond of Modo too, especially for modeling and the Luxology people seem really reasonable. I was doing some rendering in Modo too, but then Redshift came along. On 2/14/2014 11:57 AM, Angus Davidson wrote: Hi Ben The big difference is Modo is also successfully cross platform, and in active development. When the time comes to move on they will be in a position to do so. Something Softimage currently lacks. Which is something Autodesk will regret down the line. *From:* Ben Rogall [xsi_l...@shaders.moederogall.com] *Sent:* 14 February 2014 07:45 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? As a matter of fact, Modo is COM based. When programming with its SDK, the COM roots are more visible than with Softimage. However most everything is nicely wrapped in C++ classes so you don't usually have to deal with the low level nuts and bolts of COM. Ben On 2/14/2014 7:42 AM, Angus Davidson wrote: Unfortunately it will be Softimages achilles heel if they don’t find a way off of it (which is unlikely given the very small dev team) COM doesn’t scale the way new 3d apps require. To many bottlenecks. Jumping into Modo for my first attempt at particles. Managed to get the following after my allotted 5 minutes pic.twitter.com/EDOKamNkkn Just used a plain cube as a poly source. Need to update that with a more random rock ;) From: Guillaume Laforge guillaume.laforge...@gmail.com mailto:guillaume.laforge...@gmail.com Reply-To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Date: Friday 14 February 2014 at 2:06 PM To: softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com softimage@listproc.autodesk.com mailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Softimage code in Linux is pretty much the same as on Windows and so is using COM too. How it works on Linux has been explain on this list many time (almost as often as people asking how to install Softimage successfully on Linux). I have nothing against COM in theory, except that it is hard to find good programmers mastering this interface those days. It is an old tech and Softimage is built on it. Easy to get the picture no ? On Fri, Feb 14, 2014 at 12:04 AM, Angus Davidson angus.david...@wits.ac.za mailto:angus.david...@wits.ac.za wrote: How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version
Re: Survey - how would you do this?
ah I see! well then I would just instruct said junior to crank out as many individual styled asteroids as low poly as possible in the style and format desired. get primitivedodecohedron, randomize points and subdivide some impact craters etc. and to visualize (assuming final movement placement is done in-engine) duplicate or instantiate as many as needed. from your video looks like hundreds. use the multiselect and r(min,max) in the transform panel to get them into a rough rectangular patch in one axis and to the length of the radius of the intended asteroid belt to be. this way a good distribution of amounts and sizes can be ascertained straightaway. again the r(min,max) can be used to keyframe rotations of individual asteroids like Manny demonstrated. then under a null these can be deformed by a curve representing the belt and keyframing the translation along curve. simples! less than half hour easy On 14 February 2014 21:53, Matt Lind ml...@carbinestudios.com wrote: Watch the video here: http://www.wildstar-online.com/en/news/#page1 At various times you’ll see asteroid belts of various radius, density, and orbital speed. We needed to create a dense asteroid belt for a closeup. We don’t do photo-real. The emotional effect from shape and movement is more important as the game is largely based on a comic book style. Take a peek at the screenshots and other media for more examples. From a technical point of view, since this asteroid belt must perform in a real time environment, must be optimal in use of resources. The challenge was this asteroid belt had to be created by a junior artist with no technical skills and done in rapid fashion unsupervised. The question is how do you instruct such a person to create the asteroid belt to get the task done quickly ( 30 minutes), effectively, and with minimal risk against immediate and long term objectives related to pipeline. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman *Sent:* Friday, February 14, 2014 12:19 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman *Sent:* Friday, February 14, 2014 11:57 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
Re: Survey - how would you do this?
haha I said radius, I meant circumference :) but yes if your junior knows the length of the circumference of the belt then they can make nicely designed and spread out patches which can then be deformed by curve at the correct speed, On 14 February 2014 23:16, Rob Chapman tekano@gmail.com wrote: ah I see! well then I would just instruct said junior to crank out as many individual styled asteroids as low poly as possible in the style and format desired. get primitivedodecohedron, randomize points and subdivide some impact craters etc. and to visualize (assuming final movement placement is done in-engine) duplicate or instantiate as many as needed. from your video looks like hundreds. use the multiselect and r(min,max) in the transform panel to get them into a rough rectangular patch in one axis and to the length of the radius of the intended asteroid belt to be. this way a good distribution of amounts and sizes can be ascertained straightaway. again the r(min,max) can be used to keyframe rotations of individual asteroids like Manny demonstrated. then under a null these can be deformed by a curve representing the belt and keyframing the translation along curve. simples! less than half hour easy On 14 February 2014 21:53, Matt Lind ml...@carbinestudios.com wrote: Watch the video here: http://www.wildstar-online.com/en/news/#page1 At various times you’ll see asteroid belts of various radius, density, and orbital speed. We needed to create a dense asteroid belt for a closeup. We don’t do photo-real. The emotional effect from shape and movement is more important as the game is largely based on a comic book style. Take a peek at the screenshots and other media for more examples. From a technical point of view, since this asteroid belt must perform in a real time environment, must be optimal in use of resources. The challenge was this asteroid belt had to be created by a junior artist with no technical skills and done in rapid fashion unsupervised. The question is how do you instruct such a person to create the asteroid belt to get the task done quickly ( 30 minutes), effectively, and with minimal risk against immediate and long term objectives related to pipeline. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman *Sent:* Friday, February 14, 2014 12:19 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Rob Chapman *Sent:* Friday, February 14, 2014 11:57 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas?
RE: Survey - how would you do this?
The video is just a style reference. The final movement is done in the Softimage scene, placement is done in a world editor. Rocks cannot collide with anything. Operators, such as deformations (other than envelopes), do not transfer into the engine. Animation is plotted per frame. Eg; a position constrained object will have global transforms plotted and constraint removed when exported. Animation is heavy data, but is filtered for cases where values do not change over multiple frames (FCurve is horizontal). Keep that in mind when deciding how to use resources such as number of polygons, keys, textures, materials, etc… Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman Sent: Friday, February 14, 2014 3:22 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? haha I said radius, I meant circumference :) but yes if your junior knows the length of the circumference of the belt then they can make nicely designed and spread out patches which can then be deformed by curve at the correct speed, On 14 February 2014 23:16, Rob Chapman tekano@gmail.commailto:tekano@gmail.com wrote: ah I see! well then I would just instruct said junior to crank out as many individual styled asteroids as low poly as possible in the style and format desired. get primitivedodecohedron, randomize points and subdivide some impact craters etc. and to visualize (assuming final movement placement is done in-engine) duplicate or instantiate as many as needed. from your video looks like hundreds. use the multiselect and r(min,max) in the transform panel to get them into a rough rectangular patch in one axis and to the length of the radius of the intended asteroid belt to be. this way a good distribution of amounts and sizes can be ascertained straightaway. again the r(min,max) can be used to keyframe rotations of individual asteroids like Manny demonstrated. then under a null these can be deformed by a curve representing the belt and keyframing the translation along curve. simples! less than half hour easy On 14 February 2014 21:53, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: Watch the video here: http://www.wildstar-online.com/en/news/#page1 At various times you’ll see asteroid belts of various radius, density, and orbital speed. We needed to create a dense asteroid belt for a closeup. We don’t do photo-real. The emotional effect from shape and movement is more important as the game is largely based on a comic book style. Take a peek at the screenshots and other media for more examples. From a technical point of view, since this asteroid belt must perform in a real time environment, must be optimal in use of resources. The challenge was this asteroid belt had to be created by a junior artist with no technical skills and done in rapid fashion unsupervised. The question is how do you instruct such a person to create the asteroid belt to get the task done quickly ( 30 minutes), effectively, and with minimal risk against immediate and long term objectives related to pipeline. 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 Rob Chapman Sent: Friday, February 14, 2014 12:19 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. 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 Rob Chapman Sent: Friday, February 14, 2014 11:57 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose
RE: Survey - how would you do this?
Hi Matt Huge fan of the look and feel of Wildstar. Havent had a MMO with an exceptional cartoony style since Wow. Everyone in between has always tried the same formula so its refreshing to see. Good luck From: Matt Lind [ml...@carbinestudios.com] Sent: 14 February 2014 11:53 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? Watch the video here: http://www.wildstar-online.com/en/news/#page1 At various times you’ll see asteroid belts of various radius, density, and orbital speed. We needed to create a dense asteroid belt for a closeup. We don’t do photo-real. The emotional effect from shape and movement is more important as the game is largely based on a comic book style. Take a peek at the screenshots and other media for more examples. From a technical point of view, since this asteroid belt must perform in a real time environment, must be optimal in use of resources. The challenge was this asteroid belt had to be created by a junior artist with no technical skills and done in rapid fashion unsupervised. The question is how do you instruct such a person to create the asteroid belt to get the task done quickly ( 30 minutes), effectively, and with minimal risk against immediate and long term objectives related to pipeline. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Rob Chapman Sent: Friday, February 14, 2014 12:19 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Sorry, thats what I meant, if you are still curious as to seeing some more different approaches. Also, just wanted to clarify about the orbits of the asteroids. is it like Saturn ring or Asteroid belt as am sure you mentioned planets. if it is a ring then definitely a bitmap approach until close up then still bitmaps as they are only micrometer meter and you could squeeze a lot more smaller clumps onto a bitmap versus geometrydoes your engine do cloud gridss and can fly through them? I imagine an asteroid ring would be similar. On 14 February 2014 20:01, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: It was solved even before I sent out the first message. I was just curious how other people would solve the same problem given the circumstances. 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 Rob Chapman Sent: Friday, February 14, 2014 11:57 AM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Emilio wrote they simply took a pristine and talented dev team who understood the artists, and plugged them into The Matrix ahem. that will be *some*, but not all of the talented dev. am guessing some chose not to go work for the 'matrix' . some were then fired apparently in rounds of 'must make more profit for shareholders' can we get back to asteroids. Matt, has it been solved and we can end this thread or you still looking for some differnt ideas? table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. /span/font/td /tr /table
Re: Survey - how would you do this?
I don't think you can compare ICE to those other examples you described. At this point, I think the only way for ICE to go down is for the entire package to be discontinued. We are tiny compared to your place, but we also need to build assets that last us for a long time. I use ICE for a lot of these things without hesitation because I really don't see it being ripped out or becoming unsupported at any point. Also, I find it very stable; I've done many crazy things with it, and while it can sometimes be slow, it does not crash pretty much ever. Granted, kinematics is an area where I've seen some flaky behavior, but this may be from back when they weren't officially supported as I don't need kinematics much these days. On Thu, Feb 13, 2014 at 12:01 AM, Matt Lind ml...@carbinestudios.comwrote: Part of it is circumstance, as in we only have so many resources. For example, our art department is 100+, but I'm the only one in the department who writes code and I'm currently tasked with significantly higher priority issues helping out an under staffed engineering department than writing one-offs for every artist who needs a button. The other part is pipeline management of a large scale software development effort. We have a feature film sized team working to build a high profile AAA title. With an engine and tools under constant evolution, and life expectancy of 15+ years, you must choose methods of content creation which can withstand changes to the software, such as Softimage, as well as changes to the game itself. An asset created today must expect to live for 10+ years without any further maintenance. If given the choice between creating an asteroid belt using constraints vs. ICE, we'll probably opt for constraints because we know it's a fairly stable and mature system, which cannot be said for ICE. We've been bitten many times already such as when we created a number of simulations back in XSI 5 using the Softimage particle system only for the particle system to be ripped out and replaced with ICE. We can no longer open those assets in Softimage. Same happened again with updates to the realtime shader APIs. So now we must either live with their current state of dysfunction, or rebuild from scratch. On projects of this magnitude, risk assessment has a very high priority and taken extremely seriously because one bad move can literally sink the project if the ripple effect is large enough. While we do take measures to abstract data from commercial tools, we only have so much programming power in house to do so. The point is we cannot subscribe to workflows which are prone to human error. Creating temporary data and expecting the artist to clean up after himself has proven to not be reliable as assets are referenced by other assets all the time. If crap is left around, then anybody referencing that asset also inherits the crap which results in bugs in game. In film/video you can sweep things under the carpet if they aren't perfect as long as the problem doesn't show up on camera. We don't have that luxury. What you make has to be functional and optimal for a live game environment, conservative on resources, and not make any assumptions how it will be used. Function has higher priority than looking pretty. There's a lot more to it, but I think you get the gist of it. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Wednesday, February 12, 2014 10:59 AM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? So cheese and monkeys aside. After 25 years as a 3D animator I've never worked in games. So from a serious perspective I simply don't understand. It's not clear to me why you aren't able to use ICE or scripts and freeze those construction connections sending only the raw assets over without ICE or scripting. What is it about this pipeline which makes that difficult? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, February 12, 2014 1:35 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun
Re: Survey - how would you do this?
So you need to hire robots then cause all workflows involving humans are prone to error, you just have to reduce it as much as possible. I'm with Brad regarding ICE. It's stable and mature for the bread and butter work that is done with it (an example is your asteroid task). Otherwise, how is real work getting done with it? Eric T. On 2/12/2014 6:01 PM, Matt Lind wrote: The point is we cannot subscribe to workflows which are prone to human error.
Re: Survey - how would you do this?
I will drink that beer in this one with Eric. I am not on the game side but on the film and advertising, so I only know the basics of a gaming engine and I found your survey challenge just to take a look back at the legacy tools and solve the problem, because as the rest of us I believe ICE is the word and the way to think how to solve a simple task as the one you describe. I use ICE for a lot of things, not only particles fx. And I am no erudit as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc. I will say I am an average ICE user more on the artist side. And really ICE never stops surprising me. I find it very stable, and I use it very often, even for very simple projects. And it allows me to change things as a line of shopping bags vanishing to the horizon in a breeze with client's request such as No, let's make the bags bigger. More bags, less bags. Can we see two rows of bags, perhpas three?... I can hardly imagine the 2020 release of Softimage, ICE dissapears out of nowhere. For me, it is like saying the render tree will vanish. Porting to a game engine from Softimage, is something that I can't speak a word. But in my regular workflow ICE rules! Cheers! 2014-02-13 8:19 GMT-06:00 Eric Thivierge ethivie...@hybride.com: So you need to hire robots then cause all workflows involving humans are prone to error, you just have to reduce it as much as possible. I'm with Brad regarding ICE. It's stable and mature for the bread and butter work that is done with it (an example is your asteroid task). Otherwise, how is real work getting done with it? Eric T. On 2/12/2014 6:01 PM, Matt Lind wrote: The point is we cannot subscribe to workflows which are prone to human error.
Re: Survey - how would you do this?
I can see ICE disappearing like the old very clunky particle system that it replaced if the technology progresses and it does need to be replaced. I welcome it. Also, they left the old system in place for a few years so you could transition workflows and tool sets so it's not like it vanished over night. Eric T. On Thursday, February 13, 2014 11:25:06 AM, Emilio Hernandez wrote: I will drink that beer in this one with Eric. I am not on the game side but on the film and advertising, so I only know the basics of a gaming engine and I found your survey challenge just to take a look back at the legacy tools and solve the problem, because as the rest of us I believe ICE is the word and the way to think how to solve a simple task as the one you describe. I use ICE for a lot of things, not only particles fx. And I am no erudit as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc. I will say I am an average ICE user more on the artist side. And really ICE never stops surprising me. I find it very stable, and I use it very often, even for very simple projects. And it allows me to change things as a line of shopping bags vanishing to the horizon in a breeze with client's request such as No, let's make the bags bigger. More bags, less bags. Can we see two rows of bags, perhpas three?... I can hardly imagine the 2020 release of Softimage, ICE dissapears out of nowhere. For me, it is like saying the render tree will vanish. Porting to a game engine from Softimage, is something that I can't speak a word. But in my regular workflow ICE rules! Cheers! 2014-02-13 8:19 GMT-06:00 Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com: So you need to hire robots then cause all workflows involving humans are prone to error, you just have to reduce it as much as possible. I'm with Brad regarding ICE. It's stable and mature for the bread and butter work that is done with it (an example is your asteroid task). Otherwise, how is real work getting done with it? Eric T. On 2/12/2014 6:01 PM, Matt Lind wrote: The point is we cannot subscribe to workflows which are prone to human error.
Re: Survey - how would you do this?
I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes, whereas constraints, using his example, are very old tech that is pretty much not going to change... ever. I can understand his point, but on the flip side, I'm also aware that nothing lasts forever. But policies governing how assets are handled I'm sure are not Matt's to set up, so anyway... I'm starting to ramble, but I think I made my point. Now, back to your original programming :-) . On 13/02/2014 11:25 AM, Emilio Hernandez wrote: I will drink that beer in this one with Eric. I am not on the game side but on the film and advertising, so I only know the basics of a gaming engine and I found your survey challenge just to take a look back at the legacy tools and solve the problem, because as the rest of us I believe ICE is the word and the way to think how to solve a "simple" task as the one you describe. I use ICE for a lot of things, not only particles fx. And I am no erudit as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc. I will say I am an average ICE user more on the artist side. And really ICE never stops surprising me. I find it very stable, and I use it very often, even for very simple projects. And it allows me to change things as a line of shopping bags vanishing to the horizon in a breeze with client's request such as "No, let's make the bags bigger. More bags, less bags. Can we see two rows of bags, perhpas three?..." I can hardly imagine the 2020 release of Softimage, ICE dissapears out of nowhere. For me, it is like saying the render tree will vanish. Porting to a game engine from Softimage, is something that I can't speak a word. But in my regular workflow ICE rules! Cheers! 2014-02-13 8:19 GMT-06:00 Eric Thivierge ethivie...@hybride.com: So you need to hire robots then cause all workflows involving humans are prone to error, you just have to reduce it as much as possible. I'm with Brad regarding ICE. It's stable and mature for the bread and butter work that is done with it (an example is your asteroid task). Otherwise, how is real work getting done with it? Eric T. On 2/12/2014 6:01 PM, Matt Lind wrote: The point is we cannot subscribe to workflows which are prone to human error. --
RE: Survey - how would you do this?
We instance like crazy in games. Keeps the memory foot print down (just like rendering) however we still need to battle draw calls. One game I worked on had memory super low and we were doing great but our draw calls went through the roof and our frames per second went way way down. So we had to balance our memory and draw calls delicately to ensure we weren't over memory but were maintaining a consistent 30 frames per second. God help those that run at 60 fps like Call of Duty. That's a tough business. That's why profiling tools are critical (like PIX on Windows). ___ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Tuesday, February 11, 2014 12:37 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? I meant that Matt was going to say that you can't instance stuff as one additional restriction... On 2/11/2014 3:28 PM, Emilio Hernandez wrote: Well not $10 bucks but a sample scene will say yes. https://dl.dropboxusercontent.com/u/49626349/Asteroids.scn [http://img694.imageshack.us/img694/8965/erojamailpleca.jpg] 2014-02-11 14:19 GMT-06:00 Tim Leydecker bauero...@gmx.demailto:bauero...@gmx.de: Do it by hand. Create null in center of Planet. Call it Parent_Mom. Create Volume Previz Torus Helper. Create Asteroid in Origin. Create Null. Name Null Asteroid_P001. Parent Asteroid to Asteroid_P001. Animate Asteroid Rotation (its tumbling) in Origin. Snap Asteroid_P001 to Torus. Parent Asteroid_P001 to Parent_Mom. Duplicate Asteroid_P001, resulting in Asteroid_P002. Snap Asteroid_P002 to Torus. Create Null, call it Parent_Spin. Parent Parent_Mom to Parent_Spin. Animate Rotation (Y) of Parent_Spin. Create Null, name it Parent_Dad. Name Planet Forever21Planet, parent Forever21 and Parent_Spin to Parent_Dad. Duplicate Asteroid_P002 as often as you need and snap to Torus. Duplicate Parent_Spin, rename Parent_Spin_faster. Adjust Animation to spin faster. Delete any Asteroids you don´t like, offset animations where neccessary or desired. Rinse, repeat. Play. On 11.02.2014 20:23, Matt Lind wrote: The question: but how do you apply the random jitter to the object positions?
Re: Survey - how would you do this?
When is the last time they changed ICE that it broke workflows and tools? Eric T. On 2/13/2014 11:35 AM, Sergio Mucino wrote: I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes, whereas constraints, using his example, are very old tech that is pretty much not going to change... ever. I can understand his point, but on the flip side, I'm also aware that nothing lasts forever. But policies governing how assets are handled I'm sure are not Matt's to set up, so anyway... I'm starting to ramble, but I think I made my point. Now, back to your original programming :-) .
Re: Survey - how would you do this?
2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.comwrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
Re: Survey - how would you do this?
Did you just have to recompile the tools? After that everything worked like before? On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote: 2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com wrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
Re: Survey - how would you do this?
after 2 service packs... arnold plugins are not available for 2014 or 2014 SP1. On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge ethivie...@hybride.comwrote: Did you just have to recompile the tools? After that everything worked like before? On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote: 2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com wrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
Re: Survey - how would you do this?
Fair enough, so I guess you're of the opinion that ICE is still fragile / unstable and not mature tool? On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote: after 2 service packs... arnold plugins are not available for 2014 or 2014 SP1. On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com wrote: Did you just have to recompile the tools? After that everything worked like before? On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote: 2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com__ wrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
Re: Survey - how would you do this?
i am of the opinion its not all unicorns and rainbows. i have been blocked number of times and there are areas of ICE that are too finicky and i wont touch (ICE Kinematics) s On Thu, Feb 13, 2014 at 11:22 AM, Eric Thivierge ethivie...@hybride.comwrote: Fair enough, so I guess you're of the opinion that ICE is still fragile / unstable and not mature tool?
RE: Survey - how would you do this?
of the ICE compound version manager. I haven't spent much time on it, but in the limited time I have spent with it (a few years ago) it didn't seem very open. Softimage tended to automatically prompt the user with a dialog each time it found a compound that was out of date. I couldn't find a way to suppress it and drive it through scripting on a scene load event as there are times we do not want the update to happen. That is an important pipeline management issue for us. Bottom line - for most of the problems I need to solve which I've tried ICE, ICE has either crash and burned or come up short in feature set to support our needs. Believe me, I've tried many times over many betas and releases and many different applications in production. The bottom line is ICE is not tailored to our needs and is of very limited use/benefit. Therefore, it's not a priority to get it working in our pipeline compared to the many other issues I must address to get our game out the door. For sake of argument, let's pretend ICE does work and is fully mature. The context in which we can use ICE is not the same context in which you and many others use it in film/video. When you make an asset and render it, you can pretty much forget about it and move onto the next. We do not have that luxury. We must maintain our assets release to release in the same fashion a commercial application is developed. But since art isn't code, we do not have the luxury of modifying classes or sub-classing code to implement updates and have it ripple out. We must manually revisit assets to apply such updates. Since standards have evolved over time, it's not always possible to run a batch process to do these updates as there is no way to know which standard was in effect when the asset was last touched. Operators have very limited benefit in a games pipeline as they don't translate into the game engine. We have a proprietary engine which we built in-house from scratch. Our principal engineer was the inventor of HLSL and one of the engineers behind World of Warcraft's engine, so he knows his stuff. Our game engine already has its own particle system, does not support IK or other runtime effects coming from a content creation package (most MMORPG's don't). Our primary needs are data translation (import/export), database communications, texture unfolding/UV manipulation, modeling tools such as re-topology and polygon reduction, hardware (real time) shading -- All of which Softimage doesn't do very well. On a simpler level- the ability to store colors in a palette for use in vertex color painting and sharing the palette between environment scenes. The ability to paint a texture on a model in 3D. The ability to re-pack and relax texture UVs into a defined UV space without requiring the f'in Unfold operator. The ability to resolve real time shader parameter names of in render passes which are overridden. On the animation side, the only real benefit ICE can give is a custom constraint operator or perhaps a custom tail rig operator for some of our characters. All our deformations must come through envelopes, but since we have hard limits on the number of bones we can use, there isn't enough resolution for a cloth simulator or deformation operator to be of use. Each of our assets must live on its own in a vacuum inside a model so it can be referenced into other scenes. That means no external dependencies other than texture maps. What we really need is for the god damn real time shaders to function up to their name and have migration paths that actually work. That is highly important and has been our biggest issue. When art is generated and exported, it must be migrated into the pipeline so other departments can work with the data downstream in production. Scripters, designers, engineers, level builders, etc... It's not too difficult to introduce art into the system, but there is a lot of inertia to make modifications because of all the downstream dependencies. Once an asset is available, you have to make the assumption it's used anywhere and everywhere because if you rip it out or modify it, you may break many things with a very large ripple effect. Chasing down those types of problems is very difficult, time consuming and stressful if you do not know the cause. For that reason, introducing something which is still aqueous, such as ICE, into production that really doesn't need it, is really not a good idea So you tell me where I can use ICE that makes it so important to make a round hose fit over a square filter for something of very limited benefit? I really want to hear this, Brad. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe Sent: Wednesday, February 12, 2014 5:47 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do
Re: Survey - how would you do this?
this didn’t start out as an ICE bashing tread, it was about the importance of the basic toolset - which some are tied to for whatever reasons. Productions have been done for many years before/without ICE - it's not a be all end all replacement for the rest of the toolset - though I'm sure some FX/TD oriented people might get that impression. ICE is great and all and it's a shame to avoid using it - but the basic toolset is getting little development efforts while ICE sucks most attention to it - or so it seems at least. That's not a healthy outlook on the long run - as well as very frustrating for those using ICE sparingly or not at all. ... -Original Message- From: Eric Thivierge Sent: Thursday, February 13, 2014 8:22 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Fair enough, so I guess you're of the opinion that ICE is still fragile / unstable and not mature tool? On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote: after 2 service packs... arnold plugins are not available for 2014 or 2014 SP1. On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com wrote: Did you just have to recompile the tools? After that everything worked like before? On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote: 2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com__ wrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
RE: Survey - how would you do this?
That is correct. ICE introduces a lot of risk because it is still molding into shape. We must be as risk averse as possible. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sergio Mucino Sent: Thursday, February 13, 2014 8:35 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes, whereas constraints, using his example, are very old tech that is pretty much not going to change... ever. I can understand his point, but on the flip side, I'm also aware that nothing lasts forever. But policies governing how assets are handled I'm sure are not Matt's to set up, so anyway... I'm starting to ramble, but I think I made my point. Now, back to your original programming :-) . [cid:image001.gif@01CF28B3.DC597160] On 13/02/2014 11:25 AM, Emilio Hernandez wrote: I will drink that beer in this one with Eric. I am not on the game side but on the film and advertising, so I only know the basics of a gaming engine and I found your survey challenge just to take a look back at the legacy tools and solve the problem, because as the rest of us I believe ICE is the word and the way to think how to solve a simple task as the one you describe. I use ICE for a lot of things, not only particles fx. And I am no erudit as Mr. Mootz, Thiago, Paul Smith, Ola Madsen, etc. I will say I am an average ICE user more on the artist side. And really ICE never stops surprising me. I find it very stable, and I use it very often, even for very simple projects. And it allows me to change things as a line of shopping bags vanishing to the horizon in a breeze with client's request such as No, let's make the bags bigger. More bags, less bags. Can we see two rows of bags, perhpas three?... I can hardly imagine the 2020 release of Softimage, ICE dissapears out of nowhere. For me, it is like saying the render tree will vanish. Porting to a game engine from Softimage, is something that I can't speak a word. But in my regular workflow ICE rules! Cheers! [http://img694.imageshack.us/img694/8965/erojamailpleca.jpg] 2014-02-13 8:19 GMT-06:00 Eric Thivierge ethivie...@hybride.commailto:ethivie...@hybride.com: So you need to hire robots then cause all workflows involving humans are prone to error, you just have to reduce it as much as possible. I'm with Brad regarding ICE. It's stable and mature for the bread and butter work that is done with it (an example is your asteroid task). Otherwise, how is real work getting done with it? Eric T. On 2/12/2014 6:01 PM, Matt Lind wrote: The point is we cannot subscribe to workflows which are prone to human error. -- inline: image001.gif
Re: Survey - how would you do this?
Yes I agree. It would be nice to have an upgrade in other areas more than ICE. And not only a camera switcher But I really don't expect too much for the 2015 version... Maybe we will see only an enhanced camera switcher... 2014-02-13 13:50 GMT-06:00 pete...@skynet.be: this didn't start out as an ICE bashing tread, it was about the importance of the basic toolset - which some are tied to for whatever reasons. Productions have been done for many years before/without ICE - it's not a be all end all replacement for the rest of the toolset - though I'm sure some FX/TD oriented people might get that impression. ICE is great and all and it's a shame to avoid using it - but the basic toolset is getting little development efforts while ICE sucks most attention to it - or so it seems at least. That's not a healthy outlook on the long run - as well as very frustrating for those using ICE sparingly or not at all. ... -Original Message- From: Eric Thivierge Sent: Thursday, February 13, 2014 8:22 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Fair enough, so I guess you're of the opinion that ICE is still fragile / unstable and not mature tool? On Thursday, February 13, 2014 2:16:02 PM, Steven Caron wrote: after 2 service packs... arnold plugins are not available for 2014 or 2014 SP1. On Thu, Feb 13, 2014 at 11:14 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com wrote: Did you just have to recompile the tools? After that everything worked like before? On Thursday, February 13, 2014 2:12:17 PM, Steven Caron wrote: 2014... anything using ICE SDK in the array area broke. On Thu, Feb 13, 2014 at 10:21 AM, Eric Thivierge ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com mailto:ethivie...@hybride.com__ wrote: When is the last time they changed ICE that it broke workflows and tools? Eric T.
Re: Survey - how would you do this?
I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes Wishful thinking I fear. On 13 Feb 2014, at 20:05, Matt Lind ml...@carbinestudios.com wrote: I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes
Re: Survey - how would you do this?
Probably, but... you get the idea :-) On 13/02/2014 3:09 PM, Paul wrote: "I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes" Wishful thinking I fear. On 13 Feb 2014, at 20:05, Matt Lind ml...@carbinestudios.com wrote: I think that what Matt meant is that ICE is fairly young tech, and therefore, still prone to possible changes --
Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind ml...@carbinestudios.com wrote: To work around many of the issues, artists migrated to other software such as Modo, Z-brush, and so on, further fracturing our pipeline where work takes place, and reducing our needs to write tools in Softimage for art manipulation where ICE can be a meaningful contributor. [...] The bottom line is ICE is not tailored to our needs and is of very limited use/benefit. [...] Our primary needs are data translation (import/export), database communications, texture unfolding/UV manipulation, modeling tools such as re-topology and polygon reduction, hardware (real time) shading -- All of which Softimage doesn't do very well So do you have a plan to diminish your dependency on Softimage? what is it, what's next?
RE: Survey - how would you do this?
I cannot reveal what our plans are, but I can say what we need is an environment that has an open and deep SDK to allow us to build tools on our terms, and not on the application's terms, so we can make our own infrastructure without having to re-invent the wheel and reduce risk from pipeline changes/regressions from commercial software. Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric engine most closely fits that paradigm, but it needs to mature before we can give it a serious look. I would not be surprised if we develop our own tools a la Pixar or the other mainstays of the industry. The trend in this space is to build your creation tools into your engine so you can take advantage of real time feedback from iteration (a la Valve). Since we built our own engine from scratch, we have full control to implement such features on our terms. Max, Maya, and Softimage don't cater to the MMORPG space very well. You can use the products, as many have obviously demonstrated over the years, but it's very much shaving the corners of the square peg to fit it into the round hole. This has been a classic problem in games for a long time as the commercial software largely cater to film/video and assume games is a simpler version of that paradigm. In the early days of games that was a band-aid that worked, but games have evolved a lot since then making the current 3D software not so relevant anymore. The difference with an MMORPG is the game has larger scope, compared to a console or mobile game, and therefore must pull back on nifty art features and think more big picture of the gameplay as network bandwidth is an issue, and there is a very wide variety of hardware out there that must be accounted for - unlike a console where a particular platform is known in advance and likely not to change (much). Majority of our anticipated customers still use older hardware running Windows XP, for example. We have to make content which caters to that lowest denomination. As tools move forward to accommodate those working on feats like Elysium, they tend to forget and leave behind those who still need that micro-architecture edit capability like us where pixels are still pushed one by one. There is a reason why many games don't have interesting artwork - the tools get in the way. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 2:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind ml...@carbinestudios.com wrote: To work around many of the issues, artists migrated to other software such as Modo, Z-brush, and so on, further fracturing our pipeline where work takes place, and reducing our needs to write tools in Softimage for art manipulation where ICE can be a meaningful contributor. [...] The bottom line is ICE is not tailored to our needs and is of very limited use/benefit. [...] Our primary needs are data translation (import/export), database communications, texture unfolding/UV manipulation, modeling tools such as re-topology and polygon reduction, hardware (real time) shading -- All of which Softimage doesn't do very well So do you have a plan to diminish your dependency on Softimage? what is it, what's next?
RE: Survey - how would you do this?
Just to tack on... Coming from UE3 and Unity, I can safely say that building engine dependent tools\editors into a DCC is decidedly not the way to go. If you can avoid it at all costs, I would highly recommend that. It's a slippery slope. You realize that most of the infrastructure you want is already in a DCC so it makes sense to use that as a base...months and years later you realize that was not a good decision. :) And now... My mantra over the last several years has been...the DCC is just that, it creates digital content. Everything else is done in engine\editor. Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing, cameras, terrain generation, scene assembly and so on should only ever be done in your engine and editor. And I got there from having tried to build the DCC into our editors. Both with Soft and with Maya. Both were the wrong choice. My team of nearly 50+ environment artists live a daily struggle because we made that choice. ___ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Thursday, February 13, 2014 3:16 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? I cannot reveal what our plans are, but I can say what we need is an environment that has an open and deep SDK to allow us to build tools on our terms, and not on the application's terms, so we can make our own infrastructure without having to re-invent the wheel and reduce risk from pipeline changes/regressions from commercial software. Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric engine most closely fits that paradigm, but it needs to mature before we can give it a serious look. I would not be surprised if we develop our own tools a la Pixar or the other mainstays of the industry. The trend in this space is to build your creation tools into your engine so you can take advantage of real time feedback from iteration (a la Valve). Since we built our own engine from scratch, we have full control to implement such features on our terms. Max, Maya, and Softimage don't cater to the MMORPG space very well. You can use the products, as many have obviously demonstrated over the years, but it's very much shaving the corners of the square peg to fit it into the round hole. This has been a classic problem in games for a long time as the commercial software largely cater to film/video and assume games is a simpler version of that paradigm. In the early days of games that was a band-aid that worked, but games have evolved a lot since then making the current 3D software not so relevant anymore. The difference with an MMORPG is the game has larger scope, compared to a console or mobile game, and therefore must pull back on nifty art features and think more big picture of the gameplay as network bandwidth is an issue, and there is a very wide variety of hardware out there that must be accounted for - unlike a console where a particular platform is known in advance and likely not to change (much). Majority of our anticipated customers still use older hardware running Windows XP, for example. We have to make content which caters to that lowest denomination. As tools move forward to accommodate those working on feats like Elysium, they tend to forget and leave behind those who still need that micro-architecture edit capability like us where pixels are still pushed one by one. There is a reason why many games don't have interesting artwork - the tools get in the way. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 2:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 2:31 PM, Matt Lind ml...@carbinestudios.com wrote: To work around many of the issues, artists migrated to other software such as Modo, Z-brush, and so on, further fracturing our pipeline where work takes place, and reducing our needs to write tools in Softimage for art manipulation where ICE can be a meaningful contributor. [...] The bottom line is ICE is not tailored to our needs and is of very limited use/benefit. [...] Our primary needs are data translation (import/export), database communications, texture unfolding
Re: Survey - how would you do this?
Matt makes some valid points and to me shows some of the (even these days) major differences between games and film/tv pipelines. It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty example of that, but that when it comes to creating games assets and pipelines, its perhaps not best suited to some of the requirements. It¹s not much good creating custom ICE nodes and compounds, but they can in effect be useless, unless you can reflect the tool/tech in the game engine and/or get the exported. Sure you can bake as many have mentioned, but that doesn¹t always apply in all cases. Also it creates more data that has got to be loaded in game and memory, and as Marc says games is so often about balancing budget to get things running. Even when you have assets built to spec, you can still end up cutting back anywhere you can, to get the framerate. 30 fps was realistic, 60 was very often a dream. Game devs are renown for building lots of proprietary tools and technology, some of which is justifiable, others times they¹re reinventing the wheel. But I think some of that is changing. Whereas in the past games would literally write everything, more are now buying off the shelf with middleware for some things, and focusing their resources on the right things. It¹s simply not always realistic and financially viable to write everything bespoke. I used to be a firm believer of having a DCC as a game editor, as I¹d seen too many show off programmers thinking they could write their own Max/Maya and while I have seen some good editors, most have been poor. But I think Marc¹s points are very valid, I wouldn¹t take that approach now. I still think in the right context the DCC could work, but it depends a lot on the pipeline and the type of game being made. The game engine is always going to be the best place to view assets, as its the end result, but I¹d squeeze everything I could from a DCC before pushing my data through the pipe. I thought Matt challenge was great and very typical of the type of thing you see now in mobile/casual gaming. Simple data, simple process, get it down and get it out. On 13/02/2014 23:48, Marc Brinkley marc.brink...@microsoft.com wrote: Just to tack on... Coming from UE3 and Unity, I can safely say that building engine dependent tools\editors into a DCC is decidedly not the way to go. If you can avoid it at all costs, I would highly recommend that. It's a slippery slope. You realize that most of the infrastructure you want is already in a DCC so it makes sense to use that as a base...months and years later you realize that was not a good decision. :) And now... My mantra over the last several years has been...the DCC is just that, it creates digital content. Everything else is done in engine\editor. Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing, cameras, terrain generation, scene assembly and so on should only ever be done in your engine and editor. And I got there from having tried to build the DCC into our editors. Both with Soft and with Maya. Both were the wrong choice. My team of nearly 50+ environment artists live a daily struggle because we made that choice. __ _ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Thursday, February 13, 2014 3:16 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? I cannot reveal what our plans are, but I can say what we need is an environment that has an open and deep SDK to allow us to build tools on our terms, and not on the application's terms, so we can make our own infrastructure without having to re-invent the wheel and reduce risk from pipeline changes/regressions from commercial software. Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric engine most closely fits that paradigm, but it needs to mature before we can give it a serious look. I would not be surprised if we develop our own tools a la Pixar or the other mainstays of the industry. The trend in this space is to build your creation tools into your engine so you can take advantage of real time feedback from iteration (a la Valve). Since we built our own engine from scratch, we have full control to implement such features on our terms. Max, Maya, and Softimage don't cater to the MMORPG space very well. You can use the products, as many have obviously demonstrated
Re: Survey - how would you do this?
Just found this thread tonight. I must say I liked your idea Matt :) Manny and Christian demos are just great. It is funny that most of us can't think outside ICE now. As soon as something a little bit complex appear, we jump in this node graph like zombies. Constraints (no pun intended) are the key for creativity ! Cheers, Guillaume PS: I don't want to imagine how slow it would be to drive 1000 spheres kinematics using ICE :P On Thu, Feb 13, 2014 at 7:11 PM, Graham Bell graham.b...@autodesk.comwrote: Matt makes some valid points and to me shows some of the (even these days) major differences between games and film/tv pipelines. It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty example of that, but that when it comes to creating games assets and pipelines, its perhaps not best suited to some of the requirements. It¹s not much good creating custom ICE nodes and compounds, but they can in effect be useless, unless you can reflect the tool/tech in the game engine and/or get the exported. Sure you can bake as many have mentioned, but that doesn¹t always apply in all cases. Also it creates more data that has got to be loaded in game and memory, and as Marc says games is so often about balancing budget to get things running. Even when you have assets built to spec, you can still end up cutting back anywhere you can, to get the framerate. 30 fps was realistic, 60 was very often a dream. Game devs are renown for building lots of proprietary tools and technology, some of which is justifiable, others times they¹re reinventing the wheel. But I think some of that is changing. Whereas in the past games would literally write everything, more are now buying off the shelf with middleware for some things, and focusing their resources on the right things. It¹s simply not always realistic and financially viable to write everything bespoke. I used to be a firm believer of having a DCC as a game editor, as I¹d seen too many show off programmers thinking they could write their own Max/Maya and while I have seen some good editors, most have been poor. But I think Marc¹s points are very valid, I wouldn¹t take that approach now. I still think in the right context the DCC could work, but it depends a lot on the pipeline and the type of game being made. The game engine is always going to be the best place to view assets, as its the end result, but I¹d squeeze everything I could from a DCC before pushing my data through the pipe. I thought Matt challenge was great and very typical of the type of thing you see now in mobile/casual gaming. Simple data, simple process, get it down and get it out. On 13/02/2014 23:48, Marc Brinkley marc.brink...@microsoft.com wrote: Just to tack on... Coming from UE3 and Unity, I can safely say that building engine dependent tools\editors into a DCC is decidedly not the way to go. If you can avoid it at all costs, I would highly recommend that. It's a slippery slope. You realize that most of the infrastructure you want is already in a DCC so it makes sense to use that as a base...months and years later you realize that was not a good decision. :) And now... My mantra over the last several years has been...the DCC is just that, it creates digital content. Everything else is done in engine\editor. Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing, cameras, terrain generation, scene assembly and so on should only ever be done in your engine and editor. And I got there from having tried to build the DCC into our editors. Both with Soft and with Maya. Both were the wrong choice. My team of nearly 50+ environment artists live a daily struggle because we made that choice. __ _ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Thursday, February 13, 2014 3:16 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? I cannot reveal what our plans are, but I can say what we need is an environment that has an open and deep SDK to allow us to build tools on our terms, and not on the application's terms, so we can make our own infrastructure without having to re-invent the wheel and reduce risk from pipeline changes/regressions from commercial software. Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric
RE: Survey - how would you do this?
but I¹d squeeze everything I could from a DCC before pushing my data through the pipe We are trying to do that now...you wouldn't believe the pain and suffering we are going through. Oh how I long for the days of UE3. Create model and UVs, Rig and Animate, export to FBX...done. Then you do the hard work in your editor and engine on target. Of course I wouldn't dare create an MMO in UE3. Wouldn't even come close to scaling up. Most of the tools we ever needed was for asset naming, checkin and export. That was it. 99% of it was vanilla Soft or Maya. ___ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Graham Bell Sent: Thursday, February 13, 2014 4:12 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Matt makes some valid points and to me shows some of the (even these days) major differences between games and film/tv pipelines. It¹s not that ICE isn¹t capable of doing amazing things, there¹s plenty example of that, but that when it comes to creating games assets and pipelines, its perhaps not best suited to some of the requirements. It¹s not much good creating custom ICE nodes and compounds, but they can in effect be useless, unless you can reflect the tool/tech in the game engine and/or get the exported. Sure you can bake as many have mentioned, but that doesn¹t always apply in all cases. Also it creates more data that has got to be loaded in game and memory, and as Marc says games is so often about balancing budget to get things running. Even when you have assets built to spec, you can still end up cutting back anywhere you can, to get the framerate. 30 fps was realistic, 60 was very often a dream. Game devs are renown for building lots of proprietary tools and technology, some of which is justifiable, others times they¹re reinventing the wheel. But I think some of that is changing. Whereas in the past games would literally write everything, more are now buying off the shelf with middleware for some things, and focusing their resources on the right things. It¹s simply not always realistic and financially viable to write everything bespoke. I used to be a firm believer of having a DCC as a game editor, as I¹d seen too many show off programmers thinking they could write their own Max/Maya and while I have seen some good editors, most have been poor. But I think Marc¹s points are very valid, I wouldn¹t take that approach now. I still think in the right context the DCC could work, but it depends a lot on the pipeline and the type of game being made. The game engine is always going to be the best place to view assets, as its the end result, but I¹d squeeze everything I could from a DCC before pushing my data through the pipe. I thought Matt challenge was great and very typical of the type of thing you see now in mobile/casual gaming. Simple data, simple process, get it down and get it out. On 13/02/2014 23:48, Marc Brinkley marc.brink...@microsoft.com wrote: Just to tack on... Coming from UE3 and Unity, I can safely say that building engine dependent tools\editors into a DCC is decidedly not the way to go. If you can avoid it at all costs, I would highly recommend that. It's a slippery slope. You realize that most of the infrastructure you want is already in a DCC so it makes sense to use that as a base...months and years later you realize that was not a good decision. :) And now... My mantra over the last several years has been...the DCC is just that, it creates digital content. Everything else is done in engine\editor. Materials, post FX, physics, VFX, Fluids, lighting, animation sequencing, cameras, terrain generation, scene assembly and so on should only ever be done in your engine and editor. And I got there from having tried to build the DCC into our editors. Both with Soft and with Maya. Both were the wrong choice. My team of nearly 50+ environment artists live a daily struggle because we made that choice. ___ ___ _ Marc Brinkley 343 Industries Microsoft Studios marc.brinkley [at] microsoft.com -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Thursday, February 13, 2014 3:16 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? I cannot reveal what our plans are, but I can say what we need is an environment that has an open and deep SDK to allow us to build tools on our terms, and not on the application's terms, so we can make our own infrastructure without having to re-invent the wheel and reduce risk from pipeline changes/regressions from commercial
Re: Survey - how would you do this?
This should be a separate thread, but it's related: I discovered a trick long ago on how to drive kinematics with ICE and have it be quite fast, easily pushing 1000 nulls in real time. You build a single polygon mesh with a separate square for each particle, driving each square from the particle's SRTs with a simple ICE op. Then you create a cluster on each square and constrain scene objects to the clusters. I had a script that set the whole thing up, so you could select a group of scene objects, then pick a particle cloud, and it would constrain the scene objects in the order you selected them. This was a necessary workaround back in the old days when Arnold wasn't working with instances, but the tool came in handy for all kinds of situations to drive scene object kinematics based on particle sims. When they gave us ICE kinematics later on, the cluster constraint trick still performed much faster and was more stable so I kept using it. This same technique, BTW, allows you to use deformations to control SRT movement of scene objects. Once your objects are constrained to geometry, you can apply envelopes, lattices, or whatever other creative setups to animate their motion.
Re: Survey - how would you do this?
On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric engine most closely fits that paradigm sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya.
Re: Survey - how would you do this?
I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? :D On Thu, Feb 13, 2014 at 8:26 PM, Luc-Eric Rousseau luceri...@gmail.comwrote: On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. Not have licensing which ties the content creation product into our released product, and is very cost effective for very large teams working across multiple sites. Can be set up quickly and easily and is a light install, and not require engineers to make usable or explain to artists. In concept, Fabric engine most closely fits that paradigm sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya.
Re: Survey - how would you do this?
ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
sarcasm aside, i am not surprised people use maya for game dev.. i know very well how customizable it is, and envy it plenty. its just not... exciting to me. On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
Yeah, Maya is an API. Much better from a dev point of view I agree. On Thu, Feb 13, 2014 at 9:01 PM, Steven Caron car...@gmail.com wrote: sarcasm aside, i am not surprised people use maya for game dev.. i know very well how customizable it is, and envy it plenty. its just not... exciting to me. On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
difference is, autodesk already has our money. :) i am fine with it actually. share how maya is better, i too think it is important people have correct information about the subject. On Thu, Feb 13, 2014 at 6:26 PM, Luc-Eric Rousseau luceri...@gmail.comwrote: imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story.
Re: Survey - how would you do this?
Luc-Eric, you can try as you want, but you are inside AD, so you are biased as much as me when I was speaking about Softimage as an Autodesk employee or speaking about Creation Platform as a Fabric employee. On Thu, Feb 13, 2014 at 9:26 PM, Luc-Eric Rousseau luceri...@gmail.comwrote: imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
RE: Survey - how would you do this?
Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest of the industry because we needed to do certain things more efficiently whether it be how we pack data or crunch the numbers. Matt
Re: Survey - how would you do this?
Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.com wrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest of the industry because we needed to do certain things more efficiently whether it be how we pack data or crunch the numbers. Matt
Re: Survey - how would you do this?
You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest of the industry because we needed to do certain things more efficiently whether it be how we pack data or crunch the numbers. Matt
RE: Survey - how would you do this?
I still have flappy bird on my phone. Asking $2,000 USD. Don't have asteroids anymore. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Sebastien Sterling Sent: Thursday, February 13, 2014 7:42 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: Below: -Original Message- 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 Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.commailto:softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec
Re: Survey - how would you do this?
... i didn't know flappy birds was a thing. Hein... it's clearly Maya running in library mode :P On 14 February 2014 04:43, Matt Lind ml...@carbinestudios.com wrote: I still have flappy bird on my phone. Asking $2,000 USD. Don't have asteroids anymore. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Sebastien Sterling *Sent:* Thursday, February 13, 2014 7:42 PM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.com wrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move
Re: Survey - how would you do this?
LOL Cinema4D + Asteroid sounds so Amiga (the first platform of this 3D app). On Thu, Feb 13, 2014 at 10:42 PM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest of the industry because we needed to do certain things more efficiently whether it be how we pack data or crunch the numbers. Matt
Re: Survey - how would you do this?
Considering someone took the time to make a block breaker in ICE, i don't know if we get to laugh that hard :P On 14 February 2014 05:09, Guillaume Laforge guillaume.laforge...@gmail.com wrote: LOL Cinema4D + Asteroid sounds so Amiga (the first platform of this 3D app). On Thu, Feb 13, 2014 at 10:42 PM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest
Re: Survey - how would you do this?
Sorry to jump into this masters discution, but don't we have PyQT in Softimage also? And now that Luc-Eric jumped in... Ok, Maya is more customizable, and better for Devs to integrate it into a pipeline and bla, bla, bla. Because out of the box sorry but... p I am a novel in Maya and I am using it because I need to, not because I am convinced of using it. And the more I use it, the more I love Softimage. I couldn't find a way to transfer a simple UV from one mesh to another. So I went and dug into Creative Crash to find a script... A script for this, a script for that. The only thing I want to thank Maya is that I started scripting again... Thank god I have two monitors to have the script editor open with I don't know how many tabs. Or why not. I can have a lot of buttons clogging more my workspace with nice Maya icons. I don't have time to start getting creative to draw an icon for each additional script I write to do a simple task... And speaking of constrains. To constrain to a point on a mesh in Maya, you need to have UV's! and watch out. If you constrain to a point that in the UV is in two different coordinates... ciao... So yes maybe when you have an army of Devs scripting and scripting. You can have awsome custom tools... But when you have a small studio or you are freelance, for me Maya is no go. So instead of spreading the word on how good is Maya compared to Softimage to try to convince us to switch platforms, because Maya is more customizable. We want a descent upgrade of Softimage. Not only a super camera switcher. What is the fear of Autodesk? That if you guys start making real improvements on Softimage the Maya industry standard farce will fall? Sorry but I am really pissed off of how Autodesk is handling Softimage. The best thing you can do is put it on sale so that people who really cares, will take Softimage to the next level instead of burying it in Asia. But this will hardly happen. Softimage in some other hands will be a very strong contender to Maya 2014-02-13 20:49 GMT-06:00 Guillaume Laforge guillaume.laforge...@gmail.com : Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC
Re: Survey - how would you do this?
Guillaume next time you are invited round AD headquarters for an event say you are going to the toilette and steal the deeds back for softimage. THE SPICE MUST FLOW ! On 14 February 2014 05:15, Emilio Hernandez emi...@e-roja.com wrote: Sorry to jump into this masters discution, but don't we have PyQT in Softimage also? And now that Luc-Eric jumped in... Ok, Maya is more customizable, and better for Devs to integrate it into a pipeline and bla, bla, bla. Because out of the box sorry but... p I am a novel in Maya and I am using it because I need to, not because I am convinced of using it. And the more I use it, the more I love Softimage. I couldn't find a way to transfer a simple UV from one mesh to another. So I went and dug into Creative Crash to find a script... A script for this, a script for that. The only thing I want to thank Maya is that I started scripting again... Thank god I have two monitors to have the script editor open with I don't know how many tabs. Or why not. I can have a lot of buttons clogging more my workspace with nice Maya icons. I don't have time to start getting creative to draw an icon for each additional script I write to do a simple task... And speaking of constrains. To constrain to a point on a mesh in Maya, you need to have UV's! and watch out. If you constrain to a point that in the UV is in two different coordinates... ciao... So yes maybe when you have an army of Devs scripting and scripting. You can have awsome custom tools... But when you have a small studio or you are freelance, for me Maya is no go. So instead of spreading the word on how good is Maya compared to Softimage to try to convince us to switch platforms, because Maya is more customizable. We want a descent upgrade of Softimage. Not only a super camera switcher. What is the fear of Autodesk? That if you guys start making real improvements on Softimage the Maya industry standard farce will fall? Sorry but I am really pissed off of how Autodesk is handling Softimage. The best thing you can do is put it on sale so that people who really cares, will take Softimage to the next level instead of burying it in Asia. But this will hardly happen. Softimage in some other hands will be a very strong contender to Maya 2014-02-13 20:49 GMT-06:00 Guillaume Laforge guillaume.laforge...@gmail.com: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see
Re: Survey - how would you do this?
Take me in and I will distract the secretary! 2014-02-13 22:23 GMT-06:00 Sebastien Sterling sebastien.sterl...@gmail.com : Guillaume next time you are invited round AD headquarters for an event say you are going to the toilette and steal the deeds back for softimage. THE SPICE MUST FLOW ! On 14 February 2014 05:15, Emilio Hernandez emi...@e-roja.com wrote: Sorry to jump into this masters discution, but don't we have PyQT in Softimage also? And now that Luc-Eric jumped in... Ok, Maya is more customizable, and better for Devs to integrate it into a pipeline and bla, bla, bla. Because out of the box sorry but... p I am a novel in Maya and I am using it because I need to, not because I am convinced of using it. And the more I use it, the more I love Softimage. I couldn't find a way to transfer a simple UV from one mesh to another. So I went and dug into Creative Crash to find a script... A script for this, a script for that. The only thing I want to thank Maya is that I started scripting again... Thank god I have two monitors to have the script editor open with I don't know how many tabs. Or why not. I can have a lot of buttons clogging more my workspace with nice Maya icons. I don't have time to start getting creative to draw an icon for each additional script I write to do a simple task... And speaking of constrains. To constrain to a point on a mesh in Maya, you need to have UV's! and watch out. If you constrain to a point that in the UV is in two different coordinates... ciao... So yes maybe when you have an army of Devs scripting and scripting. You can have awsome custom tools... But when you have a small studio or you are freelance, for me Maya is no go. So instead of spreading the word on how good is Maya compared to Softimage to try to convince us to switch platforms, because Maya is more customizable. We want a descent upgrade of Softimage. Not only a super camera switcher. What is the fear of Autodesk? That if you guys start making real improvements on Softimage the Maya industry standard farce will fall? Sorry but I am really pissed off of how Autodesk is handling Softimage. The best thing you can do is put it on sale so that people who really cares, will take Softimage to the next level instead of burying it in Asia. But this will hardly happen. Softimage in some other hands will be a very strong contender to Maya 2014-02-13 20:49 GMT-06:00 Guillaume Laforge guillaume.laforge...@gmail.com: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep
RE: Survey - how would you do this?
How does the linux version get around all of the MFC / Com+ dependencies ? Would be great if we could get the linux version to be used as the compile base. In theory then a more open windows version and even a mac version would be possible ;) On the plus side at least you have moved to a decent laptop now ;) My only experience in this was from a long time back. FBX , was buggy and Alembic wasnt yet an option. We came up with an exporter that allowed a decent to and fro between 3D app and Games engine. Similar to how the obj exporter worked it was text based and had a separate include file for geometry, materials,bones animation etc. This allowed it to be be easy to use for version control , and also allowed us to reuse animations etc across more then one model. Admittedly things were a lot simpler then . Havent looked at Modo for creating the asteroid belt. will try have a look this weekend. From: Luc-Eric Rousseau [luceri...@gmail.com] Sent: 14 February 2014 04:26 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? imagine if we made such jokes every time the Fabric came to pimp their stuff here. ;) If there is going to be a discussion about creating custom tools for artists, sweeping statements about DCCs, and name dropping like Pixar, it's in everyone's interest to be informed about the maya side of the story. On my side, as Maya UI team lead, pyside (python+qt) is part of the day-to-day. Something I could have never imagine on Softimage. I'd always have to write everything in C++/MFC to do anything. I've also dumped my PC for a Macbook Pro. On Thu, Feb 13, 2014 at 8:56 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ? = table width=100% border=0 cellspacing=0 cellpadding=0 style=width:100%; tr td align=left style=text-align:justify;font face=arial,sans-serif size=1 color=#99span style=font-size:11px;This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify us immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the University. Only authorised signatories are competent to enter into agreements on behalf of the University and recipients are thus advised that the content of this message may not be legally binding on the University and may contain the personal views and opinions of the author, which are not necessarily the views and opinions of The University of the Witwatersrand, Johannesburg. All agreements between the University and outsiders are subject to South African Law unless the University agrees in writing to the contrary. /span/font/td /tr /table
RE: Survey - how would you do this?
Don't get me wrong...its not like I am very excited to use it either. I knew coming here my days of hands on SI work was over. But honestly, my career over the last 8 years has veered away from hands on content creation so I really don't use any DCC these days...however my team does use Maya as the main tool exactly because it is so customizable. Along with Modo and a handful of SI users too! But, just because Maya is so customizable doesn't mean that it makes life easier. From my point of view, this place built their entire workflow and toolset on Maya and we are paying a deep cost because of that in time, money and sanity. Most people don't see it that way. But having used other DCCs and other engines this pain was completely self-inflicted. The burn rate on building out Maya tools and the overhead we are paying to just support and bug fix our own tools is crazy. I would have rather spent that money on other tools, workflows and even building our own editor. Then at least we would have had all the control in the world. This is why doing it all in the DCC doesn't make sense to me. To Graham's point, yes I have seen one too many devs with eyes bigger than their stomach think they can build the next great engine and editor. Not too many places can actually afford to do that or even do it right. Though I have been lucky to work at places that can or at least be smart enough to just buy a license of UE3\4. Meh 2 cents to the pile. Back to my excel and powerpoint. :) From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron Sent: Thursday, February 13, 2014 6:01 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? sarcasm aside, i am not surprised people use maya for game dev.. i know very well how customizable it is, and envy it plenty. its just not... exciting to me. On Thu, Feb 13, 2014 at 5:56 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: Don't forget to print the threads/coupons Steven ! On Thu, Feb 13, 2014 at 8:37 PM, Steven Caron car...@gmail.commailto:car...@gmail.com wrote: ya, i get that feeling too ;) its magical On Thu, Feb 13, 2014 at 5:32 PM, Guillaume Laforge guillaume.laforge...@gmail.commailto:guillaume.laforge...@gmail.com wrote: I've got the feeling that someone is trying to sell us some Autodesk products here. Can I have a special discount if I print this thread and bring it to my reseller ?
Re: Survey - how would you do this?
really nice, first jump into thread Luc-Eric and question is like oh ditch SI what do you wanna use next (*cough* Maya *cough*) But as someone else mentioned... there is old saying... Every gypsy brags about his horse not sure how it sounds in English but should get across... On Fri, Feb 14, 2014 at 4:42 AM, Sebastien Sterling sebastien.sterl...@gmail.com wrote: You can do it in cinema4D ! with the asteroid belt deformer, its right next to the popcorn deformer and the flap your arms like a bird deformer ! On 14 February 2014 03:49, Guillaume Laforge guillaume.laforge...@gmail.com wrote: Btw, would love to see how to build such asteroid belt in Modo ;) On Thu, Feb 13, 2014 at 9:47 PM, Matt Lind ml...@carbinestudios.comwrote: Below: -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Thursday, February 13, 2014 5:26 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Thu, Feb 13, 2014 at 6:16 PM, Matt Lind ml...@carbinestudios.com wrote: Allows us to define our own primitives, data structures, and treats those data structures as first class citizens in the API. yeah, with only experience with Softimage's SDK one might think that's something special. But it's a common thing to do with Maya. [Matt] I was paraphrasing a comment made by one of our engineers. Although I have run into the issue myself more than once. sure, Fabric requires no work at all to make it usable for artist.. it's magical. (Does not really answer the questions about your uv editing, retopology, and reduction problems, though) [Matt] Never claimed it did. Only said it's closer in paradigm to what we need, and it still needs to mature for us to give it a serious look. What it does offer is the ability to take control of the situation and develop what we need without re-inventing the wheel from scratch every time. About authoring stuff that would not be obviously better authored directly in the game engine: there are a lot of custom authoring tools out there where the tool is actually the Maya running in library mode. You have no way of knowing this if all you see is a video of it on the web, the maya UI is not there at all, it looks like it was a custom tool written from scratch. Maya in library mode takes no licenses. All of this is simply inconceivable from a Softimage point of view, and it was a factor in getting kicked out of the bigger places. [Matt] The point of editing in the game engine is changes to the engine are immediately available to the artist creating content. What they see is what they get, and with real time feedback. A large portion of any artists' day is spent waiting for files to export from the DCC and collate into the engine. In some cases many minutes per export/collate. That is not iteration friendly and problematic for engineers as they have another set of code to maintain and keep in sync. Having a Maya backend in library mode doesn't solve this problem. One problem we continually face is the ability to see an asset in the context of the game with proper lighting, fx, and other game specific data in the authoring stages. An artist needs to see how a reflective surface will look in a particular zone of a world. You cannot easily replicate that in a commercial DCC. Likewise, it's not simple to recreate the DCC's editing power for creating raw assets. The process of moving towards the engine has to start somewhere. Right now many games have level editors, texture paging editors, and so on. Those tools need to come together and start incorporating raw 3D data into the mix where it can be more easily edited. That's the next generation of tools. Most engines already define how animation works and exposing transform manipulators and FCurve editors wouldn't be too much of a stretch beyond what's already in the system (in comparison to doing the same for modeling, texturing, etc...). The DCC shouldn't be dismissed, but the commercial vendors have to stop working like a cable company and forcing customers to choose off their menus to get any signal at all. There are other stuff at Autodesk that is moving away from putting everything directly in the DCC when it makes sense. For example, shaderfx is a realtime shader editor that runs also out of Maya. The Bifrost and xgen engines are also separate from Maya. [Matt] Does not apply to our situation. Make sense for small to mid sized studios that work with commercial engines where they're limited in what they can modify. Commercial tools tend to develop towards a spec, and is only useful for consumers of the spec. Once you move out of the spec, the tool is less useful because it cannot always accommodate. We built our engine from scratch and in some cases don't follow the same standards as the rest
Re: Survey - how would you do this?
On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way into the game engine are very expensive to find, fix, and QA. Therefore, great emphasis should be placed on technique and working cleanly. Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? Don't you have to do that for expression, anim mixer, etc? I mean you don't have that in the engine either, right?
Re: Survey - how would you do this?
Hmm.. I don't know why.. I must not understand the challenge. How I'd do it is: 1) duplicate your astroid(s) ( in this case not instances for art-direction ) # of times you want. 2) select all, and path constrain to a Circle Curve. ( roughly 40 units ) 3) Multi-select their constraint, and set the length to r(0,100) 4) Then set the translation along the bias, and normal to be r(-5,5) you'll have to play with the values to get a proper dispersion. 5) now you have a ring of astroids randomly distributed along a torus. You can animate the ring to get them all moving. You can set keys using the random property... *shrug* I must not fully understand the problem. On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind ml...@carbinestudios.com wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.GO! Matt
Re: Survey - how would you do this?
id go with what jeffrey said, but that doesnt protect against collisions. honestly, im using ICE alot with Unity. No biggy, If your working with a pointcloud, just take that data along with ice kinematics, and plot the information out onto the actual assets. then export to the game. I think you can still use ice and then just bake that out to a game On Wed, Feb 12, 2014 at 11:37 PM, Jeffrey Dates jda...@kungfukoi.comwrote: Hmm.. I don't know why.. I must not understand the challenge. How I'd do it is: 1) duplicate your astroid(s) ( in this case not instances for art-direction ) # of times you want. 2) select all, and path constrain to a Circle Curve. ( roughly 40 units ) 3) Multi-select their constraint, and set the length to r(0,100) 4) Then set the translation along the bias, and normal to be r(-5,5) you'll have to play with the values to get a proper dispersion. 5) now you have a ring of astroids randomly distributed along a torus. You can animate the ring to get them all moving. You can set keys using the random property... *shrug* I must not fully understand the problem. On Tue, Feb 11, 2014 at 2:23 PM, Matt Lind ml...@carbinestudios.comwrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.GO! Matt
RE: Survey - how would you do this?
We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way into the game engine are very expensive to find, fix, and QA. Therefore, great emphasis should be placed on technique and working cleanly. Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? Don't you have to do that for expression, anim mixer, etc? I mean you don't have that in the engine either, right?
Re: Survey - how would you do this?
In less than the amount of time you've spent on this thread, you could have written a simple script to bake out ICE particle SRT's, which would not only help in this situation, but a million and one others. :-) Sent from my iPhone On Feb 12, 2014, at 12:35 PM, Matt Lind ml...@carbinestudios.com wrote: We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way into the game engine are very expensive to find, fix, and QA. Therefore, great emphasis should be placed on technique and working cleanly. Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? Don't you have to do that for expression, anim mixer, etc? I mean you don't have that in the engine either, right?
RE: Survey - how would you do this?
You assume somebody besides me knows how to use ICE in this building. The only reason I'm able to write on this thread now is because I'm waiting for queries and builds to complete. That's about to end. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe Sent: Wednesday, February 12, 2014 10:52 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? In less than the amount of time you've spent on this thread, you could have written a simple script to bake out ICE particle SRT's, which would not only help in this situation, but a million and one others. :-) Sent from my iPhone On Feb 12, 2014, at 12:35 PM, Matt Lind ml...@carbinestudios.com wrote: We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way into the game engine are very expensive to find, fix, and QA. Therefore, great emphasis should be placed on technique and working cleanly. Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? Don't you have to do that for expression, anim mixer, etc? I mean you don't have that in the engine either, right?
RE: Survey - how would you do this?
So cheese and monkeys aside. After 25 years as a 3D animator I've never worked in games. So from a serious perspective I simply don't understand. It's not clear to me why you aren't able to use ICE or scripts and freeze those construction connections sending only the raw assets over without ICE or scripting. What is it about this pipeline which makes that difficult? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, February 12, 2014 1:35 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way into the game engine are very expensive to find, fix, and QA. Therefore, great emphasis should be placed on technique and working cleanly. Sorry, I missed a bit. Why couldn't you plot animation by things driven by ICE? Don't you have to do that for expression, anim mixer, etc? I mean you don't have that in the engine either, right?
Re: Survey - how would you do this?
Artists don't need to even understand that they are using ICE if you build a proper interface for the system. We even have MODELERS here using ICE! :P Eric T.
RE: Survey - how would you do this?
You're missing the point, I don't have that time available. Don't let my ability to type really fast fool you into thinking I do. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Wednesday, February 12, 2014 11:01 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Artists don't need to even understand that they are using ICE if you build a proper interface for the system. We even have MODELERS here using ICE! :P Eric T.
RE: Survey - how would you do this?
Part of it is circumstance, as in we only have so many resources. For example, our art department is 100+, but I'm the only one in the department who writes code and I'm currently tasked with significantly higher priority issues helping out an under staffed engineering department than writing one-offs for every artist who needs a button. The other part is pipeline management of a large scale software development effort. We have a feature film sized team working to build a high profile AAA title. With an engine and tools under constant evolution, and life expectancy of 15+ years, you must choose methods of content creation which can withstand changes to the software, such as Softimage, as well as changes to the game itself. An asset created today must expect to live for 10+ years without any further maintenance. If given the choice between creating an asteroid belt using constraints vs. ICE, we'll probably opt for constraints because we know it's a fairly stable and mature system, which cannot be said for ICE. We've been bitten many times already such as when we created a number of simulations back in XSI 5 using the Softimage particle system only for the particle system to be ripped out and replaced with ICE. We can no longer open those assets in Softimage. Same happened again with updates to the realtime shader APIs. So now we must either live with their current state of dysfunction, or rebuild from scratch. On projects of this magnitude, risk assessment has a very high priority and taken extremely seriously because one bad move can literally sink the project if the ripple effect is large enough. While we do take measures to abstract data from commercial tools, we only have so much programming power in house to do so. The point is we cannot subscribe to workflows which are prone to human error. Creating temporary data and expecting the artist to clean up after himself has proven to not be reliable as assets are referenced by other assets all the time. If crap is left around, then anybody referencing that asset also inherits the crap which results in bugs in game. In film/video you can sweep things under the carpet if they aren't perfect as long as the problem doesn't show up on camera. We don't have that luxury. What you make has to be functional and optimal for a live game environment, conservative on resources, and not make any assumptions how it will be used. Function has higher priority than looking pretty. There's a lot more to it, but I think you get the gist of it. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Wednesday, February 12, 2014 10:59 AM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? So cheese and monkeys aside. After 25 years as a 3D animator I've never worked in games. So from a serious perspective I simply don't understand. It's not clear to me why you aren't able to use ICE or scripts and freeze those construction connections sending only the raw assets over without ICE or scripting. What is it about this pipeline which makes that difficult? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, February 12, 2014 1:35 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic or engineering resources. If it could, there wouldn't be a challenge ;-) Cannot use ICE, but you can use expressions, constraints, or animation mixer to set up and plot out to explicit controls later if you prefer. A junior or staff level artist must be able to setup and complete the task unsupervised in 30 minutes or less. Must also avoid creating any bugs such as leaving temporary data in the scene or methods that require such tactics. Bugs that make their way
Re: Survey - how would you do this?
Yup, if you were one of the NASA engineers back in Houston during the Apollo 13 mission, the astronauts would have all died. :p ICE not stable and mature? You're kidding, right? Some things are worth figuring out how to fit a round hose over a square filter. ICE is one of those things. Sent from my iPhone On Feb 12, 2014, at 5:01 PM, Matt Lind ml...@carbinestudios.com wrote: Part of it is circumstance, as in we only have so many resources. For example, our art department is 100+, but I'm the only one in the department who writes code and I'm currently tasked with significantly higher priority issues helping out an under staffed engineering department than writing one-offs for every artist who needs a button. The other part is pipeline management of a large scale software development effort. We have a feature film sized team working to build a high profile AAA title. With an engine and tools under constant evolution, and life expectancy of 15+ years, you must choose methods of content creation which can withstand changes to the software, such as Softimage, as well as changes to the game itself. An asset created today must expect to live for 10+ years without any further maintenance. If given the choice between creating an asteroid belt using constraints vs. ICE, we'll probably opt for constraints because we know it's a fairly stable and mature system, which cannot be said for ICE. We've been bitten many times already such as when we created a number of simulations back in XSI 5 using the Softimage particle system only for the particle system to be ripped out and replaced with ICE. We can no longer open those assets in Softimage. Same happened again with updates to the realtime shader APIs. So now we must either live with their current state of dysfunction, or rebuild from scratch. On projects of this magnitude, risk assessment has a very high priority and taken extremely seriously because one bad move can literally sink the project if the ripple effect is large enough. While we do take measures to abstract data from commercial tools, we only have so much programming power in house to do so. The point is we cannot subscribe to workflows which are prone to human error. Creating temporary data and expecting the artist to clean up after himself has proven to not be reliable as assets are referenced by other assets all the time. If crap is left around, then anybody referencing that asset also inherits the crap which results in bugs in game. In film/video you can sweep things under the carpet if they aren't perfect as long as the problem doesn't show up on camera. We don't have that luxury. What you make has to be functional and optimal for a live game environment, conservative on resources, and not make any assumptions how it will be used. Function has higher priority than looking pretty. There's a lot more to it, but I think you get the gist of it. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Wednesday, February 12, 2014 10:59 AM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? So cheese and monkeys aside. After 25 years as a 3D animator I've never worked in games. So from a serious perspective I simply don't understand. It's not clear to me why you aren't able to use ICE or scripts and freeze those construction connections sending only the raw assets over without ICE or scripting. What is it about this pipeline which makes that difficult? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Wednesday, February 12, 2014 1:35 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? We'd have to add support for ICE in our exporter and pipeline management tools. We don't have resources to do that at present. If the artist doesn't clean up after himself responsibly, it creates a lot of problems. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau Sent: Wednesday, February 12, 2014 7:21 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? On Tue, Feb 11, 2014 at 10:30 PM, Matt Lind ml...@carbinestudios.com wrote: The solution is 100% art driven in this case and cannot rely on game engine logic
Re: Survey - how would you do this?
With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
Re: Survey - how would you do this?
use Fabric. but I guess that's considered custom. :-) On 2/11/2014 8:46 PM, Eric Thivierge wrote: With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
You wouldn't last long in games with that attitude. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:46 AM To: softimage@listproc.autodesk.com Cc: Matt Lind Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
Wouldn't restricting use of ICE mean you have no access to the out of the box particle tools? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Tuesday, February 11, 2014 2:46 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
Re: Survey - how would you do this?
Considering that the typical distance from one asteroid to the next is many thousands of kilometers, you really shouldn't have any issues with collisions if you scale them properly. At your scale of 40 SI units for the asteroid belt, each asteroid would be well sub-pixel in diameter anyway, so I would create a torus to represent the belt, make it only very slightly opaque and call it a day. Sent from my iPhone On Feb 11, 2014, at 1:23 PM, Matt Lind ml...@carbinestudios.com wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
F*ck. Fat finger. The rest: We have tight restrictions for making MMORPG style games. One of them being we have to think simple as there's no way to fully predict how an asset will be used once it's made available in the game. Designers and scripters will pull whatever they can get their hands on and use them for whatever purpose they can think of. Kind of the everything looks like a nail when you have a hammer problem. Matt -Original Message- From: Matt Lind Sent: Tuesday, February 11, 2014 11:47 AM To: 'Eric Thivierge'; softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? You wouldn't last long in games with that attitude. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:46 AM To: softimage@listproc.autodesk.com Cc: Matt Lind Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
Re: Survey - how would you do this?
Are all games made in an environment from what seems to be the early 90's? And true I probably wouldn't last long in games. I like using new technology too much. :) Eric T. On 2/11/2014 2:47 PM, Matt Lind wrote: You wouldn't last long in games with that attitude. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:46 AM To: softimage@listproc.autodesk.com Cc: Matt Lind Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
Re: Survey - how would you do this?
re: collision avoidance -- how big are the asteroids WRT the toroidal volume? the requirement for varying linear (meaning orbital I guess?) speeds needs to be balanced against the volume of space that each sweeps through. the position jitter I guess I would try to do via clever parenting and use of the randomize data entry command for transform values. On Tue, Feb 11, 2014 at 2:46 PM, Eric Thivierge ethivie...@hybride.comwrote: With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.GO! Matt
RE: Survey - how would you do this?
Softimage doesn't have a particle system anymore. ICE replaced it. To answer your question - yes. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Tuesday, February 11, 2014 11:48 AM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? Wouldn't restricting use of ICE mean you have no access to the out of the box particle tools? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Tuesday, February 11, 2014 2:46 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
No ICE huh.. I know! I know! Go to the grocery store. Buy a pack of lunch meat, the smelliest cheese you can find, and some monkey bread. Return to work and make your lunch from the ingredients. Whilst everyone is running away from the smell of the cheese, cheat and use ICE. I know, I broke the spirit of the challenge. Guilty as charged. But I bet Ed liked the solution. :) -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind Sent: Tuesday, February 11, 2014 2:54 PM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? Softimage doesn't have a particle system anymore. ICE replaced it. To answer your question - yes. Matt -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Ponthieux, Joseph G. (LARC-E1A)[LITES] Sent: Tuesday, February 11, 2014 11:48 AM To: softimage@listproc.autodesk.com Subject: RE: Survey - how would you do this? Wouldn't restricting use of ICE mean you have no access to the out of the box particle tools? -- Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center __ Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party. -Original Message- From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Eric Thivierge Sent: Tuesday, February 11, 2014 2:46 PM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
The focus in games is to make software that is entertaining for our customers. Much of the problem solving in 3D is on the engine side. On the content creation side, such as in Softimage, the focus is to integrate or mimic the engine or find ways of efficiently getting data to/from the engine. The critical part is to abstract game specific data so it is not tied to the content creation software, and inversely abstract the content creation software's isms from making it into the game engine. Do this while still providing an environment that artists can work quickly and efficiently. Not as easy as it sounds. The problem that is most encountered in Softimage and other 3D apps is you can't go low level enough to do what you need. Softimage doesn't really support custom classes and data structures as first class citizens in their API. Therefore, most implementations of toolsets are working around those limitations which often requires venturing into the dusty corners of the software where few people travel resulting in discovery of many bugs preventing you from reaching your goals. As for making games, it taxes your brain a lot more than film/video to figure out how to pull off an effect or implement an idea. Basically, your MacGyver skills are really put to the test. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:50 AM To: Matt Lind; softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Are all games made in an environment from what seems to be the early 90's? And true I probably wouldn't last long in games. I like using new technology too much. :) Eric T. On 2/11/2014 2:47 PM, Matt Lind wrote: You wouldn't last long in games with that attitude. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:46 AM To: softimage@listproc.autodesk.com Cc: Matt Lind Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
RE: Survey - how would you do this?
I should probably mention we don’t do realism here. Think comic book style with a little Anime thrown in. Given the dimensions of the belt, asteroids could be up to 1 SI unit in diameter for the really large rocks. The camera might move through this belt, so the fact they’re small shouldn’t be so readily dismissed. This isn’t film/video where you can sweep the stuff you don’t see under the carpet. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Bradley Gabe Sent: Tuesday, February 11, 2014 11:48 AM To: softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Considering that the typical distance from one asteroid to the next is many thousands of kilometers, you really shouldn't have any issues with collisions if you scale them properly. At your scale of 40 SI units for the asteroid belt, each asteroid would be well sub-pixel in diameter anyway, so I would create a torus to represent the belt, make it only very slightly opaque and call it a day. Sent from my iPhone On Feb 11, 2014, at 1:23 PM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was ‘good enough’. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow – like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes – and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet’s size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready…..GO! Matt
Re: Survey - how would you do this?
I have to plus one on the hand animation...do a couple meteors on a circle scale each one a litte differently. Duplicate that a number of time and offset that. Then look for nasty collisions...done. On Tue, Feb 11, 2014 at 3:01 PM, Matt Lind ml...@carbinestudios.com wrote: The focus in games is to make software that is entertaining for our customers. Much of the problem solving in 3D is on the engine side. On the content creation side, such as in Softimage, the focus is to integrate or mimic the engine or find ways of efficiently getting data to/from the engine. The critical part is to abstract game specific data so it is not tied to the content creation software, and inversely abstract the content creation software's isms from making it into the game engine. Do this while still providing an environment that artists can work quickly and efficiently. Not as easy as it sounds. The problem that is most encountered in Softimage and other 3D apps is you can't go low level enough to do what you need. Softimage doesn't really support custom classes and data structures as first class citizens in their API. Therefore, most implementations of toolsets are working around those limitations which often requires venturing into the dusty corners of the software where few people travel resulting in discovery of many bugs preventing you from reaching your goals. As for making games, it taxes your brain a lot more than film/video to figure out how to pull off an effect or implement an idea. Basically, your MacGyver skills are really put to the test. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:50 AM To: Matt Lind; softimage@listproc.autodesk.com Subject: Re: Survey - how would you do this? Are all games made in an environment from what seems to be the early 90's? And true I probably wouldn't last long in games. I like using new technology too much. :) Eric T. On 2/11/2014 2:47 PM, Matt Lind wrote: You wouldn't last long in games with that attitude. Matt -Original Message- From: Eric Thivierge [mailto:ethivie...@hybride.com] Sent: Tuesday, February 11, 2014 11:46 AM To: softimage@listproc.autodesk.com Cc: Matt Lind Subject: Re: Survey - how would you do this? With those restrictions, get a super fast animator to animate them by hand. Eric T. On Tuesday, February 11, 2014 2:23:31 PM, Matt Lind wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: -Cannot use ICE -Cannot use custom scripts, custom operators, or shaders. -Must only use tools out of the box that a junior or staff level artist would know how to use. -Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. -Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. -Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. -Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.GO! Matt
Re: Survey - how would you do this?
Well, a quick solution will be 1. create a group of asteroids and add the animation of the asteroids. 2. create the torus that will hold up the asteroids belt. 3. Instanciate the group of asteroids. 4. Create a object to cluster constrain of the asteroids group in dispersed points in the torus. 5. Randomize the torus to create the jittering of the position of the asteroids group. 6. Animate the rotation of the torus. 2014-02-11 14:06 GMT-06:00 Matt Lind ml...@carbinestudios.com: I should probably mention we don't do realism here. Think comic book style with a little Anime thrown in. Given the dimensions of the belt, asteroids could be up to 1 SI unit in diameter for the really large rocks. The camera might move through this belt, so the fact they're small shouldn't be so readily dismissed. This isn't film/video where you can sweep the stuff you don't see under the carpet. Matt *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Bradley Gabe *Sent:* Tuesday, February 11, 2014 11:48 AM *To:* softimage@listproc.autodesk.com *Subject:* Re: Survey - how would you do this? Considering that the typical distance from one asteroid to the next is many thousands of kilometers, you really shouldn't have any issues with collisions if you scale them properly. At your scale of 40 SI units for the asteroid belt, each asteroid would be well sub-pixel in diameter anyway, so I would create a torus to represent the belt, make it only very slightly opaque and call it a day. Sent from my iPhone On Feb 11, 2014, at 1:23 PM, Matt Lind ml...@carbinestudios.com wrote: An artist came to my desk yesterday asking how to do what I felt was a simple task, but after getting 80% through it I ran into a speed bump realizing it needed custom scripting or other advanced tools to fully resolve to satisfaction. I had to give him a procedure that was 'good enough'. This problem has multiple solutions, but I am curious how others would solve it: The problem: Artist must create an asteroid belt around a planet. The asteroids are likely 2D sprites which must face the camera and tumble as they orbit, but could be 3D objects as well. Asteroids must vary in size, shape, and animation speed (linear as well as rotational). Asteroids cannot collide with anything. Movement is generally slow - like a screen saver for your computer desktop. Asteroid positions are jittered within the belt. The question: Dispersing objects into a ring is fairly straightforward through a number of techniques, but how do you apply the random jitter to the object positions? The rules: - Cannot use ICE - Cannot use custom scripts, custom operators, or shaders. - Must only use tools out of the box that a junior or staff level artist would know how to use. - Must be able to create the asteroid belt, from scratch to completion, in less than 30 minutes - and be iteration friendly to react to art director feedback. - Ideally, the belt could be made a child of the planet in encompasses so it can be reoriented with respect to changes in the planet's size/shape/tilt/orbit. - Final output must be able to exist with full integrity on its own in a vacuum. Cannot not have dependencies on custom code, external assets, or special case logic. - Asteroid belt fits within the default grid as seen in the scene camera. Think torus with diameter 40 SI units, and cross section of roughly 3 SI Units diameter Ready.GO! Matt
Re: Survey - how would you do this?
Do it by hand. Create null in center of Planet. Call it Parent_Mom. Create Volume Previz Torus Helper. Create Asteroid in Origin. Create Null. Name Null Asteroid_P001. Parent Asteroid to Asteroid_P001. Animate Asteroid Rotation (its tumbling) in Origin. Snap Asteroid_P001 to Torus. Parent Asteroid_P001 to Parent_Mom. Duplicate Asteroid_P001, resulting in Asteroid_P002. Snap Asteroid_P002 to Torus. Create Null, call it Parent_Spin. Parent Parent_Mom to Parent_Spin. Animate Rotation (Y) of Parent_Spin. Create Null, name it Parent_Dad. Name Planet Forever21Planet, parent Forever21 and Parent_Spin to Parent_Dad. Duplicate Asteroid_P002 as often as you need and snap to Torus. Duplicate Parent_Spin, rename Parent_Spin_faster. Adjust Animation to spin faster. Delete any Asteroids you don´t like, offset animations where neccessary or desired. Rinse, repeat. Play. On 11.02.2014 20:23, Matt Lind wrote: The question: but how do you apply the random jitter to the object positions?
