 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> Hi!
>
> New version of PoPOV is available at http://abx.art.pl/pov/popov/
>
> This release contains next set of patches I gathered in repository at
> http://abx.art.pl/pov/patches/ and introduce windows port. Sorry for lack of
> sources and documentation. I have to make some work on them. I hope it can be
> already usefull for community.
I tried it and it worked, but the speed difference is IMO too significant
for it to be used for everyday POV-Ray work. You should really release
the source code, i understand it's easier to make a compiled version than
to create a clean version of the source but i somehow find it a bad habit
to offer binaries a lot earlier than the source.
Concerning the triangle function - i think you should include an updated
version of 'functions.inc'. And i would consider doing the docs soon,
otherwise - believe me - it will be an awful lot of work if done well.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 21 Oct 2002 21:30:14 +0200, Christoph Hormann <chr### [at] gmx de>
wrote:
> I tried it and it worked, but the speed difference is IMO too significant
> for it to be used for everyday POV-Ray work.
http://news.povray.org/pce7rugbsntvn8aboobq3ea069erg1q7k3%404ax.com
> You should really release
> the source code,
surprise at www.abx.art.pl/pov/popov :-)
but sources were available via links in original places
> i understand it's easier to make a compiled version than
> to create a clean version of the source but i somehow find it a bad habit
> to offer binaries a lot earlier than the source.
wsn't 3.5 introduced this way ? :-)
> Concerning the triangle function - i think you should include an updated
> version of 'functions.inc'.
Yes, I thought about it but somehow forgot. I hope fixed now. This issue
should be introduced as important part of patching functions.
> And i would consider doing the docs soon,
Yes, that's my next step.
> otherwise - believe me - it will be an awful lot of work if done well.
I believe You :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> > I tried it and it worked, but the speed difference is IMO too significant
> > for it to be used for everyday POV-Ray work.
>
> http://news.povray.org/pce7rugbsntvn8aboobq3ea069erg1q7k3%404ax.com
I know you already mentioned that but this does not change anything about
what i said. I'm quite confident there will be someone willing to make
regular compiles with the intel compiler once there is a standardized well
documented patch collection.
> > You should really release
> > the source code,
>
> surprise at www.abx.art.pl/pov/popov :-)
Thanks. I had a first quick look:
- renaming all file names to upper case is an *extremely* bad idea.
- all changes seem well marked by #ifdef's but most of the modifications
(counting number of blocks, not amount of code) are those preventing the
warnings. I don't want to warm up this discussion again, but for the sake
of easy adaptation to new official releases (3.50c just came out) i think
this should be dropped in a general patch collection.
- the 'patches.h' file seems a good idea, i just would wish a short
description of the individual patches at each #define (i know it's in your
repository but that's not the same as if it comes with the package).
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Oct 2002 15:50:34 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> I'm quite confident there will be someone willing to make
> regular compiles with the intel compiler
I hope too.
> > > You should really release
> > > the source code,
> >
> > surprise at www.abx.art.pl/pov/popov :-)
>
> Thanks. I had a first quick look:
>
> - renaming all file names to upper case is an *extremely* bad idea.
I not guilty. I did not changed it. It must be NT or Windows Commander.
I will automatize packing for future releases with some proces to control file
names
> - all changes seem well marked by #ifdef's but most of the modifications
> (counting number of blocks, not amount of code) are those preventing the
> warnings. I don't want to warm up this discussion again, but for the sake
> of easy adaptation to new official releases (3.50c just came out) i think
> this should be dropped in a general patch collection.
Two solutions. First, I can remove my modifications and turn off warnings -
but then incorporating new patches can have some warnings I could not catch.
Second, I can remove old behaviours and stay with new syntax when it not
changes features. Personally I prefer second solution but temporary I stayed
with #ifdefs to highlight all places modified by me.
> - the 'patches.h' file seems a good idea, i just would wish a short
> description of the individual patches at each #define (i know it's in your
> repository but that's not the same as if it comes with the package).
I though about it and probably incorporate this
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> Two solutions. First, I can remove my modifications and turn off warnings -
> but then incorporating new patches can have some warnings I could not catch.
> Second, I can remove old behaviours and stay with new syntax when it not
> changes features. Personally I prefer second solution but temporary I stayed
> with #ifdefs to highlight all places modified by me.
The description of your second solution seems confusing to me. You mean
you change the code but don't mark it with ifdef's? That would be a bad
idea for a general patch collection. As several people pointed out the
basis should always be the current official version.
IMO it would be good if every patch had a clear description of it's
purpose and a list of modified places in the source in addition to the
user documentation. Something like:
F_TRIANGLE_PATCH
introduces a new internal function 'f_triangle'.
Modified source files:
- 'fnintern.cpp'
* several helper macros at the beginning of the file
* f_triangle() function declaration and implementation
* added entry to 'POVFPU_TrapTable'
* changed 'POVFPU_TrapTableSize'
I think this is something easy to write for the author of the patch and it
would help maintaining patch collections.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> > You should really release
> > the source code,
>
> surprise at www.abx.art.pl/pov/popov :-)
Another thing about the source: Your unofficial version handling is
somewhat different from what i know from MLPov and Ryoichi Suzuki's df3
patch. I think there should be a 'opts.Unofficial_Version' with a
seperate unofficial version number. Your method of adding it to the main
version will at least lead to problems if there is official POV-Ray
3.51/3.6/...
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Oct 2002 19:14:48 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Another thing about the source: Your unofficial version handling is
> somewhat different from what i know from MLPov and Ryoichi Suzuki's df3
> patch. I think there should be a 'opts.Unofficial_Version' with a
> seperate unofficial version number. Your method of adding it to the main
> version will at least lead to problems if there is official POV-Ray
> 3.51/3.6/...
I think you missed flag UnofficialVersion.
I did not compared any other unofficial pack about handling it yet becouse
could not find any suggested way of making it. I have checked MegaPOV for it
but that implementation seemed overcomplicated for me.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 21 Oct 2002 21:30:14 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> i somehow find it a bad habit
> to offer binaries a lot earlier than the source.
Now I have comparison. Binaries are downloaded twice more than sources.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Oct 2002 18:48:12 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> > Two solutions. First, I can remove my modifications and turn off warnings -
> > but then incorporating new patches can have some warnings I could not catch.
> > Second, I can remove old behaviours and stay with new syntax when it not
> > changes features. Personally I prefer second solution but temporary I stayed
> > with #ifdefs to highlight all places modified by me.
>
> The description of your second solution seems confusing to me. You mean
> you change the code but don't mark it with ifdef's? That would be a bad
> idea for a general patch collection.
If there could be general agreement and knowledge what is changed then I don't
think so.
> As several people pointed out the
> basis should always be the current official version.
Then I prefer it as is.
> - 'fnintern.cpp'
> * several helper macros at the beginning of the file
> * f_triangle() function declaration and implementation
> * added entry to 'POVFPU_TrapTable'
> * changed 'POVFPU_TrapTableSize'
Seems logical.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
>
> I think you missed flag UnofficialVersion.
A search for 'UnofficialVersion' in your source code did not find
anything.
> I did not compared any other unofficial pack about handling it yet becouse
> could not find any suggested way of making it. I have checked MegaPOV for it
> but that implementation seemed overcomplicated for me.
Here is the relevant part from MLPov:
/*ML: version_patch*/
#ifdef MLUNOFFICIAL
/* parse unofficial version */
Get_Token();
if (pov_stricmp(Token.Token_String,"mlpov") != 0)
{
Error("This version only recognizes #version unofficial mlpov\n");
}
opts.Unofficial_Version = (int)(Parse_Float() * 100 + 0.5);;
Parse_Semi_Colon(false);
if (opts.Unofficial_Version > UNOFFICIAL_VERSION_NUMBER)
{
Error("Your scene file requires MLPOV version %g or later!\n",
(DBL)(opts.Unofficial_Version / 100.0));
}
[...]
I think this is fairly simple (compared to megapov) and you can also quite
easily add support for multiple unofficial version strings (in case
several patches are merged and old scene files should render without
changes).
The 'Unofficial_Version_Blocking()' function seems a good idea though.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
