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.
On Fri, May 4, 2012 at 6:34 PM, jo benayoun <jobenay...@gmail.com> wrote:
> 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 <nico...@redshift3d.com>
>
>> 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.
>>
>>
>> On Fri, May 4, 2012 at 6:12 PM, Nicolas Burtnyk
>> <nico...@redshift3d.com>wrote:
>>
>>> 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!!
>>>
>>>
>>> On Fri, May 4, 2012 at 6:02 PM, Steven Caron <car...@gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>> On Fri, May 4, 2012 at 5:20 PM, Nicolas Burtnyk <nico...@redshift3d.com
>>>> > wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> On Fri, May 4, 2012 at 4:54 PM, Steven Caron <car...@gmail.com> wrote:
>>>>>
>>>>>> 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)
>>>>>>
>>>>>>
>>>>>> On Fri, May 4, 2012 at 4:39 PM, Nicolas Burtnyk <
>>>>>> nico...@redshift3d.com> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
