Re: Impressions of XSI6 after using it for 1 month

Date : Tue, 06 Feb 2007 16:05:58 +0100
To : XSI(at)Softimage.COM
From : André Adam <a_adam(at)49games.de>
Subject : Re: Impressions of XSI6 after using it for 1 month
I really haven't read this list to the end, but my first impression is that you try to map Max concepts into XSI, which is natural when coming from a Max background, but will not get you to speed with XSI nor let you experience its beauty.

   -André


Fred Jacob wrote:
The followoing is a list of things that I've been running into while testing XSI6 for approximately a month now. I'm mainly coming from a 3dsMax background and work as a technical artists for a games company, although I'm doing some rendering and animation in my spare time too. Most of the things listed herein currently represents features I desperately miss or a direct problem I encountered while trying to come up with a workflow geared towards game asset creation (mainly character modeling, textzuring,animation and texture baking (rendermapping)). Some things are probably trivial to work around, some others might stem from misinterpretation or -use of a tool. Also please bear with me if some issues listed in the following are already known, I haven't read every thread in this forum from the last two months.


===Things I really miss===


Something similar to 3dsMax's Autogrid feature - The ability to create objects on Grids or other objects interactively by clicking and dragging.

A means to edit polygon or vertex normals. I know there is an SDK-example that can be installed manually but I wonder why this has never been part of the standard installation - this is still an important feature for game development.

I'm missing a render region option to only render objects that are really visible in the viewport.
Currently objects that are invisible due to some other object(s) being isolated
are still being rendered, which can make rendering regions in isolated viewports quite confusing.


Functionality to paint the strength of the effect a transform operation has on objects/components - paint selection only selects vertices 100%, the distance limit effect in the "Proportional" options cannot be painted per vertex either and is based on distance to current selection only.

It would be nice if the current proportional values per vertex could be converted to a weight map automatically when assigning a new operator. The resulting weight map could control the effect of the newly assigned operator where appropriate. resulting functionality would be similar to Max's "Soft Selections" that control the effect of transforms and modifiers alike.

UV Editing

Proportional Modeling settings are taken into account when manipulating UV's, which is really cool, but:

Proportional falloff is displayed in 3D-Views but not in the UV Editor, I usually need to adjust and test several
times before I find the right settings for a particular operation.
Useful Proportional distance limit values for UV's (usually in the range of 0 - 1) are hard to set using the slider, even when shift-sliding. I constantly dial the values in manually, which is quite inefficient. A (or several) button(s) near the slider to switch its value range down to a different set (e.g. 0-1, 1-5, 5-20 etc) would be very useful, even for modelling, not only texturing.
Alternatively, a seperate section with dedicated falloff and distance limit controls for UV's might work equally well, although it would not be equally elegant.

Symmetry Mode seems to be ignored in UV-Editor, there is no way to work with UV's symmetrically. (The Texture Editors Pivot could be used as a symmetry axis)

Moving UV'S does not respect Proportional "Consider Neighbourhood" settings.

Stamp UV-Mesh function only works when a clip is displayed in the Texture Editor.
It is not possible to set the resolution of the stamped mesh image to something different than the currently referenced clip in the editor.
This forces me to assign dummy textures of desired resolution temporarily (I have a whole library of these with different sizes on my hard drive by now) just to be able to define the resulting stamp mesh image resolution somehow. The stamp line color cannot be overridden either, the editors line color is always used. -> Overall poor "Stamp UV Mesh" workflow.


When rendermapping the rendered map is not shown while rendering. This would be very useful for early termination and testing rendermap settings.
Alternatively being able to draw a render region in the Texture editor do preview parts of a rendermap would be ultra-convenient!

A switch to specify whether the rendermapper uses the closer of the further away ray hit (in case there were two hits) when using bidirectional tracing would be useful.

More channels to display in the render region tool (Normals, irradiance,  reflection, refraction, motion etc)


Transforms:

It is possible to rotate and translate about a reference object, but not to scale (Ref greyed out) ?

Using the ALT key to set temporary pivots is cool, but can it only be used interactively?
When I try to use the transform input field to enter exact values for e.g. rotation around the temp pivot it seems to use the real pivot for the rotation,
not the temporary one I've just set.

When a reference object is picked as reference coordinate system, newly created objects still appear in the world origin and not in the reference coordinate systems origin.

XSI Installer does not support spaces in the install path? This way XSI cannot be installed in the Windows default "C:\Program Files" path. Ouch!

===Inconsistencies and misleading stuff===

The Render Tree is very powerful, but how can I assign a selected material in the Render Tree directly to an object? Drag'nDrop or using Get->Material->Assign Material does not work nor is there an entry in the right-click context menu over the material either. Not very intuitive, one would expect that a material selected in the Render Tree can be assigned to an
object somehow without having to use the explorer.


The Constant color node is not included in the Nodes menu in Render Tree, it must be loaded from disk manually every time.

Several menus, especially those in the render Tree and Get->Shader, ->Texture and ->Clip, cannot be torn off.
	
Get->Material->Assign is misleading and should be rephrased to "Aquire" or something of similar meaning, since the material is actually referenced (aquired) by an object from another object or cluster which has the desired material already assigned.  This would also make much more sense in the "Get->Material" context.

When Get->Material->Assign is used and the object to aquire the material from is picked in the viewport only the top-level material is referenced, even if the user clicked on an area of the object that belongs to a cluster with a different material assigned. To make things more straight forward and user friendly the material could be aquired from the actual cluster upon which was clicked, or a pop-up window could list all materials assigned to the object and its clusters to choose from right after being clicked.

UI:

The left side Panel has icons to switch between Main Toolbar, Weight Paint Panel and Palette Toolbar, right side panel has Tabs to switch between MCP, KP/L and MAT respectively. Could this be unified (Tabs or icons everywhere)? Personally I prefer the Tabs. They look cleaner, and the Palette Icon seems to suffer heavily from Jpeg artifacts.

>From what I've gathered in the SDK documentation plugins register their widgets and (pull down-) menu entries using some plugin registrar. Does this mean that the actual menu layout is thus not defined and stored in a centralized way but is rather defined throughout hundreds of scripted and compiled plugins?

One of the strongest features of UI customisation in Max is that even pull down menus can be freely configured through a drag and drop interface, and new menus
can be created through this system too without having to code a single line of script or C++. I haven't found similar functionality in XSI yet, am I overlooking something?

The CDK and Guide/Rig system uses Sping constraints to create tails and ears and other wobbly stuff, but this constraint is not exposed through the UI
or even documented in the SDK help files. I had to dig the script command and arguments up from the CDK scripts. Although incredibly useful, most people probably not even aware of it's existence (there was a thread in this forum about this very topic some weeks ago though).



Weight Painting:

Several brush property widgets are missing from the weight paint tool panel like hardness, softness, etc.
Alternatively a shortcut to open the Brush Properties panel would be convenient so one does not always have to open and navigate through the Explorer to find them in Application-Data-Brush Properties.


Changing Deformer Weight values in the Weight Paint Panel directly assigns the changed weight to the selected vertices in the envelope, but the slider is very small making it hard to dial in exact values. Exact values can be typed in manually, but they are also directly applied when changed. While this sounds cool this is often slowing workflow down because more often than none the dialed in value turns out to be non-ideal (skin weighting is a highly iterative process), so it would be better to always work with very small values and incrementally add them to selected vertices. To do this with the current Edit Tools one constantly has to deselect all vertices, change the Deformer Weight value, then select some vertices and shift-click on the slider (something that took me 2 hours to figure out by accident) to assign that small weight change.
This resembles very closely the way skin weights can be applied in 3dsMax, but a dedicated button to assign the weight rather than having to shift-click the slider would be more obvious, especially for new users. In this context it would also make more sense to have the
Deformer Weight slider change not directly result in changed vertex weights but rather pressing the Add, Add% or Abs buttons should have this effect instead of them being mere modal buttons.




======Bugs and Flaws========

Problems with Rig Guides:

Foot and arm positions of Rig Guides are not saved properly from one session to another.
-> Creating a guide, adjusting it, saving the scene and reopening it will result in arm
and leg positions different than at the time it was saved, they seem to "snap" back to some default position, unless their control objects positions was set to neutral before saving.
Control objects can also snap back when the Model root Null is accidentally.

It seems not possible to FK-animate a Biped leg in a useful way. The FK/IK slider of the thigh-bone can be adjusted so FK animation is theoretically possible, but the foot controls for roll and IK placement won't follow, making it useless for production.

When creating quadruped rigs from guides the shadow rig neck objects are parented under the resulting rig model and not the shadow rig model.

When creating a rig from guide (biped or quadruped) with skeleton head the Head Spine Divisions value can be set, but the value is ignored when the rig's neck is created. This seems to be properly evaluated for quaternion spine necks only.
If this is by design it might be worth greying out the slider. An enabled slider that has no effect is misleading.

Typo: Limbs Tab, Symmetrical Manipulation of Arms Section, First option reads:
	"Symmetical..." instead of "Symmetrical...".



Selecting:

Sometimes objects with clusters that carry their own material cannot be selected anymore when clicking on a polygon being a member of such a cluster in shaded mode. Object can only be seleted on those polys not being a member of the clusters, or sometimes nowhere at all. In wireframe mode it can still be selected, this only happens in shaded mode. Sometimes deleting the Material from the object removes the problem, sometimes deleting the cluster does. This seems to happen more often with objects that are a result from a merge operation of formerly idependent objects and whose clusters were automatically generated in the merge process.

Parameters in a key set cannot be shift-selected for fast selection of multiple parameters in the explorer.

When ray-cast selecting vertices on a very dense mesh by moving the pointer first over an area on the screen that is not occupied by the object, and then over the rim and into the object (e.g. diagonally moving the pointer over the viewport that is half occupied by a very dense polygonal sphere) the resulting selected vertices do not reflect the path the cursor was moved
along by the user but rather looks as if rectangle select was used instead -> The wrong vertices get selected.


UI-Flaws:

XSI does not remember last window position and size, it always tries to accupie as much space as possible.
I have to reposition and resize the application window everytime I start it, which is especially annyoing with multi-monitor setups.

Pressing the Play button in time controls with a Wacom Pen starts playback all right, but pressing again to stop playback does not work sometimes - the
mouse must be used instead. I've never seen such behaviour in any other application. This seems to be dependant on CPU-load (e.g this happens more easily when doing cloth-simulations in XSI)

When XSI autosaves, pressing S (or while pressing S) to orbit, XSI will be stuck in Orbit mode. No other tool can be activated. The only way to get out is to activate Orbit again. This seems to be happening more often when the CPU(s) are under heavy load.


Rendering:

When changing Final Gather primary or secondary bounce color, Render Region updates, but does not reflect the chosen color tint as expected. Instead it still uses the old color. A different mental ray parameter needs to be changed as well (e.g. Reflection Trace Depth) to update render region properly and make the color change visible.

So far I never managed to properly rendermap more complex objects. I always end up with black splotches on the texture even in seemingly trivial
areas that are neither concave nor obstructed by other parts of the mesh. I followed all the tutorials and help files I could get hold of and tweaked the hell out of any setting I could find in both the render and rendermap settings to no avail. I've rendermapped stuff in other applications with no bigger problems and I think I understand the concept of "rendermapping" in general, but I can't think of anything that would create these artefacts in XSI other than something is not quite working properly. Also the very same setup using the very same textures and objects in Max produces flawless rendermapped textures.

The "Ignore Rendermapped Objects" switch seems to be ignored sometimes, the rendermapped objects still shows up in the rendermapped texture after rendering, even when the flag is set, which usually looks wrong. The only workaround is to make the rendermapped object transparent :-(

Render Region options can be set to "Use current pass Options" but when changing the Current Pass "Pass Mental Ray" settings these changes are ignored in the render region.
Similarly, when setting the Region Renderer to "Use Scene Render Options" and changing the scene renderer (e.g. from Mental Ray to Hardware Renderer)
the Render Reggion does not update.


Import/Export:

DirectX exporter seems unstable, it crashes frequently when exporting.

The .XSI importer in XSI (or .XSI-exporter for 3dsMax) sometimes has problems importing/exporting correct transforms of biped bones.
I tried with a simple scene (a dog mesh enveloped to a standard Character Studio Biped rig) and some bones ended up with different orientation in XSI compared to the original orientation in 3dsMax. The animation still seemed correct, but always relative to this initial offset, which results in strangely deformed envelopes over the whole range of the animation.




===============================================================================

In conclusion I can say that I really like XSI a lot. It seems fast, responsive, well integrated and thought out.
Things that feel below the overall quality level are the Guide/Rig system (although a nice initiative to get peoople up and running quickly) and rendermapping tools and workflow.


Things I'd like to see integrated: CAT, a node-driven Particle system (like Max's Thinking Particles or Particle Flow) and Vray
(Rendering accurate and flicker free GI in Mental ray is still a pita and usually imposes massive render times compared to Vray).


--- Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body: unsubscribe xsi


Search the XSI List archives here or use the advanced search form to search across mailing lists. Searching help is available.
This site supposedly brought to you by Benjamin Grosser and the Imaging Technology Group.