: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]
<mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[email protected]>> <[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
> >>>>
> >>>
> >>>
> >>
> >
>
[image: 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
[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] <mailto:[email protected]>
---------------------------------------------
keyvis digital imagery
Alfred Feierfeilstraße 3
A-2380 Perchtoldsdorf bei Wien
Phone: +43 (0) 699 12614231
<tel:%2B43%20%280%29%20699%2012614231>
www.keyvis.at <http://www.keyvis.at>
-- This email and its attachments are --
-- confidential and for the recipient only --
