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

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

nemesis wrote:
> 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...
> 
	Well, according to Wikipedia, the first release of Renderman dates
back to 1989, whereas work on XML didn't even start until mid-1996,
so you can hardly accuse XML of having contaminated the
specification of Renderman :)

	As to why these languages look like they do instead of a simple
C-like syntax, the main reason is that they were designed to be
primarily interchange formats. This means that they were meant to be
generated by a program and read by another. They were never really
intended to be generated by hand. Because of this, they have a
syntax that is *very* easy to parse for a computer (as an example,
the XML grammar fits in about 200 lines, whereas the C grammar takes
over 400 lines (and that's *without* the preprocessor!)

		Jerome
- --
+------------------------- 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)

iD8DBQFG4589d0kWM4JG3k8RAsvaAJ9y9JJsOmuCOl4LvioTd8IzmHUuoQCgq7Sw
sk2JPkOte3EeX53ozjoY7vM=
=wm02
-----END PGP SIGNATURE-----

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> 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.

  I'm not sure I have any reason to, but what I fear is that once the
developement of POV-Ray becomes completely open, if it so happens that
nobody takes the role of strong leader ("dictator") or nobody is accepted
as such, what will happen is that there will be too many cooks spoiling
the broth and no general agreement is ever reached over which kind of
scripting language should be adopted and implemented. Even if an attempt
at designing such a language, the "too many cooks" will only stir the mud
and without that strong leadership the entire thing can become a complete
mess.
  As I see it, the three most likely scenarios are:

  1) A good agreement is never reached, and since nobody is "forcing" a
change, a new refactored SDL is never created and the current SDL will be
used forever regardless of its great limitations.

  2) An agreement is reached (good or not) and an implementation attempt is
made, but again, without anyone "forcing" it in, too many people will protest
against the change and the new scripting language will not gain wide usage
and will never reach "gold status".

  3) I would say the most likely scenario: Someone will embed an existing
scripting language (such as LUA) as an *alternative* to the existing SDL.
Again, since nobody is "forcing" the change to the new SDL only few people
will use it, and most importantly, since this existing scripting language
is not designed from scratch to support POV-Ray specifically, it will only
be half-useful. It will also look so much different from the current SDL
that not many people will be eager to change to it.

  So in summary, I fear that a half-hearted attempt might be attempted,
but the result will not be as good as it could be.

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

  The main reason for the need for a new scripting language is that the
current SDL is very limited (and slow). There are things which are simply
impossible to do. Thus making a prototype of a more flexible and powerful
language which is then simply converted into existing SDL would not be
possible.
  Another thing which I envision is that many of the features of the new
scripting language could be used during rendering (shaders being one example)
and after rendering (for post-processing effects). It would obviously just
not be possible to simply make a converter to the existing SDL to test
these features.

-- 
                                                          - Warp

Post a reply to this message

"Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht 
news:46de836a$1@news.povray.org...
>
> Is there any progress concerning Moray? Is it RIP or WIP?
>

Interestingly, I suppose that Arne's original question is indirectly 
answered by the discussion in between. Am I correct in assuming that a new 
Moray version can only be envisioned 'after' POV version 3.7 becomes 
operational, or 'during / after' POV version 4.0 becomes available? I am not 
critical about anything, I am just interested to know what the current 
thoughts about Moray are at this stage.

Regards,

Thomas

Post a reply to this message

Thomas de Groot wrote:
> "Arne Kleinophorst" <kle### [at] spamdebitelnet> schreef in bericht 
> news:46de836a$1@news.povray.org...
>> Is there any progress concerning Moray? Is it RIP or WIP?
>>
> 
> Interestingly, I suppose that Arne's original question is indirectly 
> answered by the discussion in between. Am I correct in assuming that a new 
> Moray version can only be envisioned 'after' POV version 3.7 becomes 
> operational, or 'during / after' POV version 4.0 becomes available? I am not 
> critical about anything, I am just interested to know what the current 
> thoughts about Moray are at this stage.

Looks like post-4.0 is the most realistic, though something that worries 
me is this: how long, if ever, will it take after gutting non-opensource 
code to regain similar level of functionality, and with a new SDL, will 
all prior POV data become obsolete and useless?

 From a standpoint of someone who (occasionally) uses Moray 3.5 which 
necessitates use of POV 3.5 at the most, will it be worth my while to 
migrate to a newer version, or will I be relegated to an 
ever-more-obsolete set of tools?

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message