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