Re: Maya - what were they thinking 2 - transforms

[Jason S]

  
  

  On 09/13/17 17:27, Ponthieux, Joseph G.
(LARC-E1A)[LITES II] wrote:


  Still,
  it’s not uncommon for a transform group hierarchy to resemble
  something like this:
   
  Master
     
  Translation
     
  Offset
     
      Random_Transforms
     
  Offset
  Yaw
  
     
          Pitch
  
     
      Roll
     

     
      GeometryMaster
     

  Etc
  
  
  Hum.
  
  I guess these "intermediate items" are probably part of XSI's
  internalized abstractions (?)
  
  I'm sure there must be advantages of having it this way, (1 null
  (& hierarchy level) for each axis of rotation ?)
  but I feel that these abstractions remove quite a bit of
  redundancy and clutter in sometimes already quite cluttered and
  deep hierarchies.
  
  in any event, thanks for the details!
  
  
  On 09/13/17 17:27, Ponthieux, Joseph G. (LARC-E1A)[LITES II]
  wrote:


  
  
  
  
Yes.
I think an “intermediate parent” is one way to put it and is
a reasonable assumption. But it can be variable.
 
For
example, If you know that you need local translations of Z
at a specific non-zero orientation, you use the parent to
set the orientation that governs the local transform axis in
local Z. If you don’t need that level of control you don’t
need that many parents. So it’s not always a 2:1 “double
depth” problem necessarily unless you need that level of
control. Or more control than average.

 
Still,
it’s not uncommon for a transform group hierarchy to
resemble something like this:
 
Master
   
Translation
   
Offset
   
    Random_Transforms
   
Offset
Yaw

   
        Pitch

   
    Roll
   
   
    GeometryMaster
   
Etc
 
Every
case is unique of course so not everything would look like
this but this would be fairly common for me if I were
setting up a UAV or other aircraft. Generally though I’ll
make new attributes at the Master transform group and
connect them back to each position or rotation atrribute on
the rig as needed so I only have one place to go for all
needed transformations. And stuff like the Random_Transforms
would be driven by expressions with attributes also placed
at the Master level to drive the random behavior.
 
Freezes
and Resets are always relative to the object its parented
to. If not parented under anything, it zeroes to world
“zero”. If it has a parent, it zeros to the parent “zero” or
center. Everything is always relative its parent’s transform
coordinates unless otherwise constrained on not a child of
anything.
 
If
you find you need to make significant changes, you remove
the geometry, or whatever, from the hierarchy (using
Unparent) then send it back to world zero (using Reset). For
example, in the case above I would just remove the Geometry
Master (likely an aircraft) from the hierarchy since I know
it was created at world zero. After I translate/rotate it
back to world 

RE: Maya - what were they thinking 2 - transforms

[Ponthieux, Joseph G. (LARC-E1A)[LITES II]]

Yes. I think an "intermediate parent" is one way to put it and is a reasonable 
assumption. But it can be variable.

For example, If you know that you need local translations of Z at a specific 
non-zero orientation, you use the parent to set the orientation that governs 
the local transform axis in local Z. If you don't need that level of control 
you don't need that many parents. So it's not always a 2:1 "double depth" 
problem necessarily unless you need that level of control. Or more control than 
average.

Still, it's not uncommon for a transform group hierarchy to resemble something 
like this:

Master
Translation
Offset
Random_Transforms
Offset
Yaw

Pitch

Roll

GeometryMaster

Etc

Every case is unique of course so not everything would look like this but this 
would be fairly common for me if I were setting up a UAV or other aircraft. 
Generally though I'll make new attributes at the Master transform group and 
connect them back to each position or rotation atrribute on the rig as needed 
so I only have one place to go for all needed transformations. And stuff like 
the Random_Transforms would be driven by expressions with attributes also 
placed at the Master level to drive the random behavior.

Freezes and Resets are always relative to the object its parented to. If not 
parented under anything, it zeroes to world "zero". If it has a parent, it 
zeros to the parent "zero" or center. Everything is always relative its 
parent's transform coordinates unless otherwise constrained on not a child of 
anything.

If you find you need to make significant changes, you remove the geometry, or 
whatever, from the hierarchy (using Unparent) then send it back to world zero 
(using Reset). For example, in the case above I would just remove the Geometry 
Master (likely an aircraft) from the hierarchy since I know it was created at 
world zero. After I translate/rotate it back to world zero and rework it there, 
I then drop it back into the hierarchy below Roll where it was originally 
located. When back in the hierarchy I execute Reset on GeometryMaster again. It 
should then move to be in exactly the same place it was before relative Roll, 
assuming I've managed not change the Geo's relation to transform and pivot zero 
too drastically.

To summarize:
Select geometry object
Unparent
Reset Transformations
Edit object at world zero coordinates
Reinsert object into hierarchy
Reset Transformations

If you develop a good set of habits in structuring and managing your 
hierarchies, placing at least one group transform above each geometry object, 
that kind of thing, its fairly painless. The parenting required is relative the 
articulation that is needed.

This way of doing things may not likely be familiar  if you're coming to Maya 
from XSI. When I learned Maya transforms I was coming from SI 3D, but I also 
had some experience on Wavefront TAV, so it was less difficult to understand 
why they did it this way. Funny thing is when I transitioned back to XSI from 
Maya, about XSI 5 I think, at some point I noted XSI had implemented Transform 
Groups. As a result I started using the Transform Groups in XSI to continue 
using the Maya structural "habit"  in XSI. I found that in time I rarely ever 
touched the Center again.

Bear in mind that Maya does provide a "global" abstraction through Move Tools' 
setting Axis Orientation. If you set it to world you can move an object 
according to World XYZ axis via the manipulator, but it will show up as local 
transform values local to its parent unless you remove it from the hierarchy. 
(This abstraction also seems kind of buggy in 2017 as it doesn't update the 
manipulator sometimes when switching from Object to World or back).

If you need to move something to a world specific position, use a locator or 
group that is not inserted in the hierarchy, set its world position, then snap 
the object to that world positioned locator(via Snap to Point).  Bear in mind 
that the object is still relative its parent. It can be nonzero to its parent 
without much issue if all you are doing is positioning it relative the 
articulation xform of its parent.

So it becomes kind of a game to know how to set up the hierarchy to manage 
articulations. What gets a lot of depth and what doesn't. And typically this 
means you rarely articulate a piece of geometry by 

Re: Maya - what were they thinking 2 - transforms

[Jason S]

  
  
It seems to be the same issue in these threads.

CGTalk - how to "zero to parent"

CGTalk - roll / pan / tilt of camera

So any item you would want to animate  by it's local axis (or to refer to it's local transforms in expressions) needs an intermediate parent item? 

Doesn't that make sub-sub level items become  sub-sub-sub-sub level? (double the items at double depth?)

What happens when you reset the transforms of a child of a parent that's somewhere in space, pointing somewhere?  
 (0 zeroing it's transforms) 
the item snaps to world center?  and not to whatever position/orientation of it's parent?


  
On 09/11/17 11:01, Morten Bartholdy wrote:



  Thanks guys - there is plenty to investigate here :)

//MB



  

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

Re: Soft 2014 in Linux is "always-on-top"?

[Ahmed Barakat]

Thanks Thomas
I appreciate your help a lot, as I am struggling with this for some time
now, and I am quite new to Linux too

so you mean renaming the original /usr/lib64/libx11.so.6 ?
won't this affect other apps on my computer?

here is what I got running those commands

source /usr//Softimage/Softimage_2015/.xsi_2015
xset: symbol lookup error: /usr/lib64/libX11.so.6: undefined symbol:
xcb_wait_for_reply64
xset: symbol lookup error: /usr/lib64/libX11.so.6: undefined symbol:
xcb_wait_for_reply64
xset: symbol lookup error: /usr/lib64/libX11.so.6: undefined symbol:
xcb_wait_for_reply64


ldd XSI.bin
linux-vdso.so.1 =>  (0x7fff287dd000)
libadlmint.so.9 =>
/usr/Softimage/Softimage_2015/Application/bin/libadlmint.so.9
(0x7f4a5f303000)
libctrls.so => /usr/Softimage/Softimage_2015/Application/bin/libctrls.so
(0x7f4a5f0a8000)
libsisdkplugin.so =>
/usr/Softimage/Softimage_2015/Application/bin/libsisdkplugin.so
(0x7f4a5ee7e000)
libscripthost.so =>
/usr/Softimage/Softimage_2015/Application/bin/libscripthost.so
(0x7f4a5ec46000)
libdscore.so => /usr/Softimage/Softimage_2015/Application/bin/libdscore.so
(0x7f4a5e9e8000)
libctrl.so => /usr/Softimage/Softimage_2015/Application/bin/libctrl.so
(0x7f4a5e761000)
libdsctl10.so =>
/usr/Softimage/Softimage_2015/Application/bin/libdsctl10.so
(0x7f4a5e422000)
libcts.so => /usr/Softimage/Softimage_2015/Application/bin/libcts.so
(0x7f4a5e17)
libsisdk.so => /usr/Softimage/Softimage_2015/Application/bin/libsisdk.so
(0x7f4a5defd000)
libmfbas10.so =>
/usr/Softimage/Softimage_2015/Application/bin/libmfbas10.so
(0x7f4a5dbbe000)
libdssdk10.so =>
/usr/Softimage/Softimage_2015/Application/bin/libdssdk10.so
(0x7f4a5d78a000)
libspdlparse.so =>
/usr/Softimage/Softimage_2015/Application/bin/libspdlparse.so
(0x7f4a5d549000)
libilcor10.so =>
/usr/Softimage/Softimage_2015/Application/bin/libilcor10.so
(0x7f4a5d0a3000)
libsynHub.so => /usr/Softimage/Softimage_2015/Application/bin/libsynHub.so
(0x7f4a5cad5000)
libsixmlparse.so =>
/usr/Softimage/Softimage_2015/Application/bin/libsixmlparse.so
(0x7f4a5c895000)
libolepro32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libolepro32.so
(0x7f4a5c792000)
libgk10.so => /usr/Softimage/Softimage_2015/Application/bin/libgk10.so
(0x7f4a5c3f1000)
libsigeneral.so =>
/usr/Softimage/Softimage_2015/Application/bin/libsigeneral.so
(0x7f4a5c193000)
libsialloc.so =>
/usr/Softimage/Softimage_2015/Application/bin/libsialloc.so
(0x7f4a5bf87000)
libmfc400s.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libmfc400s.so
(0x7f4a5bc16000)
liboleaut32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/liboleaut32.so
(0x7f4a5b9cb000)
libstub.so => /usr/Softimage/Softimage_2015/Application/bin/libstub.so
(0x7f4a5b7c7000)
liburlmon.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/liburlmon.so
(0x7f4a5b5db000)
libwininet.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libwininet.so
(0x7f4a5b415000)
libwsock32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libwsock32.so
(0x7f4a5b305000)
libversion.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libversion.so
(0x7f4a5b1f8000)
libshell32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libshell32.so
(0x7f4a5b01b000)
libcomctl32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libcomctl32.so
(0x7f4a5ae6b000)
libshlwapi.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libshlwapi.so
(0x7f4a5acdd000)
libuuid.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libuuid.so
(0x7f4a5abb2000)
libole32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libole32.so
(0x7f4a5a8fd000)
librpcrt4.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/librpcrt4.so
(0x7f4a5a73b000)
libmsvcrt.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libmsvcrt.so
(0x7f4a5a617000)
libgdiuser32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libgdiuser32.so
(0x7f4a5a299000)
libadvapi32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libadvapi32.so
(0x7f4a5a162000)
libkernel32.so =>
/usr/Softimage/Softimage_2015/Application/mainwin/mw/lib-amd64_linux_optimized/libkernel32.so
(0x7f4a59f17000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x7f4a59c73000)
libz.so.1 => /usr/Softimage/Softimage_2015/Application/bin/libz.so.1
(0x00390ea0)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x7f4a599f3000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x7f4a596b4000)

Re: Soft 2014 in Linux is "always-on-top"?

[Thomas Volkmann]

You still have to remove/rename libX11.so.6 .You can try to compare to my libraries:in a termianl run:tcshsource /usr/Softimage/Softimage_2015_SP2/.xsi_2015_SP2cd $XSI_HOME/Application/binldd XSI.binMy output:linux-vdso.so.1 (0x7ffdba7bb000) libadlmint.so.9 => /usr/Softimage/Softimage_2015_SP2/Application/bin/libadlmint.so.9 (0x7f678c28d000) libctrls.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libctrls.so (0x7f678c033000) libsisdkplugin.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsisdkplugin.so (0x7f678be09000) libscripthost.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libscripthost.so (0x7f678bbd1000) libsisdk.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsisdk.so (0x7f678b95e000) libdscore.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libdscore.so (0x7f678b701000) libcts.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libcts.so (0x7f678b45) libctrl.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libctrl.so (0x7f678b1c9000) libdsctl10.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libdsctl10.so (0x7f678ae8a000) libmfbas10.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libmfbas10.so (0x7f678ab4b000) libdssdk10.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libdssdk10.so (0x7f678a718000) libilcor10.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libilcor10.so (0x7f678a272000) libspdlparse.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libspdlparse.so (0x7f678a031000) libsynHub.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsynHub.so (0x7f6789a64000) libsixmlparse.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsixmlparse.so (0x7f6789824000) libolepro32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libolepro32.so (0x7f678c99d000) libgk10.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libgk10.so (0x7f6789484000) libsigeneral.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsigeneral.so (0x7f6789226000) libstub.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libstub.so (0x7f6789022000) liboleaut32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/liboleaut32.so (0x7f6788dd8000) libmfc400s.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libmfc400s.so (0x7f6788a62000) libsialloc.so => /usr/Softimage/Softimage_2015_SP2/Application/bin/libsialloc.so (0x7f6788856000) liburlmon.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/liburlmon.so (0x7f6788662000) libwininet.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libwininet.so (0x7f6788497000) libversion.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libversion.so (0x7f678838b000) libshell32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libshell32.so (0x7f67881a4000) libcomctl32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libcomctl32.so (0x7f6787ff4000) libshlwapi.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libshlwapi.so (0x7f6787e64000) libuuid.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libuuid.so (0x7f6787d39000) libole32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libole32.so (0x7f6787a73000) librpcrt4.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/librpcrt4.so (0x7f67878ac000) libwsock32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libwsock32.so (0x7f678779a000) libmsvcrt.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libmsvcrt.so (0x7f6787677000) libgdiuser32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libgdiuser32.so (0x7f6787301000) libadvapi32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libadvapi32.so (0x7f67871c9000) libkernel32.so => /usr/Softimage/Softimage_2015_SP2/Application/mainwin/mw/lib-amd64_linux_optimized/libkernel32.so (0x7f6786f78000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x7f6786cd4000) libz.so.1 => /usr/Softimage/Softimage_2015_SP2/Application/bin/libz.so.1 (0x00390ea0) libGLU.so.1 => /usr/Softimage/Softimage_2015_SP2/Application/bin/libGLU.so.1 (0x00372bc0) libX11.so.6 => /usr/lib64/libX11.so.6 (0x7f6786996000) libXext.so.6 => /usr/Softimage/Softimage_2015_SP2/Application/bin/libXext.so.6 (0x7f6786783000) libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x7f6786564000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 

Re: Soft 2014 in Linux is "always-on-top"?

[Ahmed Barakat]

Hi Thomas
I guess I will have to dig out the centos 6 libraries as I tried this and
got same error message

Thanks

Ahmed

On Wed, Sep 13, 2017 at 12:40 AM, Thomas Volkmann 
wrote:

> It's a long time since I made a clean install on a linux system.
> From what I remember you have to put these libs into the Application/bin
> folder:
> https://www.dropbox.com/sh/ph864dr6c831s6h/AABMwRSBkIO5eSheJ6aTgyg8a?dl=0
>
> These are libs from the last Fedora version that ran out of the box for me
> (14 or 16? I'm on 26 now). If these don't work for you, you might want
> to try libs from centos6.
> This should get SI up and running.
>
> good luck,
> Thomas
>
>
> Ahmed Barakat  hat am 12. September 2017
> um 22:37 geschrieben:
>
>
> Hi Christoph
> I know it's an ancient thread but I am trying to run Softimage on Centos 7
> got the same /usr/lib64/libXext.so.6: undefined symbol: _XGetRequest
> error and I followed your recommendation
> " Fortunately the solution to your problem is fairly simple:
>
> mv 
> /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib-amd64_linux/X11/libX11.so.6
> /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib
> -amd64_linux/X11/~libX11.so.6"
>
> but unfortunately now I get this error 
> "/usr/Softimage/Softimage_2015/Application/bin/XSI.bin:
> symbol lookup error: /usr/lib64/libX11.so.6: undefined symbol:
> xcb_wait_for_reply64"
>
> do you know what might be the problem I googled it with no luck
>
> Thanks
>
> On Sat, Jul 27, 2013 at 1:52 AM, Christoph Muetze 
> wrote:
>
> Hi Sylvain,
>
> ...i came across the same problem. Softimage seems to becoming more and
> more fragile on the Linux side of things, an install becomes harder with
> every release :/
>
> Fortunately the solution to your problem is fairly simple:
>
> mv /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/
> lib-amd64_linux/X11/libX11.so.6 /usr/Softimage/Softimage_2014_
> SP2/Application/mainwin/mw/lib-amd64_linux/X11/~libX11.so.6
>
> Cheers,
> Chris
>
>
>
> On 07/27/2013 03:12 AM, Sylvain Lebeau wrote:
>
> Hi thomas and Christoph
>
> i am struggling to make Softimage work in Fedora 18.  I remember seeing
> some errors in the install log too. But i dont have it underhands right now.
>
> here's the error i get when i try to launch XSI
> if any of you could help me out, it would be greatly appreciated.
>
> /usr/Softimage/Softimage_2014_SP2/Application/bin/XSI.bin: symbol lookup
> error: /usr/lib64/libXext.so.6: undefined symbol: _XGetRequest
>
> thanks!
>
> sly
>
>
>
> On 07/26/2013 04:25 AM, Thomas Volkmann wrote:
>
> Nope, I'm on Fedora19. I'm not a 100% sure if I get that problem with all
> Windowmanagers (KDE/Gnome/Fluxbox). I can check later.
>
> > Chris Chia  hat am 26. Juli 2013 um 10:14
> geschrieben:
> >
> >
> > Just curious, is everyone using just CentOS?
> >
> > From: softimage-boun...@listproc.autodesk.com [mailto:softimage-bounces@
> listproc.autodesk.com] On Behalf Of Raffaele Fragapane
> > Sent: Friday, July 26, 2013 6:51 AM
> > To: softimage@listproc.autodesk.com
> > Subject: Re: Soft 2014 in Linux is "always-on-top"?
> >
> > Hadn't noticed you guys referred specifically to 2014. Ignore my
> previous post, we don't use 2014 yet, only 12 and 13.
> >
> > On Thu, Jul 25, 2013 at 11:48 PM, Alan Fregtman  > wrote:
> > Yep, exact same symptoms... it doesn't register in the window manager at
> all. Not sure why, but I'm betting it's Mainwin. :(
> >
> >
> > On Thu, Jul 25, 2013 at 8:43 AM, Christoph Muetze  > wrote:
> > Hi,
> >
> > i can relate, i'm experiencing exactly the same problem :(
> >
> > Softimage 2014 ignores the windowmanager completely, when maximized it
> goes beyond the usual borders (almost like fullscreen), it doesn't show up
> in taskbar either and when minimized then it becomes a little icon-like
> square that is floating on top of every other application or window. Also
> it stays fixed to the screen, no matter what workspace i'm on. So switching
> spaces always drags Softimage with, no matter what you do...
> >
> > The same behaviour is true for the mainwin control app after the
> update... it's the usual suspect for this, i guess - but it is still
> noteworthy imho, especially since Softimage 2013 still behaves a 100%
> correctly on the same machine... (So do Mudbox 2014 and Maya 2014)..
> >
> > If any of the Developers is up for troubleshooting i'm more than willing
> to step in and help out as much as i can on my side... just drop me a line.
> >
> > Cheers,
> > Chris
> >
> >
> > On 07/09/2013 11:54 PM, Alan Fregtman wrote:
> > Hey guys,
> >
> > Anybody out there using Soft2014 with Linux have the problem that it sits
> > always-on-top of every other window?
> >
> > It's pretty annoying and I'm wondering if it's just me. We're on CentOS
> at
> > work.
> 

Re: softimage pass trick in houdini

[Gerbrand Nel]

Thanks.
They seem a bit above my IQ grade, but will give them a go :)
G
On 2017/09/13 10:59 AM, ralph.schoeneb...@t-online.de wrote:

Hi
You could a use scenewide stylesheet for that, should be quite fast to 
setup

(hope the jpg comes through)
Ralph


-- Originalnachricht --
Von: "Gerbrand Nel" 
An: softimage@listproc.autodesk.com
Gesendet: 13.09.2017 10:16:16
Betreff: softimage pass trick in houdini


Hey guys and girls.

Back when life was simple and softimage was still a thing in my life,
There was this thing called passes.

I know houdini has takes, and they are awesome, but There was this nifty
trick in soft where a new empty pass automatically had everything in
your scene grouped under a "background partition". This gave you the
ability to assign one material to everything in your scene. You could
then remove certain elements from that partition to isolate them for
render passes.

Can this be done in houdini without having to manually select everything
you want to overwrite?

My client has asked me to render out a matt of a single object in my
scene. I would like to make everything black, and this one thing white
without spending half a day

Thanks

G

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


---
This email has been checked for viruses by AVG.
http://www.avg.com


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



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

softimage pass trick in houdini

[Gerbrand Nel]

Hey guys and girls.

Back when life was simple and softimage was still a thing in my life, 
There was this thing called passes.

I know houdini has takes, and they are awesome, but There was this nifty 
trick in soft where a new empty pass automatically had everything in 
your scene grouped under a "background partition". This gave you the 
ability to assign one material to everything in your scene. You could 
then remove certain elements from that partition to isolate them for 
render passes.

Can this be done in houdini without having to manually select everything 
you want to overwrite?

My client has asked me to render out a matt of a single object in my 
scene. I would like to make everything black, and this one thing white 
without spending half a day

Thanks

G

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

Re: Soft 2014 in Linux is "always-on-top"?

[Thomas Volkmann]

It's a long time since I made a clean install on a linux system.
>From what I remember you have to put these libs into the Application/bin 
>folder:
https://www.dropbox.com/sh/ph864dr6c831s6h/AABMwRSBkIO5eSheJ6aTgyg8a?dl=0
 
These are libs from the last Fedora version that ran out of the box for me (14
or 16? I'm on 26 now). If these don't work for you, you might want to try
libs from centos6.
This should get SI up and running.
 
good luck,
Thomas
 

> Ahmed Barakat  hat am 12. September 2017 um
> 22:37 geschrieben:
> 
>  Hi Christoph
>  I know it's an ancient thread but I am trying to run Softimage on Centos 7
> got the same /usr/lib64/libXext.so.6: undefined symbol: _XGetRequest error and
> I followed your recommendation 
>  " Fortunately the solution to your problem is fairly simple:
> 
>  mv
> /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib-amd64_linux/X11/libX11.so.6
> /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib-amd64_linux/X11/~libX11.so.6"
>   
>  but unfortunately now I get this error
> "/usr/Softimage/Softimage_2015/Application/bin/XSI.bin: symbol lookup error:
> /usr/lib64/libX11.so.6: undefined symbol: xcb_wait_for_reply64"
>   
>  do you know what might be the problem I googled it with no luck
>   
>  Thanks 
> 
>  On Sat, Jul 27, 2013 at 1:52 AM, Christoph Muetze  mailto:c...@glarestudios.de > wrote:
>> > Hi Sylvain,
> > 
> >...i came across the same problem. Softimage seems to becoming more and
> > more fragile on the Linux side of things, an install becomes harder with
> > every release :/
> > 
> >Fortunately the solution to your problem is fairly simple:
> > 
> >mv
> > /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib-amd64_linux/X11/libX11.so.6
> > /usr/Softimage/Softimage_2014_SP2/Application/mainwin/mw/lib-amd64_linux/X11/~libX11.so.6
> > 
> >Cheers,
> >Chris
> > 
> > 
> > 
> >On 07/27/2013 03:12 AM, Sylvain Lebeau wrote:
> >  > > > Hi thomas and Christoph
> > > 
> > >  i am struggling to make Softimage work in Fedora 18.  I remember
> > > seeing some errors in the install log too. But i dont have it underhands
> > > right now.
> > > 
> > >  here's the error i get when i try to launch XSI
> > >  if any of you could help me out, it would be greatly appreciated.
> > > 
> > >  /usr/Softimage/Softimage_2014_SP2/Application/bin/XSI.bin: symbol
> > > lookup error: /usr/lib64/libXext.so.6: undefined symbol: _XGetRequest
> > > 
> > >  thanks!
> > > 
> > >  sly
> > > 
> > > 
> > > 
> > >  On 07/26/2013 04:25 AM, Thomas Volkmann wrote:
> > >> > > > Nope, I'm on Fedora19. I'm not a 100% sure if I get that
> > >> > > > problem with all Windowmanagers (KDE/Gnome/Fluxbox). I can
> > >> > > > check later.
> > > > 
> > > >> Chris Chia  > > >> mailto:chris.c...@autodesk.com > hat am 26. Juli 2013 um 10:14
> > > >> geschrieben:
> > > >>
> > > >>
> > > >> Just curious, is everyone using just CentOS?
> > > >>
> > > >> From: softimage-boun...@listproc.autodesk.com
> > > >> mailto:softimage-boun...@listproc.autodesk.com
> > > >> [mailto:softimage-boun...@listproc.autodesk.com
> > > >> mailto:softimage-boun...@listproc.autodesk.com ] On Behalf Of
> > > >> Raffaele Fragapane
> > > >> Sent: Friday, July 26, 2013 6:51 AM
> > > >> To: softimage@listproc.autodesk.com
> > > >> mailto:softimage@listproc.autodesk.com
> > > >> Subject: Re: Soft 2014 in Linux is "always-on-top"?
> > > >>
> > > >> Hadn't noticed you guys referred specifically to 2014. Ignore
> > > >> my previous post, we don't use 2014 yet, only 12 and 13.
> > > >>
> > > >> On Thu, Jul 25, 2013 at 11:48 PM, Alan Fregtman
> > > >>  > > >>  > > >> >> wrote:
> > > >> Yep, exact same symptoms... it doesn't register in the window
> > > >> manager at all. Not sure why, but I'm betting it's Mainwin. :(
> > > >>
> > > >>
> > > >> On Thu, Jul 25, 2013 at 8:43 AM, Christoph Muetze
> > > >>  > > >> > 
> > > > wrote:
> > > >> Hi,
> > > >>
> > > >> i can relate, i'm experiencing exactly the same problem :(
> > > >>
> > > >> Softimage 2014 ignores the windowmanager completely, when
> > > >> maximized it goes beyond the usual borders (almost like
> > > >> fullscreen), it doesn't show up in taskbar either and when
> > > >> minimized then it becomes a little icon-like square that is
> > > >> floating on top of every