Hi,

over the past decade of using POV-Ray, I came up with a small list of
features that would be nice to have for the render window.

Focus Movement
To be able to move the contents (dragging) of the render window not only
with the scroll bars but also by using mouse-button-down mouse movement.

Zooming
Ability to zoom in or out by using the mouse scroll wheel.

Area Rendering
Not only rectangles, but also support for any shape by offering a lasso
selection tool (like Adobe Photoshop), a circular/elliptical selection
tool, and multi-selections (using SHIFT or ALT while marking more than
one area). A tiny bar with these tools could appear and disappear by
right-click or double-click on that window or clicking that par's X
button (close).

MAYBE: Shape Info
Not sure if that idea can be done: on mouse-over on any part of the
rendered image, a popup (info or hint label) appears telling what
item(s) of the scene file are responsible for that particular area.
Might help to trace down errors in scene code writing.

Please give a feedback about these ideas. Thanks.

Post a reply to this message

Am 24.12.2015 um 15:10 schrieb Sven Littkowski:

> over the past decade of using POV-Ray, I came up with a small list of
> features that would be nice to have for the render window.

One thing you might want to know is that the current POV-Ray Windows GUI
is nearing the end of its life, and will be thrown away and replaced
with something new the very moment we find the time. Therefore, it is
unlikely that Chris (who is the person most deeply involved in the
Windows GUI) will do much in terms of adding new features, especially if
they are just "nice to have".


> Focus Movement
> To be able to move the contents (dragging) of the render window not only
> with the scroll bars but also by using mouse-button-down mouse movement.

I guess this ranks low in terms of priority even among the "nice to
have" items.

On the other hand it might be a piece of cake to implement, so there's a
bit of hope.


> Zooming
> Ability to zoom in or out by using the mouse scroll wheel.

That sounds more difficult to me.


> Area Rendering
> Not only rectangles, but also support for any shape by offering a lasso
> selection tool (like Adobe Photoshop), a circular/elliptical selection
> tool, and multi-selections (using SHIFT or ALT while marking more than
> one area). A tiny bar with these tools could appear and disappear by
> right-click or double-click on that window or clicking that par's X
> button (close).

This one would require non-trivial changes in the actual renderer, as
we'd have to first extend the interface between GUI and renderer to pass
non-rectangular selection information to the renderer, and then modify
the algorithm that dispatches the render jobs; and if we really only
want to render the selected region and nothing more, the same work would
also carry on further down into the actual render threads, which
currently expect to get rectangular render jobs.

I guess it is worth reconsidering what you actually want to achieve with
such a feature, and consider alternative approaches.

For instance, maybe a simple option to not erase the preview window when
rendering a selected rectangle would already address your intended use case.


> MAYBE: Shape Info
> Not sure if that idea can be done: on mouse-over on any part of the
> rendered image, a popup (info or hint label) appears telling what
> item(s) of the scene file are responsible for that particular area.
> Might help to trace down errors in scene code writing.

/That/ one actually sounds pretty neat and useful to me.

It won't be easy to implement though: First, a way of "naming" the
respective scene items would have to be designed; filename and line
number may be insufficient, as multiple objects may be constructed by
one and the same macro and hence at the same location in the source
code. Also, the object names would need to be stored somewhere during
rendering, which in scenes with a lot of objects might eat up a
considerable amount of memory. Thus, maybe the most useful way to do
this would be to have a new optional object property, e.g. "name", which
would take an arbitrary string to identify the object. Such a feature
would also come in handy for us developers when debugging code, so that
we can see which object is currently being processed.

Next, we'd need to modify the interface of the core render engine --
which takes a single camera ray and currently just returns a colour --
to somehow also inform which object was hit by the ray.

Then we'd need to modify the interface of the render egine -- which
currently only sends an image to the preview -- to also send the object
identification information. For the sake of memory consumption, this
information should be as compact as possible, so we may want to generate
a kind of "object map" with different "colours" for each object, and an
accompanying legend identifying which "colour" represents which object.

And finally we'd of course need to modify the preview window to display
the information to the user in a suitable manner.

Some caveats to consider along the way:
- What do we do if the first object hit is transparent? What if it is
semi-transparent? What if it is reflective?
- What if the object hit is a named child of an also named CSG object?
- What about anti-aliasing, which will typically cause multiple
independent objects to be blended together in a single pixel?

Post a reply to this message

I made already some first thoughts about this feature, before suggesting it.



> One thing you might want to know is that the current POV-Ray Windows GUI
> is nearing the end of its life, and will be thrown away and replaced
> with something new the very moment we find the time. Therefore, it is
> unlikely that Chris (who is the person most deeply involved in the
> Windows GUI) will do much in terms of adding new features, especially if
> they are just "nice to have".
If the new GUI contains useful features like this, or even features
better than this, why not? There is a reason for a new GUI, and i am
waiting excitedly for it. I offer myself as tester.

>> Focus Movement
> On the other hand it might be a piece of cake to implement, so there's a
> bit of hope.
With Delphi very easy to develop, less than 10 extra lines of code
altogether each having only one command.

>> Zooming
> That sounds more difficult to me.
Nope. Totally easy to do (in Delphi). Through the mouse wheel, just the
image size is being changed and thus the zooming effect (if the initial
image is displayed already in hi-res but just scaled down to fit the
windows dimensions).  The scrolling does change only the Width/Height
dimensions of the image object, it will overleap the window. Through the
scrollbars or the afore-mentioned Focus Movement the contents of the
image can be shifted even while zoomed in. If you like, I can create a
basic sample application in Delphi for you, that shows what I mean.

>> Area Rendering
> I guess it is worth reconsidering what you actually want to achieve with
> such a feature, and consider alternative approaches.
> For instance, maybe a simple option to not erase the preview window when
> rendering a selected rectangle would already address your intended use case.
Yes, if the original image would remain, it would be a first step
towards the right direction. This, or my suggestion, would be useful.

>> MAYBE: Shape Info
> /That/ one actually sounds pretty neat and useful to me.
> It won't be easy to implement though: First, a way of "naming" the
> respective scene items would have to be designed; filename and line
> number may be insufficient, as multiple objects may be constructed by
> one and the same macro and hence at the same location in the source
> code. Also, the object names would need to be stored somewhere during
> rendering, which in scenes with a lot of objects might eat up a
> considerable amount of memory. Thus, maybe the most useful way to do
> this would be to have a new optional object property, e.g. "name", which
> would take an arbitrary string to identify the object. Such a feature
> would also come in handy for us developers when debugging code, so that
> we can see which object is currently being processed.
> Next, we'd need to modify the interface of the core render engine --
> which takes a single camera ray and currently just returns a colour --
> to somehow also inform which object was hit by the ray.
> Then we'd need to modify the interface of the render egine -- which
> currently only sends an image to the preview -- to also send the object
> identification information. For the sake of memory consumption, this
> information should be as compact as possible, so we may want to generate
> a kind of "object map" with different "colours" for each object, and an
> accompanying legend identifying which "colour" represents which object.
> And finally we'd of course need to modify the preview window to display
> the information to the user in a suitable manner.
Yes, my own thoughts before suggesting were:
The wonderful POV-Ray is IDing automatically each object, user-given
names can be prevented this way. POV creates a reference file with all
these item IDs in it. As all output happens (still) on a two-dimensional
image frame that is defined by the camera and has Width and Height
coordinates on that frame, maybe POV has a way to add these final
position coordinates behind each ID in that reference file. More than
one IDs can have overleaping 2D coordinates.
The final mouse-over hint label on the render output window could just
refer to that ID reference file, also giving attention to the zoom level
of that image object of the output window.
Not sure if my thoughts are of any help, though. :-)

> Some caveats to consider along the way:
> - What do we do if the first object hit is transparent? What if it is
> semi-transparent? What if it is reflective?
Transparent or not, more than one item can have overleaping IDs. The
mouse-over hint label would list them below each other, in no specific
order or with some order. The order doesn't matter too much, initially.
A reflected item does not count, reflections are to be ignored, I would say.

> - What if the object hit is a named child of an also named CSG object?
Same applies: more than one item can have overleaping IDs. The
mouse-over hint label would list them below each other, in no specific
order or with some order. The order doesn't matter too much, initially.

> - What about anti-aliasing, which will typically cause multiple
> independent objects to be blended together in a single pixel?
Maybe, a rough and crude first idea would be, to reduce the 2D
coordinates of each item by one or two pixels UNLESS the items measures
less than let's say 5 pixels. Let's accept in the first version some
unexactness until we have better ideas.

Post a reply to this message

Am 24.12.2015 um 18:36 schrieb Sven Littkowski:

>>> Zooming
>> That sounds more difficult to me.
> Nope. Totally easy to do (in Delphi).

It might be worth noting that the current Windows GUI dates back to the
times before GUI toolkits, so AFAIK it uses fundamental Windows APIs.
I'm not sure how difficult the Windows API for scroll wheel events is,
or what effort would be involved in implementing the zooming feature.

Post a reply to this message

Hmmmm, that might be a point. If you have to use that old code, then
indeed. I use Delphi (based on Pascal), and there many basic things are
done with the dragging and dropping of symbols of functions. There is
still some code to be written, of course, but just small amounts.

I once, eons ago, also had Pascal for Windows. That was the time before
visual programming, and there I had to learn all these Windows and
object classes and functions, too.

That render window is such an easy thing, I could at least easily create
such a window. It could do the display of the rendered image, and the
zoom, and the focus movement. But you guys manage somehow that is also
displays the unfinished image, that is what I don't know how to do.

And I am also not sure, if your C++ POV-Ray code could call a window
that was developed in Delphi/Pascal.

Post a reply to this message