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 | nhbton 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
dolbynhb 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.
