 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MegaPOV is a collection of unofficial extensions for the freeware
raytracer POV-Ray. It is maintained by a group of POV-Community
members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
source code and it is now available at its new website:
http://megapov.inetart.net/
Go, download, read documentation, have fun.
Let's start New Year with new quality! :-)
MegaPOV Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MegaPOV Team wrote:
> MegaPOV Team
For the record - who is the MegaPOV Team?
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 31 Dec 2002 04:57:05 -0800, Ken <tyl### [at] pacbell net> wrote:
> MegaPOV Team wrote:
>
> > MegaPOV Team
>
> For the record - who is the MegaPOV Team?
Christoph Hormann,
Nathan Kopp,
Wlodzimierz ABX Skiba,
Ren� Smellenbergh,
Yvo Smellenbergh
http://megapov.inetart.net/manual/appendices.html#megapov_authors
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MegaPOV Team" <meg### [at] megapovinetartnet> wrote in message
news:1kq21vgl0o9vep1vv7ck3bmrajsqund750@4ax.com...
>
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
>
> http://megapov.inetart.net/
>
> Go, download, read documentation, have fun.
>
> Let's start New Year with new quality! :-)
>
> MegaPOV Team
Thankyou, thankyou!
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why is there no source for the Windows GUI version?
Anders
--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 31 Dec 2002 11:13:01 -0500, "Anders K." <and### [at] kaseorgcom> wrote:
> Why is there no source for the Windows GUI version?
Lack of time together with tiredness, but you can solve it as follow:
1. get POV-Ray 35 windows source
2. replace POV core with MegaPOV core from one of uploaded MegaPOV packages
3. comment windows specific patch in patches.h
(CUSTOM_KEYWORDS_IN_WINPOV_PATCH)
4. add some megapov1.bmp splash screen in windows\bitmaps folder
5. add some megapov.ico icon in windows\icons folder
6. compile
Should work, sorry for this temporary inconvenience, will be fixed in (happy)
New Year.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1kq21vgl0o9vep1vv7ck3bmrajsqund750@4ax.com>,
MegaPOV Team <meg### [at] megapovinetartnet> wrote:
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
The "listed" pattern looks like the "solid" pattern from my old patch
tutorial and MegaPOV+. Frankly, I like my name better, "listed" gives no
impression of what the result is. The pattern isn't even useful, it is
trivial with a function pattern. (function {VALUE})
I'm a bit irritated...I had asked to be included in updating my patches
for the new version. The displace warp is outdated, and updating the old
glow patch was a waste of time, the new one I'm working on isn't even
based on any of the same code. From the documentation, it looks like you
didn't even get the latest old version...glows should allow warps as
well as other transformations.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1kq21vgl0o9vep1vv7ck3bmrajsqund750@4ax.com> , MegaPOV Team
<meg### [at] megapovinetartnet> wrote:
>
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
>
> http://megapov.inetart.net/
>
> Go, download, read documentation, have fun.
>
> Let's start New Year with new quality! :-)
>
> MegaPOV Team
Is there a specific reason why total times, at least for the Mac version are
reported incorrectly? I.e. isocacti.pov reports a total time that is less
than the trace time...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 31 Dec 2002 14:05:57
Message: <3E11EA94.61D5B83A@gmx.de>
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> The "listed" pattern looks like the "solid" pattern from my old patch
> tutorial and MegaPOV+. Frankly, I like my name better, "listed" gives no
> impression of what the result is.
'solid' is also used for crackle solid so this might lead to confusion.
>
> I'm a bit irritated...I had asked to be included in updating my patches
> for the new version. The displace warp is outdated, and updating the old
> glow patch was a waste of time, the new one I'm working on isn't even
> based on any of the same code. From the documentation, it looks like you
> didn't even get the latest old version...glows should allow warps as
> well as other transformations.
Having not been around while those features were added i don't know about
the details.
Concerning the displace warp - i was planning to add a new function warp
(as well as warp functions, i think those things have been discussed
somewhere previously) and therefore voted for not including the displace
warp but the others thought it would be good to add it for convenience.
Concerning glows: warps and transformations are supported. A new glow
patch - sounds good, give it a few days rest but i am pretty sure we can
arrange something. It should be obvious that none of the MegaPOV features
will stay as it is forever and features can also vanish again when there
is a new better solution. So don't worry too much about possibly outdated
functions.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
you're king:))
you're cool
"MegaPOV Team" <meg### [at] megapovinetartnet>, haber iletisinde sunlari
yazdi:1kq21vgl0o9vep1vv7ck3bmrajsqund750@4ax.com...
>
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
>
> http://megapov.inetart.net/
>
> Go, download, read documentation, have fun.
>
> Let's start New Year with new quality! :-)
>
> MegaPOV Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Really good gift!
Best regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you, thank you to everyone who worked on this.
I'm amazed at your work.
How about merging it with MLPOV? Is that a possiblity?
Harold
"MegaPOV Team" <meg### [at] megapovinetartnet> wrote in message
news:1kq21vgl0o9vep1vv7ck3bmrajsqund750@4ax.com...
>
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
>
> http://megapov.inetart.net/
>
> Go, download, read documentation, have fun.
>
> Let's start New Year with new quality! :-)
>
> MegaPOV Team
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The new features look exciting. I have never tried any of the scattered
patches for 3.5 as I have been waiting for the unified patch, MegaPOV.
It will be interesting to play with those.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Btw, what happened to the post-processing effects? They were handy.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3E11EA94.61D5B83A@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> > The "listed" pattern looks like the "solid" pattern from my old patch
> > tutorial and MegaPOV+. Frankly, I like my name better, "listed" gives no
> > impression of what the result is.
>
> 'solid' is also used for crackle solid so this might lead to confusion.
Minimal. It makes perfect sense to me...knowing what "solid" is,
"crackle solid" is pretty obvious, and the same goes for the reverse.
"listed" is extremely vague. "constant" would work, but I still prefer
"solid".
The patch has my name on it, but I would never have chosen "listed", I
think it's a terrible choice. Since the whole thing is redundant, I'd
just remove it.
> Concerning the displace warp - i was planning to add a new function warp
> (as well as warp functions, i think those things have been discussed
> somewhere previously) and therefore voted for not including the displace
> warp but the others thought it would be good to add it for convenience.
I would have voted for leaving it out. It will be less convenient coping
with changes or replacements (and I have those in mind).
> Concerning glows: warps and transformations are supported. A new glow
> patch - sounds good, give it a few days rest but i am pretty sure we can
> arrange something. It should be obvious that none of the MegaPOV features
> will stay as it is forever and features can also vanish again when there
> is a new better solution. So don't worry too much about possibly outdated
> functions.
But in the past, MegaPOV was much more than a patch version, more people
used it than the official version. Those features could at least have
been marked "not final" in the documentation.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have had this situation with the regular POV-Ray 3.5 some time ago. We
came to the conclusion it had something to do with Einstein's e=mcc :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MegaPOV Team wrote:
> MegaPOV is a collection of unofficial extensions for the freeware
> raytracer POV-Ray. It is maintained by a group of POV-Community
> members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
> source code and it is now available at its new website:
>
> http://megapov.inetart.net/
>
> Go, download, read documentation, have fun.
>
> Let's start New Year with new quality! :-)
>
> MegaPOV Team
A big "bravo" to the MegaPOV Team.
I've especialy loved the chapters in the documentation explaining POV
internal structure and a starter to make POV patches. I strongly believe
that this kind of documentation should get in an hypothetical "POV
programming guidelines" document in the forthcoming POV 4.0 project.
--
Alessandro Falappa
web: http://www.falappa.net/alessandro
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Woohoo!
Chistmas one week late!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Very very nice! simcloth is amazing!
I'd like to see some of the changes from Slime's patches (especially 4-D
noise) incorporated.
http://www.slimeland.com/slimepov/
Is that possible? (or do I need to make my own custom patch merging the two
patches)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
0"ron_ivi" <nomail@nomail> wrote:
> Very very nice! simcloth is amazing!
>
> I'd like to see some of the changes from Slime's patches (especially 4-D
> noise) incorporated.
> http://www.slimeland.com/slimepov/
> Is that possible? (or do I need to make my own custom patch merging the two
> patches)
Of course we will add more patches in the future.
The patches from Slime are surely on the list :-)
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MegaPOV Team wrote:
>MegaPOV is a collection of unofficial extensions for the freeware
>raytracer POV-Ray. It is maintained by a group of POV-Community
>members - the MegaPOV Team. It was rewritten for POV-Ray 3.5
>source code and it is now available at its new website:
>
>http://megapov.inetart.net/
>
>Go, download, read documentation, have fun.
>
>Let's start New Year with new quality! :-)
>
>MegaPOV Team
>
yippee!!! a DOS version! I was feeling glum since I couldn't seem to find
3.5 in DOS, but since this version has it plus the Megapov extras I feel
much better... now I just need to get all the #include folders and 3.5 docs
copied over and I'll be set :)
-----------------------------
dan
Goofy Grafix - http://hometown.aol.com/goofygrafx
DanByersArt - http://www.huntel.net/goofygraffix
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 4 Jan 2003 15:54:26
Message: <3E1749FF.7BA5F31C@gmx.de>
|
|
|
| |
| |
|
|
Dan Byers wrote:
>
> yippee!!! a DOS version! I was feeling glum since I couldn't seem to find
> 3.5 in DOS, but since this version has it plus the Megapov extras I feel
> much better... now I just need to get all the #include folders and 3.5 docs
> copied over and I'll be set :)
It should be mentioned that POV-Ray 3.5 is not compatible to DOS filename
restrictions (8+3). Since the basic POV-Ray 3.5 distribution is required
for correctly running MegaPOV this is really only for hardcore DOS users
who accept the need to manually tweak things.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> I'm a bit irritated...I had asked to be included in updating my patches
> for the new version. The displace warp is outdated, and updating the old
Well Chris, for some reason you never answered a mail I send you a few
weeks ago, perhaps you never received it.
Like Chris Hormann said before you should not worry too much about it.
Nothing has to remain the same and nothing is preventing us from
changing things in a next version.
The e-mail I send you today bounced back. Do you still have your account
at mac.com?
You still use it while posting in this ng.
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Is there a specific reason why total times, at least for the Mac version are
> reported incorrectly? I.e. isocacti.pov reports a total time that is less
> than the trace time...
>
> Thorsten
There have been no changes as far as I know.
I did a test and indeed there seems to be a problem.
However if you look at the seconds alone it is correct.
It looks like a conversion problem.
I will find out if this happens also in the Windows version.
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1fo2qcy.19ici8k1yzetmkN%yvos.s@gmx.net>,
yvo### [at] gmxnet (Yvo Smellenbergh) wrote:
> Well Chris, for some reason you never answered a mail I send you a few
> weeks ago, perhaps you never received it.
Looking through my old emails, I found it. It was about the time I was
moving back home from college, it just got set aside and forgotten. I
also upgraded to OS X 10.2 about that time, I might have drafted a reply
and lost it in importing the old mailboxes.
> The e-mail I send you today bounced back. Do you still have your account
> at mac.com?
> You still use it while posting in this ng.
The correct address is in my signature, I just fixed the other setting.
The mac.com address has been dead for a while (since "free for a
lifetime" turned into "$100 a year"), I don't know how that setting
survived.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 31 Dec 2002 18:44:15
Message: <3e122bcf@news.povray.org>
|
|
|
| |
| |
|
|
In article <1fo2qiq.ix0vys5a5vcwN%yvos.s@gmx.net> , yvos.s@gmx.net (Yvo
Smellenbergh) wrote:
>> Is there a specific reason why total times, at least for the Mac version are
>> reported incorrectly? I.e. isocacti.pov reports a total time that is less
>> than the trace time...
>
> There have been no changes as far as I know.
> I did a test and indeed there seems to be a problem.
> However if you look at the seconds alone it is correct.
> It looks like a conversion problem.
> I will find out if this happens also in the Windows version.
I guess it is some rounding error in the default split time then.
Essentially the sub-second precision of that function is useless (because it
measure "OS scheduler noise"). So I will try to provide a better version of
that function for 3.51.
Thorsten
PS: Is there any special trick to view the generic documentation? It
doesn't work properly under IE 5.0/5.2 Mac, Netscape 4.79 Mac, the Mac OS
8/9 Help Viewer or the Mac OS X Help Center. As far as the error are
concerned, IE does not render any of the examples correctly (some linefeed
problem in the HTML I guess), Netscape does not render most of it at all
(not really surprising though), and the Help Viewer/Center on the one hand
never supported style sheets, but the cross-links don't work either, and
there are some warning messages displayed (different ones, let me know if
you want the exact text). Oh, and apparently some images are not there
because I get broken image images in all four programs.
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Btw, what happened to the post-processing effects? They were handy.
We will try to put it back in but we have to rerwrite it.
We do know users want it but the MP-Team voted against readding the mp
0.7 version.
So, you will have to look out for a next version.
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> The new features look exciting. I have never tried any of the scattered
> patches for 3.5 as I have been waiting for the unified patch, MegaPOV.
> It will be interesting to play with those.
Especially because MegaPOV is backwards compatible with Pov-Ray 3.5.
You can not go wrong by using MegaPOV.
If you don't use MegaPOV features, your results are the same and you are
virtually using Pov-Ray (official version), at least that is what we
agreed in the first place ;-) .
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> I guess it is some rounding error in the default split time then.
> Essentially the sub-second precision of that function is useless (because it
> measure "OS scheduler noise"). So I will try to provide a better version of
> that function for 3.51.
Great! Merging MP 1.0 with Pov-Ray 3.5.1 is a next step for us.
> PS: Is there any special trick to view the generic documentation? It
> doesn't work properly under IE 5.0/5.2 Mac, Netscape 4.79 Mac, the Mac OS
Ok, it is rather special...
You should view these docs under X with Netscape 7.0.1 or Mozilla.
Don't use IE because IE... I prefer IE for day to day use but whenever
there is something special, IE messes up. Perhaps Bill doesn't like
Mac's? :-) :-)
Well... no, we will have to figure out what is wrong in the docs.
Personally I use Chimera for OS X. A very nice browser for OS X.
We do know that the docs are not perfect for the mac builds of MegaPOV
but they will have to do for now.
We will try to improve things for a next release.
Thorsten, we disagree on OS versions but we (René and I) feel that
whenever possible you should use X and not -X.
I had to rerun 9 to test the classic version and the first thing I
encountered was a total system freeze. I didn't had that for months
while running X!
Trying to convince the guys at http://www.versiontracker.com to fix the
links for people using system 8.5 or lower was a hard job. This shows
how many people are using X.
But you are right, the Mac docs must improve.
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> In article <1fo2qcy.19ici8k1yzetmkN%yvos.s@gmx.net>,
> yvo### [at] gmxnet (Yvo Smellenbergh) wrote:
>
> > Well Chris, for some reason you never answered a mail I send you a few
> > weeks ago, perhaps you never received it.
>
> Looking through my old emails, I found it. It was about the time I was
> moving back home from college, it just got set aside and forgotten. I
> also upgraded to OS X 10.2 about that time, I might have drafted a reply
> and lost it in importing the old mailboxes.
That is what we were thinking about, more important events for you at
that moment.
The reason the Glow_Patch was readded was that users wanted it back,
even if it wasn't perfect.
MegaPOV is suitable for "features-under-development".
Simply contact me by e-mail to agree on a next update.
> > The e-mail I send you today bounced back. Do you still have your account
> > at mac.com?
> > You still use it while posting in this ng.
You are still a Tag-member, arent't you? Why don't you use that as
signature when posting in these groups?
While being a Tag-member, you should be reacheable ;-)
> The correct address is in my signature, I just fixed the other setting.
> The mac.com address has been dead for a while (since "free for a
> lifetime" turned into "$100 a year"), I don't know how that setting
> survived.
yes, €100.00 is too much for something free for a lifetime :-)
Yvo
--
MacMegaPOV at:
http://users.skynet.be/smellenbergh
E-mail: yvo### [at] gmxnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1fo366w.4sumen6c9b93N%yvos.s@gmx.net>,
yvo### [at] gmxnet (Yvo Smellenbergh) wrote:
> The reason the Glow_Patch was readded was that users wanted it back,
> even if it wasn't perfect.
It does seem to be the most popular of my patches...never figured that
out. Maybe it's just that it's hard to get wrong, fast, and gives pretty
pictures with little or nothing else.
> MegaPOV is suitable for "features-under-development".
> Simply contact me by e-mail to agree on a next update.
Well, I'll get tired of working on Sapphire sometime soon...I go back to
college on the 10th of next month, I might have extra time while classes
are getting started. I'm taking harder courses though...in decreasing
order of anticipated difficulty: English 2, Calculus 1, Physics, and
Data Structures and Object Oriented Design.
> > > The e-mail I send you today bounced back. Do you still have your account
> > > at mac.com?
> > > You still use it while posting in this ng.
> You are still a Tag-member, arent't you? Why don't you use that as
> signature when posting in these groups?
> While being a Tag-member, you should be reacheable ;-)
Still haven't looked at my signature? ;-)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1fo34gi.tdwxvc1ys7g0kN%yvos.s@gmx.net>,
yvo### [at] gmxnet (Yvo Smellenbergh) wrote:
> We do know users want it but the MP-Team voted against readding the mp
> 0.7 version.
> So, you will have to look out for a next version.
I've been thinking about this for a while...one thing I've always wanted
was a way to create different "buffers" for filter input and output.
That way, you could run two different filters on the raw image, and
combine them with another filter, or output multiple processed versions
of the same image.
Also, user-defined filters would be nice, but POV functions aren't very
flexible, something like G would be better...I could get it into working
order if there is interest. Actually, G could drive most of the image
processing...
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just checked (or "scanned") your web page, but I can't see anyting about
Sapphire. Is Sapphire the same as CSDL?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e126ec9@news.povray.org>,
"Apache" <apa### [at] yahoocom> wrote:
> Just checked (or "scanned") your web page, but I can't see anyting about
> Sapphire. Is Sapphire the same as CSDL?
Yes, Sapphire is the new name for CSDL. Or, since I never actually
released the old VM under that name and the new one is rewritten from
scratch, you could call it the successor to CSDL.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 1 Jan 2003 04:37:35
Message: <3E12B6DE.431E9AC3@gmx.de>
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> I guess it is some rounding error in the default split time then.
> Essentially the sub-second precision of that function is useless (because it
> measure "OS scheduler noise"). So I will try to provide a better version of
> that function for 3.51.
That seems a good idea, it is also broken in official POV on Linux, if you
have it rewritten it is probably a good idea to test if it fixes the
problems on all platforms since those do not necessarily have to be the
same.
>
> PS: Is there any special trick to view the generic documentation? It
> doesn't work properly under IE 5.0/5.2 Mac, Netscape 4.79 Mac, the Mac OS
> 8/9 Help Viewer or the Mac OS X Help Center. As far as the error are
> concerned, IE does not render any of the examples correctly (some linefeed
> problem in the HTML I guess), Netscape does not render most of it at all
> (not really surprising though), and the Help Viewer/Center on the one hand
> never supported style sheets, but the cross-links don't work either, and
> there are some warning messages displayed (different ones, let me know if
> you want the exact text). Oh, and apparently some images are not there
> because I get broken image images in all four programs.
Yvo already explained the Mac specialities - it looks fine on:
IE 5 Windows
Mozilla 1 Windows
Konqueror 3.0.1 Linux
but it has serious problems with Netscape 4.x - trying without the style
sheet might help.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've been thinking about this for a while...one thing I've always wanted
> was a way to create different "buffers" for filter input and output.
it also would be great to have an option to output an image as multiple
layers , a layer for each kind of contribution : diffuse, highlights,
reflection, refraction, radiosity, photons, media ..etc So we can do
compositing in post process (blur a reflection, add glow only on highlights,
increase radiosity brightness, and so on without the need to re render)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interesting idea! But in what layer would a reflection of a refraction
belong to?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Interesting idea! But in what layer would a reflection of a refraction
> belong to?
we could do this only for primary rays, or have an option to give the trace
level we want
M
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 1 Jan 2003 07:59:20
Message: <3E12E628.2FE290DD@gmx.de>
|
|
|
| |
| |
|
|
Apache wrote:
>
> Interesting idea! But in what layer would a reflection of a refraction
> belong to?
I think they should be a separate layer. The whole idea sounds very
interesting but would involve quite significant changes on source level so
it seem a rather large project.
Applications would be things like all kinds of selective blurring, for
example higher quality post processed focal blur (blurring the
reflection/refraction layers separately).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e12c8dd$1@news.povray.org>, "Mael" <mae### [at] hotmailcom>
wrote:
> it also would be great to have an option to output an image as multiple
> layers , a layer for each kind of contribution : diffuse, highlights,
> reflection, refraction, radiosity, photons, media ..etc So we can do
> compositing in post process (blur a reflection, add glow only on highlights,
> increase radiosity brightness, and so on without the need to re render)
That would use huge amounts of memory, and I'm not sure how useful it
would be. Using accumulation buffers would have big limitaitions, like
only blurring things on objects seen directly. Storing the ray trees
would use an impractical amount of memory...maybe in a decade, but by
then we probably won't need such tricks.
A single precision float usually takes 8 bytes. Assume we are using
those for everything, sacrificing some precision, a tree node is:
3 floats for ambient
3 floats for diffuse
3 floats for highlights (you could probably combine all types into this
one color, I don't think separate values for different types would be
useful)
3 floats for reflection
5(?) floats for pigment and transparency (assuming we keep the current
system...I think we shouldn't.)
2 node pointers (8 bytes each) for transmitted and reflected rays (it
could be many more, but I'll assume only two)
1 float for depth
3 floats for intersection point
3 floats for normal
3 floats for ray origin
3 floats for ray direction
30 floats and 2 pointers: 256 bytes for one node. The number of nodes
possible is 2^max depth. At the default of 7, that's 128 nodes, or 32KB
for one pixel sample. At 1024*768, that's 32MB a line, 24.6GB total.
Assuming no antialiasing and a lot of reflective transparent shapes. If
there is no transparency or reflection, only 192MB. And the overhead of
managing all that would probably destroy any benefits, especially when
using antialiasing.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That would use huge amounts of memory, and I'm not sure how useful it
> would be.
> 30 floats and 2 pointers: 256 bytes for one node. The number of nodes
> possible is 2^max depth. At the default of 7, that's 128 nodes, or 32KB
> for one pixel sample. At 1024*768, that's 32MB a line, 24.6GB total.
I wasn't talking about saving the whole rays history.. Just adding options
to output one or more kind of pixel contribution (diffuse, radiosity,
photons, etc) as a separate image. Exactly as in the post-process patch ,
but instead of keeping depth, normal, etc we'll keep diffuse, highlights, or
whatever the user asks for. So i don't think the memory overhead would be
too important.
Now you're right maybe those separate layers will not be that useful
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e1331bd$1@news.povray.org>, "Mael" <mae### [at] hotmailcom>
wrote:
> I wasn't talking about saving the whole rays history.. Just adding options
> to output one or more kind of pixel contribution (diffuse, radiosity,
> photons, etc) as a separate image. Exactly as in the post-process patch ,
> but instead of keeping depth, normal, etc we'll keep diffuse, highlights, or
> whatever the user asks for. So i don't think the memory overhead would be
> too important.
My point was that you do need the ray tree to get full use of it.
Otherwise you have to accumulate the data in a 2D buffer or only use the
primary rays...not that helpful, and making it optional would add (a
little) overhead even when you aren't using the feature.
I think these buffers about strike the right balance:
Raw color values (unclipped, antialiased)
first intersection depth
first intersection point
first intersection normal
first ray origin
first ray direction
object "ID" (internally object pointer)
136 bytes per pixel if all are used, a max of about 102MB for a 1024*768
image. More reasonable, and enough for almost anything. A minimum of
18MB for just the color information. (for comparison, a 24-bit
uncompressed image of the same size would be 2.25MB)
I'm not sure if the other buffers should be antialiased as well...it
doesn't really make a lot of sense, and would slow rendering.
You could get rid of ray direction and depth or intersection point,
direction and depth can be calculated from origin and point, point can
be calculated by direction, origin, and depth. The max memory could go
down to 78MB. This makes more calculation later on though, keeping them
means faster filters.
You could also use fixed point, especially for normal and direction,
where there is a definite range of component values.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cja### [at] netplexaussieorg> ,
Christopher James Huff <cja### [at] earthlinknet> wrote:
> A single precision float usually takes 8 bytes.
Not that it changes anything about your valid argument, but (IEEE 754)
single precision floating-point numbers still take only four bytes, not
eight.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 1 Jan 2003 15:01:58
Message: <3e134936@news.povray.org>
|
|
|
| |
| |
|
|
In article <3E12B6DE.431E9AC3@gmx.de> , Christoph Hormann
<chr### [at] gmxde> wrote:
> Yvo already explained the Mac specialties - it looks fine on:
>
> IE 5 Windows
> Mozilla 1 Windows
> Konqueror 3.0.1 Linux
Indeed, a good selection of browsers for Mac users ;-)
And the W3C once noted that IE 5.x for Mac would be very close to their HTML
and CSS recommendations. I would provide you with a reference, but somebody
at W3C accidentally or intentionally set the <www.w3.org/MarkUp/> content
type to "application/xhtml-xml", and as IE 5.0 for Mac OS does not support
XML it is successfully locked out from this part of the W3C website...
> but it has serious problems with Netscape 4.x
Of course, as said, I didn't expect it to work.
The real problem is that Mac OS ships with IE and the Apple Help viewer. So
it is reasonable to expect the help to work properly with at least one of
the two rather than forcing a multimegabyte download.
Besides, if DocBook and XML are so good, why does the official documentation
based on a proprietary system of extended HTML work so much better and on
all browsers? ;-) ;-) ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 1 Jan 2003 15:19:55
Message: <3E134D6B.5804DC6F@gmx.de>
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> > IE 5 Windows
> > Mozilla 1 Windows
> > Konqueror 3.0.1 Linux
>
> Indeed, a good selection of browsers for Mac users ;-)
If you buy me a Mac i will also be able to supply information on that...
>
> The real problem is that Mac OS ships with IE and the Apple Help viewer. So
> it is reasonable to expect the help to work properly with at least one of
> the two rather than forcing a multimegabyte download.
I really can't help much there. Have you tried if it is better without
the style sheet? If yes (like with NS 4.x) this would mean the problem is
in some style sheet definition.
> Besides, if DocBook and XML are so good, why does the official documentation
> based on a proprietary system of extended HTML work so much better and on
> all browsers? ;-) ;-) ;-)
And it also produces so much better PDF output... ;-)
Chistoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: ANNOUNCE: MegaPOV 1.0 available
Date: 1 Jan 2003 15:20:40
Message: <3E134D98.AB151D51@gmx.de>
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> [...]
>
> I think these buffers about strike the right balance:
> Raw color values (unclipped, antialiased)
> first intersection depth
> first intersection point
> first intersection normal
> first ray origin
> first ray direction
> object "ID" (internally object pointer)
As explained in my other post dividing the pixel colors into the different
contributing parts (i.e. reflected, refracted and direct, possibly split
into different parts) would be useful for post processing.
I think you are right to point out the memory problems. This was a major
problem already in the original post processing patch - post processed
focal blur on a print size render was quite difficult. Maybe it could be
avoided to have the data for the whole image in memory. For just writing
the data to a file for processing in external programs this should not be
difficult but for internal operations this is of course quite tricky.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3E134D98.AB151D51@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> As explained in my other post dividing the pixel colors into the different
> contributing parts (i.e. reflected, refracted and direct, possibly split
> into different parts) would be useful for post processing.
And as I explained, I don't think that would be useful enough. Aside
from the memory problems, it is too special purpose and limited, too
complex, and has too much impact on other things. I don't see any
practical use for it. Saving the ray tree would be far more useful, but
has monstrous memory requirements.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3e1345e3$1@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Not that it changes anything about your valid argument, but (IEEE 754)
> single precision floating-point numbers still take only four bytes, not
> eight.
Thanks for the correction, I knew I should have double-checked it...
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And it also produces so much better PDF output... ;-)
Not really: see for instance page 19 of the current PDF docs,
there are not PDF hyperlinks and no thumbnails in the file.
Use PDFLaTex ;op
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 31 Dec 2002 21:43:19 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> I've been thinking about this for a while...one thing I've always wanted
> was a way to create different "buffers" for filter input and output.
> That way, you could run two different filters on the raw image, and
> combine them with another filter, or output multiple processed versions
> of the same image.
Yes, that's exactly I have in mind. I also want to made is as pre-process for
image-maps. Not talking about connecting it with function VM.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
