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