Hi guys, Our TD and i are returning from vacation in about two weeks, is there any chance we could give this a test shot some time then?
Ogi. On Fri, Aug 2, 2013 at 12:51 PM, Helge Mathee <helge.mat...@gmx.net> wrote: > 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 <helge.mat...@gmx.net> <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 > > >>>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [image: nhb] Philipp Oeser Pipeline Engineer T +49 40 - 450 > 120 - 401 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 [image: 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. > > >
