Getting the objects to which a material was assigned in siOnEndCommand

[Nicolas Burtnyk]

Hi list people!

For my custom renderer, I'm trying to keep track of when materials get assigned to objects.

This is part of an overall system which tracks changes to the scene so that I can incrementally process only the parts of the scene that change between renders.

Since there is no specific event that gets fired when a material is assigned to an object (that I know of - please correct me if I'm wrong!), I'm trying to use siOnEndCommand to catch the AssignMaterial command.  By the way Softimage devs: please add a OnMaterialAssigned event :)

I have 1 question and 1 issue:

Question: Can material assignment happen without this command being run?  In other words, is catching this command sufficient for monitoring all the ways that a material can be assigned to an object?  I'm not very experienced with using Softimage, but I know that in Maya there are a million and one ways to assign materials.

Issue: While I'm correctly receiving the ApplyMaterial command in the siOnEndCommand callback, I'm having trouble deciphering the command arguments.

Basically I want to know the Material that was assigned and the Object(s) it was assigned to.  Simple, right?

In the siOnEndCommand callback, I get the "Command" attribute from the context and create a Command object from it.  I then retreive the arguments using Command::GetArguments().  The ArgumentArray always has a count of 2 (whether I assign the material to 1 or more objects).

The second argument (ActionWhenLocalMaterialsOverlap) is irrelevant to me.  The first argument is a CValueArray that has a CRef for the Material being assigned as its first element and some mysterious CRef as its second item.  My issue is that I don't know what to do with this strange CRef.

Here is a concrete example:

I have 2 objects and 1 material in my scene and assign the material to both objects in a single action:

Application.AssignMaterial("Sources.Materials.DefaultLib.Material,sphere,cylinder", "siLetLocalMaterialsOverlap")

In the siOnEndCommand callback I get:

Command(Context(in_ctxt).GetAttribute(L"Command")).GetArguments()[0].GetValue() returns a CValueArray with 2 items.

Item 0 : CValue, m_t=siRef - this is a CRef to the Material being assigned, as expected.  GetAsText() return "Sources.Materials.DefaultLib.Material" and GetClassIDName() returns "Material".  Good to go.

Item 1 : CValue, m_t=siRef - this is some kind of weird CRef that I don't know how to handle.  GetAsText() returns "sphere,cylinder" and GetClassIDName() returns "Object".  What do I do now?  How can I get those objects as CRefs?  Do I have to tokenize the string and parse out the object names?  It's not hard, but I'd like to do something cleaner if possible.

Thanks!!

-Nicolas

[Steven Caron]

have you tried... siOnCreateShader? i generated this event from the wizard and it seems to log a lot of relevant info. also there is siOnConnectShader

" Question: Can material assignment happen without this command being run?  In other words, is catching this command sufficient for monitoring all the ways that a material can be assigned to an object?  I'm not very experienced with using Softimage, but I know that in Maya there are a million and one ways to assign materials. "

-one could change the shader graph but not the material assignment.

-one could 'drag and drop' a material from the material view in the explorer on to an object. that calls 'CopyPaste()' command. i have always been on the fence whether that command is good or bad)

[Nicolas Burtnyk]

Thanks Steven!

I already use siOnConnectShader (and siOnDisconnectShader) to track changes to the shader tree.  These don't get fired as a result of assigning a material to an object.  siOnCreateShader only gets called when you create a shader node and in fact partially fails at even that since it doesn't get called when you create a material (which creates a shader as well).

Thanks for the tip on material assignment via drag & drop.  Kind of a shame that it ends up calling CopyPaste command but it should be simple enough to monitor for that command as well.

-Nicolas

[Guillaume Laforge]

There is unfortunately one last way to assign material to polygons using the Materials and MaterialID attributes.

And this way is not using a specific command (the user could just set those values from an ICETree or by script).

It is a relatively new feature, so not too many users know this way though.

Cheers,

Guillaume

[jo benayoun]

Hey Nicolas,

I know, this is not answering directly to your issue here, but rethinking to your problems (tracking FCurves, materials, etc) for the project you're working, I would ask why not building a custom scene graph (something relatively simple) where all nodes are just CRef (the encapsulated pointer to object should stay valid) pointing to SceneObjects. A custom scene graph would let you implement a faster visitor pattern that you could think of using the API, which would query the GetEvaluationID and GetHierarchicalEvaluationID (awesome to avoid to visit an entire branch - good for perfs) methods to track which scene objects is getting dirty. You could also register to "siOnObjectAdded" and "siOnObjectRemoved" events to keep your custom scene graph updated and aware to the scene. The scene graph would be built when your renderer gets initialized. Im quite sure, it doesnt fit your needs, but maybe it could help you to get new ideas :)

A node of your scene graph, could be as simple as:
"""
struct scenegraphnode
{
  /* next sibling  and children as linkedlist */
  struct scenegraphnode *siblings[2];
  /* previous dirty number */
  ulong_t prev_dirty;
  /* visitor to query the node */
  void (*visit)(struct scenegraphnode *self, struct visitor v);
  /* the actual ref */
  XSI::CRef ref;
};

"""

Your "struct visitor" could be a struct checking the dirty count, and if it is not equal to the previous, in charge of getting the new material, fcurve, position, etc
and sending those new informations to your renderer.
again, just an idea ...
-jo

2012/5/4 Nicolas Burtnyk <nic...@redshift3d.com>

[Nicolas Burtnyk]

To Guillaume:  Thanks for the heads-up!  Do you know of any example scripts that demonstrate this?  I can't seem to assign materials to objects this way.  Also I found 1 more: the ApplyShader command.

To Jo: Well I wasn't even aware of this GetEvaluationID/GetHierarchicalEvaluationID!  I will definitely take a look at this.  Thanks!

[Alok Gandhi]

Actually that seems to be a very excellent idea to me Joe. Again, it depends on the needs whether to warrant such a structure. But this is very good way in my view.

[jo benayoun]

I double check before suggesting it, on my side, its aware of material and animation.
The hierarchical one is pretty awesome, since it avoids you to visit an entire subtree. so you go pretty quickly to the dirty CRef.

2012/5/4 Nicolas Burtnyk <nic...@redshift3d.com>

[Steven Caron]

in my quick test i applied multiple shader's from the menu, both standard and custom. both seemed to get fired. i could have been wrong.

[Nicolas Burtnyk]

To Steven : if the application of the shader to the object creates a shader and a material and connects the shader to the material, then yeah, those events are called.  But if you assign an existing material, they're not.

To Jo: I'm playing with this right now and it's very promising.  I wonder though if it's possible to get the same hierarchical evaluation id after some edits.  The reason I'm worried about this is that I noticed that assigning different materials to an object caused the hierarchical evaluation id to go up and down.  I wonder if some combination of edits could result in the same evaluation id and therefore cause my system to think nothing has changed which would obviously be pretty bad!  Other than this worry, and verifying that this is valid for all kinds of edits that might change the way an object is rendered, this technique of checking the hierarchical object id might be a lot simpler than chasing down every last little command, callback, etc.. that can change the scene.

Thanks guys!!

[Nicolas Burtnyk]

Unfortunately I was able to pretty easily break this system :(

While playing around with all kinds of edits, I noticed that when I had Material1 assigned to my object the hierarchical eval id was 20 less than when I had Material2 assigned.  I also noticed that if the object had a bend modifier on it, changing the bend angle would increment the hierarchical eval id by 2.  So with this sequence of events, I got the same eval id before and after edits.

Hierarchical eval id of the sphere is shown in brackets at each step

Start: sphere with bend modifier, Material2 assigned (226)

Assign material 1 (206)

Change the bend angle 10 times (226)

The problem is the way the hierarchical eval id is computed by simply summing the eval ids up the hierarchy.  Maybe instead, I could crawl the hierarchy myself (annoying but not a big deal) and compute a hash from all eval ids in the hierarchy of the object.  Assuming a suitable hash function, any change to any eval id in the hierarchy would cause big changes in the hash and bring the probability of a false negative down to some infinitesimally small amount.

[jo benayoun]

Well, you can still subscribe to an event like "siOnValueChange" or why not a timer that will helps you to get an idea to when run your visitor thru your custom scene graph.
It would be enough to make a trace between each user edit. At worst you can adjust the stepping of your custom timer. Also since you're only storing the previous ID, that should not be a problem.
Thinking of lexer implementation, why not storing the last two IDs, and be sure your object is actually changing before firing an update. Im quite sure actually you will get the opposite issue, that the render event is fired too often instead of not enough ...
Anyways, there is more to explore and if you go with that way, Im sure new issues will pop up !

:)
-jo

2012/5/4 Nicolas Burtnyk <nic...@redshift3d.com>

To Steven : if the application of the shader to the object creates a shader and a material and connects the shader to the material, then yeah, those events are called.  But if you assign an existing material, they're not.

[jo benayoun]

Hey Nicolas,

This depends of the frequency of your scenegraph traversal. For sure, if you run it like this

Start: sphere with bend modifier, Material2 assigned (226)

traversal
Assign material 1 (206)

Change the bend angle 10 times (226)

traversal

the system will break. But visiting at this frequency will work:

Start: sphere with bend modifier, Material2 assigned (226)

traversal
Assign material 1 (206)

traversal

Change the bend angle 10 times (226)

traversal

Since you can avoid visiting entire branches because of the hierarchical attribute. I bet a traversal would be really fast to do reducing the number of visited node (all nodes are not traversed unlike the original visitor pattern).
The frequency is up to you, with a custom timer, or by subscribing to "siOnValueChanged" should be enough.

-jo

2012/5/4 Nicolas Burtnyk <nic...@redshift3d.com>

Unfortunately I was able to pretty easily break this system :(

[Nicolas Burtnyk]

Just to be clear, I'm not looking for ways to know when I should re-render.  That's up to the user.  What I want is a robust way to know what I need to reprocess (extract geo, convert materials, blah blah) since the last render. 

So, I don't see why I would do any traversal or visiting of nodes on regular intervals.  I would just do this at the start of each render.

Of course with what you're suggesting, the odds are much lower of getting false negatives since your evaluating "dirtiness" way more often.

[Alok Gandhi]

Hi Nicolas,

If I understand what you are saying, for each "dirty" of your interest, you would like to capture and store that as soon as it happens and compare it with last render event to process the delta change. And right now you the challenge that you are faced with is capturing the "dirties", specially with the material assignment.

But isn't it true that Joe's proposal lets you visit the scene graph to capture the scene graph changes at each render, still doing the same thing but with a different approach.

Please correct me if I am wrong.

Alok.

[Matt Lind]

>> -one could 'drag and drop' a material from the material view in the explorer

>> on to an object. that calls 'CopyPaste()' command. i have always been on

>> the fence whether that command is good or bad)

 

 

It is bad ;-)  

 

Not the case anymore, but years ago it was a source of many gremlins and corruptions.   Nowadays it’s just a nuisance in that you don’t get very useful information from the SDK as to what has just happened.  For example, if you import geometry from a custom file format, CopyPaste() is called instead of ActiveSceneRoot.AddGeometry() leaving you without much of a hook to determine whether it succeeded or not.

 

 

Matt

[jo benayoun]

Hey Nicolas,

I think there is a misunderstanding on what I'm suggesting and what you could expect.

1/ When I was talking about increasing the frequency of the custom scene graph traversal, I was thinking to it in the context of a "quick preview" ala render region where things have to be updated when a slider is touched. subscribing to the "siOnValueChanged" or with a custom timer fit the case.

2/ A regular scene graph traversing would happen in the context of your render is launched but with a range of frames (let say 0-100) where you dont need to take care of "user edits". It means, that the user press starts, your scene graph gets initialized and scene graph traversing is done for every frame. ID is ideal to track animated objects, ...

3/ The other and last one Im thinking about is if the user ask the renderer for one frame and press the button start, no need of a custom scene graph. You have to evaluate everything.

In this three cases, I don't see which one would make the system breaks considering the ID increased or decreased between updates.

If there is a context or something I didn't think about, please, let me know, that I could try to think to something else ! :)

:) 

-jo

2012/5/4 Alok Gandhi <alok.ga...@gmail.com>

[Nicolas Burtnyk]

XSI already takes care of telling my renderer when we need to render.  That includes preview renders, region renders and "batch" renders for animation.  These all happen using the same mechanism - by calling the custom renderer "Process" callback.

Since all these types of rendering are handled by a single unified system, I'm designing my "dirty" system to be more or less agnostic to the type of rendering that's being performed.  I want to avoid having to distinuish between preview renders, animation renders, region renders etc... For example, there's no reason to assume everything is dirty for a preview render (case #3 above).  Basically, every time I'm told to render a frame, I need to determine what's been added, what's been removed and what has changed since the last render.  Also, I need to distinguish between different kinds of edits - e.g. a change in a mesh's xform only doesn't require me to re-extract the geometry data from XSI.

To do this, I simply keep track of what (meshes, materials, etc...) I rendered last time.  Let's call this the previous render list.  When it's time to render, I first mark everything in my previous render list as "unused".  I then traverse the XSI scene to collect things to render.  For each "thing" I check whether it's already in my previous render list.  If not, it's a new "thing" and it gets marked for full processing.  If it is found, I mark the "thing" as "used", then determine what kind of processing it needs (full processing, xform only change, etc...).  After everything has been collected, I go through my render list and anything still marked as "unused" is removed.

The "determine what kind of processing it needs" stage above is what needs to check for dirty information.  Currently I'm relying on a bunch of callbacks to maintain a data structure that I can quickly query to see if a particular object has been dirtied.  I am investigating   the possibility of replacing all those callbacks with some checking of the evaluation ids or hierarchical evaluation ids.  This would happen only during the step when I'm querying the dirty information, not on some regular interval outside the context of rendering.

Thanks again for suggesting the evaluation id stuff.  It looks like that going to simplify my checks a lot and make the system more robust.  It's absolutely essential for the system to not miss anything - a false negative will mean we're rendering data that's inconsistent with the current state of the XSI scene which will lead to a lot of head scratching and frustration.  I'll likely need to accept some false positives in exchange for never having false negatives - a compromise that is completely acceptable in this context.

-Nicolas

[Steven Caron]

yes, we need improvements to the SDK to bring parity to the mental ray integration in regards to scene graph changes.