 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1650cf@news.povray.org>, "Warp" <war### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
