This is a list of things I'd like to see in a future version
of POV-Ray. While none of these are massive changes, they are 
all capabilites that I would find useful. Some of these are much
more 'pie in the sky' than others.


1. Overlay textures.
    I'd like the ability of give an 'overlay texture' to a group
    (e.g. union, object, etc) that would work as an additonal layered
    texture above all the constituient objects textures. Useful for
    adding things like dust, grease, moss, that kinda thing, without
    having to go back an add to every object.

2. Faster scene file parsing
    I'm a computer programmer by trade, and I often do scenes that are
    very 'programatic', with lots of 'while' loops, and the like, and
    frankly, the POV-Ray scene parser is really slow. This is really
    obvious with something like POV-Tree, and animations can really 
    be an issue, especially on a relatively slow machine like mine
    (950mhz Athlon). I'm not quite sure what to do to improve things,
    but I would guess that the parser is working with the text directly
    , and not some sort of bytecode, or similar.

3. Implementation of transforms.inc in C
    This kinda ties into #2. I find myself using this file a lot,
    and it would be nice if these functions were implemented natively.

4. Ability to dump a object to a binary format
    This goes with 2. and 3. above. The desire here is to cut to the 
    chase and provide an efficient way to save and load objects. Again, 
    the idea here is to greatly reduce the speed hit for "recursive
    objects". I don't think things like platform or version independence
    are a big deal here, so maybe this wouldn't be too hard to code?

5. Lathe/prism hybrid. 
    It would be super handy to have an object that could be shaped 
    both in the x-z plane and have an 'edge shape'. I'm thinking of an
    implementation like this. First the object is built as a prism,
    then the edge shape is build at each point along the outside, 
    pointing along the surface normal. This would be really useful
    for all sorts of archetectural things, such as moldings, tabletops,
    etc, and I'm sure many organic things as well...

6. Progressive Render
    A lightwave plugin called 'fprime' gave me this idea. Basically a 
    scene is rendered first without things like anti-aliasing, 
    radiosity, photons, etc, and then the renderer uses intelligent 
    algorithmns to determine where those would have an impact, and 
    continually adds those details in. Basically you would allow the 
    render to continue until the desired quality is acheived, at which
    point it would be stopped. This would be handy when dealing with 
    deadlines, as the scene could begin rendering when finished, and
    then improved by the renderer up until the deadline, at which point
    the render as stopped and you take the result.

7. Spline curves
    What I mean by this is taking a 2d curve, as used in a prism, etc,
    and drawing it 'along' a spline. Useful for making troughs, gutters,
    many organic things, etc, especially if a start scale and end 
    scale could be specified.

8. A C(++) API
    This is another way of acheiving some of the above speed-related 
    goals. Allowing creating a pov-scene by linking against the API,
    giving code that builds a binary to render the scene. The ultimate
    for CPU intensive stuff.

9. A larger included texture library
    I'd really like to see some texture includes based on actual
    material properties. Things like the exisiting golds.inc/metals.inc
    are a good start, but more is always a good thing.

10. Better support for 3d Object formats
    I'd love to be able to to use things like Wings3D (or 3DS Max, etc)
    objects in my POV-Scenes directly.
    Maybe using a syntax like:
    extern_object{wings3d "foo.wings"}

Keep in mind these are just the ruminations of a bored POV-User,
and not meant to imply any dissatisfaction with the current state
of the program, just some ideas for future work.

Post a reply to this message

Tyler Eaves wrote:
> [...]
>     I'm a computer programmer by trade, 

In that case - why don't you try implementing things yourself.  The 
problem with your list is that most point fall into one (or more) of the 
following categories:

- inefficient.
- contradicting the design and goals of POV-Ray.
- particularly hard to implement (or next to impossible) in the current 
POV-Ray code.
- already possible/available.

This of course does not mean that all points are completely wrong but 
concerning the 3rd category - please read the note about POV-Ray 4.0 
discussions in the POV-Team status report in p.a.f-a-q.

Christoph

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

Post a reply to this message

"Tyler Eaves" <tyl### [at] NOSPAMml1net> wrote in message
news:pan### [at] NOSPAMml1net...
> This is a list of things I'd like to see in a future version
> of POV-Ray. While none of these are massive changes, they are
> all capabilites that I would find useful. Some of these are much
> more 'pie in the sky' than others.
>
>
> 1. Overlay textures.
>     I'd like the ability of give an 'overlay texture' to a group
>     (e.g. union, object, etc) that would work as an additonal layered
>     texture above all the constituient objects textures. Useful for
>     adding things like dust, grease, moss, that kinda thing, without
>     having to go back an add to every object.
>

if you had a macro that took texture names as parameters, and the result was
a set of layered textures, could that work? i'm imagining a syntax something
like

#macro overlay_textures(texture_01, texture_02, texture_03, overlay_texture)

and results would be a set of #declare statements that were like:

#declare layered_texture_01 =
    texture {texture_01}
    texture {overlay_texture}
#declare layered_texture_02 = ... and so on.

might even pass in an array of texture names and an overlay texture. could
you even pass in an array of result names, so you have more control over
what the #declare declares? Though you would still have to modify the
texture statements in your objects to use these new texture names, which
brings you back to going after every object that will use the overlay, and
editing it's texture. but there's always search/replace features in text
editors to help you on that :)

or, i have a general question (and no copy of pov to run on my computer to
try it out, i may have to remedy that), if you previously declared a texture
like

#declare my_gray = texture { ... }
#declare overlay = texture { ... }

then later do something like
#declare my_gray =
    texture {my_gray}
    texture {overlay}

how will that behave? would it make any difference if you use.

#local my_gray =
    texture {my_gray}
    texture {overlay}

i imagine pov will barf someplace along the line, especially once you get to
an object that tries to use some my_gray texture. i'm just trying to think
of some way to use the scope of the declarations to get around having to
edit the texture name used in an object.

but alas, i'm off track now and have rambled far too long. have you thought
of any reasonable workarounds yourself? I'll humbly wait for some pov master
to point out my logic flaws, and hope that maybe something triggered someone
else to think of something better :)

have a nice one,
ross

Post a reply to this message

Wasn't it Tyler Eaves who wrote:

>5. Lathe/prism hybrid. 
>    It would be super handy to have an object that could be shaped 
>    both in the x-z plane and have an 'edge shape'. I'm thinking of an
>    implementation like this. First the object is built as a prism,
>    then the edge shape is build at each point along the outside, 
>    pointing along the surface normal. This would be really useful
>    for all sorts of archetectural things, such as moldings, tabletops,
>    etc, and I'm sure many organic things as well...

While you're waiting for this to be implemented as a POV primitive, you
can use a parametric isosurface (or, for speed, closely approximated
with Ingo Janssen's param.inc). See my "Prismatic Lathe" example at
<http://www.econym.demon.co.uk/isotut/splines.htm#plathe>

Or you could use my sweepspline.inc to approximate this with a mesh2.
It's at the bottom of  <http://www.econym.demon.co.uk/isotut/more.htm>
It uses three splines to specify the shape - one for the 2d curve that's
used as a cross section, one for the 3d spline that the shape is swept
along, and a 1d spline that describes how the scale varies along the
length of the sweep.
For a lathe/prism hybrid, the 3d spline would be a straight line.

>7. Spline curves
>    What I mean by this is taking a 2d curve, as used in a prism, etc,
>    and drawing it 'along' a spline. Useful for making troughs, gutters,
>    many organic things, etc, especially if a start scale and end 
>    scale could be specified.

While you're waiting for this to be implemented as a POV primitive, you
can use my sweepspline.inc (see above).

If you only want to linearly interpolate between a start scale and end
scale, then use a simple linear spline for the 1d "Waist" spline rather
than a more complicated spline.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Hi mike,

Lars Petter in the thread: 'questions on parametric objects
and 3d splines'
is looking for your SweepSpline macro's. The zip file you
posted in november seems to be broken.

	Andrel

Mike Williams wrote:

> Wasn't it Tyler Eaves who wrote:
> 
> 
>>5. Lathe/prism hybrid. 
>>   It would be super handy to have an object that could be shaped 
>>   both in the x-z plane and have an 'edge shape'. I'm thinking of an
>>   implementation like this. First the object is built as a prism,
>>   then the edge shape is build at each point along the outside, 
>>   pointing along the surface normal. This would be really useful
>>   for all sorts of archetectural things, such as moldings, tabletops,
>>   etc, and I'm sure many organic things as well...
> 
> 
> While you're waiting for this to be implemented as a POV primitive, you
> can use a parametric isosurface (or, for speed, closely approximated
> with Ingo Janssen's param.inc). See my "Prismatic Lathe" example at
> <http://www.econym.demon.co.uk/isotut/splines.htm#plathe>
> 
> Or you could use my sweepspline.inc to approximate this with a mesh2.
> It's at the bottom of  <http://www.econym.demon.co.uk/isotut/more.htm>
> It uses three splines to specify the shape - one for the 2d curve that's
> used as a cross section, one for the 3d spline that the shape is swept
> along, and a 1d spline that describes how the scale varies along the
> length of the sweep.
> For a lathe/prism hybrid, the 3d spline would be a straight line.
> 
> 
>>7. Spline curves
>>   What I mean by this is taking a 2d curve, as used in a prism, etc,
>>   and drawing it 'along' a spline. Useful for making troughs, gutters,
>>   many organic things, etc, especially if a start scale and end 
>>   scale could be specified.
> 
> 
> While you're waiting for this to be implemented as a POV primitive, you
> can use my sweepspline.inc (see above).
> 
> If you only want to linearly interpolate between a start scale and end
> scale, then use a simple linear spline for the 1d "Waist" spline rather
> than a more complicated spline.
>

Post a reply to this message

Tyler Eaves <tyl### [at] nospamml1net> wrote:
> 1. Overlay textures.
>     I'd like the ability of give an 'overlay texture' to a group
>     (e.g. union, object, etc) that would work as an additonal layered
>     texture above all the constituient objects textures. Useful for
>     adding things like dust, grease, moss, that kinda thing, without
>     having to go back an add to every object.

  This would certainly be useful.

> 2. Faster scene file parsing
>     I'm a computer programmer by trade, and I often do scenes that are
>     very 'programatic', with lots of 'while' loops, and the like, and
>     frankly, the POV-Ray scene parser is really slow. This is really
>     obvious with something like POV-Tree, and animations can really 
>     be an issue, especially on a relatively slow machine like mine
>     (950mhz Athlon). I'm not quite sure what to do to improve things,
>     but I would guess that the parser is working with the text directly
>     , and not some sort of bytecode, or similar.

  POV-Ray's scene parsing is certainly very slow. This is mainly for
historical reasons. The first versions of POV-Ray (up to 2.2 if I don't
remember completely wrongly) did not have any "scripting language" per se.
It was a pure scene description language, with no flow control commands,
and thus it really didn't need to be very fast. Thus it just parses and
interpretes the text directly.
  Flow control commands (#if, #while, #switch, #macro, etc) were added
afterwards because the need for them was overwhelming. However, they
were added on top of the old parser and are bound to its limitations.
  Optimizing the parsing needs a complete redesign of the parser. Probably
the best way is to do it the same way as perl does: Perl compiles the
source code to bytecode and then interpretes this bytecode, which makes
it pretty fast.
  I wouldn't be surprised if a future version of POV-Ray would do exactly
this. In fact, part of the current parser already does this: The function
parser/interpreter (this is the reason why functions are so fast compared
to eg. #macros).

> 3. Implementation of transforms.inc in C
>     This kinda ties into #2. I find myself using this file a lot,
>     and it would be nice if these functions were implemented natively.

  I tend to disagree with this. Specially if a future version of POV-Ray
has the abovementioned optimizations, the need for a core code implementation
of these features is lessened.

  There are actually more advantages than disadvantages in having features
implemented with the POV-Ray SDL: They are more flexible (you can change
or enhance them easily) and they don't clutter the core code of POV-Ray
(the larger the source code, the more bugs it will contain). It's also
easier for people to learn from them.
  The disadvantage is that you can't implement every imaginable feature
with the SDL because of its limitations (for example a renderman-style
shader engine would be something impossible to do with the SDL), and
naturally speed is an issue.
  The advantage of a core code implementation is speed. The disadvantage
is that the feature is then hard-coded, it can't be easily changed or
enhanced, and it adds to the clutter of the source code (adding the
probability of more bugs). It's also harder for people to learn from it.

> 4. Ability to dump a object to a binary format
>     This goes with 2. and 3. above. The desire here is to cut to the 
>     chase and provide an efficient way to save and load objects. Again, 
>     the idea here is to greatly reduce the speed hit for "recursive
>     objects". I don't think things like platform or version independence
>     are a big deal here, so maybe this wouldn't be too hard to code?

  If bytecode compiling/interpreting is implemented, then this feature
shouldn't be a problem.

> 10. Better support for 3d Object formats
>     I'd love to be able to to use things like Wings3D (or 3DS Max, etc)
>     objects in my POV-Scenes directly.
>     Maybe using a syntax like:
>     extern_object{wings3d "foo.wings"}

  This has maintainability problems. As you have noticed, new versions
of POV-Ray are not published every other week (and there are very good
reasons for this). New versions of popular 3D formats come out much more
often than new versions of POV-Ray. See the problem?

  Enhancing the SDL so that it can read and parse these file formats
would be a much better solution. SDL libraries are much easily updated
than POV-Ray itself. Besides, this solution is more generic, flexible and
thus better.

-- 
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

In article <pan### [at] NOSPAMml1net>,
 Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:

> 1. Overlay textures.

I think the layered texture syntax in general needs reworking. This and 
a mechanism for stripping all textures from an object, and perhaps a way 
of operating on specific sub-objects.


> 2. Faster scene file parsing

Switching from direct parsing to an interpreted opcode system would 
greatly speed parsing of complex code. However, doing it right could be 
difficult. It would mean very extensive changes to the language. The end 
result will probably be an interpreted language with a very flexible 
preprocessor, basically equivalent to the existing scriping language.


> 3. Implementation of transforms.inc in C
>     This kinda ties into #2. I find myself using this file a lot,
>     and it would be nice if these functions were implemented natively.

This becomes less necessary with #2. Also, having them in an include 
file rather than built into the POV-Ray executable means users can look 
at and modify them, and they can be updated or added to separately from 
the main program. Some language extensions could allow them to be used 
as a built-in feature would be.


> 4. Ability to dump a object to a binary format
>     This goes with 2. and 3. above. The desire here is to cut to the 
>     chase and provide an efficient way to save and load objects. Again, 
>     the idea here is to greatly reduce the speed hit for "recursive
>     objects". I don't think things like platform or version independence
>     are a big deal here, so maybe this wouldn't be too hard to code?

This one comes up every so often...it'd be really complex to do, the 
data structures can be very complex. However, dumping the instructions 
for creating the object might be possible.


> 5. Lathe/prism hybrid. 

An interesting idea...generating a mesh would be fairly simple, and it 
might be possible to trace it directly.


> 6. Progressive Render
>     A lightwave plugin called 'fprime' gave me this idea. Basically a 
>     scene is rendered first without things like anti-aliasing, 
>     radiosity, photons, etc, and then the renderer uses intelligent 
>     algorithmns to determine where those would have an impact, and 
>     continually adds those details in. Basically you would allow the 
>     render to continue until the desired quality is acheived, at which
>     point it would be stopped. This would be handy when dealing with 
>     deadlines, as the scene could begin rendering when finished, and
>     then improved by the renderer up until the deadline, at which point
>     the render as stopped and you take the result.

Not really practical, at least not in the way you describe. It would be 
either extremely slow or outrageously memory consuming, or both. 
Lightwave probably uses some form of scanlining for this, and just 
refines lighting maps...POV can not do this, being a raytracer and not 
using light maps.
However, it would be possible to continuously update antialiasing, or to 
do a low quality render, refine the radiosity and photon data, and then 
do a higher quality render.


> 7. Spline curves
>     What I mean by this is taking a 2d curve, as used in a prism, etc,
>     and drawing it 'along' a spline. Useful for making troughs, gutters,
>     many organic things, etc, especially if a start scale and end 
>     scale could be specified.

You're talking about spline sweeps? They're already possible...just 
build a mesh using the built-in splines.


> 8. A C(++) API
>     This is another way of acheiving some of the above speed-related 
>     goals. Allowing creating a pov-scene by linking against the API,
>     giving code that builds a binary to render the scene. The ultimate
>     for CPU intensive stuff.

Not practical. There is no standard way of loading object code on 
different platforms, and the code itself would have to be compiled for 
the platform the scene is to be rendered on. Including a compiler along 
with POV would be a lot of effort, and distributing precompiled code 
would create compatibility problems.


> 9. A larger included texture library
>     I'd really like to see some texture includes based on actual
>     material properties. Things like the exisiting golds.inc/metals.inc
>     are a good start, but more is always a good thing.

I agree, and a lot of the existing textures simply do not work well with 
modern scenes. For instance, things like high ambient values that make 
them look really bad when you have radiosity, or simply not using more 
realistic features added since the texture was created. It would be a 
huge amount of work, though. Perhaps a community project...


> 10. Better support for 3d Object formats
>     I'd love to be able to to use things like Wings3D (or 3DS Max, etc)
>     objects in my POV-Scenes directly.
>     Maybe using a syntax like:
>     extern_object{wings3d "foo.wings"}

This would be a bad idea...incompatibilities, trying to keep up with the 
latest version of the format used by the software, etc. However, the 
ability to load the geometry from some common, more generic formats 
would be useful. Doing more than just the geometry and perhaps UV-mapped 
textures would be difficult or impossible, because of differences in the 
way POV-Ray works and the features it offers.

-- 
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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:405771a3@news.povray.org...
>   I wouldn't be surprised if a future version of POV-Ray would do exactly
> this. In fact, part of the current parser already does this: The function
> parser/interpreter (this is the reason why functions are so fast compared
> to eg. #macros).

I always thought the reason that parsing scenes was slow had nothing to do
with the actual parser, and everything to do with memory allocation.  I seem
to remember reading about this in the vfaq and on this ng, but I can't seem
to find anything on it now.

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

Chambers <bdc### [at] yahoocom> wrote:
> I always thought the reason that parsing scenes was slow had nothing to do
> with the actual parser, and everything to do with memory allocation.  I seem
> to remember reading about this in the vfaq and on this ng, but I can't seem
> to find anything on it now.

  When creating tons of objects or very big objects (such as gigantic
meshes), the main slowdown is indeed memory allocation.
  However, if you make code which calculates something without creating
objects, then quite obviously memory allocation is not an issue there.
  If you want a concrete example, look at the raytracer made with the SDL
in the docs... :)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <40577904@news.povray.org>, bdc### [at] yahoocom says...
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:405771a3@news.povray.org...
> >   I wouldn't be surprised if a future version of POV-Ray would do exactly
> > this. In fact, part of the current parser already does this: The function
> > parser/interpreter (this is the reason why functions are so fast compared
> > to eg. #macros).
> 
> I always thought the reason that parsing scenes was slow had nothing to do
> with the actual parser, and everything to do with memory allocation.  I seem
> to remember reading about this in the vfaq and on this ng, but I can't seem
> to find anything on it now.
> 
> 
One thing that would be very helpful in byte code is 'parse once, run 
multiple times'. If you are doing animation, more time is spent parsing 
the damn scene in some cases than rendering. Byte code would not need to 
be reparsed unless the original actually changed, so would execute much 
faster and save a fair amount of time. Having to reparse it every single 
time as is done now....

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message