=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>  According to the documentation, POV converts its Bezier patches
> into meshes before rendering them, which is precisely the gripe
> nemesis seems to have with other renderers...

actually, my gripe is that to define polygon, bezier or NURBS surfaces, you
have to define them by their vertices/control points/etc.  I enjoy saying
sphere { point, radius } and having a perfect sphere.  Or getting complex
isosurfaces by playing with functions.  I don't like playing with points,
let alone lots of them.  And yes, it's annoying even in visual modellers.

Post a reply to this message

>  - Type 0 are tesselated dynamically during render time and the
> tesselation results are discarded immediately once the intersections
> are found. In particular, I noticed that POV accessed the u_order
> and v_order variables and repetitively called the DeCasteljau
> subdivision functions during intersection computations...

  I see.

-- 
                                                          - Warp

Post a reply to this message

nemesis wrote:
> 
> I feel that too:  Pixie is just like all renderers out there,
> obsessed with polygon meshes or the likes.  Other than POV, I
> don't know of any other renderer allowing for true mathematical
> surfaces as shape primitives...

Untested (and I don't know RIB well) code:

// POV-Ray SDL:
intersection {
   difference {
     sphere { <0,.5,0>, 1 pigment { rgb <1,0,0> } }
     sphere { <0,.5,0>, 1 pigment { rgb <0,1,0> } rotate z*120 }
   }
   sphere { <0,.5,0>, 1 pigment { rgb <0,0,1> } rotate z*240 }
   translate <1,2,3>
}

# Pixie RIB:
Surface "matte"
AttributeBegin
   Translate 1 2 3
   SolidBegin "intersection"
     SolidBegin "difference"
       AttributeBegin
         Color 1 0 0
         Translate 0 .5 0
         Sphere 1 -1 1 360
       AttributeEnd
       AttributeBegin
         Color 0 1 0
         Translate 0 .5 0
         Rotate 120 0 0 1
         Sphere 1 -1 1 360
       AttributeEnd
     SolidEnd
     AttributeBegin
       Color 0 0 1
       Translate 0 0.5 0
       Rotate 120 0 0 1
       Sphere 1 -1 1 360
     AttributeEnd
   SolidEnd
AttributeEnd

I don't want to start a drawn out POV vs. RIB comparison - I'm not 
qualified to do so even if I did want to. But, having used both, I will 
say that neither is a replacement for the other and that POV suits my 
needs better.

  -Shay

Post a reply to this message

Chris Cason wrote:
> 
> The process we intend to follow ...

This is extremely encouraging and exciting. Thank you for sharing this.

> We are as always interested in hearing from anyone with
> reasonable coding skills who can assist

I wish I were qualified; Best wishes to those who are.

  -Shay

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

nemesis wrote:
> =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>>  According to the documentation, POV converts its Bezier patches
>> into meshes before rendering them, which is precisely the gripe
>> nemesis seems to have with other renderers...
> 
> actually, my gripe is that to define polygon, bezier or NURBS surfaces, you
> have to define them by their vertices/control points/etc.  I enjoy saying
> sphere { point, radius } and having a perfect sphere.  Or getting complex
> isosurfaces by playing with functions.  I don't like playing with points,
> let alone lots of them.  And yes, it's annoying even in visual modellers.
> 
	Well, then any renderman compliant renderer has the ability to
define spheres, cones, cylinders, toruses, disks, paraboloids,
hyperboloids and blobs. The only truly missing POV primitive is the
box. As for isosurfaces(1), there are mostly two uses: making
abstract geometric shapes (which is easier in POV) or adding
irregularities to the surface of some objects (which is much easier
to do with renderman displacement shaders).

	I'm not saying that renderman renderers are better, or that you
should abandon POV for them, but just that you weren't really fair
in your appreciation of them.

		Jerome

(1) Isosurfaces are possible in renderman, but they require to be
programmed in C and either added to the renderer as an external
plugin, or that you not use the renderer, but instead use the
associated lib and program everything in C. A rather cumbersome if
extremely flexible method...

- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG4kU6d0kWM4JG3k8RAiXGAJ9F8cv2AAQ5yXBSpMHLzIoLQAl5ugCgkOT7
dpLVYDyJjep5gYOHFV6CV30=
=jN6n
-----END PGP SIGNATURE-----

Post a reply to this message

nemesis wrote:
> hmm, I have some C coding skills, but I guess the main problem is not C
> coding, but 3D algorithms and understanding the SDL parser...

C coding with a basic understanding of C++ would probably be sufficient for
many of the tasks in re-writing the code that has to be replaced. Recall that
all the POV code was originally c, and the fundamental core of the algorithms
and objects are still readable by a C programmer.

The re-write basically involves reading and understanding an existing
function (or group of related functions), and writing a clean version to
replace it.

One way to approach it (and one that I would favour) would be for one group
of people to reverse-engineer the functionality into pseudo-code or similar,
and for another group to then take that and write new code. This helps to
ensure that the new code does not inadvertently copy from the old.

Whichever way it's done, those involved will get a real sense of satisfaction
as each bit is done and plugged back into the program - given a working
infrastructure such as we will have, it will in many cases be possible to see
immediate results as things are turned back on. [This will depend mainly on
the order in which things are done].

Plus there's always the community and primary developers available to guide
things. And anyone who is working on the code actively is welcome to IM me
any time for assistance.

-- Chris

Post a reply to this message

Warp wrote:
>   Does this mean that 4.0 will *not* have any kind of revised SDL language?

I have to be realistic here and take the approach that attempting to write a
new SDL prior to releasing the tree for folks to work on would not be
practical. On the other hand, the existing parser has to be replaced since it
is fairly cumbersome and hard to maintain.

The fact is that once we are done, it will be possible to have any number of
parsers that interface to the rendering engine; whatever we put into the tree
for initial development will only be one of them (and most likely not the
final). Once we've got some momentum and reasonable functionality in the re-
development of the rendering core, I expect more attention can be paid to the
parser.

Of course, there's nothing to stop people discussing and perhaps designing a
new SDL in advance - and perhaps even prototyping it in a stand-along app
(e.g. perhaps something that spits out POV 3.x code).

-- Chris

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> I don't want to start a drawn out POV vs. RIB comparison

too late. ;)

anyway, I was wrong about Pixie.  Good to know it has native support for
geometric primitives, CSG and the likes, without resorting to huge meshes.
Good to know too about its SDL.

It's a bad thing though that XML has f*cked up so many minds through the
industry:  you can't have anymore a good ol' little domain specific
language to do the job without resorting to XML syntax or something quite
the same, like Pixie's and YAFRay's.  What's wrong with {} blocks?  What's
the matter with "Object.attribute = value"?  I can see the horrific day
when Java comes blended with XML syntax...

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> C coding with a basic understanding of C++ would probably be sufficient for
> many of the tasks in re-writing the code that has to be replaced. Recall that
> all the POV code was originally c, and the fundamental core of the algorithms
> and objects are still readable by a C programmer.

yes, true.  I have 3.6 source here.  I said C programming exactly for that:
I am yet to encounter any classes or other C++ features.  Overall, it's
fairly organized and readable and well modularized over a bunch of files.

> The re-write basically involves reading and understanding an existing
> function (or group of related functions), and writing a clean version to
> replace it.

hmm, I guess it's easier to rewrite a whole module (say, colour.cpp) rather
than a single function within.  Because a rewrite may be tempted to
organize things in a different way, dropping hacked functions, writing
others.  I think beginning by understand the functionality provided by the
header is a better start than thinking about one function alone.

> One way to approach it (and one that I would favour) would be for one group
> of people to reverse-engineer the functionality into pseudo-code or similar,
> and for another group to then take that and write new code. This helps to
> ensure that the new code does not inadvertently copy from the old.

yes, I agree.

> Plus there's always the community and primary developers available to guide
> things. And anyone who is working on the code actively is welcome to IM me
> any time for assistance.

I may take the plunge, though there is always the real-world (like a little
daughter) in the way of my commitments.  Plus, I'm on Linux and that means
testing against gcc only.

Post a reply to this message

Chris Cason wrote:

> The process we intend to follow (note this is not set in stone) is that
> once 3.7 is stable enough for an RC, we will make a public release of the
> 3.7 source. Some time after that (once the source is stable enough) we will
> release a modified version of the 3.7 source labeled 4.0, with all portions
> of the code that we cannot re-license stubbed out or otherwise removed.

What help with re-licensing do you need from those of us who have made 
code contributions?

Regards,
John

Post a reply to this message