I would like to see a number of features removed from the POV-Ray C 
source code.  These include:

	- all primitive shapes - sphere, plane, cone, quadric, etc.
	- all defined textures - wood, marble agate, checker, etc.
	- all surface normal effects - ripples, waves
	- all light sources - spotlight, area_light, etc.
	- all atmospheric effects - fog, absorption, scattering, etc.
	- lots of other superfluous stuff

Once this is all gone, you will end up with a much simpler raytracer 
that does very little.  This is the perfect starting point.

Now, you build a very simple but very expressive SDL grammar that allows 
you to express graphical modeling concepts very simply.  With this SDL, 
you can then define what "sphere" means but this time it's written in 
the SDL language, not in C.  You can define what marble means.  You can 
define what fog means.  All of these definitions become part of the SDL 
and are included in a library which people can use.

Now, POV-Ray users can define their own textures and add them to the 
system.  They can add their own shapes, their own light sources, their 
own atmospheric effects.  They would have much more power than they ever 
had.  If done well, users would hardly notice the difference unless they 
wanted to use the extra power.

POV-Ray should be a small simple engine to render user-defined shapes 
with user-defined textures and user-defined light sources.  To make them 
user defined, you have to push them from the cryptic and inaccessible C 
source into the SDL.

It will certainly take a considerable amount of redesign, but I feel 
it's the best way to go.  Less is more - take advantage of that.

David Buck

Post a reply to this message

POV++
?

;)


-- 
-Nekar Xenos-

Post a reply to this message

> With this SDL, you can then define what "sphere" means but this time it's 
> written in the SDL language, not in C.  You can define what marble means. 
> You can define what fog means.  All of these definitions become part of 
> the SDL and are included in a library which people can use.

Your idea sounds good in theory.  In fact I would also like to see all the 
lighting code removed, to be replaced by standard SDL libraries for 
diffuse/specular etc.  The user is then free to implement their own lighting 
models should they wish.

I suppose the SDL would also need to be extended so that users could specify 
the ray/shape intersection algorithm - otherwise it's going to be like 
making everything out of isosurfaces...

Post a reply to this message

David Buck <dav### [at] simberoncom> wrote:
> Now, you build a very simple but very expressive SDL grammar that allows 
> you to express graphical modeling concepts very simply.  With this SDL, 
> you can then define what "sphere" means but this time it's written in 
> the SDL language, not in C.

  This is a good idea only if you want your renders to take at least
10 times longer than currently.

  Not only are the C(++) implementations of the primitives faster because
the compiler can optimize them, they are also optimized on a per-primitive
basis. For example, a sphere is not a generic polynomial object which is
solved while raytracing. A sphere is a very specific piece of code which
has been optimized to calculate the intersection points between a line
and a spherical surface.

  If, however, now you would change that to a generic surface definition
language where the user specifies that "a sphere is an isosurface defined
by the function ..." the render times will sky-rocket. Solving a generic
user-written isosurface function is much slower than the optimized
ray-sphere C++ code.

  If the answer to this is "ok, then let's add an internal 'sphere' function
which is optimized for speed and which the user can call" then we are
exactly where we are now. Nothing would have changed.

  The whole idea of POV-Ray is speed. Why do think that thousands of
hours of work has been put into making POV-Ray support multi-threading?
For speed, only speed and nothing but speed.

  Killing this speed kind of defeats the whole purpose.

-- 
                                                          - Warp

Post a reply to this message

I don't want to get into an argument with povray's father, but...

David Buck wrote:
> POV-Ray should be a small simple engine to render user-defined shapes 
> with user-defined textures and user-defined light sources.  To make them 
> user defined, you have to push them from the cryptic and inaccessible C 
> source into the SDL.

but aren't functions already available for user-defined shapes and 
textures?  Aren't isosurfaces slower to calculate than the quadratic 
primitives?  Isn't SDL parsing time an aditional problem?

> Less is more - take advantage of that.

yes, but optimized solutions are good too.  C is very good at that. 
Besides, all renderers I know of offer the quadratic geometric 
primitives for granted, including Renderman.

I see no reason why user-defined and slower shapes, textures or shaders 
should take precedence over well-known and optimized builtin techniques 
for rendering quadratics, phong shading and company...

certainly, it'd be cool to have user-defined shaders, but also keep with 
the oldies and fasties...

Post a reply to this message

Warp wrote:
> David Buck <dav### [at] simberoncom> wrote:
>> Now, you build a very simple but very expressive SDL grammar that allows 
>> you to express graphical modeling concepts very simply.  With this SDL, 
>> you can then define what "sphere" means but this time it's written in 
>> the SDL language, not in C.
> 
>   This is a good idea only if you want your renders to take at least
> 10 times longer than currently.

And I am willing to back down considerably from my extreme position :-). 
  My point is that it should be possible to define a sphere or a plane 
in the SDL.  If performance dictates that a primitive shape is more 
efficient, then move it down to the C level for efficiency purposes. 
But keep the ability for the SDL to define new shapes, new textures, new 
light sources, etc.  Some of the lesser used ones may even stay at the 
SDL level.

There are ways to do this nicely. One important aspect is to try things, 
measure the performance, and optimize accordingly.  You'd be surprised 
at how many things you think are bottlenecks really aren't.

BTW, I implemented a quick raytracer in Smalltalk and rendered a simple 
scene only 5 times slower than POVRay (and I didn't work too hard at 
optimizing it).

David

Post a reply to this message

David Buck <dav### [at] simberoncom> wrote:
>   My point is that it should be possible to define a sphere or a plane 
> in the SDL.

  It is, using an isosurface or a poly object.

> But keep the ability for the SDL to define new shapes, new textures, new 
> light sources, etc.

  A shader language is one of the ideas for pov4. It's not mutually
exclusive with existing textures.

> BTW, I implemented a quick raytracer in Smalltalk and rendered a simple 
> scene only 5 times slower than POVRay

  It's relatively easy to make a raytracer in any language which renders
a *simple* scene in a comparable time. However, put for example 100000
spheres in that scene and them compare. ;)

-- 
                                                          - Warp

Post a reply to this message

>   My point is that it should be possible to define a sphere or a plane
> in the SDL.  If performance dictates that a primitive shape is more
> efficient, then move it down to the C level for efficiency purposes.
> But keep the ability for the SDL to define new shapes, new textures, new
> light sources, etc.  Some of the lesser used ones may even stay at the
> SDL level.

That seems like the best of both worlds people for people who want better ways
to define custom objects in the SDL, versuses people who would rather use
primitive to maintain render efficiency. It would be awesome if both were
included!

Just be sure to keep the SDL simpler than C or C++; One of the main reasons
POVRay is so attractive to people (myself included) is its simplicity in use
compared to those other cumbersome programming languages.

-Woody

Post a reply to this message

> Just be sure to keep the SDL simpler than C or C++; One of the main reasons
> POVRay is so attractive to people (myself included) is its simplicity in use
> compared to those other cumbersome programming languages.


And other raytracers with scripting capability. Anim8or uses a scripting
language suspiciously like C/C++. (Possibly making it easier to parse, but
can't say).

-Woody

Post a reply to this message

"Woody" <nomail@nomail> wrote:
> >   My point is that it should be possible to define a sphere or a plane
> > in the SDL.  If performance dictates that a primitive shape is more
> > efficient, then move it down to the C level for efficiency purposes.
> > But keep the ability for the SDL to define new shapes, new textures, new
> > light sources, etc.  Some of the lesser used ones may even stay at the
> > SDL level.
>
> That seems like the best of both worlds people for people who want better ways
> to define custom objects in the SDL, versuses people who would rather use
> primitive to maintain render efficiency. It would be awesome if both were
> included!
>
> Just be sure to keep the SDL simpler than C or C++; One of the main reasons
> POVRay is so attractive to people (myself included) is its simplicity in use
> compared to those other cumbersome programming languages.
>
> -Woody

I do like the idea of having two levels of SDL.  While the predifined stuff is
what I use mostly, lately I've been mucking about with the user defined camera
in megaPOV to achieve cameras that I can't otherwise.  I do think there would
be some advantage to other user-definable properties as well.

-tgq

Post a reply to this message