POV-Ray : Newsgroups : povray.programming : A few ideas : A few ideas Server Time
29 Jul 2024 06:14:29 EDT (-0400)
  A few ideas  
From: Mike Hough
Date: 31 May 1998 06:55:18
Message: <35713716.4E875048@aol.com>
I've tried going through the POV source and figure out how to do a few
of these things, but I didn't even come close (I can't really program),
so I thought I'd post a few ideas for additions to POV if anyone wants
to take a crack at them.

1)A true spherical camera, such that if rendered and then mapped onto a
sphere in POV would look just like the original scene.  Such images
could be used in VRML, Livepicture, or QTVR.  I think the trick here is
that a ray for the screen space should be matched to a sphere.  I
couldn't figure it out, but I know it can be done.  I actually found
where I think this would be added in create_ray in render.c.

2)A distance mask.  This is pretty easily done by making a union of the
scene and applying a gradient, but would be much more useful if it could
be rendered to the alpha channel of a tga or png image.  Two types would
be useful.  The first would invlove going from Black at the camera and
White going into the image, becoming completely white at a distance
specified in the scene file.  The resulting image could have a color
added to it with the mask in place to create a very quick fog.  The
second type would use a focal point for the center of the black area of
the image and then would become lighter (eventually to white) as the
distance away from the focal point increases in line with the camera
direction.  The resulting image could then have a gaussian blur added to
it to create a blur effect in a much shorter amount of time.  It could
also be saved and reused after changes have been made to a scene
provided the camera and object do not move.

The first one is mostly for fun, but it sure would provide an
interesting way to render and view scenes created with POV-Ray.  The
second is a way of speeding up a some of the slower features of POV
through the use of Post-processing (though all info is created by the
renderer).  The post-processing could probably even be handled by the
renderer.  Atmospheric effects could even be added to the list of
options.

3)This is a little more involved, but I've been wondering if a patch
mesh primitive would be more useful than the present bi_cubic patch.
This could allow a group of meshes to be treated as one object and a uv
space could be generated for the whole mesh. Could make parametric
mapping a more realistic proposition in the future, though I imagine
writing a modeller to handle them would require a little more work.  (I
stole the idea from BMRT, so sue me)

Some of these may sound silly (they are from my long running wish list),
but I'm sure there's a winner in there somewhere ;-) <---anti-flame wink

-Mike


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.