 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Does anyone know what new features will definitely be a part of v3.5?
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
>
> Does anyone know what new features will definitely be a part of v3.5?
> --
> ICQ: 46085459
Chris Cason rumored a possible distributed rendering addition but that
is not promised. Beyond that the only "official" statement to date on
what might be expected is this from Chris Young:
USER PATCHES AND VERSION NUMBERS
When we started on 3.1 it was supposed to be a "quick" release before our
planned total rewrite in C++ for 4.0. Unfortunately version 3.1 took a year
longer than expected. Meanwhile a number of excellent user-created patches
had appeared. When 3.1 was released without these patches we were
criticized for ignoring them. Many of the patches were not available until
after 3.1 was well under way. Some of the patches we were not aware they
existed. (Its that nasty CY-doesn't-read-newsgroups problem again <heheh>)
Hey the Team Coordinator can't coordinate what he doesn't know existed can
he?
Anyway, I think we've recognized and corrected this problem too. I did
know about a user-submitted #macro patch and although we didn't use his code
directly, it was a VERY BIG help in designing our own. As you know, #macros
made it into 3.1 along with much requested arrays and file i/o which was
pretty easy to include. Also halo author Zsolt Szalavari told me about his
idea for generalizing all patterns such as bozo, gradient, wood etc. for use
with halo.
As one of the major purposes of 3.1 was to turn halo into media, it was
the perfect chance to add this feature. So version 3.1 was either based on
user-created patches or some strongly demanded user features. However we have
to recognize that the whole reason for having a 3.1 version was to correct
problems with a haphazard integration of a user-submitted patch into 3.0.
We had already implemented atmosphere when we first heard about halo. Halo
was so wonderful that we could not resist putting it in even though we were
nearly ready to release 3.0. While the original design looked good, it was
confusing. It was inconsistent with atmosphere. It created big problems within
the core code and it aggravated other long-standing design problems. Our zeal
to drop in a user patch late in the game caused lots of problems and it took
lots of work in 3.1 to fix them.
So we recognize that there is a BIG backlog of user patches with features
we REALLY want. But do we really want to force them to wait until a major
4.0 rewrite in a new language?
After much debate the answer is no. Therefore the current plan is to create
a POV-Ray 3.5 whose primary purpose is make official, as many user-submitted
patches as possible. To borrow Ron Parker's term, this will be a "Super Patch"
version. Note however we will not simply be rubber-stamping Ron's work in
collecting patches as they currently exist. Ron's super-patch is proving
useful to the team in evaluating various patches (thanks Ron) however some
work must be done to integrate the new features in way that won't conflict
with future plans.
Also some of the features will be modified or eliminated. For example
cross-platform portability is a major design priority and the iso-surface
patch makes use of DLLs that are not portable. We will likely eliminate
that part of the patch. At this point we can't say what will or will not
make the final cut. We'll be contacting authors of all the patches we know
about.
We'll be asking their permission to use their patch but WE CANNOT GUARENTEE
that it will be used and you should expect that it may be modified or rewritten
in some way if it does make the cut. If you have a POV-Ray 3.1 compatible patch
and do not receive email from me by February 1, 1999 then I don't know about
your patch and you should email me at c_y### [at] compuserve com to tell me about
it. We'll try to keep everyone informed of our progress as best we can.
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yikes. No iso-surface part of the Official POV-Ray 3.5? That's got
to hurt.
All in all I have to favor the POV-Teams' commitment to a good program
versus a sloppy haphazard one regardless the downfalls.
Bob
Ken <tyl### [at] pacbellnet> wrote in message
news:37EAE86E.BBCD7F89@pacbell.net...
>
>
> John VanSickle wrote:
> >
> > Does anyone know what new features will definitely be a part of
v3.5?
> > --
> > ICQ: 46085459
>
> Chris Cason rumored a possible distributed rendering addition but
that
> is not promised. Beyond that the only "official" statement to date
on
> what might be expected is this from Chris Young:
>
> USER PATCHES AND VERSION NUMBERS
>
> When we started on 3.1 it was supposed to be a "quick" release
before our
> planned total rewrite in C++ for 4.0. Unfortunately version 3.1 took
a year
> longer than expected. Meanwhile a number of excellent user-created
patches
> had appeared. When 3.1 was released without these patches we were
> criticized for ignoring them. Many of the patches were not
available until
> after 3.1 was well under way. Some of the patches we were not aware
they
> existed. (Its that nasty CY-doesn't-read-newsgroups problem again
<heheh>)
> Hey the Team Coordinator can't coordinate what he doesn't know
existed can
> he?
> Anyway, I think we've recognized and corrected this problem too.
I did
> know about a user-submitted #macro patch and although we didn't use
his code
> directly, it was a VERY BIG help in designing our own. As you know,
#macros
> made it into 3.1 along with much requested arrays and file i/o which
was
> pretty easy to include. Also halo author Zsolt Szalavari told me
about his
> idea for generalizing all patterns such as bozo, gradient, wood etc.
for use
> with halo.
> As one of the major purposes of 3.1 was to turn halo into media,
it was
> the perfect chance to add this feature. So version 3.1 was either
based on
> user-created patches or some strongly demanded user features.
However we have
> to recognize that the whole reason for having a 3.1 version was to
correct
> problems with a haphazard integration of a user-submitted patch into
3.0.
> We had already implemented atmosphere when we first heard about
halo. Halo
> was so wonderful that we could not resist putting it in even though
we were
> nearly ready to release 3.0. While the original design looked good,
it was
> confusing. It was inconsistent with atmosphere. It created big
problems within
> the core code and it aggravated other long-standing design problems.
Our zeal
> to drop in a user patch late in the game caused lots of problems and
it took
> lots of work in 3.1 to fix them.
> So we recognize that there is a BIG backlog of user patches with
features
> we REALLY want. But do we really want to force them to wait until a
major
> 4.0 rewrite in a new language?
> After much debate the answer is no. Therefore the current plan is
to create
> a POV-Ray 3.5 whose primary purpose is make official, as many
user-submitted
> patches as possible. To borrow Ron Parker's term, this will be a
"Super Patch"
> version. Note however we will not simply be rubber-stamping Ron's
work in
> collecting patches as they currently exist. Ron's super-patch is
proving
> useful to the team in evaluating various patches (thanks Ron)
however some
> work must be done to integrate the new features in way that won't
conflict
> with future plans.
> Also some of the features will be modified or eliminated. For
example
> cross-platform portability is a major design priority and the
iso-surface
> patch makes use of DLLs that are not portable. We will likely
eliminate
> that part of the patch. At this point we can't say what will or will
not
> make the final cut. We'll be contacting authors of all the patches
we know
> about.
> We'll be asking their permission to use their patch but WE CANNOT
GUARENTEE
> that it will be used and you should expect that it may be modified
or rewritten
> in some way if it does make the cut. If you have a POV-Ray 3.1
compatible patch
> and do not receive email from me by February 1, 1999 then I don't
know about
> your patch and you should email me at c_y### [at] compuservecom to tell
me about
> it. We'll try to keep everyone informed of our progress as best we
can.
>
> --
> Ken Tyler
>
> See my 1000+ Povray and 3D Rendering and Raytracing Links at:
> http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> Yikes. No iso-surface part of the Official POV-Ray 3.5? That's got
> to hurt.
If Ron doesn't correct me here there are parts of the ISO-Surface patch
that can be ported without having to use the .dll files in question.
--
Ken Tyler
1100+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: If Ron doesn't correct me here there are parts of the ISO-Surface patch
: that can be ported without having to use the .dll files in question.
I doubt that there's anything in those dll's that can't be written in
ANSI C.
He said that the parts which use dll's will be eliminated. He didn't say
that those parts will not be replaced with ANSI C equivalents...
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37eb03e4@news.povray.org> , "Bob Hughes" <inv### [at] aolcom>
wrote:
> Yikes. No iso-surface part of the Official POV-Ray 3.5? That's got
> to hurt.
Why do you assume this? "We will likely eliminate that part of the patch."
does obviously *not* mean we eliminate the whole patch, does it???
Sorry for sounding a bit unfriendly, but I don't think wild rumors or
assumptions will help you find out what POV-Ray 3.5 can or will be able to
do :-) And specifically the iso-surface issue has come up and been
clarified several times by now ... if even the little bit of information
that there will be a 3.5 next and a few general issues about it create such
a lot of confusuion, maybe for 4.0 there should be no details available in
advance?
Thorsten
PS: This is my _own_ opinion, I do not speak (write) for the team!
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> maybe for 4.0 there should be no details available in advance?
>
> Thorsten
Thorsten that would be cruel and inhuman punishment : {
I promise not to spread any(more?) rumors.
--
Ken Tyler
Over 1100 Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Aeehhmm,
Povray 4.0 will be written in python, will have support for PentiumIII
and Athlon as well as a complete XML/XSL capable web browser. Also
included is support for cell phone modems and there will be a free offer
for a ASIC speeding up parsing times by a factor of 1000 just by lying
on the table.
Now here we have the difference between rumors and interest with some
misunderstandings.
The less people know, the more phantasy comes into play. If the povteam
leaves the folks just sitting there drooling, it's going to be a mess.
I found the way for 3.5 just all right. One statement giving information
about what is in their heads, and why.
Axel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
AFAIK, 4.0 will just be a rewrite to reconstruct the base of POV-Ray to be
easier to upgrade and add features to. The rewrite will be in C++. Let's
just hope it makes rendering faster than C has been able to. ( I still say
ASM is the way to go! ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB wrote:
>
> AFAIK, 4.0 will just be a rewrite to reconstruct the base of POV-Ray to be
> easier to upgrade and add features to. The rewrite will be in C++. Let's
> just hope it makes rendering faster than C has been able to. ( I still say
> ASM is the way to go! ;)
If you write the ASM for my R5000 processor I will agree. Otherwise I
will continue to believe that the compilers are optimizing in a fashion
which is good enough for everyone.
I don't think that C++ will make the render faster but I think it might
make programming faster which is something I would like to see too. :-)
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
