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
