Let's make a nice big list of all the features people would like to see in
an official/unofficial version of POVRay!

I'll start it off with a couple of items.

Bicubic texture filtering. There is actually a #DECLARE statement for cubic
filtering in the POV source, but there is no implementation that uses it.

Fractal texture filtering. I've seen a sample image that has been resized
using fractal interpolation, and did it ever look good.

Displacement mapping. I've read a bit about it in a magazine (although this
article was about it in DirectX 9), and it sounds like it would be quite
useful in POVRay. Add a displacement{} block with the appropriate contents,
just like the normal{} one.

I'll leave it to the rest of you to come up with some more items for the
list.

Rohan _e_ii

Post a reply to this message

In article <web.3edf5ebd7e2b69fbaa7c54710@news.povray.org>,
 "Rohan Bernett" <rox### [at] yahoocom> wrote:

> Bicubic texture filtering. There is actually a #DECLARE statement for cubic
> filtering in the POV source, but there is no implementation that uses it.

That shouldn't be too hard.


> Fractal texture filtering. I've seen a sample image that has been resized
> using fractal interpolation, and did it ever look good.

Aside from being highly complex to implement, this would probably slow 
things down a lot. You'd be better off resizing outside of POV, and 
using a computationally cheaper method in the rendering.


> Displacement mapping. I've read a bit about it in a magazine (although this
> article was about it in DirectX 9), and it sounds like it would be quite
> useful in POVRay. Add a displacement{} block with the appropriate contents,
> just like the normal{} one.

This one has been discussed a *lot*. To summarize: it is possible, but 
is far from simple. General displacement would require tessellation of 
all objects, which is possible but a real pain to implement.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

BTW, here's the POV-related stuff on my own "to-do" list.

voxelize pigment/pattern: what I originally called "smooth blur", takes 
samples at the vertices of a 3D lattice (like the corners of the 
checkers pattern) and interpolates between them. With a fine enough 
lattice, it might allow infinite gradients in things like the object 
pattern to be softened enough for efficient isosurface solving without 
too many artifacts.

blur pigment/pattern: What it says, it blurs a pigment or pattern.

portal pigment: I've made some posts about this before, I just need to 
get it into release-ready form. It's a pigment that serves as a "portal" 
into another area of the scene.

Tessellation: I'm working on my own tessellation patch. Others have done 
general tessellation methods, I'm doing shape-specific methods. So far 
I've got nice tessellations for spheres, cylinders, cones, and a few 
other shapes.

Glow: I want to eventually have a glow feature that allows point, line, 
hoop, and spline glows (think of neon lights for that last one) as well 
as object glows. The last feature will require the tessellation patch.

Proximity and curvature patterns: I have some ideas for making the 
rendering faster while getting rid of grainyness with the general 
method, and object-specific methods that are very fast.

point_field object, displaced_mesh.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> portal pigment: I've made some posts about this before, I just need to 
> get it into release-ready form. It's a pigment that serves as a "portal" 
> into another area of the scene.

  I see two possible ways of implementing this:

  1: The pigment works as a projection plane of a secondary camera. That is,
     When the color of the point <x,y> is asked from the pigment, these
     coordinates are converted to the secondary projection plane coordinates,
     and a ray is raytraced from the secondary camera passing through that
     point.
       The effect of this method is exactly the same as if you had rendered
     an image with the secondary camera and then used this resulting image
     as an image map in the final scene (which is rendered using the main
     camera). The advantage being, of course, that only those pixels which
     are really needed are traced and you don't need a temporary image file.

  2: The pigment warps rays to another location. That is, when a ray hits
     the object and the color of the surface is requested, a given offset
     is added to the intersection point and a new ray is traced in the
     same direction as the original incoming ray. A given transformation
     may be applied to the ray as well.
       This would allow making, eg. windows which show scenery from a
     completely different part of the scene (ie. which are not really
     behind that window). The difference with the implementation 1 is
     that when you move the camera, you see different parts of the
     scene through the portal.

  I think that both of these variants are useful. It might be a good idea
to implement them both.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

On 5 Jun 2003 13:19:15 -0400, Warp <war### [at] tagpovrayorg> wrote:
>  I think that both of these variants are useful. It might be a good idea
> to implement them both.

Case 1 is already in MegaPOV 1.1 code. It is called camera_view{}. It can be
used as follow:
   pigment{ camera_view{ CAMERA_IDENTIFIER || CAMERA_SYNTAX } }
Has to wait for 3.51 unfortunatelly.

ABX

Post a reply to this message

In article <3edf7b93@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   1: The pigment works as a projection plane of a secondary camera. That is,
>      When the color of the point <x,y> is asked from the pigment, these
>      coordinates are converted to the secondary projection plane coordinates,
>      and a ray is raytraced from the secondary camera passing through that
>      point.

Someone else wrote a camera pigment patch which does this.


>   2: The pigment warps rays to another location. That is, when a ray hits
>      the object and the color of the surface is requested, a given offset
>      is added to the intersection point and a new ray is traced in the
>      same direction as the original incoming ray. A given transformation
>      may be applied to the ray as well.

This is what my portal pigment does. It is not just an offset, it is a 
full transformation. I've used it to make something look like a 
"gateway" to another world and to make one of those infinitely 
self-containing scenes, where the entire scene was visible in a crystal 
ball in the center of the scene. Other effects are based on making the 
ray directions interact with the normal.

Here's my original post:
http://news.povray.org/povray.binaries.images/13490/

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Rohan Bernett wrote:

> Let's make a nice big list of all the features people would like to see in
> an official/unofficial version of POVRay!

I would like to see some of POVMan's nice surfaces and finishes implemented 
in POV-Ray. I really like this anisotropic reflections or FSSS. 
Unfortunately I'm not familiar with renderman specs so I cannot really use 
POVMan.

Regards,
Andreas

-- 
http://www.render-zone.com

Post a reply to this message

Rohan Bernett wrote:
> 
> Let's make a nice big list of all the features people would like to see in
> an official/unofficial version of POVRay!

I don't think this is a good idea, a lot of 'i want' without much
knowledge about how something works and if it is necessary at all is not
very helpful.  An 'i would like to see feature XXX in POV-Ray' when XXX is
anything someone has read about in an advertisement for whatever program
won't lead to anything.

There is nothing against putting together a list but this would only be
valuable when at least someone has already seriously made up his mind
about any item in that list.  

If you want to discuss an idea for a new feature it is usually better to
post about what effect you are trying to achieve and possibly why you are
not content with the way this is currently possible in POV.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Rohan Bernett wrote:
> Let's make a nice big list of all the features people would like to see in
> an official/unofficial version of POVRay!

I am wondering if there are so many programmers out there who are 
wondering what project to do next. I am under the impression that most 
are rather overwhelmed by their own project (pov patches, other 
programming and RL).


Povingly,


Philippe

Post a reply to this message

"Rohan Bernett" <rox### [at] yahoocom> wrote in message
news:web.3edf5ebd7e2b69fbaa7c54710@news.povray.org...

I'm waiting patiently for the camera_view pigment and perhaps at a later
date a scene pigment where a pigment is taken from an entirely separate
scene.

I would also like to see uv_mapping for functions, so that uv_mapped and
traditional pigments can be combined and manipulated the way that other
function pigments can.

The point of my response however is to ask how polygon displacement can
do anything which isosurfaces cannot do. I would like some clarification
because now I really cannot see the point.

What would be interesting is a set of mesh structures which could be
"built" when rendering and require less memory usage. For example, a
mesh box which would only need 8 vertices stored in memory. PoV-Ray
would know where the 12 triangles should be. This would be most useful
for grass, tiny spaceship details, flower petals, etc. Even better would
be some way to define a set list of triangles (as vertex list
references) for any list of the correct number of vertices. Just
throwing this out there. I've of course got no idea how to implement it.

 -Shay

Post a reply to this message