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
                 www.keyvis.at
--   This email and its attachments are    --
-- confidential and for the recipient only --

Reply via email to