ICETree executes twice if components selected, does not reset data

[Mathias N]

If an ICE tree executes while any components of the mesh are selected, the
entire stack will execute twice. (SI2013)

When this happens, none of the data from the first pass is reset.

This generally isn't much of a problem, unless parts of your tree only
initializes a value after checking that it has not already been set.

First pass:  Value not initialized. Setting to 0.
 Adding 1. Output: 1.

Second pass: Value initialized. Leaving at 1.
 Adding 1. Output: 2.

Gif of behavior: https://gfycat.com/HauntingDecisiveKoalabear


It would be nice to know if this issues exists in later versions of
XSI, but I don't have very high hopes.


I am adding ICETrees as operators, with each individually having to
check whether to use the

value set by the previous operator (if it exists), or load the base
value from an external source.

The only workaround I can think of is to leave an ICEtree at the top
(bottom?) of the stack dedicated to loading the base data,

rather than relying on the operators to check themselves. It wouldn't
be a very pretty solution, and someone is bound to

delete it by mistake and break everything.

Penny for your thoughts?
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Aborting commands (C++)

[Mathias N]

I have been trying to use the OnEvent callback with siOnBeginCommand to
abort and replace ApplyTopoOp commands in SI2013

Building on the example in the SDK documentation

I am successfully intercepting events, but only some of them abort
correctly, returning

> ' INFO : 4373 - This event was aborted:
>
before executing the command anyway.

CreatePrim and ApplyTopoOp, for instance, behave this way. Other commands,
such as selection and navigation commands, abort successfully.

Code when attempting to abort ApplyTopoOp:

> XSIPLUGINCALLBACK CStatus HCoverrideCommand_OnEvent( CRef& in_context ){
>
> Application app;
> Context ctxt(in_context);
> Command currentCommand = ctxt.GetAttribute("Command");
> CString commandName = currentCommand.GetName();
>
> if (commandName=="Extrude Comp. Axis")
> {
> app.LogMessage("Extrude detected. Attempting to abort.");
>
> //Abort command.
> return CStatus::OK;
>
> }
>
> //Return false to NOT cancel the intercepted command
> return CStatus::False;}
>
> Output:

> ' INFO : Extrude detected. Attempting to abort.
> ' INFO : 4373 - This event was aborted:
> ' 
> '  C:\Users\Roughy\Autodesk\Softimage_2013\Addons\HairCommands\Application\Plugins\hairCommands.dll>
> '
> ApplyTopoOp "ExtrudeComponentAxis", "grid.poly[27,28,35,36]",
> siUnspecified, siPersistentOperation


 Are you only allowed to abort certain commands, or am I doing something
wrong here?

The docs also state that you can modify the arguments of the command.
I don't quite see how to do so, unless you're expected to abort the command
and call its replacement yourself.

Any help would be greatly appreciated.

Re: ICE Topo: Not able to disconnect 1 edge

[Mathias N]

Disconnecting a single edge works fine for me, unless you are trying to
disconnect
an edge that is surrounded by polygons on all sides.

Disconnecting an edge basically means splitting the vertex on either side
of the edge
into two and drawing 2 edges between the 3 vertices. Unless the vertex you
split is a
boundary point, splitting it in 2 will also end up separating neighboring
edges.

If it is impossible to split the edge without also separating neighboring
edges, then it will do
nothing unless you also pass the neighboring edges as arguments.

Please see the attached image.



On Wed, Sep 24, 2014 at 10:36 PM, Eric Thivierge 
wrote:

> Hey all,
>
> Anyone know why you can't just disconnect 1 edge with the Disconnect
> Component node?
>
> Thanks,
> Eric T.
>
>

Re: Softimage transition webinar is starting in 10 minutes

[Mathias N]

Aye, the stream just died here too.


On Mon, Mar 17, 2014 at 5:25 PM, Greg Punchatz  wrote:

>  just lost link
>
>  --
> *Greg Punchatz*
>  *Sr. Creative Director*
> Janimation
> 214.823.7760
> www.janimation.com
>  On 3/17/2014 11:23 AM, Ognjen Vukovic wrote:
>
> Just wow.
>
>
> On Mon, Mar 17, 2014 at 5:21 PM, Artur Woźniak wrote:
>
>> Now they playing some sales material.
>>
>>  Artur
>>
>>
>> 2014-03-17 17:18 GMT+01:00 Ognjen Vukovic :
>>
>>  Thanks autodesk, i just put my foot through a 500 $ dell monitor.
>>>
>>>
>>> On Mon, Mar 17, 2014 at 5:12 PM, Nicolas Esposito <3dv...@gmail.com>wrote:
>>>
 Smooth streaming here...they look a bit scared though
 SPOLIER: Softimage go open source will never happen


 2014-03-17 17:08 GMT+01:00 Rob Chapman :

  it stutters - have to keep clicking on it for playback. hopefully
> this will be recorded right?
>
>
> On 17 March 2014 16:05, Marc-Andre Carbonneau <
> marc-andre.carbonn...@ubisoft.com> wrote:
>
>>  It’s actually not working for me. L anyone got it to work?
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *
>> sku...@gmail.com
>> *Sent:* 17 mars 2014 11:59
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Softimage transition webinar is starting in 10 minutes
>>
>>
>>
>> Thank you for the link Marc.  I’m finally in the acceptance stage of
>> grief and am resigning myself to using Maya, learning Houdini and
>> continuing to use Softimage as is.  I hope they show of some of the
>> upcoming Maya “Humanization” plans (not just shove ICE into maya).  
>> Again,
>> best of luck to all Softimage users out there, but this just fucking
>> sucks…  And though this hurts me, best of luck to Autodesk as well too.
>>
>
>

>>>
>>
>
>

Re: Last release and ICE and addons

[Mathias N]

The greater problem is that in another 3 weeks you won't even be able to
purchase Softimage.

I can deal with losing support, but making Softimage abandonware that
cannot even be purchased is the equivalent of shooting it in the knee.


On Wed, Mar 5, 2014 at 6:59 PM, Eric Thivierge wrote:

> You are dead in the water if there is no one to fix a bug that a 3rd party
> dev needs fixed to make a certain feature... or implement a feature in
> order to do so as well...
>
>
> On Wednesday, March 05, 2014 12:54:59 PM, Stephen Davidson wrote:
>
>> I have a question.
>>
>> If the last release is Softimage 2015 (with ICE). Won't this
>> version just run as long as you have it installed? If so,
>> I would think this is a great opportunity for 3rd party developers to
>> improve Softimage with some great addons, or plugins, that
>> would keep it going as long as there is 3rd party development.
>>
>> I would point to the great addons, offered by Exocortex
>> , as a perfect example
>>
>> of integrating enormously extended functionality of Softimage.
>>
>> The recent prolific ICE compounds, such as StrandTree
>> > approach-to-tree.html> and
>> Mootzoid 
>>
>> are just two of many offerings out there. In fact, Mootzoid states on
>> their
>> main page
>>
>> "The Mootzoid plugin development for Softimage|XSI will not be
>> affected by this lame decision."
>>
>> Am I missing something?
>> Are we really dead in the water if AD shuts down development?
>> I think this deserves further exploration.
>>
>> comments?
>>
>> --
>>
>> Best Regards,
>> *  Stephen P. Davidson**
>> **(954) 552-7956
>> *sdavid...@3danimationmagic.com
>>
>> /Any sufficiently advanced technology is indistinguishable from magic/
>>
>>
>>- Arthur C. Clarke
>>
>> 
>>
>>
>

Re: Softimage transition audience poll

[Mathias N]

No option for sticking with Softimage till the end?


On Tue, Mar 4, 2014 at 5:37 PM, Alan Fregtman wrote:

> I've set up a poll out of curiosity...
>
> *Where will you transition to when Softimage falls?* Vote!
>
> http://strawpoll.me/1257710
>
> (Multiple-choice allowed btw.)
>
>

Re: Softimage Hair options?

[Mathias N]

m.
>
> For a hair system ?
>
> *) First off, it should be able to stand on it's own without ICE.
>
> *) it should probably work on its own engine (like yeti, i assume).
>
> *) If it has its own engine, it should be open so as to offer TD's and
> Dev's the freedom and space they need to solve problems and expand tools or
> implement new tools. (this point is more a given, TD's and Dev's should
> always be facilitated in this regard).
>
> *) It Should have its own unit, like a strand, guide or null, that exists
> for this purpose.
>
> *)It should be tablet compatible, as in stylus, pen pressure, all that
> jazz.
>
> *) It should be ICE compliant ; stand on it's own yes, but that should not
> subject isolated from ICE, it's too good a tool to be ignored. Ideally, a
> relationship where ICE is less of a crutch and more of a third arm. e.g The
> proprietary Guides/strands/units can be brought into ICE as data, so if you
> where making a wood nymph, and you wanted to make flowers bloom from the
> tips of her hair: all this managed through ICE. Listening to Paul Smith, in
> his demo of FUZZ, he says that strand collisions are very slow. So
> regarding hair, ICE would be more an aesthetics effects base tool then a
> physics engine, the actual simulation being taken care of by the hair
> systems dedicated engine. so yes as much compliance between the two systems
> as possible.
>
> *) UI integration. where would it live ? i'd love to see the sparsely
> inhabited paint tools panel, be sectioned into 3 tabs, similar to the right
> side, MCP/KP-L/PPG.
>
> Tab 1: the original xsi paint tools, weight painting etc...
>
> Tab 2:... maybe some sculpting tool implementations :P ? (for another time
> !).
>
> Tab 3: The new hair system panel, including as preliminary features:
>
>
> 1) A stylus pressure segment with curve profile.
>
> 2) A layer system like the "scene" one in the KP/L so you can have
> separate hair systems on different hide-able reference-able layers, with
> the addition of a slider enabling you to increase or decrees the number of
> hairs shown in the viewport per layer. (this would allow you to rapidly
> test incremental density simulations, on the fly without having to dive
> into an ice tree or bring up a ppg ).
>
> 3) I'm a big fan of the M tool in SI, i love the 3 small grey icons that
> appear at the bottom of the view port, (manipulate, magnet and weld) i just
> wish it was customisable with even more tools !
>
> In this spirit i would like to have a small library of icons on the hair
> system panel, icons for guide painting, and manipulation: paint/erase
> grow/cut, brush/frizz,orient ...etc. i would like it to be possible to
> click and drag these icons into a small tray on the viewport like the M
> tool small grey icons. so you can have your own customizable loadout.
>
> 4) Convert To: a series of utilities that allow you to convert elements,
> primitives or meshes, into hair guides; so you can choose to draw a curve
> and then click "convert to"  guides or strands, upon which you get prompted
> to choose an existing layer to add to, or to create a layer for this new
> hair element. if you choose a mesh like a rectangle, it would give you the
> options on how you would like the hairs to populate the inside of the mesh,
> by length? what density? etc...
>
> note: if you convert to a guide, them the elements will become guides, if
> you choose convert to strand then the elements will become hair in witch
> ever layer you put them, influenced by the closest guide on that layer.
>
>
> And that's it, these are some of the things i would like to see in a
> "heavier" hair system.
>
>
> I toyed with the notion of a node graph like yeti's but from what i could
> see of it so far, it is very linear, nowhere near as fun as ICE, so a cool
> idea, for visualisation but i'd have to see a little more matured version
> to be sold.
>
> i doubt anyone will ever implement any of this, this is just a lot of pipe
> dreaming, but that is my answer.
>
>
>
>
>
>
> On 14 February 2014 00:51, Mathias N  wrote:
>
>> Sticking with the idea of a complete solution within Softimage, what
>> would your definition of heavier be?
>>
>>
>> On Fri, Feb 14, 2014 at 12:23 AM, Sebastien Sterling <
>> sebastien.sterl...@gmail.com> wrote:
>>
>>> I saw that the first day it was up Eddie
>>>
>>> And as jawdroppingly cool as it is, i have a feeling we are going to
>>> need something a little heavier to go forward.
>>>
>>>
>>> On 14 February 2014 00:01, Ed Manning  wrote:
>&

Re: Softimage Hair options?

[Mathias N]

Sticking with the idea of a complete solution within Softimage, what would
your definition of heavier be?


On Fri, Feb 14, 2014 at 12:23 AM, Sebastien Sterling <
sebastien.sterl...@gmail.com> wrote:

> I saw that the first day it was up Eddie
>
> And as jawdroppingly cool as it is, i have a feeling we are going to need
> something a little heavier to go forward.
>
>
> On 14 February 2014 00:01, Ed Manning  wrote:
>
>> https://vimeo.com/80382153
>>
>>
>> On Thu, Feb 13, 2014 at 5:10 PM, Sebastien Sterling <
>> sebastien.sterl...@gmail.com> wrote:
>>
>>> A new hair system is kinda over due. :(
>>>
>>>
>>> On 12 February 2014 16:54, Luc Girard  wrote:
>>>
 Hi Tim,

 Thanks for the way you mentioned our projects :) .

 I would like to chime in and say that we, at Shed, are also looking at
 hair solutions actively. Our solution based on Kristinka does the job but
 it is very far from being an out of the box solution and it requires a lot
 of RnD to maintain as it not supported by AD. If a problem pops up, with
 substeps motion blur per example, we are left to our own devices. We
 usually prevail but we end up spending nearly 50% of the time on technical
 details vs real look dev.  I thought you should know :).

 >From what I've seen around, Yeti seems to be a good contender but I've
 yet to do a full production setup with it.

 Good luck in your search !

 Luc Girard // SHED
 VFX artist
 1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
 T 514 849-1555 F 514 849-5025 WWW.SHEDMTL.COM


 -Original Message-
 From: softimage-boun...@listproc.autodesk.com [mailto:
 softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Leydecker
 Sent: 8 février 2014 07:26
 To: softimage@listproc.autodesk.com
 Subject: Re: Softimage Hair options?

 Thanks for this in-depth answer!

 Personally, I´m starting to lean towards going for the trial of Yeti,
 one reason being that I think I remember Colin Doncaster´s name from
 another maya maling list and another because of the really nice sample
 image of a bear posted by Yolandi Meiring in a similar thread here:

 (Thread) https://groups.google.com/forum/#!topic/xsi_list/2erKqUcghpI

 (Image)
 https://groups.google.com/group/xsi_list/attach/994086131ca9460/bear_still.jpg?part=4&view=1


 Another really nice one is a proof of concept of bringing (3dsMax)
 hair-farm into Softimage from Lee-Perry Smith, with props to Dani Garcia
 and Steven Caron.
 That human hairdo and it´s renderings look incredibly awesome.

 http://ir-ltd.net/hair-farm-hair-into-softimage/

 For a Melena/Kristinka workflow using Anto Matkovic´s tools in those
 beautiful shed projects there´s a nice clip posted by/on Lester Banks


 http://lesterbanks.com/2013/05/workflow-tips-for-creating-and-grooming-hair-in-softimage/

 --

 I have only limited amounts of time I can spend on this and need to
 find something that has potential to be useable for testing Redshift´s hair
 shading approach when applicable but ideally integrates seamlessly into
 either Maya/Max/Softimage.

 The combination of Maya+Redshift is allready working very well and it
 seems it´ll be easier to successfully migrate from simple hair/fur testing
 to something actually looking good (using yeti). Also, yeti has a variety
 of licensing options I might find atractive at a later date if tempted to
 actually finish something beyond spare-time doodling.

 I´d prefer Softimage but if that stuff works better in Maya, it´ll be
 Maya.

 I suck with Max, even the fastest and most intuitive plugin can´t
 compensate that sad fact.

 Cheers,

 tim







 On 08.02.2014 12:57, Stefan Kubicek wrote:
 > Hi Tim,
 >
 > I've just been dealing with hair an a hamster and used the built-in
 hair&fur of Softimage /2014SP2).
 >
 > A few tips about working with built-in hair:
 >
 > Avoid too dense meshes. It creates a guide hair for every vertex,
 > hence dense meshes make you fiddle with lots and lots of guide hair
 strands manually, which can be counter-productive and -intuitive.
 >
 > If you want to edit hair parameters on a per vertex basis (via vertex
 > colors), you need to plan ahead where exactly you want your hair to
 be and where you want certain features (transparency, density, kink &
 frizz) to change and over which distance/area. This is especially important
 for areas like hand and feet, as well as nose & eye lids.
 > So, before you move the mesh into skinning/rigging, you better make
 sure your topology works not only for animation but also for the hair setup
 you have in mind.
 >
 > Don't rely on the built-in style transfer f

Re: Nesting custom properties

[Mathias N]

Aye, character key sets are a good way of organizing existing parameters,
but I am hoping to avoid having to do long-winded names like
attribute_1_gradient_marker_1_Red just because they all have to exist on
the same object.

Halim: Mind -> blown. I had no idea it was possible to manage scripts like
that ...

Luckily I don't intend to do much organizing beyond creating and deleting
the nested properties, and since this seems to be the go-to method for
doing so I guess I'll be sticking with my original plan.

Thanks!


On Wed, Feb 12, 2014 at 3:48 PM, Halim Negadi  wrote:

> Hi,
>
> I'm not sure that's what you really need to do but I've been using and
> manipulating hierachies of custom properties for a long time now.
> for this, I use an addon I first published nearly 10 years ago:
> http://hnegadi.myftp.org/resources.html
>
> The core is a quick and dirty vbscrip plugin but it still does what I need
> from so I never got the chance to do a complete refactor.
> Basically the AddProp xsi built in custom command allows you to create any
> custom property nested underneath the object ( including another custom
> property ) of your choice.
>
> Here is an quik and dirty example:
>
> AddProp("Custom_parameter_list", "Scene_Root", siDefaultPropagation, "cp0" );
> AddProp("TextProp", "Scene_Root", siDefaultPropagation, "text0" );
> SetValue("text0.Text", "there she goes again" );
> SIAddCustomParameter("cp0", "Param0", siDouble, 1 );
> SIAddCustomParameter("cp0", "Param1", siDouble, 2 );
> AddProp("Custom_parameter_list", "cp0", siDefaultPropagation, "cp1" );
> SIAddCustomParameter("cp0.cp1", "Param2", siBool, true );
> SIAddCustomParameter("cp0.cp1", "Param3", siBool, false );
> AddProp("Annotation", "Scene_Root", siDefaultPropagation );
> SetValue("preferences.scripting.language", "JScript" );
>
> If you install xporc plugins, you'll find menu items that allows you to
> replicate and move custom properties hierachies, which means duplicate and
> reparent in xsi classic objects terminology.
> Unfortunately, I wrote these ages ago and the commands are selection based
> and don't take input arguments.
>
> Since XSI doesn't support duplicating nested custom propertis, the
> workaround consists in replicating recursively the hierarchy you want to
> duplicate: Store and recreate the custom props and copy their params and
> values.
> I'm not sure any animation or expression source replication are supported
> though.
>
> Attached are the vbs functions I use in xproc to "replicate" hierarchies
> of custom properties ( I removed the vbs extention so google would allow me
> to send the attachement ).
>
> Hope this helps.
>
>
>
> On Wed, Feb 12, 2014 at 1:19 PM, David Barosin  wrote:
>
>> Character Key sets are hierarchical.  I think they only work with
>> existing parameters but it's a potential way to organize...
>>
>>
>> On Tue, Feb 11, 2014 at 11:37 PM, Mathias N  wrote:
>>
>>> Evening
>>>
>>> I will be managing an obscene number of parameters, a number that
>>> requires that I keep things somewhat structured rather than just dumping
>>> everything into a single custom property.
>>>
>>> Since we are apparently unable to create hierarchies of parameters (see
>>> https://groups.google.com/d/topic/xsi_list/OkUqJFjOqP0/discussion )
>>> my current plan is to use nested CustomProperties in the following
>>> manner:
>>>
>>> Gradient
>>>   Marker_1
>>> Red
>>> Green
>>> Blue
>>>   Marker_2
>>> Red
>>> Green
>>> ...
>>> Where gradient and marker_1/marker_2 are custom properties, and
>>> red/green/blue are parameters.
>>>
>>> I am primarily posting to ask whether there isn't a better way of doing
>>> this, but assuming the answer to that is no, I was wonder if it is possible
>>> to accomplish purely with C++.
>>>
>>> With scripting you would just use AddProp to create the CustomProperty,
>>> setting the parent property as the input.
>>> In C++ the only way to add a custom property is, as far as I can tell,
>>> by calling AddCustomProperty, but this method is not available to a
>>> CustomProperty as it is not derived from SceneItem.
>>>
>>> Calling the native AddProp to do the job wouldn't be much of a problem,
>>> but I do prefer to keep my code, ehem, *pure*. Also not a fan of
>>> spamming the console.
>>>
>>> Cheers
>>>
>>
>>
>

Nesting custom properties

[Mathias N]

Evening

I will be managing an obscene number of parameters, a number that requires
that I keep things somewhat structured rather than just dumping everything
into a single custom property.

Since we are apparently unable to create hierarchies of parameters (see
https://groups.google.com/d/topic/xsi_list/OkUqJFjOqP0/discussion )
my current plan is to use nested CustomProperties in the following manner:

Gradient
  Marker_1
Red
Green
Blue
  Marker_2
Red
Green
...
Where gradient and marker_1/marker_2 are custom properties, and
red/green/blue are parameters.

I am primarily posting to ask whether there isn't a better way of doing
this, but assuming the answer to that is no, I was wonder if it is possible
to accomplish purely with C++.

With scripting you would just use AddProp to create the CustomProperty,
setting the parent property as the input.
In C++ the only way to add a custom property is, as far as I can tell, by
calling AddCustomProperty, but this method is not available to a
CustomProperty as it is not derived from SceneItem.

Calling the native AddProp to do the job wouldn't be much of a problem, but
I do prefer to keep my code, ehem, *pure*. Also not a fan of spamming the
console.

Cheers

Re: Gradient in PPG

[Mathias N]

> isn't the SDK documentation awesome.

Impeccable (屮ﾟДﾟ)屮

So, int for type, 8 groups pf RGB(A?), position float ...

Both the ICE gradient and the fxtree gradient have 16 colors though, with
the former also having mid points in addition to the positions.

Do I have to set those? What about the number of markers?

Do I create an actual array of parameters and pass it, or just create a
bunch of parameters and pass the first as with .AddColor?

The number of possible combinations to try without XSI giving you any real
feedback boggles the mind.



On Wed, Jan 22, 2014 at 12:07 AM, Luc-Eric Rousseau wrote:

> you need to create an array of parameters with the right types and add
> the control on the first parameter. So it's just like the color
> widget.
> Check the Gradient operator in the fxtree.  Open its .spdl file to see
> how it works.
>
> it's something like, one integer for type, and 8 groups of rgb color
> and a float for their position. something like that.
>
> isn't the SDK documentation awesome.
>
> On Tue, Jan 21, 2014 at 5:13 PM, Mathias N  wrote:
> > Evening
> >
> > Would any of you happen to know how to add a gradient (siControlGradient)
> > item to a PPG layout?
> >
> > With any of the standard data types it is pretty straight forward:
> > parameter, label, UI type.
> > A color item is given its own method, where instead of pointing to a
> single
> > parameter you point to float parameter representing red and it handles
> the
> > rest.
> >
> > But how exactly does this function with gradients? By definition it
> cannot
> > be linked to only a single parameter, but there is no special method for
> it
> > like with color.
> >
> > The docs would suggest that it is possible, but provides no information
> as
> > to how. Blindly flinging arguments at it has gotten me nowhere.
> >
> http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_om/siPPGControlType.html
> >
> > Cheers
>

Gradient in PPG

[Mathias N]

Evening

Would any of you happen to know how to add a gradient (siControlGradient)
item to a PPG layout?

With any of the standard data types it is pretty straight forward:
parameter, label, UI type.
A color item is given its own method, where instead of pointing to a single
parameter you point to float parameter representing red and it handles the
rest.

But how exactly does this function with gradients? By definition it cannot
be linked to only a single parameter, but there is no special method for it
like with color.

The docs would suggest that it is possible, but provides no information as
to how. Blindly flinging arguments at it has gotten me nowhere.
http://download.autodesk.com/global/docs/softimage2014/en_us/sdkguide/si_om/siPPGControlType.html

Cheers

Re: oculus rift sdk

[Mathias N]

I have obtained the source and docs from a friend who owns one (but
unfortunately does not use XSI), so I am covered on that front. I had him
test a standalone app to confirm I was successfully querying orientation
data, but could not get him to test it inside XSI.

The actual Oculus SDK is amazingly simple to get running, so most of the
work is going to be on the XSI side. Shaders, input device support,
scripting access etc.

I probably won't be able to do most of that anytime soon though, as I am
hoping to put off buying an Oculus until the 1080p or consumer versions are
out.

Cheers


On Sun, Dec 29, 2013 at 7:50 PM, Francisco Criado wrote:

> Mathias! sorry for not responding! this time of the year can be a little
> bit complicated :). I will try it tonight and tell you how it goes. Can
> Oculus docs and code would help you of something? I´m using in unity and
> the code is available in C#.
> Thanks for all.
> F.
>
>
>
> 2013/12/29 Mathias N 
>
>> I am going to take the lack of anyone yelling profanities at me as a sign
>> that none of you oculus owners have tried it out yet.
>>
>> The initializing-every-frame issue has been taken care, so it should now
>> be working properly.
>> Same URL: http://www.mayulive.com/riftDevice.dll
>>
>> I suspect the rotation will be incorrect (not sure about the rotation
>> order), but it would be nice if any of you could let me know if it is
>> managing to update properly.
>>
>> Thanks!
>>
>>
>>
>>
>> On Sun, Dec 22, 2013 at 6:53 PM, Mathias N  wrote:
>>
>>> I suppose this should ideally be implemented as a custom device rather
>>> than an ICE node, but trying to get that mess working without having an
>>> Oculus to play with would likely prove to be a lesson in frustration.
>>>
>>> No idea if this works, but technically it should.
>>>
>>> http://www.mayulive.com/riftDevice.dll
>>>
>>> Place it in a simulated ice tree, plug the rotation into whatever and
>>> hit play to make it update constantly.
>>>
>>> It just occurred to me that userdata allocated in BeginEvaluate is
>>> recreated for every update, which means I am initializing the oculus every
>>> single frame instead of just grabbing the orientation. So ... enjoy your
>>> latency for now, if it even works.
>>>
>>>
>>> On Fri, Dec 20, 2013 at 7:25 PM, Francisco Criado >> > wrote:
>>>
>>>> Just wanted to add that i posted the same initiative on fe splice
>>>> group, and the idea has been very welcomed. Thought it would be great to
>>>> have this tool, not only in SI.
>>>>
>>>>
>>>> F.
>>>>
>>>> On Wednesday, December 18, 2013, Francisco Criado wrote:
>>>>
>>>>> Hi Andy,
>>>>>
>>>>> tried last night to send the sdk pdf to the mailing list,but it seems
>>>>> mail couldn´t make because of the attachment. My ftp is currently down, 
>>>>> but
>>>>> it would be great to share sdk documentation and the c# files in case
>>>>> someone wants to get a look inside. Maybe wetransfer, but it has a certain
>>>>> amount of time on line.
>>>>>
>>>>> F.
>>>>>
>>>>>
>>>>>
>>>>> 2013/12/18 Andy Moorer 
>>>>>
>>>>>> I'm also playing with the rift and recently a couple of guys at an
>>>>>> important Softimage using studio mentioned to me they were using the rift
>>>>>> and unity. So Softimage tools for the rift clearly has value, glad to see
>>>>>> this thread.
>>>>>>
>>>>>> Sent from my iPad
>>>>>>
>>>>>> On Dec 17, 2013, at 12:17 PM, francisco criado 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Mirko, nice to see at least two Softimage users with the rift, i´m
>>>>>> currently learning unity and c#, and already imported material from Soft 
>>>>>> in
>>>>>> Unity without any trouble. Just realized that having access to the 
>>>>>> complete
>>>>>> c++ and c# code in the sdk  is like having a Mercedes and don´t know how 
>>>>>> to
>>>>>> turn it on :S
>>>>>> If i get into something useful i wil let you know. By now the only
>>>>>> autodesk dcc app having access to the rift is Maya, which plugin is being
>>>>>> sold for more tha

Re: oculus rift sdk

[Mathias N]

I am going to take the lack of anyone yelling profanities at me as a sign
that none of you oculus owners have tried it out yet.

The initializing-every-frame issue has been taken care, so it should now be
working properly.
Same URL: http://www.mayulive.com/riftDevice.dll

I suspect the rotation will be incorrect (not sure about the rotation
order), but it would be nice if any of you could let me know if it is
managing to update properly.

Thanks!




On Sun, Dec 22, 2013 at 6:53 PM, Mathias N  wrote:

> I suppose this should ideally be implemented as a custom device rather
> than an ICE node, but trying to get that mess working without having an
> Oculus to play with would likely prove to be a lesson in frustration.
>
> No idea if this works, but technically it should.
>
> http://www.mayulive.com/riftDevice.dll
>
> Place it in a simulated ice tree, plug the rotation into whatever and hit
> play to make it update constantly.
>
> It just occurred to me that userdata allocated in BeginEvaluate is
> recreated for every update, which means I am initializing the oculus every
> single frame instead of just grabbing the orientation. So ... enjoy your
> latency for now, if it even works.
>
>
> On Fri, Dec 20, 2013 at 7:25 PM, Francisco Criado 
> wrote:
>
>> Just wanted to add that i posted the same initiative on fe splice group,
>> and the idea has been very welcomed. Thought it would be great to have this
>> tool, not only in SI.
>>
>>
>> F.
>>
>> On Wednesday, December 18, 2013, Francisco Criado wrote:
>>
>>> Hi Andy,
>>>
>>> tried last night to send the sdk pdf to the mailing list,but it seems
>>> mail couldn´t make because of the attachment. My ftp is currently down, but
>>> it would be great to share sdk documentation and the c# files in case
>>> someone wants to get a look inside. Maybe wetransfer, but it has a certain
>>> amount of time on line.
>>>
>>> F.
>>>
>>>
>>>
>>> 2013/12/18 Andy Moorer 
>>>
>>>> I'm also playing with the rift and recently a couple of guys at an
>>>> important Softimage using studio mentioned to me they were using the rift
>>>> and unity. So Softimage tools for the rift clearly has value, glad to see
>>>> this thread.
>>>>
>>>> Sent from my iPad
>>>>
>>>> On Dec 17, 2013, at 12:17 PM, francisco criado 
>>>> wrote:
>>>>
>>>> Hi Mirko, nice to see at least two Softimage users with the rift, i´m
>>>> currently learning unity and c#, and already imported material from Soft in
>>>> Unity without any trouble. Just realized that having access to the complete
>>>> c++ and c# code in the sdk  is like having a Mercedes and don´t know how to
>>>> turn it on :S
>>>> If i get into something useful i wil let you know. By now the only
>>>> autodesk dcc app having access to the rift is Maya, which plugin is being
>>>> sold for more than 200 bucks (no comments). And is "just a python script"
>>>> that works with the viewport 2.0 and uses the stereo cams that already come
>>>> in Autodesk products.
>>>> Trying to figure out if it is posible in Softimage through HQ viewport.
>>>> Again, if any of you guys want to give us a hand here, you are more than
>>>> welcome, it would be great to see Softimage getting involved in VR.
>>>>
>>>> F.
>>>>
>>>>
>>>>
>>>> 2013/12/17 Mirko Jankovic 
>>>>
>>>>> I have no idea about coding I'm afraid but do have Oculus rift dev kit
>>>>> here so if you need testing I'm there :)
>>>>>
>>>>>
>>>>> On Tue, Dec 17, 2013 at 5:42 PM, francisco criado <
>>>>> malcriad...@gmail.com> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Just wanted to ask you if any of you is interested in helping on
>>>>>> developing an Oculus plugin for Softimage. The idea is to build a free
>>>>>> plugin that would help our comunity to use this when the consumer product
>>>>>> comes to the market. I have access to the sdk and the c# sources that may
>>>>>> help (a lot), and i´m trying by my self, but since i began learning 
>>>>>> coding
>>>>>> a few months ago, its getting quite difficult.Thought that maybe any of 
>>>>>> you
>>>>>> great coding gurus around here :)) might be interested. If so, let me 
>>>>>> know!
>>>>>>
>>>>>> Greetings,
>>>>>> Francisco.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

Forcing evaluation of entire stack

[Mathias N]

I have a polygon mesh with a number of custom operators that maintain a
custom mesh structure.

An operator (Loader) at the very beginning of the modeling stack reads the
custom mesh structure and makes a copy that we can work on without
modifying the original.
If later operators were modifying the base structure instead of a copy, the
modifications would stack on each evaluation.

You can then apply standard topology operators (extrude, move etc), or
other custom operators that modify the internal structure directly, then on
the next evaluation cycle we reset the work copy and start with a fresh
copy of the unmodified mesh.

With the Loader operator set to AlwaysEvaluate it will update every frame
on playback, but when making certain changes (MoveComponent, for instance)
the evaluation stack will not re-evaluate operators earlier in the stack.

It would seem that if you have a mesh with [extrude op] and [move
component]s around after it, the first [extrude op] operator will not be
evaluated unless you jump to a different frame.

This means that my work copy is never reset, and any changes I make via
other operators stack on every evaluation.

I suppose this is a desired optimization for XSI's own cacheable data, but
it becomes a bit of a show stopper if you want your own data to be
evaluated in the stack.

As I am assuming the SDK does not provide the means to mimic this caching
behavior, is there any way to force the entire stack to always be evaluated?

Thanks!

Re: oculus rift sdk

[Mathias N]

I suppose this should ideally be implemented as a custom device rather than
an ICE node, but trying to get that mess working without having an Oculus
to play with would likely prove to be a lesson in frustration.

No idea if this works, but technically it should.

http://www.mayulive.com/riftDevice.dll

Place it in a simulated ice tree, plug the rotation into whatever and hit
play to make it update constantly.

It just occurred to me that userdata allocated in BeginEvaluate is
recreated for every update, which means I am initializing the oculus every
single frame instead of just grabbing the orientation. So ... enjoy your
latency for now, if it even works.


On Fri, Dec 20, 2013 at 7:25 PM, Francisco Criado wrote:

> Just wanted to add that i posted the same initiative on fe splice group,
> and the idea has been very welcomed. Thought it would be great to have this
> tool, not only in SI.
>
>
> F.
>
> On Wednesday, December 18, 2013, Francisco Criado wrote:
>
>> Hi Andy,
>>
>> tried last night to send the sdk pdf to the mailing list,but it seems
>> mail couldn´t make because of the attachment. My ftp is currently down, but
>> it would be great to share sdk documentation and the c# files in case
>> someone wants to get a look inside. Maybe wetransfer, but it has a certain
>> amount of time on line.
>>
>> F.
>>
>>
>>
>> 2013/12/18 Andy Moorer 
>>
>>> I'm also playing with the rift and recently a couple of guys at an
>>> important Softimage using studio mentioned to me they were using the rift
>>> and unity. So Softimage tools for the rift clearly has value, glad to see
>>> this thread.
>>>
>>> Sent from my iPad
>>>
>>> On Dec 17, 2013, at 12:17 PM, francisco criado 
>>> wrote:
>>>
>>> Hi Mirko, nice to see at least two Softimage users with the rift, i´m
>>> currently learning unity and c#, and already imported material from Soft in
>>> Unity without any trouble. Just realized that having access to the complete
>>> c++ and c# code in the sdk  is like having a Mercedes and don´t know how to
>>> turn it on :S
>>> If i get into something useful i wil let you know. By now the only
>>> autodesk dcc app having access to the rift is Maya, which plugin is being
>>> sold for more than 200 bucks (no comments). And is "just a python script"
>>> that works with the viewport 2.0 and uses the stereo cams that already come
>>> in Autodesk products.
>>> Trying to figure out if it is posible in Softimage through HQ viewport.
>>> Again, if any of you guys want to give us a hand here, you are more than
>>> welcome, it would be great to see Softimage getting involved in VR.
>>>
>>> F.
>>>
>>>
>>>
>>> 2013/12/17 Mirko Jankovic 
>>>
 I have no idea about coding I'm afraid but do have Oculus rift dev kit
 here so if you need testing I'm there :)


 On Tue, Dec 17, 2013 at 5:42 PM, francisco criado <
 malcriad...@gmail.com> wrote:

> Hi guys,
>
> Just wanted to ask you if any of you is interested in helping on
> developing an Oculus plugin for Softimage. The idea is to build a free
> plugin that would help our comunity to use this when the consumer product
> comes to the market. I have access to the sdk and the c# sources that may
> help (a lot), and i´m trying by my self, but since i began learning coding
> a few months ago, its getting quite difficult.Thought that maybe any of 
> you
> great coding gurus around here :)) might be interested. If so, let me 
> know!
>
> Greetings,
> Francisco.
>
>

>>>
>>

Re: ICEAttribute from custom operator not updating

[Mathias N]

As an operator apparently cannot have ICEAttribute output ports, I instead
pass the polymesh and pointcloud primitives and add the operator to the
pointclud.

CustomOperator customOperator =
> pickedObject.GetActivePrimitive().AddCustomOp( L"HairCommandsGenerate",
> inputs,L"HairCommandsGenerate",siConstructionModePrimaryShape  ) ;
>

In the update callback I grab the create or grab the ICEAttribute from the
pointcloud and fetch its 2DArray.

ICEAttribute rootsAttribute = outputCloud.GetGeometry().AddICEAttribute(
> "hairCommandsRoots", XSI::siICENodeDataVector3,
> XSI::siICENodeStructureArray, XSI::siICENodeContextSingleton);
> CICEAttributeDataArray2D rootsArray2D;
> rootsAttribute.GetDataArray2D(rootsArray2D);
>

After this a bunch of calculations are performed, and then we resize the
2DArray and memcpy over the new data

CICEAttributeDataArray< MATH::CVector3f > data;
>

if (rootIO.size()>0)
> {
> rootsArray2D.ResizeSubArray(0,0,data);
> rootsArray2D.ResizeSubArray(0,rootIO.size(),data);
> memcpy(&data[0],&rootIO[0],sizeof(MATH::CVector3f)*rootIO.size());
> }
>

I just remembered why I resize the array to 0 before setting it to the
correct size.
Earlier on, only resizing the array to the correct size would randomly
result in half the array being zeroed out.
Doing the above without first resizing the array to 0 now just gives me
this:

[image: Inline image 1]

Only resizing the array once (on creation, first to 0 then to the correct
size) crashes on successive evaluations.


On Tue, Nov 5, 2013 at 1:48 AM, Alok Gandhi wrote:

> Ok, I get it. Can you share how you are  pushing the data from the
> operator to ice tree ?
>
> Sent from my iPhone
>
> On Nov 4, 2013, at 7:23 PM, Mathias N  wrote:
>
> To be more specific, in addition to reading the point positions I also
> grab a myriad of custom properties (userdatamaps and userdatablobs) which
> are combined to generate the attribute data.
>
> Seeing as the operator itself is evaluating correctly, I felt it best to
> use a simplified example.
>
>
> On Tue, Nov 5, 2013 at 1:15 AM, Alok Gandhi wrote:
>
>> Is there a particular reason you are reading the pointposition from a
>> custom operator and not from the ice tree which is supposed to have the
>> data ?
>>
>>
>> On Mon, Nov 4, 2013 at 6:48 PM, Mathias N  wrote:
>>
>>> I have set up a custom operator that reads the point positions of a mesh
>>> and spits an array into a per-object ICEAttribute.
>>>
>>> For the most part this setup is working flawlessly, but it appears to be
>>> updating on a 1-frame delay.
>>>
>>> The custom operator is in the modeling stack, with the ICE tree that
>>> reads the attribute it creates in the animation stack.
>>>
>>> The operator itself is being evaluated, and logging to console confirms
>>> that it is generating the expected output, but when reading the same
>>> attribute in the ICE tree the values are from the previous evaluation
>>> rather than the current one.
>>>
>>> I had a go at deleting and re-creating the attribute on each update,
>>> hoping that it would counteract any caching that might be occurring, but it
>>> had no effect.
>>>
>>> Any Ideas? Is using a customer operator to write to ICEAttributes a
>>> no-no?
>>>
>>> Using Softimage 2013 SP1
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>
>
<>

Re: ICEAttribute from custom operator not updating

[Mathias N]

To be more specific, in addition to reading the point positions I also grab
a myriad of custom properties (userdatamaps and userdatablobs) which are
combined to generate the attribute data.

Seeing as the operator itself is evaluating correctly, I felt it best to
use a simplified example.


On Tue, Nov 5, 2013 at 1:15 AM, Alok Gandhi wrote:

> Is there a particular reason you are reading the pointposition from a
> custom operator and not from the ice tree which is supposed to have the
> data ?
>
>
> On Mon, Nov 4, 2013 at 6:48 PM, Mathias N  wrote:
>
>> I have set up a custom operator that reads the point positions of a mesh
>> and spits an array into a per-object ICEAttribute.
>>
>> For the most part this setup is working flawlessly, but it appears to be
>> updating on a 1-frame delay.
>>
>> The custom operator is in the modeling stack, with the ICE tree that
>> reads the attribute it creates in the animation stack.
>>
>> The operator itself is being evaluated, and logging to console confirms
>> that it is generating the expected output, but when reading the same
>> attribute in the ICE tree the values are from the previous evaluation
>> rather than the current one.
>>
>> I had a go at deleting and re-creating the attribute on each update,
>> hoping that it would counteract any caching that might be occurring, but it
>> had no effect.
>>
>> Any Ideas? Is using a customer operator to write to ICEAttributes a no-no?
>>
>> Using Softimage 2013 SP1
>>
>>
>>
>>
>
>
> --
>

ICEAttribute from custom operator not updating

[Mathias N]

I have set up a custom operator that reads the point positions of a mesh
and spits an array into a per-object ICEAttribute.

For the most part this setup is working flawlessly, but it appears to be
updating on a 1-frame delay.

The custom operator is in the modeling stack, with the ICE tree that reads
the attribute it creates in the animation stack.

The operator itself is being evaluated, and logging to console confirms
that it is generating the expected output, but when reading the same
attribute in the ICE tree the values are from the previous evaluation
rather than the current one.

I had a go at deleting and re-creating the attribute on each update, hoping
that it would counteract any caching that might be occurring, but it had no
effect.

Any Ideas? Is using a customer operator to write to ICEAttributes a no-no?

Using Softimage 2013 SP1

Re: mail delay

[Mathias N]

This Softimage Mailing List archive updates almost instantly:

https://groups.google.com/forum/?hl=en#!searchin/xsi_list/royston$20michaels|sort:date

If it's not there, then something went wrong.


On Wed, Oct 30, 2013 at 5:13 PM, royston michaels wrote:

> Hmmm, let me check...
> Everything's stable, thanks Alan.
>
> I sent mail before this...not seeing
> it on the list...can you confirm?
>
>
>
> On 10/30/13, Alan Fregtman  wrote:
> > No delays here, and I'm on gmail. Have you turned off all and any flux
> > capacitors? You may be a time traveller.
> >
> >
> >
> > On Wed, Oct 30, 2013 at 7:48 AM, royston michaels
> > wrote:
> >
> >> Hi list,
> >> anyone experiencing delays sending mail to the list?
> >> sending from gmail account.
> >>
> >> my mail appears a week later from send date.
> >>
> >
>

Strand Collision Framework

[Mathias N]

A couple of years ago I decided I needed inter-colliding strands and spent
an ungodly amount of time trying to make it in ICE.

As a result of not knowing anything back when I started working on it the
code is a complete mess, and fixing the more glaring issues would be a
significant undertaking. Thus, the project was abandoned long ago.

A few weeks ago I got a message asking if I could share the unfinished
product, prompting me to dust it off and apply a few strategically placed
band-aids to at least get it functioning.
Consider it a lesson in bad design.

What it can do: https://vimeo.com/groups/ice/videos/76018502
Download (Addon and example scenes):
http://www.mayulive.com/StrandCollisionFramework.zip
Will likely require the VC++2012 redistributable:
http://www.microsoft.com/en-us/download/details.aspx?id=30679

More details on how broken it is in the si-community thread:
http://www.si-community.com/community/viewtopic.php?f=4&t=4486

Any bugs that do not result in Softimage crashing are features.

Re: CICEAttributeDataArray and SDK backwards compatibility

[Mathias N]

I made the move to the 2014SP2 SDK a while back hoping that some of the
problems I was encountering were bugs rather than me simply having no idea
what I was doing (Spoiler: it was the latter). Seeing as all my plugins
compiled against it also worked fine in 2011 I figured it would be
preferable to stick with it. Clearly I was mistaken.

If doing so does not provide any benefit I guess I have no reason to use
the newer SDK. Unless 2014SP2 does indeed begin breaking 2013 SDK plugins,
in which case I'll have to compile and release multiple flavors.
Bit of a shame though, seeing as everything else seems to be working just
fine using the 2014SP2 SDK.




On Wed, Oct 23, 2013 at 7:58 PM, Steven Caron  wrote:

> ya, what advantage where you hoping to attain by using the newer SDK?
>
>
> On Wed, Oct 23, 2013 at 10:54 AM, Mathias N  wrote:
>
>> Huh, so I guess I should stop using the 2014SP2 SDK for my 2011 plugins.
>>
>> Thanks for clearing that up.
>>
>>

Re: CICEAttributeDataArray and SDK backwards compatibility

[Mathias N]

Huh, so I guess I should stop using the 2014SP2 SDK for my 2011 plugins.

Thanks for clearing that up.


On Wed, Oct 23, 2013 at 7:50 PM, Alok Gandhi wrote:

>
> On 10/23/2013 1:40 PM, Mathias N wrote:
>
> The plugin loads fine in 2014 SP2 even when compiled against the 2013SP1
> SDK;
>
>
> This means backwards compatibility not forward. You might want to check :
>
> http://xsisupport.com/2012/08/08/understanding-backwards-and-forwards-compatibility/
> for definitions.
>
> Plugins compiled against 2014 SDKs are supposed to work only in Soft 2014
> and not in earlier versions. Although Soft 2014 should be able to load
> plugins compiled against earlier version like 2013. This is backward
> compatibility.
>
> Although when it comes to SDK compatility, I would always compile against
> the SDK for the target Soft version, as there can be a host of issues that
> might go wrong from SDK to SDK. It is always a good idea to recompile your
> plugins with SDK for the version of Soft that you are targeting.
> --
>
> ALOK
>
> GANDHI
>
> / directeur technique senior- senior technical director
>
> alok.gan...@modusfx.com
>
> T:
> *450 430-0010 x225
>
> F:
> 450 430-0009
> www.modusfx.com
>
>
> -
>
> MODUS
>
> FX
>
> 120 Rue Turgeon,
>
> Sainte-Therese (Quebec) CANADA J7E 3J1
>
> Follow us on
> Facebook <http://www.facebook.com/ModusFX>
>
> &
> Twitter <https://twitter.com/Modusfx>
> *
>

Re: CICEAttributeDataArray and SDK backwards compatibility

[Mathias N]

The plugin loads fine in 2014 SP2 even when compiled against the 2013SP1
SDK; it is not forward but backward compatibility that appears to be broken.

Although the only proper rundown of SDK backwards compatibility I can find
is from the 2011 SDK wiki, it states that "The Softimage SDK is backwards
compatible with previous versions of Softimage and XSI", with exceptions
for a few classes prior to 2010. The 2014 SDK similarly notes that "Some of
the custom ICE node classes may break backwards compatibilty as of
Softimage 2010", while making no mention of any new backward compatibility
issues.

This would suggest that plugins compiled against the 2014sp2 SDK, including
use of the CICEAttributeDataArray class, should work in earlier versions,
provided they do not make use of any newly introduced methods.
Am I wrong?


On Wed, Oct 23, 2013 at 11:56 AM, Stephen Blair wrote:

>
> From the Softimage 2014 SP2 Readme:
>
> SOFT-9089
> Very slow access to the ICE attribute arrays
>
> *Note:
> You may need to recompile your plugins, if they were compiled using
> Softimage versions prior to 2014 SP2.
>
>
>
> On Wed, Oct 23, 2013 at 4:33 AM, Mathias N  wrote:
>
>> I've spent the night figuring out how to set per-component ICE attributes
>> from a custom operator, which most of the threads on the subject had me
>> beginning to believe was impossible.
>>
>> I was working with SI2013 and compiling against the SDK that ships with
>> 2014sp2, and as soon as I declared a CICEAttributeDataArray the plugin
>> would refuse to load with the error "A procedure couldn't be found in the
>> library".
>>
>> Having never worked with CICEAttributeDataArray before I assumed support
>> for it was added with SI2014, which would have explained the lack of
>> working examples. Lo-and-behold it loaded fine in 2014sp2.
>>
>> After much frustration I did eventually manage to coax the C++ api into
>> dumping arrays into per-point attributes, but was somewhat bummed that it
>> would only work with 2014. However, hours of digging through the SDK
>> documentation had made it abundantly clear that CICEAttributeDataArray was
>> nothing new and should work fine in earlier versions.
>>
>> I swapped out the 2014sp2 SDK and compiled against the 2013sp1 SDK
>> instead, which allowed the plugin to be loaded in 2013 without any errors.
>>
>> Aren't SDKs supposed to be backwards compatible?
>> Are there any extra steps necessary to make it play nice with earlier
>> versions, or do I have to stick with the old SDKs?
>>
>
>

CICEAttributeDataArray and SDK backwards compatibility

[Mathias N]

I've spent the night figuring out how to set per-component ICE attributes
from a custom operator, which most of the threads on the subject had me
beginning to believe was impossible.

I was working with SI2013 and compiling against the SDK that ships with
2014sp2, and as soon as I declared a CICEAttributeDataArray the plugin
would refuse to load with the error "A procedure couldn't be found in the
library".

Having never worked with CICEAttributeDataArray before I assumed support
for it was added with SI2014, which would have explained the lack of
working examples. Lo-and-behold it loaded fine in 2014sp2.

After much frustration I did eventually manage to coax the C++ api into
dumping arrays into per-point attributes, but was somewhat bummed that it
would only work with 2014. However, hours of digging through the SDK
documentation had made it abundantly clear that CICEAttributeDataArray was
nothing new and should work fine in earlier versions.

I swapped out the 2014sp2 SDK and compiled against the 2013sp1 SDK instead,
which allowed the plugin to be loaded in 2013 without any errors.

Aren't SDKs supposed to be backwards compatible?
Are there any extra steps necessary to make it play nice with earlier
versions, or do I have to stick with the old SDKs?

Re: Overriding commands

[Mathias N]

siOnBeginCommand does indeed appear to fit the bill.

Adding even a single component to the mesh using the normal tools would be
enough to make everything collapse, so I would like to consider it
warranted.

Thanks!


On Sun, Oct 20, 2013 at 8:47 AM, Martin  wrote:

> A simple event with something than stops the user and make him think in
> what is he doing (a msgbox perhaps) and then cancel the command should be
> good enough to make him use the correct tool. And very easy to write and
> disable.
>
> Martin
> Sent from my iPhone
>
> > On 2013/10/20, at 14:50, Chris Chia  wrote:
> >
> > +1
> > Do it carefully.
> >
> >
> >> On 20 Oct, 2013, at 11:40 AM, Alok Gandhi 
> wrote:
> >>
> >> In my opinion, overriding the commands is not advisable. You are
> effectively removing the native funtionality of the app, which might be
> needed in certain cases, if not now, then in future.
> >>
> >> Yes you can do it by hooking into the command events but note that the
> command is still going to finish doing what it is supposed to. You can only
> do some pre/post stuff. In your case, for example, you can nullify the
> extrude in a post procedure and proceed to your custom extrude. You also
> call undo but not all commands support it.
> >>
> >> I would still consider overriding commands as a bad practice. Maybe in
> some extreme scenario you can, if the situation absolutely warrants it. In
> such case you have to remember which commands you have overridden and how,
> so that you can restore the original behaviour when need be. You have to
> baby-sit it basically.
> >>
> >>> On Oct 19, 2013, at 9:24 PM, Mathias N  wrote:
> >>>
> >>> Is it at all possible to intercept and override commands made by the
> user?
> >>>
> >>> For instance, in my case I need to make a number of other changes
> every time the user extrudes something.
> >>> At the moment I have implemented my own separate extrude command, but
> I imagine the user would often end
> >>> up using the normal extrude tool purely out of habit.
> >>>
> >>> It would be nice to be able to prevent them from doing so, or better
> yet redirect it to my own custom command.
> >
>
>

Overriding commands

[Mathias N]

Is it at all possible to intercept and override commands made by the user?

For instance, in my case I need to make a number of other changes every
time the user extrudes something.
At the moment I have implemented my own separate extrude command, but I
imagine the user would often end
up using the normal extrude tool purely out of habit.

It would be nice to be able to prevent them from doing so, or better yet
redirect it to my own custom command.

Re: Custom Icenode singlethreaded memory leak

[Mathias N]

If you happen to be running x64, would you (or anyone else listening in)
mind running the node and scene file below and seeing if it affects your
memory usage?

http://www.mayulive.com/memleak.scn
http://www.mayulive.com/MemLeakSingleThread.dll

(Post with files attached got stuck in the moderator queue due to file size
limits. Link to cancel it is not reachable so a duplicate may show up later)


On Tue, Oct 1, 2013 at 9:50 PM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> This is strange because I'm actually working on a single threaded ICENode and
> don't have any memory leaks. The output port is a single structure of type
> Vec3 in 0D context.
> I can run it on a mesh with 3 millions points for 10 000 frames without
> memory issue.
>
> I'm using 2013 QFE7 btw.
>
>
>
>
> On Tue, Oct 1, 2013 at 2:57 PM, Mathias N  wrote:
>
>> Thanks for the reply.
>>
>> The trial version I'm using is 2014 SP2.
>> Testing is being done in an empty scene with nothing but the newly
>> created pointcloud and a simple ice tree. There are no attribute display
>> properties present.
>>
>> To rule out any other possible culprits I created two identical nodes
>> that simply output the float input (0D component), one single-threaded and
>> the other multi-threaded. Both created via the wizard with the only manual
>> change being setting each to pass the value instead of printing it as the
>> sample code does.
>>
>> Switching between the two, the multi-threaded node barely affected memory
>> usage, while the single-threaded node resulted in a steady increase in
>> memory usage that was never released.
>>
>> It does not appear to have been fixed in SP2 :(
>>
>> Given that I am only passing a relatively modest number of components
>> through it, I can imagine this would be quite a showstopper for larger sets
>> of data.
>>
>>
>>
>>  On Tue, Oct 1, 2013 at 7:25 PM, Guillaume Laforge <
>> guillaume.laforge...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Indeed, there has been some memory leaks issues in the past. If you were
>>> testing in 2014, you should try 2014 SP2 as it fixed (some parts) of the
>>> ICE related memory issue.
>>> If 2014 SP2 doesn't fix the pb you can also check if you've got some
>>> attribute display properties on your objects. They could be the culprit.
>>>
>>> Guillaume
>>>
>>>
>>> On Tue, Oct 1, 2013 at 12:24 PM, Mathias N  wrote:
>>>
>>>> Please excuse any errors; mailing lists are confusing.
>>>>
>>>> While wrapping up work on a system that includes 5 custom icenodes, I
>>>> noticed that memory usage was increasing by about 1mb per second during
>>>> playback.
>>>>
>>>> I eventually narrowed it down to a per-point-array node, the only
>>>> single-threaded node in the setup. In a test scene I have it reading about
>>>> 30 turbulized mesh point positions and spitting them into a single
>>>> per-object array, and after leaving it for 15-30 minutes a while memory
>>>> usage had increased from 400mb to 1.5gb. It is not released until the
>>>> program is closed.
>>>>
>>>> Being at loss as to what might be causing it I removed everything but
>>>> the absolute necessary pieces of the code (port declarations etc), only to
>>>> find that the problem persisted.
>>>>
>>>> Next I created a new icenode using the wizard, adding one input and one
>>>> output port with the default settings, and setting it to single threaded.
>>>> This also slowly increases memory consumption when executed. Using an 8x8x8
>>>> grid as input it increases memory usage by about 150kb per second.
>>>>
>>>> If the input is singular (object context) there is no perceivable
>>>> increase in memory usage. The rate of increase appears to be relative to
>>>> the number of input components.
>>>>
>>>> I primarily use Softimage 2011, but running it in the 2014 trial
>>>> produces the same result. Were it a legitimate bug it would seem unlikely
>>>> that it would persist for so long.
>>>>
>>>> Could anyone shed some light on what is going on here? Is this normal?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> --
>>>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with
>>>> subject "unsubscribe" and reply to the confirmation email.
>>>>
>>>
>>>
>>> --
>>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with
>>> subject "unsubscribe" and reply to the confirmation email.
>>>
>>
>>
>> --
>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with
>> subject "unsubscribe" and reply to the confirmation email.
>>
>
>
> --
> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject
> "unsubscribe" and reply to the confirmation email.
>
--
To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject 
"unsubscribe" and reply to the confirmation email.

Re: Custom Icenode singlethreaded memory leak

[Mathias N]

Thanks for the reply.

The trial version I'm using is 2014 SP2.
Testing is being done in an empty scene with nothing but the newly created
pointcloud and a simple ice tree. There are no attribute display properties
present.

To rule out any other possible culprits I created two identical nodes that
simply output the float input (0D component), one single-threaded and the
other multi-threaded. Both created via the wizard with the only manual
change being setting each to pass the value instead of printing it as the
sample code does.

Switching between the two, the multi-threaded node barely affected memory
usage, while the single-threaded node resulted in a steady increase in
memory usage that was never released.

It does not appear to have been fixed in SP2 :(

Given that I am only passing a relatively modest number of components
through it, I can imagine this would be quite a showstopper for larger sets
of data.


On Tue, Oct 1, 2013 at 7:25 PM, Guillaume Laforge <
guillaume.laforge...@gmail.com> wrote:

> Hi,
>
> Indeed, there has been some memory leaks issues in the past. If you were
> testing in 2014, you should try 2014 SP2 as it fixed (some parts) of the
> ICE related memory issue.
> If 2014 SP2 doesn't fix the pb you can also check if you've got some
> attribute display properties on your objects. They could be the culprit.
>
> Guillaume
>
>
> On Tue, Oct 1, 2013 at 12:24 PM, Mathias N  wrote:
>
>> Please excuse any errors; mailing lists are confusing.
>>
>> While wrapping up work on a system that includes 5 custom icenodes, I
>> noticed that memory usage was increasing by about 1mb per second during
>> playback.
>>
>> I eventually narrowed it down to a per-point-array node, the only
>> single-threaded node in the setup. In a test scene I have it reading about
>> 30 turbulized mesh point positions and spitting them into a single
>> per-object array, and after leaving it for 15-30 minutes a while memory
>> usage had increased from 400mb to 1.5gb. It is not released until the
>> program is closed.
>>
>> Being at loss as to what might be causing it I removed everything but the
>> absolute necessary pieces of the code (port declarations etc), only to find
>> that the problem persisted.
>>
>> Next I created a new icenode using the wizard, adding one input and one
>> output port with the default settings, and setting it to single threaded.
>> This also slowly increases memory consumption when executed. Using an 8x8x8
>> grid as input it increases memory usage by about 150kb per second.
>>
>> If the input is singular (object context) there is no perceivable
>> increase in memory usage. The rate of increase appears to be relative to
>> the number of input components.
>>
>> I primarily use Softimage 2011, but running it in the 2014 trial produces
>> the same result. Were it a legitimate bug it would seem unlikely that it
>> would persist for so long.
>>
>> Could anyone shed some light on what is going on here? Is this normal?
>>
>> Thanks
>>
>>
>> --
>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with
>> subject "unsubscribe" and reply to the confirmation email.
>>
>
>
> --
> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject
> "unsubscribe" and reply to the confirmation email.
>
--
To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject 
"unsubscribe" and reply to the confirmation email.

Custom Icenode singlethreaded memory leak

[Mathias N]

Please excuse any errors; mailing lists are confusing.

While wrapping up work on a system that includes 5 custom icenodes, I
noticed that memory usage was increasing by about 1mb per second during
playback.

I eventually narrowed it down to a per-point-array node, the only
single-threaded node in the setup. In a test scene I have it reading about
30 turbulized mesh point positions and spitting them into a single
per-object array, and after leaving it for 15-30 minutes a while memory
usage had increased from 400mb to 1.5gb. It is not released until the
program is closed.

Being at loss as to what might be causing it I removed everything but the
absolute necessary pieces of the code (port declarations etc), only to find
that the problem persisted.

Next I created a new icenode using the wizard, adding one input and one
output port with the default settings, and setting it to single threaded.
This also slowly increases memory consumption when executed. Using an 8x8x8
grid as input it increases memory usage by about 150kb per second.

If the input is singular (object context) there is no perceivable increase
in memory usage. The rate of increase appears to be relative to the number
of input components.

I primarily use Softimage 2011, but running it in the 2014 trial produces
the same result. Were it a legitimate bug it would seem unlikely that it
would persist for so long.

Could anyone shed some light on what is going on here? Is this normal?

Thanks
--
To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject 
"unsubscribe" and reply to the confirmation email.