Ok, will get in touch when i get back then. Off to do some revaluation of things... and stuff.
On Fri, Aug 2, 2013 at 1:19 PM, Helge Mathee <helge.mat...@gmx.net> wrote: > aside from your personal fondness you may of course evaluate splice at a > later time as well. > > > On 02.08.2013 13:15, Ognjen Vukovic wrote: > > :D The coffee still hasn't kicked in, and i doubt it would be that fun of > a vacation if it did happen, probably spend the whole time discussing wave > rigs and so on... > > > On Fri, Aug 2, 2013 at 1:12 PM, Stefan Kubicek <s...@tidbit-images.com>wrote: > >> Is he/she that bad looking? >> >> Just to make this clear, we are not on vacation together :D. >>> >>> >>> On Fri, Aug 2, 2013 at 1:09 PM, Ognjen Vukovic <ognj...@gmail.com> >>> wrote: >>> >>> 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. >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> -- >> --------------------------------------------- >> Stefan Kubicek ste...@keyvis.at >> --------------------------------------------- >> keyvis digital imagery >> Alfred Feierfeilstraße 3 >> A-2380 Perchtoldsdorf bei Wien >> Phone: +43 (0) 699 12614231 <%2B43%20%280%29%20699%2012614231> >> www.keyvis.at >> -- This email and its attachments are -- >> -- confidential and for the recipient only -- >> >> > >
