LAST CHANCE TO FIX STUFF!!

[Pooby]

Ok so I have very good reason to believe we will get an SP2 for Softimage and the Reinterpret location to new Geometry Node will be fixed.

"As mentioned, your issue has been reported to our engineering department.

Here is the logged issue with Development:

BSPR-18973 The 'reinterpret Location to new Geometry' ICE node does not work properly


No eta is determined for a fix date yet although I was told that they will look into integrating the fix on the next SP release."


SO... this will be the last fix we get in all likelihood.
Time is running out. The reinterpret node was the only thing thats stopping me using 2015, so I'm delighted, but if there is anything else you guys really want fixing in 2015 then lets assemble a list and post it to them. ( complete with examples etc). I'm in direct communication with AD now so I can hopefully prompt them to give the list proper attention.

[rray]

Sounds good...fingers crossed - So we should focus on things that are realistic to fix in a short timeframe, and at the same time don't have a workaround.

One things that annoys me most during modeling and should be a really simple fix:
* When starting orbit ('s') from a top down view, then moving downwards, left-right navigation is inverted 50% of the time. I think it depends on whether the start point was a bit 'over' the top. It was working much better a few versions ago. So I'd be happy with a preference setting that switches back to the old method (which had some minor issues in itself, but was better overall)

1 Feature addition that might be possible to do:
* Native (non ICE) dual quaternion support for envelopes. including support for storing shape keys in secondary shape mode ("invertible deformer")

[mattmos]

Thanks for pushing on this Paul, will try to stress test 2015 a bit more over the next couple of days and see if there are any other squashable bugs around.

[xsi_fanatic]

Hi Pooby,

There's a bug with Syflex ICE in SI 2015. Not sure if it has been fixed, it is in the pin or nail node. I can't remember which, also I don't have access to it at the moment. But create a basic setup on a grid using either one (pin / nail) and add an obstacle; and you'll see the Syflex sim on the grid jerk back in a spontaneous manner once you hit the play button.

This bug does not occur in SI 2012, or SI 2013. I hope that helps.

Thanks,
Jason

[Rez007]

Thanks Pooby for looking into these fixes and taking the time to navigate your way to get a direct contact with Autodesk. It is disappointing though, that these - very constructive - threads hardly get any posts, which could help all of us with Softimage, and the ones that pertain to nothing, get pages of replies.

This is the last chance, people, post some of the fixes you would like to see, and/or contact Autodesk directly to add it to the list.

I have been talking to Maurice, from Autodesk, quite a bit the past couple of weeks myself in regards to Softimage perpetuity https://www.si-community.com/forum/v ... 28&p=51628 In that discussion I asked about the 'GoTo Softimage' function being implemented, and unfortunately you can see in the link that the reply he was able to find, results that it would not be possible. I think that would have been a nice addition.

I haven't been on Softimage 2015 too much, but if I find something I will post it here.

Thank you again for the initiative!

[Pooby]

You're welcome.
It would be very helpful if anyone could post bug scenes that I can send to AD. I am quite busy at the mo so not sure how much time I'll get to recreate them.

[FXDude]

Greetz,

To follow-up on this thread, if there would be a few (3) things that I would find important to address considering it may be the last state XSI will be left in, it would be the following:


-1. Zoomed-out text clarity in ICE and Render Tree views

Since the the release of ICE has there been a Preference (in Editors -> RenderTree)
for "high quality text" in ICE & RT views.

Which is OFF by default, probably because when ON, dragging new nodes to the graph
resets the font size to as proportionally small to how zoomed-out the view is.

Zooming-in completely, and dragging a new node, does restore correct font sizes
(without having to actually drop the dragged item) ,
but having to do that is also what can make the option basically unusable.


But why addressing this may be important, is that font antialiasing isn't only to make fonts look pretty,
it's also what makes subpixel text details for whenever not being zoomed-in almost completely up-close.

Because with HQ Text ON , you can still make-out words even from a birds eye view, or at least the node titles,
when connecting things to other things far away,
or just overviewing connections, or working without a dedicated 2nd screen for your ice graphs
(even -with- a 2nd screen, it's quite good to be able to see details in wide views of ice graphs)




and with HQ text OFF , even zooming-out just 2 or 3 wheel scroll steps out,
already makes port names become almost undecipherable.




Also considering that it should (or could?) be a relatively small fix,

With "HQ Text" ON, perhaps auto-resetting the graph fonts after drop event?
or perhaps would it be the drawing of the dragged node around cursor
(at a completely different font scale to current graph fonts)
whenever mouse hovers over graph before inserting, that's causing the graph font to resize?


_________________________
-2. HQV transparency mapping

Softimage being particulary good for all sorts of camera projection work,
and considering the general usefulness of either shot or prerendered elements on cards and cutouts,

although using the HQV may not necessarily be always ideal for large amounts of complex shaders
(performance-wise when compiling shaders),
for just a bunch of basic constant materials, (typically used for cards)
the HQV works fairly fast (or fast enough) and handles depth-sorting flawlessly ...
(being a common OGL issue with alpha driven transparencies,
and was what previously hindered regular "Textured" views).

And also allows to accurately navigate, preview and even render usable (8 bit) elements
for use in final comps, having very good subpixel AA and high frequency detail texture filtering.

*BUT*
The single, equally unfortunate as hindering, while possibly easy to address problem, (fingers crossed)
is that there seems to be a 'compositing error' in displaying cutouts or map driven transparency,
when using the otherwise quite accurate HQV,
thus preventing correct (and therefore useful or representative) results with realtime cutouts and cards.


It's as if the very transparent values in transparency masks
(either using black or white values as transparent)
was also proportionally darkening the RGB, which appears in mid-value transparency ranges.

So even if 100% transparent values does indeed make the surface completely transparent,
the half transparent parts between fully opaque and fully transparent, get somehow darkened.

Most noticeable in edges around opaque areas, and even if the RGB itself is just solid constant white.


To illustrate, below are 2 grids with constant white materials,
both over another grid (gray) to reveal transparency, and everything over a solid white BG.

One of the white grids has a radial gradient ramp plugged into it's transparency,
and the other has an XSI logo, (also with a render region showing what should be correct results)
and showing how darkening in transparency midpoints can be considerable and problematic.



Not having to draw or update regions for cutouts is one reason for this to work,
but the ability, speed or "liveness", and convenience to reliably preview,
show or use realtime outputs of elements with transparency maps
from the Render Manager (Hardware Renderer), or the viewport capture,
(without resorting to RGB edge tweaks to compensate)
is something that greatly depends on HQV transparency maps being correctly represented.
(if hopefully not a MetaSL shader limitation)



_________________________
-3. Disabling of what is like a "performance-mode on interaction" of HQV AntiAliasing


Since the HQV was introduced has it been qualified as relatively "slow".

Which I believe could mostly have to do with compilation-time of entire scene shaders upon view activation
(which also happens upon every material slider tweak or shader node insertion)
... and perhaps less about actual HQV navigation performance or even playback FPS .

But without suggesting any improvement to HQV performance,
my question is, could it's perceived slowness also have motivated the
"temporary disabling of Anti-aliasing during interactions" which was later introduced?


Because as far I could tell, even with fairly complex scenes on very mid-range GPUs,
of all things, anti-aliasing barely made a difference if at all, even at high 32x AA

And the constant (and non-optional) auto-off & on-again switching of AA when navigating
or transforming things in the viewport, quite defeats the purpose realtime anti-aliasing
when orbiting and looking or moving things around.

While the switching itself & the slight delay before turning AA ON again at each mouse release,
also considerably 'disturbs' or distracts from what is currently being observed.


Also even without considering the main purpose of HQV ,
this would also apply to a "trick" to have like "enhanced standard views"
when enabling "mixed viewing modes" in Display options,
and setting (or toolbar button scripting) the global (common to all objects) display property
to any standard view like say "Hidden line", and then turning-on HQV with AA,
(which of course bypasses evaluation of any shaders)



Allowing to have anti-aliased "hidden line", "shaded" or whatever other view
for showing better looking playblasts, or just working in that mode.
(without any display or raycast-selection bugs previously attibutable to forcing AA using graphics card settings)


Below: "Hidden Line" + HQV AA (2x resize) with AA turning off when interacting .



( or did I perhaps miss an existing environment variable for disabling "auto-AA-throttling" on interaction?)


In any event, thanks for reading,
and I also wanted to say thanks to Pooby for the initiative of this thread,

- and what would you consider important to be fixed before possibly the last ever tweaks to XSI sources?

Cheers!


(EDIT: typos)

[luceric]

that transparency in the viewport looks different probably because the render region is doing it in linear space, and opengl is in gamma space

[FXDude]

You may be right,
but if that was the case then wouln't the different color spaces also show-up in RGB representations?
(which otherwise doesn't seem to differ, everything else yeilds the same results as it's rendered counterpart)

And even if the linear transparency gradient was somehow interpreted or represented as an exponential ramp, wouldn't it simply exponentially (vs. linearly) become more transparent?

Meaning that, would it reveal anything other than what is in the RGB?

Because in the previous example, there is nothing but pure white (1,1,1) to reveal, and we can clearly see that lower than white RGB values are gradually being revealed at mid transparency levels (even darker than the background gray grid), and is what seems to make the otherwise unavoidable (at least as much as I tried to avoid) dark outlines around everything.

[FXDude]

Which may be of help:
To reproduce the issue withtin a rendered region,
you can (pre-)multiply the RGB with the same map modulating transparency, before plugging it in the 'color' slot.



And could it perhaps be 'just' that? the RGB somewhere getting premultiplied while maybe it should or could not?

[Hirazi Blue]

Good point, Pooby!

@luceric is there someone who still is officially responsible for "the last of the bugs" and could you direct him/her to this thread? I seem to recall Chris Chia to be quite active on the XSI Base back in the day. So someone similar...

[luceric]

As far as I know, the last service pack would be a roll-up of QFEs done by consulting for the studios (The Mills, Hybrid, Animal Logic, Japan..) and a few critical fixes escalated by the support team, like the reintepret-location mentionned here.

[Hirazi Blue]

Crystal clear answer. Thanks... ;)

[Pooby]

yes I'm not imagining any 'feature requests' at this stage. But any critical showstopping bugs have a decent chance of being addressed.

If anyone wants to send me files with notes that I can send on, I'll do so. ( unfortunately I dont have time to recreate scenes or type up notes etc.)

[FXDude]

yes I'm not imagining any 'feature requests' at this stage. But any critical showstopping bugs have a decent chance of being addressed.

If anyone wants to send me files with notes that I can send on, I'll do so. ( unfortunately I dont have time to recreate scenes or type up notes etc.)

Apart of course any critical bugs, I would hope that a few (or a few more) perhaps non-showstopping, yet possibly easily fixed ones would also be submitted and considered.

[Hirazi Blue]

I might have missed the announcement, but is there any kind of ETA on this near-mythical SP2?