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 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
