Steve, Remember, you need to re-apply the sign of the relative distances when you do computations like this, as well. Points that are behind the viewpoint have exactly the same distance as points in front when you are squaring, which returns the absolute distance. Remember to restore the sign of the original vector, or all the points behind you will look like they are in front.
Steve From: nuke-dev-boun...@support.thefoundry.co.uk [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Stephen Newbold Sent: Friday, May 20, 2011 9:11 AM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Artifacts in drawIop 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 On 19 May 2011, at 20:23, "Colin Doncaster" <co...@peregrinelabs.com<mailto:co...@peregrinelabs.com>> wrote: 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. :) -- Colin Doncaster Peregrine Labs www.peregrinelabs.com<http://www.peregrinelabs.com> 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 -- Colin Doncaster Peregrine Labs www.peregrinelabs.com<http://www.peregrinelabs.com> 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<http://www.moving-picture.com> _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk<mailto: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<mailto: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<http://www.moving-picture.com> ________________________________ _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk<mailto: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<http://www.moving-picture.com> _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk<mailto: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<mailto: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<mailto: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<http://www.moving-picture.com> (CONFIDENTIALITY NOTICE: The information contained in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient, or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email, or the information contained herein is strictly prohibited. If you have received this communication in error, please notify the sender by return email and delete this email from your system. Thank You.)
_______________________________________________ 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
