Peter Popov wrote:
> 
> With time I've compiled a list of features I would be happy to see in
> POV-Ray. I think it wouldn't hurt if I posted it here.

Here is my little wish list - tee hee !

1.) displacement mapping

2.) export capabilities pov2???

3.) programmable shaders ala renderman

4.) the ability to internaly tesselate POV-Ray primatives

5.) subdivision surfaces

6.) extended capabilities for the warp turbulence feature

7.) nurbs

and...

and...

and...

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Actually, I have an associative array (of sorts) that I've written here
: that has an O(1) increment, not amortized.  It's a threaded 2-3 tree.  
: Indexing is still, of course, O(log n), as are insertion and deletion.

  How can the increment of the iterator be O(1) non-amortized with a tree?
Unless you have next-pointers in each node making the container also a
linked list... (well that _is_ a solution but it takes a little bit more
memory).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: TMTOWTDI, indeed.

  Sorry?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Tue, 29 Feb 2000 05:06:01 -0800, Ken wrote:
>
>
>Peter Popov wrote:
>> 
>> With time I've compiled a list of features I would be happy to see in
>> POV-Ray. I think it wouldn't hurt if I posted it here.
>
>Here is my little wish list - tee hee !
>
>1.) displacement mapping
>
>2.) export capabilities pov2???
>
>3.) programmable shaders ala renderman
>
>4.) the ability to internaly tesselate POV-Ray primatives
>
>5.) subdivision surfaces
>
>6.) extended capabilities for the warp turbulence feature
>
>7.) nurbs

Most of these are perfectly reasonable things to wish for.  (1) and (2) are of
course rather dependent on (4), and of course that ability would be limited to
the primitives that can be tesselated.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 29 Feb 2000 08:15:51 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Actually, I have an associative array (of sorts) that I've written here
>: that has an O(1) increment, not amortized.  It's a threaded 2-3 tree.  
>: Indexing is still, of course, O(log n), as are insertion and deletion.
>
>  How can the increment of the iterator be O(1) non-amortized with a tree?
>Unless you have next-pointers in each node making the container also a
>linked list... (well that _is_ a solution but it takes a little bit more
>memory).

That's the "threaded" part.  It's actually a doubly-linked list.  Memory is
cheaper than processor time in this application.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 29 Feb 2000 08:16:15 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: TMTOWTDI, indeed.
>
>  Sorry?

The Perl motto: There's More Than One Way To Do It.  Not true in this case.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Wouldn't displacement mapping require LOTS of triangles? And I mean _LOTS_.
  Just think that you want to apply a 640x480 displacement map to each side
of a cube. If I have understood correctly, you will need at least 2 triangles
per map pixel (like in a heightfield), which would make a total of at least
640x480x2x8 = 4915200 triangles.
  Since this kind of triangle mesh can not (AFAIK) be optimized like a
height field can be, it would take rather lot of memory.

  Perhaps I'm just exaggerating.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
>   Wouldn't displacement mapping require LOTS of triangles? And I mean _LOTS_.
>   Just think that you want to apply a 640x480 displacement map to each side
> of a cube. If I have understood correctly, you will need at least 2 triangles
> per map pixel (like in a heightfield), which would make a total of at least
> 640x480x2x8 = 4915200 triangles.
>   Since this kind of triangle mesh can not (AFAIK) be optimized like a
> height field can be, it would take rather lot of memory.
> 
>   Perhaps I'm just exaggerating.

Since other programs offer this feature there must be some way to optimize
the process so it is not so memory and parsing intensive. There must be :)

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On 29 Feb 2000 08:24:35 -0500, Nieminen Juha wrote:
>  Wouldn't displacement mapping require LOTS of triangles? And I mean _LOTS_.
>  Just think that you want to apply a 640x480 displacement map to each side
>of a cube. If I have understood correctly, you will need at least 2 triangles
>per map pixel (like in a heightfield), which would make a total of at least
>640x480x2x8 = 4915200 triangles.
>  Since this kind of triangle mesh can not (AFAIK) be optimized like a
>height field can be, it would take rather lot of memory.
>
>  Perhaps I'm just exaggerating.

There are ways to make it less memory-intensive.  One is to displacement-map 
adaptively.  This is particularly useful if you have information on the 
footprint of the ray, but if you're not careful it can lead to cracking.  
Another is to displacement-map on demand and cache the results, but 
raytracing can be markedly less coherent than other rendering methods, so a 
cache might not be as good a solution in a raytracer.  There have been a 
number of papers written on the subject.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Chris Huff wrote:
> 
> In article <38B7FCCF.A533B213@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> 
> > I didn't mean not to include the z-depth option, just that using planar
> > mapping would make a lot of uses difficult.  Maybe reuse the mapping
> > keyword here, I could see at least spherical, planar and cylindrical
> > being useful.
> 
> Not planar mapping, spherical mapping. Distance would be z, and
> vertical/horizontal angle would be x and y, and the center would be the
> light_source position. It would be like wrapping the pigment around the

Sorry, I read x and y and assumed planar mapping.

> sphere, except the color also varies depending on it's distance from the
> center of the sphere. You would have to tile it in some cases(many times
> the tiling wouldn't be visible), but I don't see any other way of
> mapping 3D space around a point. Maybe also cylinderical mapping.

Planar would be useful for image mapped lights such as slide projectors.

> 
> > Here's something if you had z-depth.  Use a density file as the pattern
> > and project 'solid' holograms into media with shadowing from intervening
> > objects :)
> 
> That is an idea...although I guess it could also be done with scattering
> media using the density file and a plain colored light, at least as long
> as no other lights interact with it.

That's pretty much what I'd do with current POV, but it'd look pretty
cool in an animation with characters walking in front of the projector.

PoD.

Post a reply to this message