William Tracy <wtr### [at] calpolyedu> wrote:
> Re the idea of a demo implementation of SDL: If the main thing we can't 
> implement currently is post-processing, we could hack a program that 
> writes "classic" SDL, executes POV, and then runs some post-processing 
> on the output (ImageMagick comes to mind as a possible starting point).

  Not possible without things like per-pixel depth and normal info.

-- 
                                                          - Warp

Post a reply to this message

>         OpenOffice was first developed as proprietary software and is
> currently maintained by Sun. I believe that there is a strong
> leadership emanating from Sun to guide the project.

  Yes. Another example is Linux, which works because of strong leadership
and strict control. Likewise many FSF software.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Not possible without things like per-pixel depth and normal info.

Spit out the depth and normal info via a set of several images made with 
Megapov's own postprocessing feature?

It would suck for everyday use, though. ;-)

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you can't look at any 
raytraced image without thinking up ways on how to improve it.
Taps a.k.a. Tapio Vocadlo

Post a reply to this message

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

Ger wrote:

> 
>>> I wonder why you think this.
>>>
>>> There is a sufficient large number of open source projects out there with
>>> which it worked, and still works. OpenOffice and such come to mind.
>>>
>> Probably because there is a sufficiently large number of open
>> source projects out there with which it didn't work, and precious
>> few with which it did.
>>
>> OpenOffice was first developed as proprietary software and is
>> currently maintained by Sun. I believe that there is a strong
>> leadership emanating from Sun to guide the project.
>>
> 
> Agreed, but still.......
> Just have a look around, Lazarus, Amarok, KOffice, even KDE, Gnome and Linux
> itself are joint efforts. And because they are works in progress people
> will come and go.

	I don't know how the Lazarus, Amarok, KOffice and KDE teams are
organized, but I do know that the Gnome and Linux teams each have a
"dictator" that steers the project.

> If the group of designers, developers, coders and testers is willing to work
> on it then an open source version of Povray will work. It's just one of
> those things that one has to be willing to do, not because one is paid to
> do it.
> If after a while only Thorsten and Chris are the only ones left working on
> it then obviously Povray didn't have what it needs to be an open source
> project, but saying from the getgo that it can't work sounds a bit defiant
> to me.

	If you re-read Warp's post, you'll notice that this is *not* what
he said. What he did say is that such a project needs a strong
leader to keep the team focused and to take decisions and make them
stick. All open source projects whose management method I know fall
into three categories:

 - Small projects (1 to 3 developers) which don't need much
organization, but progress slowly and often disappear when the
original team loses interest;

 - Large projects which have a strong leader and succeed (Linux,
Gnome, Blender...);

 - Large projects which don't have a strong leader and eventually
fail (Stampede...).

		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)

iD8DBQFG5GUtd0kWM4JG3k8RAsjFAJ9LXOHUOV87PEPC66TLCCqqVUN+egCbBdKH
1ueHMmIQieB1XpiuG1lybEI=
=xidZ
-----END PGP SIGNATURE-----

Post a reply to this message

Warp wrote:
>   Not possible without things like per-pixel depth and normal info.

I have considered providing this in the intermediate stream info (i.e. the
.pov-state file). It's certainly possible for us to extract it from the
rendering engine, provided we put reasonable constraints on it (e.g. the
info is that of the first item hit in the path of the primary ray that is
non-100% transparent). Otherwise we may end up outputting things like the
depth/normal of a media volume, which probably isn't what's wanted. It's
not clear to me what exact criteria should be used, and it may well be that
we need a keyword for it since there may not be any one single solution
that suits everyone.

-- Chris

Post a reply to this message

> Thorsten Froehlich wrote:
> 

>>
>>>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!)
>>
>>No XML is better discussion (not sure if that is your argument or not),
>>please, those lead nowhere. XML being easy to parse is not an argument for
>>anybody who knows something about (programming) language theory - the
>>complexity of a grammar* isn't defined by the name of the language after all ;-)
>>
> 
> 	I don't understand your answer so I can't really answer to it, but
> I'll try to clarify my post:
> ...
I also found Thorsten's opening sentence confusing, but I was finally 
able to parse it as meaning:
      No "XML is better" discussion, please...

      -=- Larry -=-

Post a reply to this message

Warp wrote:
>   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

Well, it is my hope that whatever is released as 'official' by povray.org
will be accepted as official.

I do accept (and it has been my concern for many years, hence e.g. the
requirements for '.unofficial' in non-standard SDL's) that without a
standard for the language, it will diverge into various incompatible
derivatives. Hence, I may well want to take the stance that anything that
uses the 'POV-Ray' name has to comply with certain requirements regarding
the language. Not sure exactly what these would be, it's something we can
work out later.

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

I have had a look at a few embeddable languages, such as AngelCode (see
http://www.angelcode.com/angelscript/) but haven't come to any solid
conclusion yet.

I will comment however that it's probable that we would want to take an
existing library and modify it (if necessary) to suit, rather than writing
something entirely new. I would expect that whatever language we use, it
would require some modification, since expressing POV vectors and so forth
would become too cumbersome otherwise.

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

I think it's important that any new SDL be at least P-coded, if not fully
JIT'd on platforms that support it. The latter would be handy in particular
for user-defined shaders. And also note that as a GPL'd program, we can use
portions of the GCC suite as needed.

-- Chris

Post a reply to this message

John VanSickle wrote:
> What help with re-licensing do you need from those of us who have made 
> code contributions?

If we can clearly identify your contribution, and it is stand-alone, then
an assignment form stating it's released under the GPL3 would be needed.

Apart from that, help in re-coding the existing code would be great ;]

-- Chris

Post a reply to this message

Woody wrote:
> I did C++ coding in college, only about 4 years ago. I still remember most
> of the concepts related to OOP i.e. pointers datatypes stacks ques
> struct/typedef, althought my syntax may have gotten a bit rusty. I use
> mostly VBA now for work. I don't know if this counts as reasonable, but if
> it does, let me know what I can do to help.

That's fine. As long as you can read the existing code and use the same C++
concepts as it uses in re-implementing it, then you're right.

I'll post an example of some code in a new thread shortly.

-- Chris

Post a reply to this message

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

Larry Hudson wrote:

>> Thorsten Froehlich wrote:
>>

>>>
>>>> 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!)
>>>
>>> No XML is better discussion (not sure if that is your argument or not),
>>> please, those lead nowhere. XML being easy to parse is not an
>>> argument for
>>> anybody who knows something about (programming) language theory - the
>>> complexity of a grammar* isn't defined by the name of the language
>>> after all ;-)
>>>
>>
>>     I don't understand your answer so I can't really answer to it, but
>> I'll try to clarify my post:
>> ...
> I also found Thorsten's opening sentence confusing, but I was finally
> able to parse it as meaning:
>      No "XML is better" discussion, please...
> 
	Thanks for the translation ;) Then I can answer Thorsten: No, that
wasn't my argument. I firmly believe that XML would be a poor choice
given the goals pursued by POVRay. As I explained, XML was designed
to be an exchange format between different softwares. As such, it is
intended to be generated by a computer program, not hand-typed. This
is quite incompatible with the idea that POVray scenes are primarily
written by hand.

	XML has its uses, but replacing the POV SDL most emphatically is
*not* one of them.

		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)

iD8DBQFG5Ym2d0kWM4JG3k8RAoMbAJ4uiJyqloRfW8XK/Q6RYujbrG6Z+QCfcZ1v
z5Y1l4iHGh+ZDix1dzDWT4g=
=3Fwk
-----END PGP SIGNATURE-----

Post a reply to this message