So, found the issue. As part of my pixel engine I'm comparing
distanceSquared between 2 points to obtain the minimum distance from a
set of points. I'm then only finding the square root of the smallest
in order to try and speed things up. I thought this was a pretty
standard thing? But for some reason this is where my artifacts are
coming from. If I compare actual distances, everything works
correctly. I'm not seeing a noticeable performance hit from doing this
as my point set is small.
This is why it took me ages to find the problem, I just assumed this
code would be fine as it was so simple.
Still have no idea why this glitches, or why updating _validate() (when
changing any knob value) outputs different artifacts, but I'm glad its
sorted. Thanks for all the suggestions.
Steve
Stephen Newbold wrote:
Hi Colin,
Yeah random speckles. When I get back to work tomorrow I'll do
as you suggest. Can't really share code as it's a work tool, but thanks
for all the advice and I'll strip it right back until I find the
culprit.
Cheers,
Steve
Hi Steve,
Just to be certain we're talking about the same thing, is it
safe to assume that the artifacts you're seeing are noise like speckles
that change frame to frame/on refresh vs some equally random though
more structured issue?
It still sounds like it's an issue with the output row not
being set to 0 - can you isolate it to one or more channels, ie. just
in red, or just red and green, etc.? You're not creating any new rows
yourself that haven't been set to 0?
I would say comment everything out except for your memset, and
then slowly add them back in until you see the artifacts. It's really
hard to help more without seeing code. :)
On 2011-05-19, at 1:23 PM, Stephen Newbold wrote:
I might be wrong when I
said the artifacts were consistent, artifacts do actually seem to be
random, which makes more sense but is still annoying.
Steve
Stephen Newbold wrote:
Hi Colin,
Of course, rookie error! That has stopped the crashing but hasn't
stopped the artifacts. Does this mean I can rule out issues with the
output buffer? I think all I can do is get the pixel output down to a
manageable size so I can check exactly what values are getting output
and any variables associated with them. Sounds like a fun evening!
Steve
Colin Doncaster wrote:
It sounds like you need to zero out the row ( nuke doesn't
do this for you ) prior using it - thus you're memset is heading down
the right path you're call is wrong,
memset( buffer +x, 0, (r-x) * sizeof(float));
you have to remember that although the pointer is
pointing to [0] that may not be safe if Nuke's only managing x to r.
This should hopefully avoid the crash.
cheers
On 2011-05-19, at 12:28 PM, Stephen Newbold wrote:
Hi,
I'm wondering if you guys can give me some pointers in where I might
look to iron out a glitch in my DrawIop. So everything is generally
working as I want it, but I'm getting very small glitches in the
output. Could be in my code but I'm noticing the glitches change when
I use any knob, even those unconnected with the output which is a bit
odd. I've even added a null knob that does absolutely nothing just to
test this. Change this knob and my artifacts change.
So, what I'm trying to do first is work out why my output (albeit with
artifacts) is changing when I move unrelated controls. I'm assuming
certain things get updated on any knob change? I know it hard without
seeing code, but have you guys got any ideas what is called/updated
each time a knob is changed? If it helps, things don't change when
changing to a different frame, only when using a knob. Also, the
change in artifacts will change consistently, in other words if I move
a slider back and forth, the result will change consistently back and
forth, same artifact pattern for each value.
I've also tried emptying the output buffer with memset for each row
before filling it again to see if this affected things, but this is
crashing nuke,
memset(buffer, 0, (R - X) * sizeof(float));
This has kind of got me stumped.
Steve
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
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
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
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
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
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
--
Stephen Newbold
Compositing Lead - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
|
