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

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

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

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

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

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

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

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

On Wed, 01 Jan 2003 21:01:45 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > IE 5 Windows
> > Mozilla 1 Windows
> > Konqueror 3.0.1 Linux
>
> Indeed, a good selection of browsers for Mac users ;-)

Well, we have also txt version (it is in included dos archive) so there should
be no problem with the browser in that case ;-)

> 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?  ;-) ;-) ;-)

That's not the problem of the DocBook idea but problem of rendering process. I
had not much time to customize all features available in free XSL stylesheets
and templates at http://docbook.sourceforge.net/projects/xsl/index.html. Also
I choosed xhtml as target for output for documentation. It is possible to use
'traditional' html. Please, verify:

html chunked: http://megapov.inetart.net/manual/html/index.html
html long: http://megapov.inetart.net/manual/html/megapov01.html

xhtml chunked: http://megapov.inetart.net/manual/index.html
xhtml long: http://megapov.inetart.net/manual/megapov01.html

I have checked xhtml output in validators but noticed only report about missed
alt and unnecessary "xmlns" attribute. Now I rechecked this and it seems
during development there appeared some duplicated ids. I have to investigate
it more. I have already found some bugs in free XSL files and some were fixed
for our release.

ABX

Post a reply to this message

On Thu, 02 Jan 2003 00:09:05 +0100, Nicolas Calimet <pov### [at] freefr> wrote:
> > 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.

page 19 counting from first or page 19 counting from numbered as "1" ? :-)

In case of some urls there was no <ulink> tag applied. So I have to know what
tag you mean exactly to verify a bug. Please be more specific to help us make
it better.

>	Use PDFLaTex  ;op

Note, we are multienvironment team: windows (development tested on 95, 98, NT
and probably more), linux, mac (various versions) and we need effective but
uniform development. XSLT processors are easier to operate than TeX
environment. I could not force to work any of PDF outputs using TeX. I have
already looked for help with some experienced persons and could not find any.
But DocBook sources are available, if you have some experience, free time and
can provide tutorial how to do it for all mentioned platforms, please help us.

Any help in making MegaPOV documentation better either in appearance and
content is welcome.

ABX

Post a reply to this message

In article <msp71v8a6018mhh2apioh9anqa6b7om4ov@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I choosed xhtml as target for output for documentation. It is possible to use
> 'traditional' html. Please, verify:

XHTML???  For what reason would any sane person use XHTML?  On the other
hand, if your goal is to break as many browsers as possible, using XHTML is
fine, of course.

> html chunked: http://megapov.inetart.net/manual/html/index.html

Well, seems to work fine everywhere.  Except that Netscape 4.78 still
doesn't render the preformatted elements correctly.  I really wonder what
you did to break this?!?

    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

In article <msp71v8a6018mhh2apioh9anqa6b7om4ov@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I have checked xhtml output in validators but noticed only report about missed

Don't tell me that is all the testing you did???

    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

> 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.

Here is a simulated example (http://195.221.122.126/layers/layers.html) to see
what happens
i agree that
- it's probably useless for scene with lots of reflection/refraction
- it allows to tweak, and *fake* stuff (and this can sound like heresy to
ray-tracer integrists :)

M

Post a reply to this message

Mael wrote:
> 
> > 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.
> 
> Here is a simulated example (http://195.221.122.126/layers/layers.html) to see
> what happens
> i agree that
> - it's probably useless for scene with lots of reflection/refraction

It is surely more difficult but with an object 'ID' output like Chris Huff
suggested you could generate a mask to post process only certain objects
(like blurring the floor reflection in your case) Of course this would
miss the indirect appearances of that object in other reflections etc. but
this is only relevant in some situations and can often be neglected.

> - it allows to tweak, and *fake* stuff (and this can sound like heresy to
> ray-tracer integrists :)

It is out of question that post processing effects are not as good as
doing things internally but they have great speed advantages.

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

On Thu, 02 Jan 2003 11:17:30 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> XHTML???  For what reason would any sane person use XHTML?  On the other
> hand, if your goal is to break as many browsers as possible, using XHTML is
> fine, of course.

I don't remember exact reason why xhtml was used instead of html. I'm sure it
was becouse of some of several DocBook tutorials but can't recall url.
Everyone of us tested documentation versions on his native platform and it
seemed to work. I have also posted a link to you and you said nothing about
not readable pages, so I don't understand so much panic in your sentences :-)
It is a first release mostly concerned on building team, effective environment
and learning cooperation. It worked and we are happy about that. We can now
make it better. Would you like to provide some references according to "sane
persons vs. XHTML" ?

> > html chunked: http://megapov.inetart.net/manual/html/index.html
>
> Well, seems to work fine everywhere.

Then it will be changed probably in the future.

> Except that Netscape 4.78 still
> doesn't render the preformatted elements correctly.  I really wonder what
> you did to break this?!?

Nothing intentionally :-)

ABX

Post a reply to this message

ABX wrote:
> 
> > XHTML???  For what reason would any sane person use XHTML?  On the other
> > hand, if your goal is to break as many browsers as possible, using XHTML is
> > fine, of course.
> 
> I don't remember exact reason why xhtml was used instead of html. I'm sure it
> was becouse of some of several DocBook tutorials but can't recall url.
> Everyone of us tested documentation versions on his native platform and it
> seemed to work. 

I have compared html and xhtml versions with Netscape 4.x (which is the
only relevant Browser i could test causing problems) and there were no
differences in the result.

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

On Thu, 02 Jan 2003 11:18:14 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > I have checked xhtml output in validators but noticed only report about missed
>
> Don't tell me that is all the testing you did???

As it already appeared in this thread several browsers were checked.

ABX

Post a reply to this message

In article <do481v8qf80s9tm16632nvel7sg7ei5c9m@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> I don't remember exact reason why xhtml was used instead of html. I'm sure it
> was becouse of some of several DocBook tutorials but can't recall url.
> Everyone of us tested documentation versions on his native platform and it
> seemed to work. I have also posted a link to you and you said nothing about
> not readable pages, so I don't understand so much panic in your sentences :-)

Try this, the problem is the same for all of the links you provide, unless
of course the examples are supposed to look this way?


<http://mac.povray.org/md.gif>


> Would you like to provide some references according to "sane persons vs.
> XHTML" ?

Well, I do with this post. This message completely compiles with long
standing RFC MIME specifications. I hope you get the point now.

----------------------------------------------------------------------------



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

Attachments:
Download 'utf-8' (2 KB)

On Thu, 02 Jan 2003 13:46:21 +0100, "Thorsten Froehlich" <tho### [at] trfde>
> Try this, the problem is the same for all of the links you provide, unless
> of course the examples are supposed to look this way?
>
> <http://mac.povray.org/md.gif>

Could it be that your browser ignore that sequence (hex) 0D 0A 20 20 20
appeared in <pre> block for some reason should not be renderen as one space?

The same for: http://megapov.inetart.net/manual/html/test.html ?

> I hope you get the point now.

Ok. Will be htmled in the next release.

ABX

Post a reply to this message

Thorsten Froehlich wrote:
> 
> <http://mac.povray.org/md.gif>
> 

As i said most of the Netscape problems can be solved by not using the
style sheet.  I already considered making a separate version of the style
sheet for Netscape 4.x but i did not find the time yet.

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

> page 19 counting from first or page 19 counting from numbered as "1" ? :-)

	It's the number written on the top of the page. I just took this
one as an example of the equations being justified on the line (while they
should note). It's really nothing. Just to tell the conversion is not
perfect, as any conversion I suppose  :-)

> Note, we are multienvironment team: windows (development tested on 95, 98, NT
> and probably more), linux, mac (various versions) and we need effective but
> uniform development.

	Sure. This is good. (Don't know if TeX and friends are available
on Mac architectures, though OS X should not be a problem; for windows
it exists for sure). My notice was not meant to be a criticism, but only
a small joke. The work you're doing on MegaPOV and all the things before
is simply amazing...

> if you have some experience, free time and
> can provide tutorial how to do it for all mentioned platforms, please help us.

	I would if I had this free time. At least more than the few minutes
I spend reading the newsgroups and the very good docs that were prepared on
this brand-new MegaPOV.

	Please keep up the good work and don't forget to notice the
smileys I put in my previous message  :-) ;-)

	- NC

Post a reply to this message

In article <3E143CF8.6AAD01C2@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

>> <http://mac.povray.org/md.gif>
>
> As i said most of the Netscape problems can be solved by not using the
> style sheet.  I already considered making a separate version of the style
> sheet for Netscape 4.x but i did not find the time yet.

Indeed, but the problems are solvable ones one knows the Netscape internal
implementation of stylesheets:  Netscape does not cascade relative so some
internal style sheet for anything but the most elementary formatting (afaik
only for font types and sizes).  So when you assume the cascading works
relative to a complete internal stylesheet, some CSS elements will inherit
the CSS defaults rather than reasonable values.  So the "pre" block in the
CSS simply needs to be completed with

    white-space: pre;

because Netscape uses the default, which is "normal" rather than "pre".

    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

In article <7do71v0ei2pe14hld0kppo35d1cuqnpqt3@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Yes, that's exactly I have in mind. I also want to made is as pre-process for
> image-maps.

Well, it would need image input features, some way to read and write 
files. Maybe it could just be allowed to be activated during parsing, 
without the predefined buffers that would be available for post 
processing.

global_settings {
    post_process {IMAGE_PROCESSING_STUFF}
}

process_images {IMAGE_PROCESSING_STUFF}


> Not talking about connecting it with function VM.

Not sure what you meant here..."Not to mention connecting it with a 
function VM."? "I refuse to talk about connecting it with a function 
VM."?

-- 
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 <1ee81vkknlso5kvbak89vq4mpu7e00d06e@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

>> <http://mac.povray.org/md.gif>
>
> Could it be that your browser ignore that sequence (hex) 0D 0A 20 20 20
> appeared in <pre> block for some reason should not be renderen as one space?
>
> The same for: http://megapov.inetart.net/manual/html/test.html ?

No, Netscape has no problem with line-endings (that would be really bad,
wouldn't it ;-)    I explained the problem in my reply to Christoph.  The
following will work just fine:

pre {
  font-family: "Lucida Console","Lucida Sans Typewriter","Courier
New","monospace" ;
  color: #000000 ;
  background-color: #e6f4ff ;
  border: 1px solid ;
  border-color: #cfdbe5 ;
  padding: 3pt;
  white-space: pre ;
}

BTW, note that "Courier New" is a typical M$ font.  People on those
operating systems whose creators were willing to pay the royalties to the
font copyright holders will have fonts with the proper name - "Courier".
They are unlikely to have any of the fonts you list of pre elements as they
are all Windows specific ;-)   If you want to add a good-looking font for
Mac OS, that would be "Monaco", which is also used by Mac text editors by
default.

You may also want to change the order of Verdana, Arial, Helvetica,
sans-serif to Verdana, Helvetica, Arial, sans-serif for the same reason, as
Arial is just a cheap M$ replacement for Helvetica, and Verdana is a M$
invented font...

>> I hope you get the point now.
>
> Ok. Will be htmled in the next release.

You do a lot of readers a favor, thanks a lot!

    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

On Thu, 02 Jan 2003 09:38:31 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> > Not talking about connecting it with function VM.
>
> Not sure what you meant here..."Not to mention connecting it with a 
> function VM."? "I refuse to talk about connecting it with a function 
> VM."?

I meant that post processed should use user defined functions.

ABX

Post a reply to this message