What really puzzles me is this.
Newly created shaders all live in the TransientObjectContainer, which
I believe to be some sort of XSI clipboard.
Now, if you create the shader by scripting, it remains in the TOC as
long as the XSI session lives. On the other hand, if the shader is
created in the Render Tree (through the interactive menus), it is also
put in the TOC, but vanishes as soon as you close the Render Tree.
Closing the Render Tree on such a created shader prints this message:
Application.DeleteObj("TransientObjectContainer.Image")
Here is a little script to demonstrate this behavior:
import win32com
xsi = Application
xsifactory = win32com.client.Dispatch( 'XSI.Factory' )
def enumTOC():
oColl = xsifactory.createobject( 'XSI.Collection' )
oColl.items = 'TransientObjectContainer.*'
xsi.logmessage( oColl.count )
for oTOCObject in oColl:
xsi.logmessage( oTOCObject.fullname )
xsi.logmessage( '---------------------------------------------' )
xsi.newscene( None, False )
# Create sphere and material
oSphere = xsi.activesceneroot.addgeometry( 'Sphere', 'MeshSurface', 'mySphere' )
oMat = oSphere.addmaterial( 'Lambert', False, 'myLambert' )
oAmbient = oMat.surface.source.parameters( 'ambient' )
enumTOC()
# Create image and color_share shaders, only the Image will be used
oImage = xsi.createobjectfrompreset( r'Shaders\Texture\Image.Preset' )
oCShare = xsi.createobjectfrompreset(
r'Shaders\Texture\Share\Color_share.Preset' )
enumTOC()
# Connect the image shader
oAmbient.connect( oImage )
enumTOC()
# Disconnect the material
oAmbient.disconnect()
enumTOC()
You should get this output:
Application.NewScene("", 0)
#INFO : 0
#INFO : ---------------------------------------------
Application.CreateObjectFromPreset("Shaders\\Texture\\Image.Preset", "")
Application.CreateObjectFromPreset("Shaders\\Texture\\Share\\Color_share.Preset",
"")
#INFO : 2
#INFO : TransientObjectContainer.Image
#INFO : TransientObjectContainer.Color_share
#INFO : ---------------------------------------------
#INFO : 1
#INFO : TransientObjectContainer.Color_share
#INFO : ---------------------------------------------
#INFO : 2
#INFO : TransientObjectContainer.Color_share
#INFO : TransientObjectContainer.noIcon_pic
#INFO : ---------------------------------------------
You can see at the end the Image shader has been destroyed, but now
the ImageClip is in the TOC! At all times the color_share remains.
Why is the Render Tree shader wiped of the TOC?
- fabulations ahead -
I suspect this has to do with some namespace issue. I believe that a
caracteristic of a material is that it has its own namespace. The
Render Tree, when opened on a material, is exposing the names in that
namespace. When you create a shader, its name is shared between the
TOC and the material namespace. When you close the Render Tree, I
would assume the shader is destroyed because there is no way to
remember in what material namespace the shader was originally
instantiated.
Then, could the solution be to have materials implement their own TOC,
where shaders could live for the time they are disconnected?
But then, what would happen with shaders shared accross several
materials? Granted, the GUI doesn't allow this, but we can connect
shaders into different materials via scripting. The shader name would
no longer be exclusive to a material namespace, but if we disonnect it
from one material, what happens...? Interesting.....
My two cents
Bernard
On 6/14/06, Andy Jones <andy(at)thefront.com> wrote:
Keeping dead nodes in the rendertree is sort of a separate topic, since
it's totally an interface issue. On the one hand, it'd be nice to never
lose a tree I made and accidentally left unconnected, but on the other
hand, 90% of the time, I actually don't need the nodes anymore. Maybe
what I'd like to see happen is for dangling nodes to be global to the
rendertree view, and not get wiped whenever I close the window or change
materials. So, the rendertree view would double as a sort of clipboard,
not unlike the FXTree. A similar feature I'd like to see even more is a
shader node macro/phenomenon engine that would allow shader fragments to
be saved and reused on the fly, and referenced into existing trees.
This sort of thing could also work nicely with node preview. Node
preview could also function as a simple short-circuit for surface,
whereby the material would have an implicit connection to whichever node
is being previewed, and in a previewing context, that input would be
rendered instead of the actual surface input.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
