Hi Helge, Looking forward to this :) (I actually felt more at home with SCOPs than ICE anyways - old scripting fart)
regarding FE's internal mesh representation: is there any info on how this is structured? (half-edge, winged-edge, radial-edge, something else?) [e.g. was looking at FE's documentation but couldnt find anything regarding neighborhood (aka SI's Neighbor*() methods)] thanx phi > Helge Mathee <helge.mat...@gmx.net> hat am 2. August 2013 um 11:15 > geschrieben: > > > Hey Eugen, > > anything you can write to within the SDK will eventually be supported at > some point. > The integration I am aiming at for the initial release will have the > same feature set as the > maya one. This includes: > > - boolean > - scalar > - int > - string > - vec3 > - quaternion > - matrices (kinematics) > - meshes > > Since we will be providing the integration as source code as well, > you'll be able to implement missing types in case you require them > prior to the corresponding service releases. > > -H > > On 02.08.2013 11:03, Eugen Sares wrote: > > Helge, or Paul, two questions: > > 1 - is it possible with Splice to write to NURBS as well? Curves, > > foremost. Surfaces would be interesting for experiments, too. > > 2 - what about the writing to clusters? > > > > I assume Splice can only "move" inside the limits of the SDK. > > Basically, the classic SDK supports NURBS, but not changing clusters. > > > > I'm considering porting my curve and extrusion operators to splice, > > since they are unfinished yet anyway (JScript). > > Thanks! > > Eugen > > > > > > Am 02.08.2013 10:51, schrieb Helge Mathee: > >> The real issue here is performance. ICE by itself is fast, our core > >> is fast by itself as well. Now to integrate our core into ICE is kind > >> of difficult, essentially due to competition of greedy schedulers. We > >> can of course do that by adding a single threaded node inside of ICE, > >> but that kind of defeats the purpose. The lack of flexibility for > >> procedurally created ports within an ICE node also makes it very hard > >> to integrate there. > >> > >> Of course you can build ICE nodes for specific purposes. For Horde > >> for example we've integrated in there, but the data streamed is > >> trivial (1000 matrices etc). Once you get into millions of particles > >> the performance will drop. > >> > >> I don't think it's required at all to integrate the Splice system > >> into the ICE graph, since at that point portability won't work anyway. > >> > >> -H > >> > >> On 02.08.2013 10:39, Stefan Kubicek wrote: > >>> Hi Paul, > >>> > >>> one question: Since SPLICE for Softimage will use classic operators > >>> rather than ICE, I was wondering what the current status is > >>> regarding FE interaction with ICE. I remember some of your/Helges > >>> videos where you showed deformations and other things controlled > >>> through ICE by talking to a CP App through (what looked like > >>> generic) ICE nodes. Is this still a viable solution? I never found > >>> any documentation or sample scenes on this (at least not in the > >>> downloadable packages, I admit I did not scour the Github repo), but > >>> found it really exciting. My hope is that even if SPLICE will not be > >>> integrated with ICE I could still use the detour via a CP > >>> Application (if I understand the concept correctly). > >>> > >>> > >>>> Hi everyone - now we're back from Siggraph and recovered, we've > >>>> started > >>>> working on Spliced Softimage. Should have a first prototype next week. > >>>> > >>>> https://twitter.com/FabricPaul/status/362975245562437632/photo/1 > >>>> > >>>> The Hybride guys have been doing some awesome stuff with FE > >>>> already, so I > >>>> can't wait to get this into their hands soon :) Eric might stop > >>>> stalking > >>>> the Montreal employees as well, which would be nice. > >>>> > >>>> A description of Spliced Softimage: > >>>> Creation:Splice will be integrated into Softimage as a new class of > >>>> custom > >>>> operators. Each operator can be setup using the SpliceEditor IDE, > >>>> defining > >>>> ports, adding removing them etc, very much like the Scripted Operator > >>>> Editor. The IDE will also contain a KL Source Code editor as well as > >>>> functionality for dynamically compiling the code etc. Operators > >>>> defined > >>>> with the SpliceEditor will become completely portable between all > >>>> support > >>>> host applications, such as Maya, Softimage and Nuke, for example. > >>>> > >>>> We are not integrating KL into ICE, for a range of reasons. Splice is > >>>> targeting areas where ICE doesn't work so well, i.e. Fast procedural > >>>> geometry, kinematics, simulated rigs, custom OpenGL drawing etc Splice > >>>> solves the portability issues of moving tools between applications, > >>>> and as > >>>> such we try to take a consistent approach within applications. > >>>> > >>>> This also means I don't get to make up such compelling slogans as > >>>> "Spliced > >>>> ICE baby", which is frankly disappointing. > >>>> > >>>> If you want to understand more about Splice, please visit the webpage: > >>>> http://fabricengine.com/creation/splice/ > >>>> > >>>> Cheers, > >>>> > >>>> Paul > >>>> > >>> > >>> > >> > > > [nhb] Philipp Oeser Pipeline Engineer T +49 40 - 450 120 - 401 www.nhb.de <http://www.nhb.de> nhb video GmbH | nhb ton GmbH Alsterglacis 8 | 20354 Hamburg nhb video GmbH, HRB 61617 Geschäftsführer: Michael Vitzthum, Matthias Rewig nhb ton GmbH, HRB 73877 Geschäftsführer: Michael Vitzthum, Matthias Rewig [dolby]nhb is Dolby approved Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Das unerlaubte Weiterleiten dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. Any unauthorised disclosure of the material in this e-mail is forbidden.
