Would be nice to have a block-fill frame order where it goes:
0, 10, 20, 30…,100
5, 15, 25, 35… 95
2, 7, 12, 17, 22…
etc.
Would be nice to have a block-fill frame order where it goes:
0, 10, 20, 30…,100
5, 15, 25, 35… 95
2, 7, 12, 17, 22…
etc.
Can you finish the sequence please?
[code]start = 0
end = 500
frames = #(start,end)
function split list =
(
sList = copy list #nomap
sort sList
for i = 1 to (sList.count-1) do appendifunique list (int((float(sList[i+1])+sList[i])/2))
return list
)
while frames.count < (end-start) do
(
frames = split frames
)[/code]
0,100,50,25,75,12,37,62,87,6,18,31,43,56,68,81,93,3,9,15,21,28,34,40,46,53,59,65,71,78,84,90,96,1,4,7,10,13,16,19,23,26,29,32,35,38,41,44,48,51,54,57,60,63,66,69,73,76,79,82,85,88,91,94,98,0,2,3,5,6,8,9,11,12,14,15,17,18,20,22,24,25,27,28,30,31,33,34,36,37,39,40,42,43,45,47,49,50,52,53,55,56,58,59,61,62,64,65,67,68,70,72,74,75,77,78,80,81,83,84,86,87,89,90,92,93,95,97,99
EDIT: It’s a bit slow with hundreds of thousands of frames. I guess you could do something like…
for i = 1 do
(
for j = 1 to ((i * 2) -1) do
(
something something... append end-start * i/2 or something...
)
)
I wrote a faster version that produces a VERY similar sequence, and then realized it was a special case of the “Half Raster Refine” mode, but with Nth set to the length of the interval. So if rendering frames 0 to 100, the user has to set the Nth value to 100, and then he gets
0,100,50,25,75,12,24,36,48,60,72,84,96,6,18,30,42,54,66,78,90,3,9,15,21,27,33,39,45,51,57,63,69,81,87,93,99,1,2,4,5,7,8,10,11,13,14,16,17,19,20,22,23,26,28,29,31,32,34,35,37,38,40,41,43,44,46,47,49,52,53,55,56,58,59,61,62,64,65,67,68,70,71,73,74,76,77,79,80,82,83,85,86,88,89,91,92,94,95,97,98
Not exactly what you posted, but quite similar.
I could add a special mode that runs the Half Raster Refine function with Nth set automatically to the range size if the above list is something you can live with… In the mean time, you can just use the existing feature by entering the Nth value yourself. However, the Nth field is currently limited to 1000, so you won’t be able to submit sequences longer than 1000 frames where the first two tasks are the first and end frame.
Cool! Thanks. Yeah I figured there was a mathematical function which could handle the sequence more efficiently than bruteforce. It looks like brute force does better on the first couple iterations and the mathematical approach works best on the last iteration.
Found a small bug in the workaround. You can’t set the out Of Order step > 1,000 so it’s limited to working with less than 1,000 frames.
Yeah, I mentioned that in the last sentence of my post But it is easy to fix in the SMTD UI MAXScript code, just change the range…