: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 <[email protected]> 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 <[email protected]> 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 <[email protected] >>> >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 <[email protected]> <[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<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/<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 [email protected] > ------------------------------**--------------- > keyvis digital imagery > Alfred Feierfeilstraße 3 > A-2380 Perchtoldsdorf bei Wien > Phone: +43 (0) 699 12614231 > www.keyvis.at > -- This email and its attachments are -- > -- confidential and for the recipient only -- > >
