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