2015 SP2?

thorsnuts · Post by **thorsnuts** » 18 Mar 2015, 17:49

Does anyone know if they plan on releasing SP2 for 2015, or is SP1 it?

thanks

Draise · Post by **Draise** » 19 Mar 2015, 01:58

Buen pregunta.

Maximus · Post by **Maximus** » 19 Mar 2015, 23:21

pretty sure sp1 is the last one we'll ever see. but i might be wrong.

luceric · Post by **luceric** » 19 Mar 2015, 23:56

There is a planned SP2 - I think licensing requires it - but it'll probably be small like the SP1.

Pooby · Post by **Pooby** » 20 Mar 2015, 08:45

Well as long as they leave 2015 useable ( for me) then thats ok (by me).. At the moment its not ( for me) , due to the reintepret location to new Geometry node being broken.
Ive Filed a bug report on it, but not sure if there is a way of hassling them to make sure they fix it.

rray · Post by **rray** » 20 Mar 2015, 19:18

Yep quite annoying regression about the reinterpret node, ran into that one too. It can be worked around, but I believe at a performance cost.

Also important, some of the distributed core DLLs seem to be the debug builds (or at least they include symbols)
I hope they'll use the release build for the last SP, that usually gives quite a performance boost.

.. alhough the symbols in the debug dll gives some interesting glimpse into the core architecture

Hirazi Blue · Post by **Hirazi Blue** » 20 Mar 2015, 20:01

Okay, I'll bite...
What is wrong with the reinterpret node & is this a SI2015 SP1 problem or is "vanilla" SI2015 affected too?

rray wrote: It can be worked around, but I believe at a performance cost.

Do tell us more about this workaround...
$:-\$

rray · Post by **rray** » 20 Mar 2015, 21:36

might remember wrong, but I was getting wrong locations back from when the input geometry link was shared e.g.

get data1(geometry port )----->(geometry port)reinterpret1
get data2(geometry port )----->(geometry port)reinterpret2

was ok, but

get data1(geometry port )------->(geometry port)reinterpret1
\---------------------------------->(geometry port)other node

wasn't always working

There's a workaround here: https://www.si-community.com/forum/v ... w=previous that I didn't try/understand, I went with the workaround of splitting up 1 get data nodes into multiple get data nodes. Probably not a big perfomance loss.

I think it started with Version 2015 no SP.

luceric · Post by **luceric** » 20 Mar 2015, 21:37

Pooby wrote:Well as long as they leave 2015 useable ( for me) then thats ok (by me).. At the moment its not ( for me) , due to the reintepret location to new Geometry node being broken.
Ive Filed a bug report on it, but not sure if there is a way of hassling them to make sure they fix it.

You could mail hsiao ming chia and ask, he's the dev manager of Softimage.

Pooby · Post by **Pooby** » 20 Mar 2015, 22:01

Do you know his email? I will do that if I can find it out.

luceric · Post by **luceric** » 20 Mar 2015, 22:36

You can find that in the mailing list archive, but it's his name with dots between the words @autodesk.com

Mathaeus · Post by **Mathaeus** » 20 Mar 2015, 23:10

Hirazi Blue wrote:Okay, I'll bite...
What is wrong with the reinterpret node & is this a SI2015 SP1 problem or is "vanilla" SI2015 affected too?
rray wrote: It can be worked around, but I believe at a performance cost.
Do tell us more about this workaround...
$:-\$

If anyone is interested in my version of workaround , two nodes of latest Kristinka Hair (v 3.2) describes it probably better than my words. Nodes are 'kh3 initialize polymesh emitter' and 'kh3 deform hair'. Trick is to get both attributes from 'first' location, while 'first' location gets the attributes from 'second', using ICE switch context. Because attributes are coming from location, they are nicely interpolated - but 'switch context' don't care about SRT, only deformation is considered.

In little defense of developers, from little time I've spent with SI 2015 trial. It seems some old inconsistencies are fixed, like omitting to transfer the filtered attributes from points to strands in some cases - where mentioned hair system already had a bit brutal workaround, just trying to not do that.
I'd say, it always was 'gray zone' of unexpected behaviors with ICE. This one with re-interpret is really annoying, but it's not first. While ago, if re-interpret was called through 'get closest location', cutoff distance was calculated by 'second' object.

As far as I know, bug is firstly reported on this forum by our member mattmos in kh thread, few days after SI 2015 release.

Bullit · Post by **Bullit** » 21 Mar 2015, 12:08

Maybe i am going too far in the wilderness but can't the old node V2014 work in V2015?

Mathaeus · Post by **Mathaeus** » 21 Mar 2015, 12:51

Don't believe, I think the 'engine part' it's not a separate dll, like MR shader or like. GUI counterpart, ICE node or compound, is just a textual, XML definition. This allows great compatibility, even in upward direction, sometimes. But, if something goes wrong with 'engine part', no hope, I'm afraid.
On positive side, in my opinion, it's more a convenience node, functionality should be possible to re-assemble by other nodes. I don't believe it is used anywhere in factory ICE compounds.

2015 SP2?

2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?

Re: 2015 SP2?