clipka <ano### [at] anonymousorg> wrote:

> An object that is part of a CSG but doesn't take part in CSG?
> That makes absolutely NO sense to me at all. Care to try a different
> approach at explaining it to me?

It doesn't make any less sense than having an object in between a light source
and another object, yet not cast a shadow.  (no_shadow)
or not be reflected (no_reflection)
or not even "be there" at all (no_image)

I guess the idea is that if you're stuck defining an object in a scene, and for
"reasons", it needs to be defined within some sort of CSG operation, then it
might be useful to "opt it out" of the CSG.
Not sure if it's possible with the way the rendering engine is coded, but it
seemed like something I'd post here for consideration.


> > A split, or multi-image feature.
> > Let's say I want to render a LARGE image, and want it split up in a 3x3 grid
> > into 9 images of equal size.
> > Related to this, I was thinking that the partial render feature would be nice if
> > there were a way to select a region, and have it get saved to a secondary file
> > aside from the main render.
>
> Have /what/ get saved -- the partial render parameters? The image? And
> what do you mean by "aside from the main render?"

Yes.
Have the selected region be saved as a small image, independent of the larger
main render window.  If I select an 80x80 pixel region to render, and my
resolution is set at 640x480, then POV-Ray normally saves the 640x480 as
filename.png.  I just thought it might be useful to ALSO save the selected 80x80
region as a seperate file - with a suffixed filename like filename(1).png or
filename_selection.png.


> Are you thinking along the lines of a kind of "auto-crop" feature,
> effectively trimming down your output image to contain only the portion
> actually rendered?

Yes, but the auto-cropped, trimmed-down output image gets saved in addition to
the usual output.


> I see nothing that stands in the way of implementing such stuff as
> macros, except maybe for the fact that trace() does not currently return
> UV coordinates.

Doesn't trace() return the coordinates of the object's surface, regardless of
color/texture?
If I have an object patterned by onion or wood, trace() would only return the
coordinates of the outermost surface.
I'm suggesting a trace() that would go THROUGH any color other than the one
specified.  Just a light ray goes through a pigment with a transmit value of 1
even though the object is still there.

Post a reply to this message