It's been a while, but I thought I'd follow up with an update:
Jonathan, I tried caching a map of all object matrices, and then using that
to set it in init_geoinfo_params as suggested. In order to keep a unique id
for each sample, I appended the current outputContext.frame to the out_id()
hash, set the GeoInfo's out_id to that new hash, and saved it to the
matrices map.
That seemed to work in most cases, but it was also failing when modifying
the the texture input of my SourceGeo. From what I could tell, when that
happened, init_geoinfo_params was being called again, but with a different
out_id for each GeoInfo (which was not stored in my map).
In the end, though, I found that for all the cases where this was failing,
create_geometry was also being called with a rebuild OBJECT mask only. So,
I tried setting the GeoInfo's matrix whenever the rebuild mask contains
Mask_Matrix OR Mask_Object. That, combined with an init_geoinfo_params that
doesn't reset the matrix seemed to be enough.
Does that sound like a sensible way to approach it? Or are there any corner
cases you can think of where I'd still need to cache the matrices to set
them again later?
Thanks again,
Ivan
On Tue, Aug 21, 2012 at 10:16 PM, Ivan Busquets <ivanbusqu...@gmail.com>wrote:
> Thanks Jonathan,
>
> That's a bummer, but great to know. I did think about the option of
> caching out the matrices to avoid re-reading from file, but didn't know if
> there was anything I could use to reliably get back the right matrix for
> the right object, particularly when dealing with multiple samples.
>
> So, thanks for pointing out the out_id() hash. I will give that a try.
>
> Cheers,
> Ivan
>
>
> On Tue, Aug 21, 2012 at 1:26 PM, Jonathan Egstad <jegs...@earthlink.net>wrote:
>
>> If I recall there's a bug (at least I consider it a bug) that the matrix
>> is reset to identity when a Source_Geo Op is called with an already created
>> cache. In other words the GeometryList has been previously filled in and
>> the create_geometry() method is being called for another reason than to
>> rebuild primitives.
>> You probably need to always set the matrix in init_geoinfo_params() , so
>> you'll probably need to cache the matrices yourself to avoid having to open
>> the file again. I used a map with a key of out_id() hashes.
>>
>> -jonathan
>>
>> On Aug 20, 2012, at 11:10 PM, Ivan Busquets wrote:
>>
>> Thanks Peter,
>>
>> The matrix calculation itself doesn't use any variables that are stored
>> in the op.
>> It's being read from a file, and set within create_geometry. If possible,
>> I'd rather keep it there, to avoid having to re-read the file in
>> geometry_engine as well.
>>
>> However, the geo hash for "Group_Matrix" DOES use values that are stored
>> in the Op (through knobs). I tried checking if this came from one of the
>> ops not forcing the Group_Matrix update, but that doesn't seem to be the
>> case. In fact, the geo hash for Group_Matrix is hashed up the same way as
>> Group_Points, and if I bake the matrix into the points then everything
>> updates fine.
>>
>> On closer inspection, I can see the following happening:
>>
>> 1. If I inspect the matrix right after it's being set (in
>> create_geometry), I can see it's correct for all samples. If I inspect it
>> within init_geoinfo_params, same thing. Except that, every now and then,
>> init_geoinfo_params seems to be called twice for the first sample, the
>> first time yielding the correct matrix, and the second time being set to
>> the identity.
>>
>> 2. If I add a texture/shader to my SourceGeo, whenever I modify that
>> input then create_geometry is not called (I'm not adding anything from the
>> input to the geo hash), but init_geoinfo_params is, this time with all
>> samples producing an identity matrix.
>>
>> Does that make sense? Or at least, does it help figure out where things
>> could be going wrong?
>>
>> Again, thanks for the help.
>>
>> Cheers,
>> Ivan
>>
>> On Mon, Aug 20, 2012 at 3:16 AM, Peter Crossley <
>> cross...@thefoundry.co.uk> wrote:
>>
>>> Hi Ivan,
>>>
>>> The only thing I can see that's different to the way we handle
>>> SourceGeos internally is that we do our matrix stuff inside a
>>> re-implementation of geometry_engine instead of create_geometry, so we do
>>> something like:
>>>
>>> void geometry_engine(Scene& scene, GeometryList& out)
>>> {
>>> SourceGeo::geometry_engine(scene, out);
>>>
>>> // Now do matrix stuff
>>> ...
>>> }
>>>
>>> However, if you're also re-implementing init_geoinfo_params then I can't
>>> see anything else that would overwrite the geoInfo's matrix, so it may be
>>> worth giving this a try but I don't think it's the problem.
>>>
>>> How do you calculate the matrix? Do you use any variables that are
>>> stored on the op? I'm wondering if you're just getting a new instance of
>>> your op which doesn't have the correct values stored. This would explain
>>> why it only happens occasionally and why changing frames can fix it.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>>
>>> On 20/08/2012 07:06, Ivan Busquets wrote:
>>>
>>> Hi all,
>>>
>>> I'm having a problem where a change in an GeoInfo's matrix does not
>>> always update immediately (in the viewer).
>>>
>>> Details:
>>>
>>> - In a SourceGeo subclass I'm setting a matrix for each GeoInfo within
>>> create_geometry
>>> - I've overridden init_geoinfo_params so it won't reset to an identity
>>> matrix
>>> - output_context().frame() is added to the hash in append()
>>> - output_context().frame() is added to the geo_hash[Group_Matrix] in
>>> get_geometry_hash()
>>>
>>> This seems to work well, except that, every now and then, I'll hit a
>>> frame where the matrix is reset to the identity.
>>> This happens more often when rendering with multi-samples. Most of the
>>> samples will behave properly, but every now and then there will be one
>>> that's off (matrix reset to identity). Sometimes hovering over the viewer
>>> is enough to force an update that fixes it, and sometimes it'll take moving
>>> forward one frame and back.
>>>
>>> If I don't set the GeoInfo's matrix and bake it into all points
>>> instead, I don't have any of those issues.
>>> Has anyone else had similar problems?
>>> Is there anything else I should be doing to make sure that the GeoInfo's
>>> matrix is up to date?
>>>
>>> Thanks,
>>> Ivan
>>>
>>>
>>> _______________________________________________
>>> Nuke-dev mailing listnuke-...@support.thefoundry.co.uk,
>>> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Nuke-dev mailing list
>>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>
>>>
>> _______________________________________________
>> Nuke-dev mailing list
>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>
>>
>>
>> _______________________________________________
>> Nuke-dev mailing list
>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>
>>
>
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
