Apologies for dragging this subject back up but there's still a few
things I need to get clear on.
Ok, so I have a my vector full of points defining a curve that I'm
pre-processing using a locked thread. I'm able to sort the vector to an
upper/lower_bound as mentioned by Colin so I don't have to iterate
through every point which speeds things up a bit. So essentially, using
the DrawIop, I check that the current row is within the region that
contains my points. If not I return false.
Originally I was doing this. If we ARE within the region we iterate
through the points comparing the y-coord of each point with our row Y
value. If we have a match we fill the buffer for corresponding x-coord
with the value '1'. This was nice and fast but what I forgot was that
although I'm setting the pixels to '1' for the points, I'm not setting
all the X pixels that AREN'T our points with '0' resulting in garbage in
the viewer. So if I need to fill all the other row values with black
that means I have to iterate through every pixel in our row, checking
for a match and setting the pixel value accordingly. This slows things
down a lot.
So my question is, is there a way of defaulting the entire row to be
filled with '0' before simply iterating through my points once setting
the corresponding X values within the row to '1'? This would be a lot
faster, yes?
My second question concerns the actual generation of my curve points to
start with. As I mention I am currently using a single locked thread to
do this within the draw_engine() but is there a better place to be doing
this? Would it not be more efficient to process this somewhere before
the call to draw_engine() so I can limit the output to only the X values
I'm going to need as defined by looking at the values within my vector
of points?
Sorry for all the questions, it just seems like a lot of work to output
a predetermined point to a pixel within Nuke!
Cheers,
Steve
Stephen Newbold wrote:
Hi Colin,
Thanks for the response. Yeah, my actual data isn't random so I will
be able to define bounds to speed everything up, but random is kind of
worse case scenario. My actual points are defined by a cubic curve so
I don't think I can get around pre-processing them. I guess maybe my
method is the most efficient and once I can limit the data to a 'real
world' scenario then maybe it will be usable. I'm just aware that
this is just the premise at its most basic, I'm going to have to do a
lot more than fill a pixel by the end!
Cheers,
Steve
Colin Doncaster wrote:
If you're keen on using stl containers you can always sort them and
then use lower_bound/upper_bound to define an iterator for the
scanline you're interested in - the sort should be faster than
iterating through the vector for every scanline. The other option
is to store the pixels in a multimap with the key being you're x
value and then "finding" all of the entries with that key value - stl
uses slow hashing for maps though, so on second thought - option 1
might be best.
I imagine you're reading from disk and/or generating the random
points else where - but an even better option could be removing your
"intermediate buffer" that's holding all the random points and just
setting the pixel value directly from the random number generator?
If you're reading from a file could the random points be sorted
prior to being written thus removing the need all together? Just a
shot in the dark but sometimes the best way of optimizing something
is completely removing it from the equation. :)
Cheers
*/
*/
*/--
Colin Doncaster/*
*/
*/
*/Peregrine Labs/*
/*
/*
*/
*/
www.peregrinelabs.com <http://www.peregrinelabs.com>
/*
/*
/*
/*
On 2011-03-09, at 5:40 AM, Stephen Newbold wrote:
Hi,
I have a question about the best way of 'drawing' a set of
pre-defined points with the NDK. As a simplified example, say I
have a list/vector full of random points (x,y screen coords) where I
could have multiple points on a row in various x positions. I
simply want to draw a pixel for each of these points. Since the
draw engine can call any row in any order, it seems like I have to
use a seemingly inefficient method to check whether the current
row/pixel matches one of the points within my list.
Although I still have to try this, the best I can think of is for
each row called we check to see if the row position (Y) matches that
of any of the y-coords within my list. If not it looks at different
row. If there is a match then we iterate through the points and
output a pixel for every occasion where our X Y matches the coords
of the point. It seems like a lot of work to output pixels for
points we already know the position of and I guess could be very
slow if we have thousands of points. Am I missing something obvious?
Cheer,
Steve
--
Stephen Newbold
Senior Compositor - 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
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
------------------------------------------------------------------------
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
--
Stephen Newbold
Senior Compositor - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
------------------------------------------------------------------------
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
--
Stephen Newbold
Senior Compositor - Film
MPC
127 Wardour Street
Soho, London, W1F 0NL
Main - + 44 (0) 20 7434 3100
www.moving-picture.com
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
