Hmm. A pity. Alright, thanks.

Sven



> Also, rendering an irregular shaped area could ultimately be slower than a 
> slightly to large area. This will be due to a substentialy more complex 
> code. The code for a simple square section is simple: you limit the region 
> to render. That for an arbitrary free-hand capture will need to test every 
> pixel against the desired area. You may also need to render, but not 
> display, in a, square, region larger than the selected area.
>
> -- 
> Alain

Post a reply to this message

Alain wrote:
> Also, rendering an irregular shaped area could ultimately be slower than 
> a slightly to large area. This will be due to a substentialy more 
> complex code. The code for a simple square section is simple: you limit 
> the region to render. That for an arbitrary free-hand capture will need 
> to test every pixel against the desired area. You may also need to 
> render, but not display, in a, square, region larger than the selected 
> area.

While I don't necessarily think we need this feature, I don't think it 
would be that bad.  For each line, you could just store the beginning 
and ending points (assuming only convex shapes were allowed) and render 
a straight line across.

...Chambers

Post a reply to this message

Hi Chambers and Alain,

I am also a programmer and when suggesting the new lasso feature, I had 
exactly in mind what Chambers explains.

But on the other side, I am not sure how and how much it affects the speed.

I would like to have here an opinion by someone from the POV-Ray team, as 
they know the source code the best, and can also very fine estimate how the 
new lasso would affect calculation amount and speed.

Greetings,

Sven


"Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
news:445a1426$1@news.povray.org...
> Alain wrote:
>> Also, rendering an irregular shaped area could ultimately be slower than 
>> a slightly to large area. This will be due to a substentialy more complex 
>> code. The code for a simple square section is simple: you limit the 
>> region to render. That for an arbitrary free-hand capture will need to 
>> test every pixel against the desired area. You may also need to render, 
>> but not display, in a, square, region larger than the selected area.
>
> While I don't necessarily think we need this feature, I don't think it 
> would be that bad.  For each line, you could just store the beginning and 
> ending points (assuming only convex shapes were allowed) and render a 
> straight line across.
>
> ...Chambers

Post a reply to this message

Wasn't it Sven Littkowski who wrote:
>Hi Chambers and Alain,
>
>I am also a programmer and when suggesting the new lasso feature, I had 
>exactly in mind what Chambers explains.
>
>But on the other side, I am not sure how and how much it affects the speed.
>
>I would like to have here an opinion by someone from the POV-Ray team, as 
>they know the source code the best, and can also very fine estimate how the 
>new lasso would affect calculation amount and speed.

One awkwardness might be the difficulty of doing a shift-lasso to
remember a permanent region.

With the existing shift-drag rectangle, only four parameters need to be
appended to the command line, but an arbitrary shape might require a
very large number of parameters.

Without the ability to set the lassoed region permanently, you'd have to
re-lasso the area after each test run, even if the last test failed so
badly that nothing was visible in the target region.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Thanks for your replay, Manuel.

However, I am not sure if I understood your points right, let me repeat the 
way I understood. So you can correct me.

"When selecting with a rectangle, POV-Ray is currently remembering the 
outlines and can therefore repeat a render just like that. However when 
using a lasso shape (irregular shape) with more corners than a rectangle, 
POV-Ray could not automatically re-render that selection.

And it is not possible to select (based on what you see so far after a 
rendering) to select a part of the scene so exactly as you could with a 
rectange."

Is this what you meant?

Sven




"Mike Williams" <nos### [at] econymdemoncouk> schrieb im Newsbeitrag 
news:Qq3### [at] econymdemoncouk...
> Wasn't it Sven Littkowski who wrote:
>>Hi Chambers and Alain,
>>
>>I am also a programmer and when suggesting the new lasso feature, I had
>>exactly in mind what Chambers explains.
>>
>>But on the other side, I am not sure how and how much it affects the 
>>speed.
>>
>>I would like to have here an opinion by someone from the POV-Ray team, as
>>they know the source code the best, and can also very fine estimate how 
>>the
>>new lasso would affect calculation amount and speed.
>
> One awkwardness might be the difficulty of doing a shift-lasso to
> remember a permanent region.
>
> With the existing shift-drag rectangle, only four parameters need to be
> appended to the command line, but an arbitrary shape might require a
> very large number of parameters.
>
> Without the ability to set the lassoed region permanently, you'd have to
> re-lasso the area after each test run, even if the last test failed so
> badly that nothing was visible in the target region.
>
> -- 
> Mike Williams
> Gentleman of Leisure

Post a reply to this message

"Sven Littkowski" <sve### [at] jamaica-focuscom> wrote:
> Thanks for your replay, Manuel.
>
> However, I am not sure if I understood your points right, let me repeat the
> way I understood. So you can correct me.
>
> "When selecting with a rectangle, POV-Ray is currently remembering the
> outlines and can therefore repeat a render just like that. However when
> using a lasso shape (irregular shape) with more corners than a rectangle,
> POV-Ray could not automatically re-render that selection.
>
> And it is not possible to select (based on what you see so far after a
> rendering) to select a part of the scene so exactly as you could with a
> rectange."
>
> Is this what you meant?
>
> Sven
>
>

What he means is that when selecting with a rectangle, only points (4
numbers) are needed to describe the lower left and upper right corners of
the selection.  When you do this, you canoptionally have these written to
your ini file for rerendering the exact selection.  These are written to
the ini as Start_Column, Start_Row, End_Column and End_Row (+SC, +SR, +EC,
+ER).  These can also be appended manually to the commandline to render
onlya region.  However with a lasso selection, many more values need to be
used to describe the region.  It is likely possible to do this, however,
adding it to the ini file or command line would not be convenient.
Not to say that it can't be done, but it would likely have to implemented
differently than the current rectangle selection.

-tgq

Post a reply to this message

Greetings, Trevor!

Yes, I agree with you about both points you are making: it can be 
implemented, but due the more positions it would have some sort of impact to 
the current command line options (integration of an array of x-y numbers). I 
think, this parameter could look this way ("laso needs to be replaced by a 
single letter):
+LASSO50:10,40:30,50:50,70:50,80:40,70:30
This could make a hexagon.

But even if so, the old SC, SR, EC,ER parameters could be continued, as 
well. Why not?

It is just, that some scenes have details surrounded by many slow objects. 
In order to prevent any of these unneccessary slowing objects, only a lasso 
can do.

Sincerely,

Sven





> What he means is that when selecting with a rectangle, only points (4
> numbers) are needed to describe the lower left and upper right corners of
> the selection.  When you do this, you canoptionally have these written to
> your ini file for rerendering the exact selection.  These are written to
> the ini as Start_Column, Start_Row, End_Column and End_Row (+SC, +SR, +EC,
> +ER).  These can also be appended manually to the commandline to render
> onlya region.  However with a lasso selection, many more values need to be
> used to describe the region.  It is likely possible to do this, however,
> adding it to the ini file or command line would not be convenient.
> Not to say that it can't be done, but it would likely have to implemented
> differently than the current rectangle selection.
>
> -tgq
>
>
>

Post a reply to this message

It's trivially easy, actually.  Just render the selection region to a 
1-bit mask, then test the mask pixels to see if a display pixel should 
be rendered.

Ray


Chambers wrote:
> Alain wrote:
>> Also, rendering an irregular shaped area could ultimately be slower 
>> than a slightly to large area. This will be due to a substentialy more 
>> complex code. The code for a simple square section is simple: you 
>> limit the region to render. That for an arbitrary free-hand capture 
>> will need to test every pixel against the desired area. You may also 
>> need to render, but not display, in a, square, region larger than the 
>> selected area.
> 
> While I don't necessarily think we need this feature, I don't think it 
> would be that bad.  For each line, you could just store the beginning 
> and ending points (assuming only convex shapes were allowed) and render 
> a straight line across.
> 
> ...Chambers

Post a reply to this message

Sounds very interesting, but also very ununderstandable! Ray, I just never 
had POV-Ray doing such. I even don't know, how. Can you give me/us more 
details? Can you describe the entire procedure?

Sorry for my unknowledgement, but I really want to understand your idea as I 
truly look for suggestions.

Thanks, greetings,

Sven





"Ray Gardener" <ray### [at] daylongraphicscom> schrieb im Newsbeitrag 
news:445c4cab$1@news.povray.org...
> It's trivially easy, actually.  Just render the selection region to a 
> 1-bit mask, then test the mask pixels to see if a display pixel should be 
> rendered.
>
> Ray
>
>
> Chambers wrote:
>> Alain wrote:
>>> Also, rendering an irregular shaped area could ultimately be slower than 
>>> a slightly to large area. This will be due to a substentialy more 
>>> complex code. The code for a simple square section is simple: you limit 
>>> the region to render. That for an arbitrary free-hand capture will need 
>>> to test every pixel against the desired area. You may also need to 
>>> render, but not display, in a, square, region larger than the selected 
>>> area.
>>
>> While I don't necessarily think we need this feature, I don't think it 
>> would be that bad.  For each line, you could just store the beginning and 
>> ending points (assuming only convex shapes were allowed) and render a 
>> straight line across.
>>
>> ...Chambers

Post a reply to this message

In semi-pseudocode, you want to do something like this:

render_window::on_mousedown(point)
{
	if(selmode == lasso)
		pt_array.clear();
		pt_array.push_back(point);
		set_capture(this);
}

render_window::on_mousemove(point)
{
	if(selmode == lasso)
		if(get_capture() = this))
			pt_array.push_back(point);
}

render_window::on_mouseup(point)
{
	if(selmode == lasso)
		release_capture(this);
		pt_array.push_back(point);
		build_mask(pt_array);
		pt_array.clear();
}

build_mask(pt_array)
{
	if(win32)
		set up offscreen 1-bit dib
		dib.clear(black);
		define polygon from pt_array
		make region from polygon
		dib.selectobject(region)
		dib.fillregion(white);
		povray.mask.make_from(dib); // white = transparent
		
}

povray::render_scene(...)
{
	...
	for each pixel in scene
		if(mask.exists and mask pixel is black)
			continue;
		...
		render(pixel);
}

Ray


Sven Littkowski wrote:
> Sounds very interesting, but also very ununderstandable! Ray, I just never 
> had POV-Ray doing such. I even don't know, how. Can you give me/us more 
> details? Can you describe the entire procedure?
> 
> Sorry for my unknowledgement, but I really want to understand your idea as I 
> truly look for suggestions.
> 
> Thanks, greetings,
> 
> Sven
> 
> 
> 
> 
> 
> "Ray Gardener" <ray### [at] daylongraphicscom> schrieb im Newsbeitrag 
> news:445c4cab$1@news.povray.org...
>> It's trivially easy, actually.  Just render the selection region to a 
>> 1-bit mask, then test the mask pixels to see if a display pixel should be 
>> rendered.
>>
>> Ray
>>
>>
>> Chambers wrote:
>>> Alain wrote:
>>>> Also, rendering an irregular shaped area could ultimately be slower than 
>>>> a slightly to large area. This will be due to a substentialy more 
>>>> complex code. The code for a simple square section is simple: you limit 
>>>> the region to render. That for an arbitrary free-hand capture will need 
>>>> to test every pixel against the desired area. You may also need to 
>>>> render, but not display, in a, square, region larger than the selected 
>>>> area.
>>> While I don't necessarily think we need this feature, I don't think it 
>>> would be that bad.  For each line, you could just store the beginning and 
>>> ending points (assuming only convex shapes were allowed) and render a 
>>> straight line across.
>>>
>>> ...Chambers 
> 
>

Post a reply to this message