 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris has asked me to help out with getting a MediaWiki installation set
up so we can document a number of things, among which are the suggestions
for 4.0.
I'm still in the process of getting things configured, but wanted to get
a discussion going about the structure - as Wikis tend to be pretty free-
form, having an idea about how we want to structure things makes a lot of
sense.
We can break things down by POV version, for example; that would give us
distinct discussion areas for 3.6, 3.7, and 4.0.
As the prospective users of this system, what would be a useful structure
for you?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14.10.2007 21:21, Jim Henderson nous fit lire :
> Chris has asked me to help out with getting a MediaWiki installation set
> up so we can document a number of things, among which are the suggestions
> for 4.0.
>
> I'm still in the process of getting things configured, but wanted to get
> a discussion going about the structure - as Wikis tend to be pretty free-
> form, having an idea about how we want to structure things makes a lot of
> sense.
>
> We can break things down by POV version, for example; that would give us
> distinct discussion areas for 3.6, 3.7, and 4.0.
>
> As the prospective users of this system, what would be a useful structure
> for you?
Setup 3 pages full of links for 3.6, 3.7 and 4.0 if you want.
But I would be more interested in entries being sorted by:
0/ data structures in memory of the renderer (no syntax, no SDL !)
1/ shapes (pure shape, no texturing: think sphere/plane... also
all isosurfaces & functions)
2/ textures (plains, all possibles tunning: pigment, finish,
normal...)
3/ patterns (when unrelated to the shape)
4/ cameras
5/ light sources
6/ media & fog (every 3D density related...)
7/ shapes & pattern together (such as UV mapping)
8/ goodies for any objects (shapes with textures) (such as no_image)
9/ syntaxical goodies (#macro, #declare... but also all builtin
functions)
10/ miscellenous (global_settings, but also any other things such
as data access from object)
11/ known patches & unofficial
Expect 1 page per specific object, with flag/logo about availability
in which versions.
(Yes, that means strlen() might end up with its own page! linked to
both the string page (taken as argument) and the integer page
(result). String/Float/Vector3D/Vector2D/Vector4D/Vector5D/integer
pages in the section 9)
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14.10.2007 21:44, Le Forgeron nous fit lire :
> Le 14.10.2007 21:21, Jim Henderson nous fit lire :
I forgot one important things for 4.0 (too late for 3.6/3.7): order
of quality criteria.
That could turn a bit of flamewar, but getting some priorities
clearly stated (and discussed) for 4.0 would be really a good thing.
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le Forgeron <jgr### [at] free fr> wrote:
> 0/ data structures in memory of the renderer (no syntax, no SDL !)
> 1/ shapes (pure shape, no texturing: think sphere/plane... also
> all isosurfaces & functions)
> 2/ textures (plains, all possibles tunning: pigment, finish,
> normal...)
> 3/ patterns (when unrelated to the shape)
> 4/ cameras
> 5/ light sources
> 6/ media & fog (every 3D density related...)
> 7/ shapes & pattern together (such as UV mapping)
> 8/ goodies for any objects (shapes with textures) (such as no_image)
> 9/ syntaxical goodies (#macro, #declare... but also all builtin
> functions)
> 10/ miscellenous (global_settings, but also any other things such
> as data access from object)
> 11/ known patches & unofficial
Perhaps it would be a good idea to distribute these things into
higher-level sections, such as "Core features", "Scripting language",
etc.
From the core features it should be discussed which features from
POV-Ray 3.7 should be kept, which should be moved to scripting, and
which new core features should be added. (Of course this will be hard
to do before knowing what the new scripting language will be capable
of doing, but as a rough estimate it will be good enough.)
The overall structure of the core code should also be discussed.
Will it be a "microkernel" style rendering core with a powerful
scripting language library, will the core code be actually a C++
library and POV-Ray just one implementation of it, or something else?
The scripting language can be roughly divided into required features
and syntax. The latter will obviously depend on the former, but it can
nevertheless be discussed fairly independently.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Chris has asked me to help out with getting a MediaWiki installation set
> up so we can document a number of things, among which are the suggestions
> for 4.0.
>
> I'm still in the process of getting things configured, but wanted to get
> a discussion going about the structure - as Wikis tend to be pretty free-
> form, having an idea about how we want to structure things makes a lot of
> sense.
>
> We can break things down by POV version, for example; that would give us
> distinct discussion areas for 3.6, 3.7, and 4.0.
>
> As the prospective users of this system, what would be a useful structure
> for you?
>
> Jim
Please feel free to take the existing content in http://www.wikipov.org/
I can send you the database backend if you like.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 15 Oct 2007 07:45:42 -0400, Tom Galvin wrote:
> Jim Henderson wrote:
>> Chris has asked me to help out with getting a MediaWiki installation
>> set up so we can document a number of things, among which are the
>> suggestions for 4.0.
>>
>> I'm still in the process of getting things configured, but wanted to
>> get a discussion going about the structure - as Wikis tend to be pretty
>> free- form, having an idea about how we want to structure things makes
>> a lot of sense.
>>
>> We can break things down by POV version, for example; that would give
>> us distinct discussion areas for 3.6, 3.7, and 4.0.
>>
>> As the prospective users of this system, what would be a useful
>> structure for you?
>>
>> Jim
>
> Please feel free to take the existing content in http://www.wikipov.org/
>
> I can send you the database backend if you like.
Cool, what type of database is on the backend? Is there an XML export
for the entire wiki?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15.10.2007 02:09, Warp nous fit lire :
> Perhaps it would be a good idea to distribute these things into
> higher-level sections, such as "Core features", "Scripting language",
> etc.
And a change of design would cost you a lot to change the pages
hierarchy ?
How would you deal with a feature available as Core in XX and
Scripting in YY ?
maybe tag/icons for 3.1g/3.5/3.6/3.7/4. must be duplicated by
categories.
Let's make a "Core 3.7" logo, and so on.
I would suggest the feature-extension "not
available","Core","Scripting","Patch".
Style with icons in wiki is really easy, once you found it.
A new user (better, an innocent user) does not have to know the
internal of the product to find the information. An intuitive
approach should all that would be required.
Hence my first proposal: understanding what is a shape is at least
something a 7 year-old child can do.
Of course, some grow-up might be needed for more advanced concept,
but they should not be ordered by implementation.
I recognised section 11/ was a late addition, trying to keep the
"official" clean.
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le Forgeron <jgr### [at] freefr> wrote:
> A new user (better, an innocent user) does not have to know the
> internal of the product to find the information.
I thought the main audience of this new wiki was POV-Ray developers,
with its main goal being the development of POV-Ray 4.0 and beyond.
Perhaps the wiki could be split into two distinct parts: Development
and users. The former would deal with the development of the program
(especially concentrating on pov4), while the latter could contain
everything related to using the program.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 15 Oct 2007 14:17:59 -0400, Warp wrote:
> Le Forgeron <jgr### [at] freefr> wrote:
>> A new user (better, an innocent user) does not have to know the
>> internal of the product to find the information.
>
> I thought the main audience of this new wiki was POV-Ray developers,
> with its main goal being the development of POV-Ray 4.0 and beyond.
>
> Perhaps the wiki could be split into two distinct parts: Development
> and users. The former would deal with the development of the program
> (especially concentrating on pov4), while the latter could contain
> everything related to using the program.
I like this idea - we can easily do multiple categories to accomplish
this sort of "division of parts".
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15.10.2007 20:17, Warp nous fit lire :
> Le Forgeron <jgr### [at] freefr> wrote:
>> A new user (better, an innocent user) does not have to know the
>> internal of the product to find the information.
>
> I thought the main audience of this new wiki was POV-Ray developers,
> with its main goal being the development of POV-Ray 4.0 and beyond.
>
> Perhaps the wiki could be split into two distinct parts: Development
> and users. The former would deal with the development of the program
> (especially concentrating on pov4), while the latter could contain
> everything related to using the program.
>
I do not know.
I think it's better to have an approach with the "what" rather than
the "how".
That way, you can easily identify duplicated expression of a "need"
in the big collection.
Just taking an extreme example, with only shapes:
Imagine that Core has only available shapes like quartic, quadric,
and so.
And that so far, Cone/Ellipsoid/Cylinder/Plane are macro for the
right definition. (just assume that it's fine with the math, I did
not check).
Then someone push in the Core section, the superellipsoid object,
introducing also a macro for Box (that just a special superellipsoid).
You have everything you need... if you know where to look!
That's the problem: if someone want a box, should it look at the
core or scripting ?
What will stop the braves from adding a sphere in the Core section,
because there was none here and they missed the bable about
ellipsoid macro and the particular case of sphere in the dark part
of a page amongst a thousand others ?
A program is finished not when there is no more features to add, but
when there is no more to removed. (that's a bit of a caricature)
That example is trivial, but populate your wiki with the vaste
amount of possible features, you might very well end-up with two
suggestions for the same target, via differents means. By ordering
on the "how", you will more probably miss the detection of the
identical target.
If you order by the "what" (without considering its possible
implementations), it is easier to find similarities, then factoring
the variations and ending up with a potent yet usable single
implementation.
A bit of ordering at the conception then save you quite some work at
the code-writing stage. (and less code should also mean less
potential bugs, as long as you did not raise the complexity too much).
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
>
> Cool, what type of database is on the backend? Is there an XML export
> for the entire wiki?
>
> Jim
Simple MS access with pointers to the file attachments. You should be
able import the whole thing with a few SQL statements in an afternoon.
I bet Tom Melly can move the dns entries to point to the new server in a
flash too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Oct 2007 00:11:09 -0400, Tom Galvin wrote:
> Jim Henderson wrote:
>
>> Cool, what type of database is on the backend? Is there an XML export
>> for the entire wiki?
>>
>> Jim
>
> Simple MS access with pointers to the file attachments. You should be
> able import the whole thing with a few SQL statements in an afternoon. I
> bet Tom Melly can move the dns entries to point to the new server in a
> flash too.
Hmmm, well, I'm not that great with SQL. but I do know that there'll have
to be some structural transformations take place to fit the schema in
MySQL for Mediawiki - but I sure can take a look at it and see.
If you want to e-mail it, you can send it to povwiki at gmail (set that
up just for the wiki).
Or I can arrange to pick it up on an FTP server at work on Thursday.
Whichever works best for you. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I thought the main audience of this new wiki was POV-Ray developers,
> with its main goal being the development of POV-Ray 4.0 and beyond.
Initially, this is so.
> Perhaps the wiki could be split into two distinct parts: Development
> and users. The former would deal with the development of the program
> (especially concentrating on pov4), while the latter could contain
> everything related to using the program.
This is a good idea. I had already thought I would like to find a way to
import the POV documentation into the wiki (need to finish setting up some
math and latex stuff for that), to allow either annotations or corrections.
(What becomes of it after that is a different question - I doubt that the
wiki would support sufficiently rich layout that we could directly export
the edited docs into the same form as in which they currently exist).
I'd also encourage folks to add tutorials and suchlike to the wiki, under
the user section.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> We can break things down by POV version, for example; that would give us
> distinct discussion areas for 3.6, 3.7, and 4.0.
>
> As the prospective users of this system, what would be a useful structure
> for you?
>
> Jim
I don't think breaking things down by version is a good idea at all. Let's
say I have a question about radiosity, I have to look thru 3 sections. If
the wiki is broken down by subject, I can look for that subject. If it
turns out the solution is in a Pov version I don't have, I just have to
download that version.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 19 Oct 2007 15:12:43 -0400, fls13 wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>
>> We can break things down by POV version, for example; that would give
>> us distinct discussion areas for 3.6, 3.7, and 4.0.
>>
>> As the prospective users of this system, what would be a useful
>> structure for you?
>>
>> Jim
>
> I don't think breaking things down by version is a good idea at all.
> Let's say I have a question about radiosity, I have to look thru 3
> sections. If the wiki is broken down by subject, I can look for that
> subject. If it turns out the solution is in a Pov version I don't have,
> I just have to download that version.
Perhaps cross-linking between versions would help with this - then you
could search by subject or by version?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson escribió:
> We can break things down by POV version, for example; that would give us
> distinct discussion areas for 3.6, 3.7, and 4.0.
If you want a discussion area, use this news server. The wiki should be
used to document stuff. Ideas included, but still, not a discussion in
terms of a "conversation". Don't let it morph into a "forum".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason escribió:
> This is a good idea. I had already thought I would like to find a way to
> import the POV documentation into the wiki (need to finish setting up some
> math and latex stuff for that), to allow either annotations or corrections.
> (What becomes of it after that is a different question - I doubt that the
> wiki would support sufficiently rich layout that we could directly export
> the edited docs into the same form as in which they currently exist).
What is the "source files" of POV-Ray documentation? Docbook? A few
months ago I helped migrate all of BOINC documentation into a wiki, with
originals being messy HTML. While a few people were migrating pages
manually, I was writing a script, then I got all of it done in a few
days. So maybe I can help...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Oct 2007 18:20:22 -0300, Nicolas Alvarez wrote:
> Jim Henderson escribió:
>> We can break things down by POV version, for example; that would give
>> us distinct discussion areas for 3.6, 3.7, and 4.0.
>
> If you want a discussion area, use this news server. The wiki should be
> used to document stuff. Ideas included, but still, not a discussion in
> terms of a "conversation". Don't let it morph into a "forum".
Actually, I agree with this idea - I phrased that badly, really - I was
thinking more in terms of distinct coverage of specific versions.
(All one needs to do is read my comments on the Inkscape mailing list to
see that I really am a proponent of "the right tool for the job", and
Wikis are not for discussion but for collaborative documentation).
Sorry for the confusion.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> On Wed, 24 Oct 2007 18:20:22 -0300, Nicolas Alvarez wrote:
>
>> Jim Henderson escribió:
>>> We can break things down by POV version, for example; that would give
>>> us distinct discussion areas for 3.6, 3.7, and 4.0.
>> If you want a discussion area, use this news server. The wiki should be
>> used to document stuff. Ideas included, but still, not a discussion in
>> terms of a "conversation". Don't let it morph into a "forum".
>
> Actually, I agree with this idea - I phrased that badly, really - I was
> thinking more in terms of distinct coverage of specific versions.
>
> (All one needs to do is read my comments on the Inkscape mailing list to
> see that I really am a proponent of "the right tool for the job", and
> Wikis are not for discussion but for collaborative documentation).
>
A partly agree, but there is nothing to document yet on POV4, mainly
because it does not exist yet. A newsgroup is better to discuss things,
but it also means that all comments are scattered around in the
discussion tree. I'd like a place where we can collect all opinions and
possibly the consensus reached, if any. That would mean that there will
be several pages each discussing a specific topic that everybody can
alter, but with the 'restriction' that nobody alters somebody else's
comments. And where everybody preferably not even reacts to the other
comments, but plainly states their own point of view.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel escribió:
> Jim Henderson wrote:
>> On Wed, 24 Oct 2007 18:20:22 -0300, Nicolas Alvarez wrote:
>>
>>> Jim Henderson escribió:
>>>> We can break things down by POV version, for example; that would give
>>>> us distinct discussion areas for 3.6, 3.7, and 4.0.
>>> If you want a discussion area, use this news server. The wiki should be
>>> used to document stuff. Ideas included, but still, not a discussion in
>>> terms of a "conversation". Don't let it morph into a "forum".
>>
>> Actually, I agree with this idea - I phrased that badly, really - I
>> was thinking more in terms of distinct coverage of specific versions.
>>
>> (All one needs to do is read my comments on the Inkscape mailing list
>> to see that I really am a proponent of "the right tool for the job",
>> and Wikis are not for discussion but for collaborative documentation).
>>
>
> A partly agree, but there is nothing to document yet on POV4, mainly
> because it does not exist yet. A newsgroup is better to discuss things,
> but it also means that all comments are scattered around in the
> discussion tree. I'd like a place where we can collect all opinions and
> possibly the consensus reached, if any. That would mean that there will
> be several pages each discussing a specific topic that everybody can
> alter, but with the 'restriction' that nobody alters somebody else's
> comments. And where everybody preferably not even reacts to the other
> comments, but plainly states their own point of view.
Exactly, I agree. The discussion is better on a newsgroup/forum/thing,
and the ideas getting summarized in a wiki (minus flamewars :P).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 25 Oct 2007 16:18:56 -0300, Nicolas Alvarez wrote:
>> A partly agree, but there is nothing to document yet on POV4, mainly
>> because it does not exist yet. A newsgroup is better to discuss things,
>> but it also means that all comments are scattered around in the
>> discussion tree. I'd like a place where we can collect all opinions and
>> possibly the consensus reached, if any. That would mean that there will
>> be several pages each discussing a specific topic that everybody can
>> alter, but with the 'restriction' that nobody alters somebody else's
>> comments. And where everybody preferably not even reacts to the other
>> comments, but plainly states their own point of view.
>
> Exactly, I agree. The discussion is better on a newsgroup/forum/thing,
> and the ideas getting summarized in a wiki (minus flamewars :P).
Agreed. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> What is the "source files" of POV-Ray documentation? Docbook? A few
> months ago I helped migrate all of BOINC documentation into a wiki, with
> originals being messy HTML. While a few people were migrating pages
> manually, I was writing a script, then I got all of it done in a few
> days. So maybe I can help...
It's a custom syntax ... Jim Henderson has a copy of them so he can comment
if he has had time to look into it. I'm optimistic that an import can be
done, however less optimistic that the full metadata (e.g. index entries,
special cross-references and so forth) can be preserved sufficiently to
allow re-export.
If you want to have a go at it please co-ordinate with myself or Jim to
avoid duplication of effort;]
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
