Re: Thoughts on USD in comparison to Softimage 'Referenced Models'

[Steven Caron]

Thanks Matt for elaborating, your memory is so much better than mine. But
those were the 'issues unique to softimage' I was referring too.

The composition of layers, the resolving of those complex compositions, the
openess of the specification, and it's API makes highly inspectable and
customizable, which was what I was alluding to earlier, Johnathan. This
makes the biggest difference between what softimage provided with reference
models vs USD.

*written with my thumbs

On Fri, Aug 30, 2019, 4:48 PM Matt Lind  wrote:

> I worked at Omation too. While I didn't write O-Net or metascene, I sat in
> the same office as those who did and was part of discussions.
>
> As Steven said, metascene wasn't that similar to USD, but there were also
> two versions. Helge's version was the first version, but it was replaced by
> Adam and Mike when he left, and their version was much more developed. It
> was mostly designed to work around XSI's limitations with access to scene
> contents through the .scntoc as all the file formats were black boxes. The
> main problem we were bumping into was that 32 bit computers couldn't hold
> all the data we needed to load and render. We needed a system to offload
> contents selectively when it got to be too much. We also had significant
> problems with data corruption and needed a means to work with data reliably
> by having some form of control of it so it could be inspected and repaired
> if needed.
>
> Barnyard had a very deep revolving door of talent coming and going, and
> with that, a lot of inside knowledge of how things were done often
> disappeared without record because it was an ad-hoc production. and very
> little was documented. In my particular case, after I fixed the animation
> pipeline I assumed shader writing responsibilities, but my predecessor did
> not leave source code behind for many shaders, or documentation of which
> ones were deployed in production for situations when multiple versions of
> the code existed. So for me, metascene was a way to track down which scene
> files had gone through the pipeline using these rogue undocumented shaders
> that needed to be addressed when the shots got kicked back for
> re-rendering. Without a shader .dll, the artist cannot open the scene file.
> Without the source code to the shaders, I couldn't produce a shader .dll.
> That meant the entire shot would have to be rebuilt from scratch making
> management very unhappy. I spent many long nights reverse engineering these
> shots to figure out how to rewrite the shader code to match the results of
> shots that had already gone through the pipeline with the rogue shaders –
> and across two different platforms. Ugh.
>
> When artists created work at their workstation, they'd iterate all day
> long until they had something worthy of submission for approval. At that
> point they'd publish to O-Net (the system), and plugins on the back end
> would intercept the scene data and re-encode it into a list of files in a
> proprietary file format. Each hierarchy in the scene would become it's own
> file, pretty much like a model, but described in XML instead (or other
> format). the relations of these files would be recorded in a SQL database
> and other places so when they go onto the render farm they could be
> rendered and tracked. Once the system was fully fleshed out, front ends
> were made to automate tasks so scenes could be re-rendered if necessary, or
> fabricated entirely from the command line and submitted for rendering
> (mostly for rudimentary tasks like mattes). I cannot remember for sure, but
> I think later in the production all scenes were loaded from O-Net and not
> the scene file created from the previous save operation. This meant the
> scene was assembled from the re-encoded and tracked data, not the scene
> file. This helped limit corruptions and other issues.
>
> O-Net / Metascene was more a scene manipulation and analytics tool. But as
> stated above, Softimage's file formats were black boxes, so there were
> limits to what could be done. Not all assets could be successfully
> re-encoded and produce the same results. A lot of guess work was involved.
>
> USD is a specification of how to handle data and resolve disputes when
> collisions arise. It's not an analytical tool, but analytic tools can be
> written to work with USD files.
>
> Matt
>
>
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: OTish - Maya Camera Projection?

[Martin Yara]

In Maya you can create a Projection Node and put it in a Material. The
Texture will be projected to the objects using this material, but it won't
affect the UVs.
I don't know if there is anything like the Softimage UV projections.

Martin

On Thu, Aug 29, 2019 at 10:47 PM  wrote:

> Apologies for asking Maya related questions here, but Autocraps Forums are
> no help and you guys are the closest I get to a comprehensive likeminded
> hivemind with some Maya knowledge :)
>
> I am doing some modeling work based on reference photos in Maya currently,
> and in XSI I would just set up a camera, camera project the reference photo
> onto a rough model and work from there.
>
> Maya apparently has the ability to do camera projection based UV's (a new
> UV set, not rendertime projection), but it seems to sort of normalize the
> UV's making them useless for directly applying the reference photo as
> texture, and the documentation is bloody useless (as usual) since it
> doesn't provide any camera options information.
>
> Is there a trick to do this in Maya or is it just another of those
> gazillion annoying things that are soo much easier to do in XSI?
>
> Thanks Morten
>
> -- 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.

Re: Thoughts on USD in comparison to Softimage 'Referenced Models'

[Matt Lind]

I worked at Omation too.  While I didn't write O-Net or metascene, I sat in 
the same office as those who did and was part of discussions.

As Steven said, metascene wasn't that similar to USD, but there were also 
two versions.  Helge's version was the first version, but it was replaced by 
Adam and Mike when he left, and their version was much more developed.  It 
was mostly designed to work around XSI's limitations with access to scene 
contents through the .scntoc as all the file formats were black boxes.  The 
main problem we were bumping into was that 32 bit computers couldn't hold 
all the data we needed to load and render.  We needed a system to offload 
contents selectively when it got to be too much.  We also had significant 
problems with data corruption and needed a means to work with data reliably 
by having some form of control of it so it could be inspected and repaired 
if needed.

Barnyard had a very deep revolving door of talent coming and going, and with 
that, a lot of inside knowledge of how things were done often disappeared 
without record because it was an ad-hoc production. and very little was 
documented.  In my particular case, after I fixed the animation pipeline I 
assumed shader writing responsibilities, but my predecessor did not leave 
source code behind for many shaders, or documentation of which ones were 
deployed in production for situations when multiple versions of the code 
existed.  So for me, metascene was a way to track down which scene files had 
gone through the pipeline using these rogue undocumented shaders that needed 
to be addressed when the shots got kicked back for re-rendering.  Without a 
shader .dll, the artist cannot open the scene file.  Without the source code 
to the shaders, I couldn't produce a shader .dll.  That meant the entire 
shot would have to be rebuilt from scratch making management very unhappy. 
I spent many long nights reverse engineering these shots to figure out how 
to rewrite the shader code to match the results of shots that had already 
gone through the pipeline with the rogue shaders - and across two different 
platforms.  Ugh.

When artists created work at their workstation, they'd iterate all day long 
until they had something worthy of submission for approval.  At that point 
they'd publish to O-Net (the system), and plugins on the back end would 
intercept the scene data and re-encode it into a list of files in a 
proprietary file format.  Each hierarchy in the scene would become it's own 
file, pretty much like a model, but described in XML instead (or other 
format).  the relations of these files would be recorded in a SQL database 
and other places so when they go onto the render farm they could be rendered 
and tracked.  Once the system was fully fleshed out, front ends were made to 
automate tasks so scenes could be re-rendered if necessary, or fabricated 
entirely from the command line and submitted for rendering (mostly for 
rudimentary tasks like mattes).  I cannot remember for sure, but I think 
later in the production all scenes were loaded from O-Net and not the scene 
file created from the previous save operation.  This meant the scene was 
assembled from the re-encoded and tracked data, not the scene file.  This 
helped limit corruptions and other issues.

O-Net / Metascene was more a scene manipulation and analytics tool.  But as 
stated above, Softimage's file formats were black boxes, so there were 
limits to what could be done.  Not all assets could be successfully 
re-encoded and produce the same results.  A lot of guess work was involved.

USD is a specification of how to handle data and resolve disputes when 
collisions arise.  It's not an analytical tool, but analytic tools can be 
written to work with USD files.

Matt





Date: Thu, 22 Aug 2019 08:41:32 -0700
From: Steven Caron 
Subject: Re: Thoughts on USD in comparison to Softimage 'Referenced Models'
To: softimage@listproc.autodesk.com

It would be purely speculative to comment about Animal Logic's pipeline. So 
I won't.

I can see what your saying about people using Softimage probably appreciate 
something like USD more than users of other packages but the desire to work 
this way has been around for a while. We have had slice of this with 
Softimage a lot longer than most, we also had better render passes then 
everyone else for probably a decade. Maybe links are being made but just not 
as deep as you think. People have wanted something like USD for many years, 
I think you see people embracing it because they needed it so bad.

I did work at Omation, I honestly am a little fuzzy about the details but I 
used (and tested) Helge, Adam, and Mike's work on 'metascene'. But it wasn't 
that similar to USD and it kinda solved some issues which were unique to 
Softimage at the time. Which then Helge went to work at Avid and helped 
address with the 6.0 referencing rewrite. 


--
Softimage Mailing List.
To unsubscribe, send a mail to 

Re: Thoughts on USD in comparison to Softimage 'Referenced Models'

[Matt Lind]

Models are not really comparable to USD.  Models are more similar to 
Houdini's concept of Digital Asset than a scene.

The purpose of a model was to be a container for an asset so it could be 
more easily included in large scenes and independently manipulated with 
regards to versioning and level of detail control.  The main message of 
'Sumatra' and DS was that artists were to be removed from the burden of low 
level manipulation, such as setting key frames, and able to focus more on 
higher levels of control such as choreography via animation mixing.

XSI Models are derived from the "hierarchy" (.hrc) from predecessor 
Softimage|3D.  One could argue the Model is a superset of the .hrc as the 
main difference is the addition of the animation mixer (independent 
timeline).  The .hrc had level of detail control and other mechanisms, but 
they were rarely used due to lack of tools to do it in a practical manner by 
the end user.  The Softimage|3D implementation required a lot of digging 
through menus and strong self-discipline in organization of files.  For some 
operations, one had to jump out to the command line and use DbTools - a 
proprietary environment for running shell scripts developed by Softimage.

Softimage|3D had an ASCII text scene file format which related multiple 
files, this was closer to the concept of USD.  The main file was the Scene 
Description (.dsc) which contained all the high level information of what 
elements were in the scene and how they were related.  This included 
relations such as parent/child, master/slave relation of constraints, light 
and model associations, groupings, custom effects and their parameter 
settings, asset LOD, and the list goes on.  It even includes position of 
nodes as represented in the schematic view,  The Scene Description was 
accompanied by the Scene Setup file (.sts) which contained description of 
the user's environment such as how the viewports were arranged, current 
settings, render parameters, etc.  All the other files pointed by the Scene 
Description and Scene Setup were binary files and contained the actual 
content (cameras, lights, models (hierarchies), materials, animation, ...). 
This meant a scene was a conglomerate of many files - handy for versioning 
and substitutions, but took forever to load/save when the database started 
to fill up.  A single scene could consist of thousands of files, and each 
file would have to be checked individually for version collision, and sync 
with the other assets in the database.  If scene save operation was 
interrupted (e.g. crash), you had many orphaned files floating around in 
your database creating all sorts of havoc.  Since the default number of 
versions kept was 4, and all hard drives of the day were disc drives with 
small caches and slow spin rates and 10 Mbps ethernet (if lucky), it took 
forever to get work done.  That was a strong motivation behind XSI using a 
single file for it's scene file format, and the .scntoc to mimic (to a much 
lesser degree) the Scene Description.  Ironically, Alias|Wavefront did the 
exact opposite as Power Animator used a single file scene format, but 
migrated to the Softimage|3D style with Maya.

USD is more robust in that it's a rule based language to do the work of 
assembly and has some amount of intelligence to handle collisions and other 
problems.  XSI models had limited ability to do that in the delta, but it 
was self contained.  XSI Scenes had some back door exceptions to the rule to 
accommodate models in certain situations, but otherwise were passive and not 
available to the user to manipulate.  The Softimage|3D scene description 
language was more primitive than USD in that it was more like a passive list 
of commands to execute than a language with decision making intelligence. 
Although error checking existed, it was largely assumed the contents of the 
file were ordered and compliant.  If a model was listed twice, for example, 
the parser would not catch it and made every effort to import the model and 
establish all the relations.  It would be left to the other operations 
downstream to catch the problem and report it.

USD isn't rocket science, but it serves a very important role that's been 
long needed.

Matt



Date: Tue, 27 Aug 2019 10:13:05 +0100
From: Jordi Bares 
Subject: Re: Thoughts on USD in comparison to Softimage 'Referenced Models'
To: "Official Softimage Users Mailing List.

I guess the concepts are rooted in our reality and therefore it is only 
natural the approaches are not that dissimilar, but it is fun to realise 
Softimage Models were so advanced at the time as to be compared and all to 
USD.

IMHO USD is a major leap forward and models and references are a minor 
attribute as the real meat is the whole versioning in combination with 
layering which somehow makes me thing of XML document conversions for the 
web and data mining but I digress..

USD is a framework and the scope is enormous, to the point that you don?t 

RE: Friday Flashback #384

[Sven Constable]

I don’t think it was a quirk but intendend. :) Even that feature likely felt 
illogical at first, it's intriguing how much thought went into the tiniest bits 
of the GUI.
Btw it was the only feature where a "before-state" was displayed, I think.

Workwise it made sense because switching to a viewmode like Shaded or Textured 
would took some time. Knowing to which viewmode you'll switch was surely an 
advantage.

Besides this, its kinda obvious which viewmodeis currently used because the 
viewport is displaying it already. Therefore, having a label that indicates to 
which viewmode you will switch is more useful. Otherwise it would be redundant 
information. 

I work that way even today (middle click to switch modes) and to be honest I 
would prefer the old way telling me to which viewmode I'll switch. Rather than 
in which viewmode I am currently in.

 

Sven

 

 

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Matt Lind
Sent: Friday, August 30, 2019 11:32 PM
To: softimage@listproc.autodesk.com
Subject: RE: Friday Flashback #384

 

I just fired up my copy of SI3D and can confirm. The viewport title bar shows 
the shading mode that will be activated when clicked, not the current shade 
mode.

SI3D had a lot of those quirks.

Matt

Date: Fri, 30 Aug 2019 14:32:11 +0200 From: “Sven Constable” 
 Subject: RE: Friday Flashback #384 To: "'Official 
Softimage Users Mailing List.

IIRC it was always that way in SI3D and in a few versions of XSI too. 
Indicating which view mode was used before the current mode, so when you middle 
click to switch it will revert to that view mode. Actually quite handy.

Sven

-- 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.

Re: render tree mixer/texture limit

[Matt Lind]

I believe mental ray has a limit of 64 textures per triangle, not per 
object.  However, since XSI only allows one material per triangle (not to be 
confused with material shader), the limit is effectively 64 textures per 
material.  That is described in the mental ray manual in the early sections, 
but I'm too lazy to look it up right now.  I wouldn't be surprised if other 
renderers have the same limit as it's a common choice.

A good test would be to apply a default material to the object (without 
textures).  Next, create two polygon clusters and apply unique materials to 
each cluster, each with 64 textures.  None of the textures used by the first 
cluster material should be used any the second cluster material, and vice 
versa.  If it renders successfully, it means the texture limit is per 
triangle (per material).  If it fails, it means there's likely a bug in the 
XSI to mental ray translator and you should file a bug report to 
supp...@softimage.com.

Matt


Date: Thu, 29 Aug 2019 23:17:40 -0400
From: Kris Rivel 
Subject: render tree mixer/texture limit
To: softimage@listproc.autodesk.com

Hey all…been ages but still here! Weird question but anyone know if the 
render tree has a max limit on the number of nodes, 8mixers or textures it 
can load beyond any memory issue…just physical “number” limit? I have about 
65+ texture nodes plugged into a stack of mixers and all was working 
fantastic but I noticed some are missing and only show up in render if I 
unplug a few. So I'm thinking that I've hit some sort of ceiling. I have no 
memory issues at all, they're just not there and mysteriously show up if I 
cut some out. If there is a limit, anyway to bypass it?

Kris


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

RE: Friday Flashback #384

[Matt Lind]

I just fired up my copy of SI3D and can confirm.  The viewport title bar 
shows the shading mode that will be activated when clicked, not the current 
shade mode.

SI3D had a lot of those quirks.

Matt




Date: Fri, 30 Aug 2019 14:32:11 +0200
From: “Sven Constable” 
Subject: RE: Friday Flashback #384
To: "'Official Softimage Users Mailing List.

IIRC it was always that way in SI3D and in a few versions of XSI too. 
Indicating which view mode was used before the current mode, so when you 
middle click to switch it will revert to that view mode. Actually quite 
handy.

Sven


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

RE: render tree mixer/texture limit

[Sven Constable]

I did some tests and it seems to me that there is a limitation regarding the
maximum amount of texture sets per object which is 64 apparently. More than
64 image clips per objects seemed to be ok as well as a lot of mix8color
nodes (I had  ten of them and 72 image clips on that object). As soon as I
hit the 65th texture set, it rendered incorrectly.

 

Not sure if there is a workaround except splitting it in several objects.

 

Sven

 

Heres the scene if someone likes to play with it. 

 

https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNcheFfpiVb5gBjGpm0Nj5Q4I7hVw843xtQ23aUjuGbpkshpjEl1Iv1pzPIKHGeZG2cGS22RrZ8fhB1hSVxngOZkoXIDmqnFloIDPbbt6Xfob594kax1Qmc4htJMRDcofypRLdQ7P69yWQMkrlu5xpyX5Xds4MiCMi5dVPd3AHEBubeU1ghVdUybKMfU9MxJqv9ZeaLwmEbepwwW5cq-2FytX-2BSBMISCsXLEcyjkOKUeyBmo4AGecVmbcIjuxAEAopszKnvVWn8RGsZXvsWqpQmNyrDwnPBhKiabKQ0wqXU4rMlxhO0ZSWY4DDRpXfmCANlkTGxz5TQTAVE7MFDFXHAcnarZxBXzqls2l4p-2FG6LtJouqM-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuQumCj8OZwlT-2FF1neYPjuah3gCDOQ3DTT-2B4pWDfEkPkGYKI3tGO2jlBcSHprqZWItgESNTF-2FQAjd2tgqIkpWKp2PqCRmrvp8DCZdpSsyFzzBd2A79rfK-2FBcTIMAVGHLKrv0ehopJoHj5hbx9YYrNOH1JVLKLTwbRRTcB3sHqdxydVcIkawHyyvcY2O0BS2E4KI-3D
 

 

 

From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Kris Rivel
Sent: Friday, August 30, 2019 5:19 AM
To: Softimage List
Subject: render tree mixer/texture limit

 

Hey all...been ages but still here! Weird question but anyone know if the
render tree has a max limit on the number of nodes, 8mixers or textures it
can load beyond any memory issue...just physical "number" limit? I have
about 65+ texture nodes plugged into a stack of mixers and all was working
fantastic but I noticed some are missing and only show up in render if I
unplug a few. So I'm thinking that I've hit some sort of ceiling. I have no
memory issues at all, they're just not there and mysteriously show up if I
cut some out. If there is a limit, anyway to bypass it?

 

Kris

 
 

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

RE: Friday Flashback #384

[Sven Constable]

IIRC it was always that way in SI3D and in a few versions of XSI too.
Indicating which view mode was used before the current mode, so when you
middle click to switch it will revert to that view mode. Actually quite
handy.

 

Sven

 

From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Stephen Blair
Sent: Friday, August 30, 2019 2:06 PM
To: Official Softimage Users Mailing List.
https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchiLG9o7ECJDJ0Mw-2FRzSlfldhFWvv2G7M9xrogMv-2BiUgrG-2BmCVAfC2HxBWG0Czpbw8UUe9Xkbh68Twjp-2FiA-2FSErOz3lccvrWE7C7snOO94pqmTkDnU09wuG-2FkEm7HJQnrZzQY-2B53gQmbgC-2FF9m19y4wNQ520J-2FWrQM4tGWKNMloZtluITcEwX3yKg8ukanaldxje39eDORBRlex-2FNW0Q3mD-2FqoEmPLbKG-2Ban3APidQ-2FcJrwXsRSzALnX7-2BQ0IW82qlSfBG9Tfeak-2BmAAt5aPyxahEqT8rEXW1cFugSie2hDhy0K633d3dwbo8tKIHviiO3chzE9jnpMqQI-2FL-2FRk3Pa4g-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuRcZr2RyZOlp5DepHNrrdnI9fNzoGy4uJzgW2q8jeozCit5lnNeyqIbInvrRQQWNWziufbWGsFdPBPIXyemMCAZaG94-2BTYa6SiBYXkbx1wXKPMm3EzkMCK79d3jitIa4zBlmsEsQX90caDGNtPo812c-2FnQIvYTxBLAseTueJKkJOkZ-2Fkr79z5wWQp-2FIUxgzA-2BU-3D
 
Subject: Friday Flashback #384

 

https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchE18B7lYLnvRU16qf6Hf-2B5tXhllou-2BhB9HJ580Y-2Fq-2BR0DNUMRi0bRMY-2BcJLk7fnF4GJC7lYmzya9kM2DDaHH0zeqCJw7RBPuJFREElFS-2BGnIRmolo-2B9y1HZNKAy7WHuRVUonSmoDKZXOLFXUi2DuunUPMmlhXcimxvG2-2Bw9F8tzSvQUextWKZZ6cAY6oEdKKL36whq4D9lpklhk2q-2BaLXUWqrkgvmH-2Bxs6SEUnQKojCi7-2FFUwwEGC7-2BLHIrOhCpVEoyDXOc5TSWZ2JztE-2FtFpuWa-2BBx5PD60ezAgnVi9nvn5L3DCVxYDthm9jt7kBubEK_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuRcZr2RyZOlp5DepHNrrdnI9fNzoGy4uJzgW2q8jeozCqtnUOsHKKPy-2F-2Bkek1nelKik3gudGxSMacoXlkc-2FCTK3pvbkGvmvjjeZf-2FOws-2Bg0naJK0QXcoNp-2B3Yq1lCs32y514-2BG1me2ZHedFZYbXxgRUIOIJWk6c0d9WwDCUOr8caekcu8JKRW1rYZUaOCTYs18-3D
 

 

SOFTIMAGE|3D screenshot

Is it just me, or are the view mode labels reversed? The Perspective
viewport title bar says "WIRE" but it's showing SHADE, right?

 
 

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

Friday Flashback #384

[Stephen Blair]

https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchE18B7lYLnvRU16qf6Hf-2B5tXhllou-2BhB9HJ580Y-2Fq-2BR08HAZe4zwyQ3d4xriutR40DCHrQezhloxWi6nfBzmBokU0C2q6Ou9VP07-2Fdg80MGzkheT3ybKBsE-2BJqb0cAaLh5mDinrTnvgrTmqfUd-2FKjtgtEAHomADk3DZNdRWVIENY303QWP5xNDGDrSuu0O8BwPtLmTrJsrB7stXX1vNk2uxwLwpgs-2FycmiLzhKaLWxb8OlNr-2B4MHhFRc6R-2F-2BmGqUvJ5sYqNVdAsCWfKek8BYpWcKyQB-2FeIBgkTB4kfdbSgpERqb-2Bn5A03kO-2B6nXDGpTRH_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuSabBmUrrsy8xUKBTWB3oiLZkLeWhtgKXw4SjvWnbw1oMQqFI9zDHLfCY-2FKMHXYlg5hGwyX4VIjxdKF2nWbkLusJsjX3n2e6vc-2B53Tc6WWb24MZCLO4f36dsQE05NFgQPR8qCUZq47XuFvt0tta5Iys8pUgquGJPBvmdhMvhETCUarMbAP8r4q30CPhz4qPDQY-3D
 

SOFTIMAGE|3D screenshot
Is it just me, or are the view mode labels reversed? The Perspective
viewport title bar says "WIRE" but it's showing SHADE, right?
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.