 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] NOSPAMml1 net> 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
|
|
| |
| |
|
|
|
|
| |
|
|
