Chris Cason wrote:
> andrel wrote:
>> Can someone set something up somewhere?
> 
> Can someone recommend specific Wiki software?
> 
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.

Mediawiki seems a natural choice because a lot of people know how to use 
it (from wikipedia) and anything we need in the lines of the above is 
probably already available in some form.  For authentication a long list 
of extensions can be found on:

http://www.mediawiki.org/wiki/Category:User_identity_extensions

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Warp wrote:
> 
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.
> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.

The Asymptote array concept provides a fairly flexible sort of array:

http://asymptote.sourceforge.net/doc/Arrays.html

The internal representation is derived from deque i think.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

> Is it still ray-tracing? You only get an image that is based on a ray-traced
> one. But if you end up with what you want, then OK.

It's not raytracing, indeed, it's post-processing.  The post-processing
included in megapov (for example) isn't raytracing, either.  The purpose of
post-processing is precisely to allow some transformations over the already
rendered image, ideally using more data (like depth or normals) than the image
itself, but it happens AFTER rendering, which makes it fast and flexible.

If we are discussing render-time effects, well, okay, but let's not call it
POST-processing, then.  Just call it 'effects' (and limit them to things
that *cannot* be done in post-processing).

Nevertheless, simultaneous output of rendered image, and depth, normal,... data
would allow extremely interesting things to be done (besides being easy to
implement).

(BTW, thinking of it, being able to simultaneously output images with different
  settings would be great; i.e : rendering an image with and without media,
  but doing intersection calculations only once; of course, it  becomes
complicated...)

Fabien.

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> How, in the system you envision, will I be able to change the
>> focal point and get a new image within a few seconds, instead
>> of taking 3 hours to re-render everything ?
> 
>   Regardless of which method is used it's clear that povray must keep
> all the necessary information in files (or at the very least in memory)
> between renders.
> 
>   There could be a few possibilities:
> 
> 1) An option to tell POV-Ray to write all the necessary information on files.
>    Then if you want to re-post-process, you just use the option +C to skip
>    the rendering.
>    One disadvantage of this is that you have to remember to use the option
>    if you want to be able to post-process multiple times.

If POV-Ray "sees" there's a file with post-process data, it can ask the
user if he really wants to re-render or not.  Also, an "archival" mode (POV-Ray
gives an automatically numbered name to its output) would avoid any
dangerous overwrite (and allow to easily keep a record of an image's evolution,
which is currently tedious).

> 2) POV-Ray could always write the extra info on files, allowing
>    post-processing whenever you want.
>    The disadvantage is that it will consume disk space and the user would
>    have to manually delete those unneeded files to clean it up.

Disk space is cheap in these days of hard-disks filled with music and videos.

> 3) POV-Ray could automatically write the info on files and keep them there
>    as long a it's running, and when it's closed, it removes them (unless
>    an option is given). This would allow re-post-processing the image as
>    many times as necessary as long as POV-Ray is running.
>    The disadvantage is that this idea doesn't work with the command-line
>    version. Another slight disadvantage is that if the execution of the
>    program is ended abruptly, the files will be left there.
> 
> 4) As 3, but the info is kept in memory until next render.
>    Doesn't garbage the disk, but has the same disadvantages.
> 
>   Make your pick, or suggest something better.

All in all, I think that there could be a choice (for the user) between :
1) write to files, keep it forever (default)
2) write to files, keep it until session ends

I think that "keep in memory" would quickly lead to memory saturation (fast
memory is precious for rendering).

Option 2 would be unavailiable to command-line, but there could be a script
to clean unused files afterwards.  Maybe the files (in option 2) could be
written in some temporary path.

Fabien.

Post a reply to this message

Bruno Cabasson wrote:

> 
> Right.
> 
> But the concern is so present that the question of a new SDL is 'on air'
> since quite a while, made this discussion happen, and interests a lot of
> people (I think). And I bet that those people you mentionned, once/if ever
> POV has its new nice syntax with new long-awaited features, will be the
> first to use it with greed ... The demand for new POV-SDL araised from the
> lacks and drawbacks of POV, even if it is a marvelous tool.
> 
> Bruno

:)

I guess you would call me one of "those people".
Don't get me wrong, I'm not against a new language perse but I am against "a
new language for the sake of a new language". If at the end of the
discussion it turns out that the current SDL cannot be cleaned up/extended
to do what we all want it to do, then off course we need a new language.
But implementing a new language has major cons. 
1) All current and older projects are useless because of loss of backwards
compatibility.
2) We'll upset/drive away a good portion of the current userbase because of
the new syntax.

-- 
Ger

Post a reply to this message

> If POV-Ray "sees" there's a file with post-process data, it can ask the
> user if he really wants to re-render or not.  Also, an "archival" mode 
> (POV-Ray
> gives an automatically numbered name to its output) would avoid any
> dangerous overwrite (and allow to easily keep a record of an image's 
> evolution,
> which is currently tedious).

That's just a GUI detail. Well, you *better* aren't thinking on adding 
"ask the user" to the rendering backend...

Post a reply to this message

>> If POV-Ray "sees" there's a file with post-process data, it can ask the
>> user if he really wants to re-render or not.  Also, an "archival" mode 
>> (POV-Ray
>> gives an automatically numbered name to its output) would avoid any
>> dangerous overwrite (and allow to easily keep a record of an image's 
>> evolution,
>> which is currently tedious).
> 
> That's just a GUI detail. Well, you *better* aren't thinking on adding 
> "ask the user" to the rendering backend...

That would logically be done at front-end (CLI or GUI) level.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Disk space is cheap in these days of hard-disks filled with music and videos.

  Not when rendering animations.

-- 
                                                          - Warp

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Disk space is cheap in these days of hard-disks filled with music and videos.
> 
>   Not when rendering animations.

Well, let's give the option to not keep the files, then.

(hope some wiki or dedicated group will come soon, this thread
is becoming huge !)

Fabien.

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> I guess you would call me one of "those people".
> Don't get me wrong, I'm not against a new language perse but I am against "a
> new language for the sake of a new language". If at the end of the
> discussion it turns out that the current SDL cannot be cleaned up/extended
> to do what we all want it to do, then off course we need a new language.
> But implementing a new language has major cons.
> 1) All current and older projects are useless because of loss of backwards
> compatibility.
> 2) We'll upset/drive away a good portion of the current userbase because of
> the new syntax.
>
> --
> Ger

That's not so obvious to me. AFAIK, compatibility problems already happened
in POV's life when the syntax evolved and new features were added. The
#version clause was added for that. If the new syntax inherits enough from
the current one, we can imagine either that the new is a subset of the old
and the new parser will understand old syntax, or converters can be
developped (which is not far from the first case). I can't imagine that the
new syntax makes less features than the old, so I dont't see why there would
be an impossibility.

However, the arrival of a new syntax is a major change, thus we can't hope
making a significant step without some eventual concessions.

Even if lots of nice stuff was produced with pov 3.6 & megapov 1.2.1 syntax,
it appears that many people feel limited and want something new. That's the
reason of this discussion and justifies we think seriously about it and try
to determine the WHAT, the WHY, and the HOW.

Bruno

Post a reply to this message