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