Why: because the interesting part of a render in progress might not
start at the top left, continuing on the right and proceding like a book
of western culture. (and it might be more fun to have the pictures
rendered with alternative ways)

Apply to 3.7beta38

Default remain left-to-right, top to bottom (ro1.png).
Additional possibilities are:
 - top-left to bottom, then left to right (ro2.png)
 - top corners, top line, then last line and ending on the center (ro3.png)
 - start at center, make it line by line (above & under alternatively)
(ro4.png)
 - left-most cornet, then last columns and ending on the center (ro5.png)
 - start at center, build central column and expand on each side.
(ro6.png)

Pictures are illustration from black to white of blocks' dispatching.

How to use: (syntax free to change for better naming)
===========
command line: +HGRO x (with x between 0 and 5)
ini file: HG_Render_Order=x

Interest: Up to you.

Post a reply to this message

Attachments:
Download 'ro1.png' (31 KB) Download 'ro2.png' (31 KB) Download 'ro3.png' (31 KB) Download 'ro4.png' (31 KB) Download 'ro5.png' (32 KB) Download 'ro6.png' (32 KB) Download 'order.tar.gz' (35 KB)

Preview of image 'ro1.png'

Preview of image 'ro2.png'

Preview of image 'ro3.png'

Preview of image 'ro4.png'

Preview of image 'ro5.png'

Preview of image 'ro6.png'

Le_Forgeron <jgr### [at] freefr> wrote:
> Why: because the interesting part of a render in progress might not
> start at the top left, continuing on the right and proceding like a book
> of western culture.

indeed.  Blender starts from the center.  Unbiased renderers start from
everywhere and a rough noisy preview is available in a few seconds, with most
light contributions already in place so you know before hours if that caustic is
looking good next to a wall or not...

Post a reply to this message

I like this. Should have great potential indeed.

Thomas

Post a reply to this message

Am 14.07.2010 21:04, schrieb Le_Forgeron:
> Why: because the interesting part of a render in progress might not
> start at the top left, continuing on the right and proceding like a book
> of western culture. (and it might be more fun to have the pictures
> rendered with alternative ways)
>
> Apply to 3.7beta38

Did you make sure that it co-operates properly with the recent changes 
to radiosity pretrace (especially the adaptive pretrace mechanism)?

How about a mode that starts in the center and then goes around in 
"circles"?

Post a reply to this message

Le 21/07/2010 22:41, clipka nous fit lire :
> Am 14.07.2010 21:04, schrieb Le_Forgeron:
>> Apply to 3.7beta38
> 
> Did you make sure that it co-operates properly with the recent changes
> to radiosity pretrace (especially the adaptive pretrace mechanism)?

Does radiosity pretrace rely on the View object ?
Only the View object is impacted by this patch. (well, the option system
too; but that's only a minor addition)

> 
> How about a mode that starts in the center and then goes around in
> "circles"?

Code is provided; it's basically adding 2 functions to replace the
previous computation made inline with modulo, twice in the code
(duplicating such code is a call for trouble in the futur).
Each function (one for X, the other for Y) is a switch statement which
choose how the bloc number is converted into X,Y block coordinates.
If you want more mode(s), just add your own case(s) in the switch, and
expand the clipped-range used for the option.

I do not have the math for computing a transformation which start at
center and goes around as circle (starting at center is easy and done
for mode 3 & 5, but circling is not, at least for me), feel free to
provide that if you can. (beware, the picture might not be a square, and
the numbering must cover any rectangle ratio)

Post a reply to this message

Am 22.07.2010 10:38, schrieb Le_Forgeron:

> Code is provided; it's basically adding 2 functions to replace the
> previous computation made inline with modulo, twice in the code
> (duplicating such code is a call for trouble in the futur).
> Each function (one for X, the other for Y) is a switch statement which
> choose how the bloc number is converted into X,Y block coordinates.
> If you want more mode(s), just add your own case(s) in the switch, and
> expand the clipped-range used for the option.

I just found time to actually look at the code, and I must say it looks 
like a pretty elegant, "minimally-invasive" solution.

Yes, the other modules are perfectly unaware of the mapping of "block 
numbers" vs. screen coordinates; some are actually aware of block 
nubers, but all they know (or expect) is that the number is unique for 
each block - plus a special mode of operation in which radiosity 
pretrace code expects the numbers to be consecutive and in the same 
order in which the blocks are actually dispatched to the individual threads.

I have only two points of critique:

(1) I think the computation of blockX and blockY should be done in one 
single function, to prevent "fragmentation" of the mapping rules for 
each case. (It is not uncommon in the POV-Ray code for a function to 
have multiple output values.)

(2) Your code does not match the files' overall code formatting style :-P

Post a reply to this message

Am 22.07.2010 12:29, schrieb clipka:

> I have only two points of critique:
>
> (1) I think the computation of blockX and blockY should be done in one
> single function, to prevent "fragmentation" of the mapping rules for
> each case. (It is not uncommon in the POV-Ray code for a function to
> have multiple output values.)
>
> (2) Your code does not match the files' overall code formatting style :-P

Oh, and (3) I can't make out what the "HG" in "HG_Render_Order" and 
"HGRO" stands for, so I'd suggest to reconsider those option names.

Post a reply to this message

Le 22/07/2010 12:34, clipka nous fit lire :
> Am 22.07.2010 12:29, schrieb clipka:
> 
>> I have only two points of critique:
>>
>> (1) I think the computation of blockX and blockY should be done in one
>> single function, to prevent "fragmentation" of the mapping rules for
>> each case. (It is not uncommon in the POV-Ray code for a function to
>> have multiple output values.)
>>
>> (2) Your code does not match the files' overall code formatting style :-P
> 
> Oh, and (3) I can't make out what the "HG" in "HG_Render_Order" and
> "HGRO" stands for, so I'd suggest to reconsider those option names.

Go for it! Feel free to amend and do what ever you want with it.
Find & use any naming you like for (3).
I even agree with (1), it was just easier to try it that way (replacing
each formula with a function) as a plugged replacement. On a
production-source, it might be better to rethink it further: you're right.

For (2), do you have any documentation (or indent rules, in fact, I
would like the indent rules better, as autoformating is far easier than
following manual rules), I would be glad to set my editor (gvim) to
format the code (in any futur contribution, should it happen)

Post a reply to this message

Le 22/07/2010 12:29, clipka nous fit lire :

 plus a special mode of operation in which radiosity
> pretrace code expects the numbers to be consecutive and in the same
> order in which the blocks are actually dispatched to the individual
> threads.
> 

Same order, yes (probably), but consecutive...I fear some render_order
modes are using a kind of double-head implicit list (apart from 0 & 1,
all use alternatives block dispatching : left/right or up/down... as
even/odd block numbers, look at the pictures of the first message, so as
to expand the image quickly)

Mode 3 & 5 (expanding from center) remains connected (even if block
expansion is done both way, even in one direction, odd in the opposite),
but 2 & 4 starts with top-left corner for block 0, then either top-right
or bottom-left for block 1, and then when the first line is done, the
next line is the one at the opposite side of the picture. They keep
alternating all the way down to the center of the picture (final block),
in both X & Y.

Post a reply to this message

Am 22.07.2010 13:09, schrieb Le_Forgeron:
> Le 22/07/2010 12:29, clipka nous fit lire :
>
>   plus a special mode of operation in which radiosity
>> pretrace code expects the numbers to be consecutive and in the same
>> order in which the blocks are actually dispatched to the individual
>> threads.
>>
>
> Same order, yes (probably), but consecutive...I fear some render_order
> modes are using a kind of double-head implicit list (apart from 0&  1,
> all use alternatives block dispatching : left/right or up/down... as
> even/odd block numbers, look at the pictures of the first message, so as
> to expand the image quickly)

Maybe there's a misunderstanding here. What I mean is not that blocks N 
and N+1 are next to each other, but that if there exists a block with 
number N, there also exists a block with number N+1 (unless it's the 
last block), and that block N+1 is dispatched after block N.

Post a reply to this message