Sebastien, Exactly right, which was the idea of this thread. Will we actually ever get to where we are today with ICE, with the approach AD are taking with Bifrost? Nothing they can tell us in an open forum like this will actually answer that question. So read into that what you will.
On 24 March 2014 05:37, Sebastien Sterling <sebastien.sterl...@gmail.com>wrote: > If they are already talking about it being a stand alone engine that can > plug into Maya AND Max, how exactly would it be able to deal with: > > > - building custom deformers (thereby reading and driving polygon mesh > point positions) > - manipulating shape data (--> reading and driving the per-point shape > vectors per polygon mesh point position) > - manipulating UV's > - manipulating kinematic transforms > > Would there be two context libraries ? one for Maya and one for Max ? > cause that sounds like an awful amount of work, not that there are any > plans to port to max i would not think. > > Plus you often hear that phrase, Maya is aware of bitfrost but bitfrost is > unaware of Maya, it doesn't know where the data it crunches is going. > > At any rate for now its a FLIP solver, next year will it be a FLIP solver > with a Node based interface ? and a year and X$ subscription dollars after > that? what will it be ? > > It is going to take at least 3 years for it to be something other then > what we can expect. > > > > On 23 March 2014 17:21, Aleksa Orlov <aleksaor...@gmail.com> wrote: > >> Or, to put it more bluntly, we already waited and invested those 5 years. >> It is now expected to do it all over again. *Cui bono*? >> >> >> On Sun, Mar 23, 2014 at 5:22 PM, Jordi Bares <jordiba...@gmail.com>wrote: >> >>> Adrian, we are talking years (5?) of development here to get a full >>> solid stable platform... don't you think it is quite a lot to ask to someone >>> that already has almost all of that? >>> >>> Jordi Bares >>> jordiba...@gmail.com >>> >>> On 21 Mar 2014, at 17:41, Adrian Graham <adrian.gra...@autodesk.com> >>> wrote: >>> >>> > Look, I can't comment exactly on where we're going with Bifrost, this >>> is where I run into all sorts of SEC limitations and stuff. I could defer >>> to ChrisV to answer those questions in a more official manner. >>> > >>> > Rest assured we're aware that ICE is more than just FX, more than >>> particles and simulation, that it's a complete procedural workflow >>> involving all kinds of data, throughout the package. >>> > >>> > Adrian >>> > >>> > From: softimage-boun...@listproc.autodesk.com [mailto: >>> softimage-boun...@listproc.autodesk.com] On Behalf Of Sebastian Kowalski >>> > Sent: Friday, March 21, 2014 10:38 AM >>> > To: softimage@listproc.autodesk.com >>> > Subject: Re: ICE - When will we have todays functionality in Maya? >>> > >>> > thats is my concern too. as much as I embrace a decoupling from maya, >>> its how ICE is capable to talk to different scene elements that makes it so >>> powerful. >>> > managing data until the very least work process at render time. and >>> we are in full control. >>> > as beautiful big ass fluid sims look, its not what we day for day. >>> > please have a look on the 'what uses is ICE?' thread ( >>> https://groups.google.com/forum/#!topic/xsi_list/7aGyes8lBQE) >>> > >>> > thanks >>> > >>> > Am 21.03.2014 um 18:29 schrieb Alastair Hearsum < >>> hear...@glassworks.co.uk<mailto:hear...@glassworks.co.uk>>: >>> > >>> > >>> > Hi Adrian >>> > >>> > I'm no egg head so forgive the simplicity of my question. Would this >>> platform agnostic scenario actively prevent any of the procedures and >>> scenarios that we currently use ICE for? Is ICE so functional because its >>> embedded in Softimage? Can we have the same functionality with a non >>> embedded engine? >>> > >>> > Alastair >>> > Alastair Hearsum >>> > Head of 3d >>> > [GLASSWORKS] >>> > 33/34 Great Pulteney Street >>> > London >>> > W1F 9NP >>> > +44 (0)20 7434 1182 >>> > glassworks.co.uk<http://www.glassworks.co.uk/> >>> > Glassworks Terms and Conditions of Sale can be found at >>> glassworks.co.uk<http://glassworks.co.uk/> >>> > (Company registered in England with number 04759979. Registered office >>> 25 Harley Street, London, W1G 9BR. VAT registration number: 867290000) >>> > Please consider the environment before you print this email. >>> > DISCLAIMER: This e-mail and attachments are strictly privileged, >>> private and confidential and are intended solely for the stated >>> recipient(s). Any views or opinions presented are solely those of the >>> author and do not necessarily represent those of the Company. If you are >>> not the intended recipient, be advised that you have received this e-mail >>> in error and that any use, dissemination, forwarding, printing, or copying >>> of this e-mail is strictly prohibited. If this transmission is received in >>> error please kindly return it to the sender and delete this message from >>> your system. >>> > On 21/03/2014 16:53, Adrian Graham wrote: >>> > >>> > Ah, but may I respectfully point out that this was one of the problems >>> with ICE, in that its complete and total integration into Softimage makes >>> it difficult to engineer and manage, from a software and, unfortunately, a >>> marketing point of view. >>> > >>> > >>> > >>> > Most modern software libraries are platform-agnostic, and this is what >>> we're aiming for with Bifrost. The problem with ICE is that you had to use >>> Softimage in order to gain access to it. Nothing against Softimage, just >>> that you're limiting ICE's exposure to the industry at large. >>> > >>> > >>> > >>> > Would a renderer be more or less popular if it only worked with Maya, >>> and not with Max or Houdini? No, it should be available on all >>> applications, on all OSs if you want it to be successful. >>> > >>> > >>> > >>> > Adrian >>> > >>> > >>> > >>> > <winmail.dat> >>> >>> >>> >> > -- Chris Marshall Mint Motion Limited 029 20 37 27 57 07730 533 115 www.mintmotion.co.uk
