 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
from povray.co.uk
Seems that for a couple of French guys at least, POV and its patches are not
enough. They have decided to write zRCube, current release only has standard
raytracing, however planned features include radioasity, NURBS and network
rendering.
Why a clone? Well it uses POV-Rays scene description language. Cheers to
Thomas for the heads up.
http://zrcube.sourceforge.net/
is there an official line on this, as in a way its pov, but not pov?
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" <ric### [at] kitty5 com> wrote in message
news:3b156c2e@news.povray.org...
> from povray.co.uk
>
> Seems that for a couple of French guys at least, POV and its patches are
not
> enough. They have decided to write zRCube, current release only has
standard
> raytracing, however planned features include radioasity, NURBS and network
> rendering.
Any chance of someone hosting a Win32 executable of this - I have no idea
what a tar.gz file is, but I assume it's something to do with compiling....
it's just that I'd love a play with this and don't have the software/skills
required to compile my own.
Thanks,
Peter Cracknell
--
http://www.petercracknell.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.255 / Virus Database: 128 - Release Date: 17/05/2001
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b15701d@news.povray.org>, "Peter Cracknell" <pc### [at] lineonenet>
wrote:
> "Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
> news:3b156c2e@news.povray.org...
>> from povray.co.uk
>>
>> Seems that for a couple of French guys at least, POV and its patches
>> are
> not
>> enough. They have decided to write zRCube, current release only has
> standard
>> raytracing, however planned features include radioasity, NURBS and
>> network rendering.
>
> Any chance of someone hosting a Win32 executable of this - I have no
> idea what a tar.gz file is, but I assume it's something to do with
> compiling.... it's just that I'd love a play with this and don't have
> the software/skills required to compile my own.
>
> Thanks,
> Peter Cracknell
>
> --
> http://www.petercracknell.com
A tar.gz file is a source archive for Linux. Winzip should be able to
open it, but without a working Linux ditstribution, you wouldn't be able
to compile it without porting it to Windows. Hope this helps!
David
smu### [at] ameritechnet
ICQ#: 118347772
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b15701d@news.povray.org>,
"Peter Cracknell" <pc### [at] lineonenet> wrote:
> Any chance of someone hosting a Win32 executable of this - I have no idea
> what a tar.gz file is, but I assume it's something to do with compiling....
The tar.gz file is just a compression/archive format, like .sit or .zip,
common on Unix and Unix-like systems. It has nothing to do with
compiling...
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b156c2e@news.povray.org>,
"Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> Why a clone? Well it uses POV-Rays scene description language. Cheers to
> Thomas for the heads up.
It sounds like it's a completely different kind of renderer, sharing
most of the SDL, but using other rendering and lighting methods(like
"real" radiosity, not Monte-Carlo raytracing like POV uses). They also
don't seem to know that POV itself will be rewritten soon...
> is there an official line on this, as in a way its pov, but not pov?
Since no POV source is involved, and it doesn't claim to be POV, I don't
see why...
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
>
> is there an official line on this, as in a way its pov, but not pov?
IIRC, the POV License specifically forbids reuse of POV-Ray
code, and specifically encourages re-use and implementation
of POV-Ray SDL, though they reserve the right to change the
language at any time.
--
Adrien Beau - adr### [at] freefr - http://adrien.beau@free.fr
Hé, mes propos n'engagent que moi !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Cracknell wrote:
>
> Any chance of someone hosting a Win32 executable of this - I have no idea
> what a tar.gz file is, but I assume it's something to do with compiling....
> it's just that I'd love a play with this and don't have the software/skills
> required to compile my own.
>
I had a quick look, the program uses gtk and therefore will not be
compilable straight away with cygwin. There is a port of gtk for Windows
so it should be possible.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> It sounds like it's a completely different kind of renderer, sharing
> most of the SDL, but using other rendering and lighting methods(like
> "real" radiosity, not Monte-Carlo raytracing like POV uses). They also
> don't seem to know that POV itself will be rewritten soon...
>
Now i'm disturbed, doesn't 'real' radiosity require tessellation of
objects?
BTW i don't agree with most of the things they write in their
introduction, especially the stuff about "more recent algorithms" and
rendering speed.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3B15FC14.4280E329@gmx.de Christoph Hormann wrote:
> BTW i don't agree with most of the things they write in their
> introduction, especially the stuff about "more recent algorithms" and
> rendering speed.
Well, they must have found some amazing algorithms, as they state:
"... I don't care if I spent 40 seconds or 25 secs for my final
rendering if the final result is better for the longer rendering...."
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chr### [at] povrayorg> , Chris Huff
<chr### [at] maccom> wrote:
> It sounds like it's a completely different kind of renderer, sharing
> most of the SDL, but using other rendering and lighting methods(like
> "real" radiosity, not Monte-Carlo raytracing like POV uses).
Interesting enough, their description implies it will support "radiosity"
and POV-Ray uses a different not "real" radiosity. Both are "radiosity"
regarding the effect they simulate, and their approach will force
tessellation for most objects. As far as I know others have tried to
combine the classic radiosity with raytracing and the results were hardly
ever fast enough for complex scenes.
> They also don't seem to know that POV itself will be rewritten soon...
Their description shows some misunderstanding. The fundamental raytracing
algorithm has been developed over 30 years ago, so whether it was
implemented ten years ago or ten days ago will not make any difference in
output quality or speed.
Besides, features like radiosity don't just make a difference of 40 instead
of 25 seconds to render (as said in their description). A good
approximation of a complex scenes will take much longer, and since one
usually ends up solving a big matrix, memory and/or processing requirements
are extreme, it only makes sense for animations (because it is viewpoint
independent) but for still images the method currently used by POV-Ray will
likely give a better results on non-supercomputers.
And, right now there is no word on support of future official features like
photons, which probably add more realism to a scene than a more precise
radiosity algorithm.
In conclusion, the most useful feature they offer is the reuse of POV-Ray
scenes, but I would expect them to look just different, not necessarily
"more realistic"...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] maccom> wrote in message
news:chr### [at] povrayorg...
> In article <3b156c2e@news.povray.org>,
> "Rick [Kitty5]" <ric### [at] kitty5com> wrote:
>
> > Why a clone? Well it uses POV-Rays scene description language. Cheers to
> > Thomas for the heads up.
>
> It sounds like it's a completely different kind of renderer, sharing
> most of the SDL, but using other rendering and lighting methods(like
> "real" radiosity, not Monte-Carlo raytracing like POV uses). They also
> don't seem to know that POV itself will be rewritten soon...
Maybe this is a stupid question, but why doesn't Pov use real radiosity? Will
future versions have real radiosity as an option? It would be nice to have both
methods available IMHO. =)
Maybe the coding is too difficult, or copyrighted in a way that Pov couldn't use
it?
Nekar
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3B15F9CD.DB43743C@gmx.de...
>
>
> Peter Cracknell wrote:
> >
> > Any chance of someone hosting a Win32 executable of this - I have no
idea
> > what a tar.gz file is, but I assume it's something to do with
compiling....
> > it's just that I'd love a play with this and don't have the
software/skills
> > required to compile my own.
> >
>
> I had a quick look, the program uses gtk and therefore will not be
> compilable straight away with cygwin. There is a port of gtk for Windows
> so it should be possible.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/
Thanks for the replies but I still couldn't get it to work. I downloaded
the file zapped it in Winzip and ended up with a huge list of .h, .cpp,
.sub, .in, .am type files, but no binary. Aren't these C++ related files?
Sorry to appear so stupid I just wouldn't mind a play with this...
Peter Cracknell
--
http://www.petercracknell.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.255 / Virus Database: 128 - Release Date: 17/05/2001
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos <j-p### [at] citywalkcoza> wrote in message
news:3b15fe70@news.povray.org...
>
> Maybe this is a stupid question, but why doesn't Pov use real radiosity?
Will
> future versions have real radiosity as an option? It would be nice to have
both
> methods available IMHO. =)
>
afaik 'Real' radiosity requires triangle meshes. That means for pov to
implement it, every object would need to be tesselated (Converted to
triangles). Easy enough for boxes, imagine tesselating a julia fractal
or a complex isosurface...
Gail
--
*************************************************************************
* gsh### [at] monotixcoza * Step into the abyss, *
* http://www.rucus.ru.ac.za/~gail/ * and let go. Babylon 5 *
*************************************************************************
* The difficult we do immediately, the impossible takes a little longer *
*************************************************************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
>
> afaik 'Real' radiosity requires triangle meshes. That means for pov to
> implement it, every object would need to be tesselated (Converted to
> triangles). Easy enough for boxes, imagine tesselating a julia fractal
> or a complex isosurface...
>
Not to mention a sphere...
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote in message
news:3B1605D5.B0C5D0A3@gmx.de...
>
>
> Gail Shaw wrote:
> >
> > afaik 'Real' radiosity requires triangle meshes. That means for pov to
> > implement it, every object would need to be tesselated (Converted to
> > triangles). Easy enough for boxes, imagine tesselating a julia fractal
> > or a complex isosurface...
> >
>
> Not to mention a sphere...
>
A reasonable approximation of a sphere isn't hard. A sphere's geometry
is well defined. The problem I can see with isos expecially is that they
don't
have a well defined geometry and can look like anything.
I don't even want to think about writing code to tesselate any isosurface.
Gail
--
*************************************************************************
* gsh### [at] monotixcoza * Step into the abyss, *
* http://www.rucus.ru.ac.za/~gail/ * and let go. Babylon 5 *
*************************************************************************
* The difficult we do immediately, the impossible takes a little longer *
*************************************************************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> IIRC, the POV License specifically forbids reuse of POV-Ray
> code, and specifically encourages re-use and implementation
> of POV-Ray SDL, though they reserve the right to change the
> language at any time.
It just struck me as odd that David Gemelli was concerned with the wording
of pov legal for his max to pov plugin, yet there are no problems
duplicating the scene description language.
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1609e6@news.povray.org> , "Gail Shaw" <gsh### [at] monotixcoza>
wrote:
> I don't even want to think about writing code to tesselate any isosurface.
It is possible with some approximation because the inside and outside of an
isosurface is defined (this works for other objects with this property,
too). However, a lot of triangles are necessary and the level of detail
will be far from a "real" isosurface.
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 <3b15fe70@news.povray.org> , "Nekar Xenos"
<j-p### [at] citywalkcoza> wrote:
> Maybe this is a stupid question, but why doesn't Pov use real radiosity?
There is no "real" radiosity, only different ways to do the same thing. In
fact the radiosity POV-Ray uses can be adapted to produce perfect results,
but this would require us to wait a billion years or more to see the final
image ...
> Will future versions have real radiosity as an option? It would be nice to
> have both methods available IMHO. =)
No, it is pointless to have the other algorithm in a raytracer in almost all
cases because it likely reduces (still) image quality due to tessellation.
In fact both methods approximate their results, while one approximates the
surfaces and contribution, the method used by POV-Ray approximates the
contribution only but in a less precise way than in the other method does.
> Maybe the coding is too difficult, or copyrighted in a way that Pov couldn't
> use it?
No, neither is the problem. It is simply that one method is more suitable
for a raytracer than the other method. There are programs out there that do
a very good job applying the "other" radiosity algorithm without raytracing.
Look for links to renderers in the POV-Ray links collection.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b16012c@news.povray.org> , "Peter Cracknell" <pc### [at] lineonenet>
wrote:
> Thanks for the replies but I still couldn't get it to work. I downloaded
> the file zapped it in Winzip and ended up with a huge list of .h, .cpp,
> .sub, .in, .am type files, but no binary. Aren't these C++ related files?
> Sorry to appear so stupid I just wouldn't mind a play with this...
It is just a the source files to be compiled under Linux. No use on any
other platform.
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:
>
> It is just a the source files to be compiled under Linux. No use on any
> other platform.
I would rather say: this is just the source files. They
probably can compile only under Linux, and need work on
them before they can compile under Windows.
Cheers... :-)
--
Adrien Beau - adr### [at] freefr - http://adrien.beau@free.fr
Hé, mes propos n'engagent que moi !
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David <smu### [at] ameritechnet> wrote:
: A tar.gz file is a source archive for Linux.
No, it isn't.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos <j-p### [at] citywalkcoza> wrote:
: Maybe this is a stupid question, but why doesn't Pov use real radiosity?
There's no such a thing as "real" radiosity.
There's an algorithm called "radiosity" which calculates the
inter-reflection of light between flat polygons. This algorithm is usable
only if your scene consists of polygons.
POV-Ray uses a monte-carlo raytracing method in order to calculate
the inter-reflection of light between surfaces. The advantage of this
method is that it works with any object you can raytrace.
Both methods have their advantages and disadvantages. Usually the first
method is faster but more limited. It's also a bit unoptimized (it has
to be calculated for every surface, even those which are not seen and do
not contribute to the global illumination in any way). And as said, it only
works with polygons.
The second method is usually slower, but can give as good results as the
first, and even better. AFAIK Radiance uses monte-carlo raytracing for
the radiosity calculations, and its quality is well known.
The implementation of this in POV-Ray just suffers from some problems
(probably bugs), which makes it problematic in some cases.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> David <smu### [at] ameritechnet> wrote:
> : A tar.gz file is a source archive for Linux.
>
> No, it isn't.
Mostly true.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is an interesting "our program is better than POV-Ray but it isn't".
Fancy words, but mostly crap.
"zRcube aims to be more modern than pov, using more recent algorithms."
This resumes the whole crap: It assumes that POV-Ray is old, that it
uses old algorithms and is not developed anymore.
What is old in POV-Ray? Take any modern raytracer and its basic algorithms
will be the same as in POV-Ray.
Moreover, POV-Ray even uses more modern and efficient algorihtms than many
other raytracers (such as LightFlow etc). These include vista buffers, light
buffers, automatic bounding, polynomial objects, adaptive antialiasing and so
on. The upcoming 3.5 will have even more sophisticated features, such as
functions, isosurfaces and photon mapping. Most opimizations in POV-Ray
make it often faster than other raytracers with similar scenes.
"The idea behind this project is that most of available free
rendering software were designed a long time ago, when computers were
really slower than now, and consequently these engines were a
compromise between rendering quality and speed. But now, our computers
are fast, maybe too fast for what we use them for... I don't care if I
spent 40 seconds or 25 secs for my final rendering if the final result
is better for the longer rendering..."
The crap continues.
For some reason they assume that image quality was compromised in order
to get faster rendering. I really don't understand where did they get that
idea.
What I understand of that paragraph is that they think that the developers
of POV-Ray thought something like "ok, we could do this to look better, but
it would be very slow, so we'll just rip off something from the quality in
order to get more speed". This makes no sense. I would like to hear some
examples of POV-Ray where this kind of compromise was made. Which feature
could look better if we don't worry about the rendering time (and you have
no way of tuning its quality so that you can get the better result)?
They also have this funny conception that in current computers the
scenes made by people take usually much less than 1 minute to render.
What a crap. You can look at almost any high-quality image (no matter
which renderer) and see how much time it took to render: The render
time of a final rendering is usually several hours, no matter what
computer was used. For example most IRTC images take many hours to
render (often the rendering times can be even several days).
What they are saying in the paragraph above is "as in current computers
scenes take less than a minute to render, it doesn't matter if it takes
a half minute or one minute". This is crap. If you are making a good-quality
final render, it will usually take hours to render.
Besides, this has a funny drawback: What they are actually saying is
that their renderer is 1.6 times slower than POV-Ray. This means that
something that takes 1 hour to render with POV-Ray will take more than
1 hour and a half to render with their program. Not too positive. Not
something that encourages you to switch to their program.
"When we began to think about this project, we first said:
'radiosity is a great algorithm for illumination, it makes no
compromises and the pictures rendered using it are really realistic'.
So we have to use it. Then, one of us said 'But we cannot handle refraction
and reflexion with radiosity, only ray-tracing can do that'."
I really don't understand why everyone speaks about "radiosity" as if
it was a _rendering_ algorithm. That is, you _render_ a scene with the
"radiosity" algorithm and you get a final image.
I know how the "radiosity" algorithm works and I have seen how it is
calculated (at mathematical formula level).
"Radiosity" is _NOT_ a rendering technique. I just don't understand why
everyone speaks about it as if it was.
What "radiosity" does is to calculate the illumination of the surfaces.
That is, it calculates how a surface (or a point on the surface, depending
on how accurately it is implemented) is illuminated by all the other
surfaces in the scene.
That is, "radiosity" just calculates illumination values. It does _NOT_
project the surfaces on screen, it does _NOT_ write anything to the screen
(or an image file for that matter). You _DON'T_ get a final image from
the radiosity calculations, just illumination values (for example in
the form of a light map or something similar).
In order to get the final image from the polygons you have to use a
rendering algorithm. The most viable ones are scanline rendering (which
is the most commonly used) and raytracing (which isn't very rare in
radiosity renderings either).
That is, the polygons are rendered with scanline rendering or raytracing
and taking into account the lighting values given by the radiosity algorithm.
(People who talk about "radiosity" as a rendering technique often oppose
it to raytracing, as if they were equal techniques and mutually exclusive.
This is just plain laughable. Radiosity just calculates illumination values;
it couldn't care less what is the actual rendering algorithm used to
draw the polygons on screen; it can be scanline rendering or raytracing;
it doesn't care.)
I personally think about these kind of people as ignorants. And it seems
that these guys fall into this category.
By the way, looking at their "complete features" list is quite funny.
Their "modern" raytracer lacks most of POV-Ray's "old" (and perhaps
obsolete?) features, such as CSG, media, matrix transformations, most
objects, most camera types, normal modifiers, antialiasing and almost every
flow control feature of the POV-Ray SDL (ie. #if, #while, #switch, #macro
and so on).
Many of those are probably explained with the fact that they probably
use polygons and some things are quite hard to tesselate (eg. CSG).
Modern my ass.
PS: Yes, every time someone makes a stupid claim of something being "better"
than POV-Ray, I see red.
This is not because I think POV-Ray is perfect and the best renderer
possible in every aspect, but it's because I consider it completely stupid
to start comparing different renderers and say that one is better than
the other. Every renderer is good in its own field of expertise and every
renderer is good for certain things. There's no such a thing as a renderer
which is better than another renderer.
Specially "I have made a renderer better than POV-Ray"-type of people are
extremely irritating.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
:> : A tar.gz file is a source archive for Linux.
:>
:> No, it isn't.
: Mostly true.
I'm sorry about my minimalist and rude answer :)
Firstly, a .tar.gz has nothing to do with source archives. It's just
a packing format completely equivalent to .zip, .arj or .rar. It couldn't
care less about what's packed inside it. Unix program sources are usually
distributed in this format, but that's just because it's the most common
packing format in Unix; everything else is usually packed with this format
as well. The format itself has nothing to do with sources or anything.
(If we are pedantic, a .tar.gz file is actually packed with _two_ programs:
first tar and then gzip, although the gtar program supports both at the same
time.)
Secondly, .tar.gz has nothing to do with Linux. In the same well as .zip
and .rar are universal formats, so is .tar.gz. It's just a system-independent
packing format.
The fact that it has become popular in the Unix world does not make it
a Linux format.
(I smell a say-Linux-when-should-say-Unix phenomenon in the original
article as well, which is rather irritating...)
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> (People who talk about "radiosity" as a rendering technique often oppose
> it to raytracing, as if they were equal techniques and mutually exclusive.
> This is just plain laughable. Radiosity just calculates illumination values;
> it couldn't care less what is the actual rendering algorithm used to
> draw the polygons on screen; it can be scanline rendering or raytracing;
> it doesn't care.)
Thanks for clearing this for me. I really got quite confused about this by just
looking at their site :-P
Nekar
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Only nitpicking... do not take too seriously :-)
Warp wrote:
> The crap continues.
> For some reason they assume that image quality was compromised in order
> to get faster rendering. I really don't understand where did they get that
> idea.
> What I understand of that paragraph is that they think that the developers
> of POV-Ray thought something like "ok, we could do this to look better, but
> it would be very slow, so we'll just rip off something from the quality in
> order to get more speed". This makes no sense. I would like to hear some
> examples of POV-Ray where this kind of compromise was made. Which feature
> could look better if we don't worry about the rendering time (and you have
> no way of tuning its quality so that you can get the better result)?
>
The 'sturm' keyword is such a case (probably the only one), where the default
choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
poly,
some prism and quartic).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 31 May 2001 17:33:32 +0200, Jérôme Grimbert wrote:
>> examples of POV-Ray where this kind of compromise was made. Which feature
>> could look better if we don't worry about the rendering time (and you have
>> no way of tuning its quality so that you can get the better result)?
>>
>The 'sturm' keyword is such a case (probably the only one), where the default
>choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
>poly,
>some prism and quartic).
Likewise media parameters and perhaps the default radiosity parameters. But
you seem to have ignored the parenthetical part of the question.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> They also have this funny conception that in current computers the
> scenes made by people take usually much less than 1 minute to render.
> What a crap. You can look at almost any high-quality image (no matter
> which renderer) and see how much time it took to render: The render
> time of a final rendering is usually several hours, no matter what
> computer was used. For example most IRTC images take many hours to
> render (often the rendering times can be even several days).
My Rusty animations take about twenty minutes per frame for final
rendering, and I generally draw the line at about thirty. But since
there are usually over a thousand of them in each animation, I have to
draw the line somewhere.
The only ones that take less than a minute are the very dark parts of
the fades... As for the others, I assume I'm leaving stuff out if
they take less than ten minutes per frame in the final rendering.
Regards,
John
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B15F9CD.DB43743C@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> I had a quick look, the program uses gtk and therefore will not be
> compilable straight away with cygwin.
Or OS X...I don't know about any GTK port projects for OS X.
POV-Ray, on the other hand, compiles fine...
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1609e6@news.povray.org>,
"Gail Shaw" <gsh### [at] monotixcoza> wrote:
> I don't even want to think about writing code to tesselate any isosurface.
Actually, any object that has an inside and outside, and a finite volume
can be tesselated, for example by using the marching cubes or marching
tetrahedrons algorithms. Warp's tesselation patch is an example of this.
However, the meshes don't use triangles very efficiently, and high
amounts of detail require *huge* meshes.
PS: I think even shapes without an inside can be tesselated, as long as
you can figure out if the surface is between any two points.
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b164ee8@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> it can be scanline rendering or raytracing; it doesn't care
You imply the rendering algorithm used to apply the radiosity light model
does not matter. Are you really sure this holds true in case of raytracing?
Do the light models for reflection and refraction really work if you just
see the radiosity data as a surface color variation? Would it be applied
prior or after the reflection/refraction is calculated? I am just
wondering, if you are not sure - no problem, I am asking because I don't
know but would be interested in knowing because I never saw any written
description of the classic radiosity being used with recursive raytracing.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> This is an interesting "our program is better than POV-Ray but it isn't".
> Fancy words, but mostly crap.
> ...
> Modern my ass.
>
> PS: Yes, every time someone makes a stupid claim of something being "better"
> than POV-Ray, I see red.
> This is not because I think POV-Ray is perfect and the best renderer
> possible in every aspect, but it's because I consider it completely stupid
> to start comparing different renderers and say that one is better than
> the other. Every renderer is good in its own field of expertise and every
> renderer is good for certain things. There's no such a thing as a renderer
> which is better than another renderer.
Another approach is to look at what can be done to improve things. When
a good idea exists, why not implementing it? This is how we got our
patches, and finally why we'll have 3.5 "soon". There is a "bright" side
at benchmarking, but their (mindcraft-like) approach is definitely dumb.
BTW I won't comment their assertion that parallel radiosity is not
possible with POV-Ray ;-)
--
François DISPOT -- http://www.wozzeck.net
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
>
> A reasonable approximation of a sphere isn't hard. A sphere's geometry
> is well defined.
A reasonable tesselation of a sphere is quite a difficult thing IMO.
Enough triangles that no corners are visible with the current camera
position and angle and not to much that it does not need too much memory.
Newly generating the mesh with every change of viewpoint, ...
Of course these things also apply for other objects, but most other things
do not need to be that totally smooth.
> The problem I can see with isos expecially is that they
> don't
> have a well defined geometry and can look like anything.
>
> I don't even want to think about writing code to tesselate any isosurface.
>
I don't see that much principal difference between a sphere and an
arbitrary isosurface apart from the fact that you can parametrize a sphere
and thereby have a way for tesselating it.
I recently read an article about tessellation of isosurfaces (in
March/April issue of IEEE Computer Graphics and Applications) and it's not
that difficult, the method Warp uses in his tesselation patch for example
works equally good (or bad) on conventional objects and isosurfaces.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B16644C.477C3B1F@atosorigin.com> , Jérôme Grimbert
<jer### [at] atosorigincom> wrote:
> The 'sturm' keyword is such a case (probably the only one), where the default
> choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
> poly, some prism and quartic).
Actually, this is not the case. Any platform and library could provide a
square root that provides the same precision as the you get with "sturm" *.
It is just that on most platforms this is not done by default and POV-Ray
contains code that works around this compiler/library/platform limitation.
Kind of a platform specific hack you can add to your scenes, just that it is
necessary on all current desktop platforms.
I would also expect the precision of the default square root to be good
enough on platforms that support 128 bit floating-point arithmetic. Then
"sturm" would not be needed at all.
Thorsten
* Yes, we are talking about polynoms here, but internally POV-Ray uses
"sqrt" to find the roots, while "sturm" switches to the sturmian sequence to
solve it. Effectively, the limited precision of "sqrt" is one of the
problems together with the use of some other library functions such as "cos"
and "acos" which are frequently based on approximations in C libraries...
____________________________________________________
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 <chr### [at] povrayorg> , Chris Huff
<chr### [at] maccom> wrote:
> Actually, any object that has an inside and outside, and a finite volume
> can be tesselated
You should say "finite surface" just to make sure you cover certain odd
functions.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
it was the amount of crap they had written, and the use of pov files that
made me wonder if they had just snaffled pov and tweaked it a little.
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31 May 2001 10:02:16 -0400, Warp wrote:
> This is an interesting "our program is better than POV-Ray but it isn't".
>Fancy words, but mostly crap.
You missed one. Features: NURBS? How do you do NURBS with POV SDL?
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 30 May 2001 22:44:18 +0100, Rick [Kitty5] wrote:
>is there an official line on this, as in a way its pov, but not pov?
This isn't me speaking in any official capacity, but.. um... what is the
license on colors.inc?
At first glance, though, their parser looks okay. They can't have used
any POV code, because they're missing some tokens that have been there
since 2.2 and before.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On 31 May 2001 10:02:16 -0400, Warp wrote:
> > This is an interesting "our program is better than POV-Ray but it isn't".
> >Fancy words, but mostly crap.
>
> You missed one. Features: NURBS? How do you do NURBS with POV SDL?
>
As far as i have seen from the sample scenes included, there is nothing
like a NURBS object, they probably just represent spheres etc. internally
as NURBS.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1650cf@news.povray.org>, "Warp" <war### [at] tagpovrayorg> wrote:
> Firstly, a .tar.gz has nothing to do with source archives. It's just
> a packing format completely equivalent to .zip, .arj or .rar. It
> couldn't care less about what's packed inside it. Unix program sources
> are usually distributed in this format, but that's just because it's the
> most common packing format in Unix; everything else is usually packed
> with this format as well. The format itself has nothing to do with
> sources or anything.
> (If we are pedantic, a .tar.gz file is actually packed with _two_
> programs:
> first tar and then gzip, although the gtar program supports both at the
> same time.)
>
> Secondly, .tar.gz has nothing to do with Linux. In the same well as
> .zip
> and .rar are universal formats, so is .tar.gz. It's just a
> system-independent packing format.
> The fact that it has become popular in the Unix world does not make it
> a Linux format.
> (I smell a say-Linux-when-should-say-Unix phenomenon in the original
> article as well, which is rather irritating...)
I apologize for the rather incorrect respomse. As you can see from the
time, it was late, and I probably should've waited until morning to post.
Oh well, thank you for correcting me.
David
ICQ#: 118347772
smu### [at] ameritechnet
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> :> : A tar.gz file is a source archive for Linux.
> :>
> :> No, it isn't.
>
> : Mostly true.
>
> I'm sorry about my minimalist and rude answer :)
I was just jerking your chain anyway :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: You imply the rendering algorithm used to apply the radiosity light model
: does not matter. Are you really sure this holds true in case of raytracing?
: Do the light models for reflection and refraction really work if you just
: see the radiosity data as a surface color variation? Would it be applied
: prior or after the reflection/refraction is calculated? I am just
: wondering, if you are not sure - no problem, I am asking because I don't
: know but would be interested in knowing because I never saw any written
: description of the classic radiosity being used with recursive raytracing.
As far as I know, the radiosity is (at least usually) a pre-calculation
step, much like photon mapping. It's very similar to photon mapping in that
you first calculate the illumination (eg. light maps) of every surface and
after that you render the scene.
I don't know how well the basic radiosity algorithm can simulate reflected
light of mirror surfaces (as photon mapping does), but I have the impression
that not very well. AFAIK it can't simulate refracted light at all (I think
that would require raytracing, exactly what photon mapping does).
When taking into account these illumination values I don't think there's
any difference on whether you use scaline rendering or raytracing. Radiosity
merely changes the color of the surfaces and that's it.
I might be completely wrong here of course, but I have never heard of
anything else (well, there might be more advanced versions of the basic
algorithm which do more, but I have never heard of those).
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
: As far as i have seen from the sample scenes included, there is nothing
: like a NURBS object, they probably just represent spheres etc. internally
: as NURBS.
It will be interesting to see if they are able to implement more complex
objects as NURBS, such as CSG and many complicated objects (julia_fractal
being a good example).
I don't mean that they are not possible to simulate with NURBS (they
probably are), I mean that the coordinate parameters is the hard thing to
calculate...
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> This is an interesting "our program is better than POV-Ray but it isn't".
> Fancy words, but mostly crap.
Come on, these are just 4 computer school students writing a raytracer for their
curriculum. They're due to show it to their teacher this month. Blame the fancy
words and inaccuracies on Young Programmer Hubris coupled with enthousiasm and
lack of research. Nothing uncommon, and nothing to get excited about.
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
First of all I would like to say that I am the one that pointed povray.co.uk to
the zRCube web page.Secondly I also want to say that I really really like pov
and I have used it for years.
I stumbled acros the zrcube program a few months ago and had a quick look at it.
Last week I updated the sources, compiled them and ran a few test renders, and
they looked fine. I don't want to go into all the detailed discussion that has
been going on here regarding how radiosity should/could be done and certainly
not what is "real" radiosity. As a user I only care in the end how it looks like
and how long it takes.
One of the thing I would like to comment on is that zrcube currently compiles
and runs only on Unix like operating systems with gtk installed (which is only
used to display the image to the screen), but I see no reason why the rendering
core could be ported to other platforms quite easily, pov does the same in the
end. And whether one renderer is better then the other or not is no discussion
either POV is better and probably will stay better for a long time, but zrcube
adds a few very interesting feature, most notably network rendering. Which is a
VERY big miss in pov. What I also like about zrcube is the license, it has been
licensed under GPL which means everyone can do with the code whatever they want,
as long as they provide the sources as well.
It will be interesting to see how far these guys get in the next two weeks and
to see whether development will continue after that (after they handed over the
code to their teachers everyone can contribute to the code). Maybe a little
competition for POV is good thing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And what I forgot to add was that there might be a bit of a language barrier as
well, these guys are French and for some reason I have the feeling that there
English is not the best (no offence intended to anyone), maybe just take everything
with a grain of salt.
And another thing is that I think that pov should be a little bit honoured that
someone else has decided to take the SDL and make a compatible raytracer.
just my two cents
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas wrote:
>
> [...]
> , but I see no reason why the rendering
> core could be ported to other platforms quite easily, pov does the same in the
> end.
Not really correct, the Povray rendering engine is originally designed as
being portable, the platform specific frontends are purely optional.
> [...]
> , but zrcube
> adds a few very interesting feature, most notably network rendering. Which is a
> VERY big miss in pov. What I also like about zrcube is the license, it has been
> licensed under GPL which means everyone can do with the code whatever they want,
> as long as they provide the sources as well.
On both things there were lengthy discussions in the past.
Concerning network rendering: The main concern is portability again, it
will be quite impossible to set up an universal system that works with all
platforms povray currently runs on.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Concerning network rendering: The main concern is portability again, it
> will be quite impossible to set up an universal system that works with all
> platforms povray currently runs on.
Seeing as the frontends are optional, couldn't this also be added as an
optional, platform-specific thing later on?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > , but I see no reason why the rendering
> > core could be ported to other platforms quite easily, pov does the same in the
> > end.
>
> Not really correct, the Povray rendering engine is originally designed as
> being portable, the platform specific frontends are purely optional.
I see no reason why the same could apply to zrcube, it might mean that you have to
change the current code base.
> > [...]
> > , but zrcube
> > adds a few very interesting feature, most notably network rendering. Which is a
> > VERY big miss in pov. What I also like about zrcube is the license, it has been
> > licensed under GPL which means everyone can do with the code whatever they want,
> > as long as they provide the sources as well.
>
> On both things there were lengthy discussions in the past.
I know, I just like both :). But IMHO network rendering is a feature that is missing
from pov, and yes I know it is next to impossible to implent it with the current code
and nobody, including me, was able to get pvmpov running on win32.
> Concerning network rendering: The main concern is portability again, it
> will be quite impossible to set up an universal system that works with all
> platforms povray currently runs on.
I don't know about the amiga and I'm not really sure about the Mac but it should be
possible to write an abstraction layer that hides all the platform dependent stuff
from the core. Pov does that at the moment as well, but only for a few minor things,
just look in the platform specific file in source/your_platform.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
