 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <1fo366w.4sumen6c9b93N%yvos.s@gmx.net>,
yvo### [at] gmx net (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
|
|
| |
| |
|
|
|
|
| |
|
|
