thanx Helge, hope to jump the wagon soonish ;) phi
> Helge Mathee <[email protected]> hat am 2. August 2013 um 12:51 > geschrieben: > > Hey Philip, > > the internal mesh representation is current WIP and will change dramatically > with the next > release. We have been experimenting with winged-edge as well as half-edge. > For data compression > we will hopefully end up with a structure which doesn't hold any neighboring > information until > requested. > > Once you get access to splice you can have a look at the full source of the > SpliceMesh.kl > > -H > > On 02.08.2013 11:53, philipp.oeser wrote: > > > > 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 <[email protected]> <mailto:[email protected]> 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. > > > > > [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.
