 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas wrote:
>
> 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.
Why not? I never tried it until now, but i don't know about any problems?
>
> 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.
Surely, but what do you gain with that, there still needs to be a lot of
code written for every platform and it can still be extremely difficult to
get all the different versions work together.
> 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.
>
There is nothing but the user interface that is specific to the platform,
of course some minimal interface is always needed.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <tra### [at] inapginrafr> wrote:
: 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.
I don't have any problem with the program itself. The idea of the program
is quite good, actually.
What irritated me was that "povray is old and our program is more modern
and better" tone of voice.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas <tho### [at] gmxnet> wrote:
: Maybe a little competition for POV is good thing.
They have a long way to go if they want to even start competing with
POV-Ray 3.5 :)
--
#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 wrote:
> Thomas wrote:
> >
> > 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.
>
> Why not? I never tried it until now, but i don't know about any problems?
I have tried it (for a very long time) but I never managed to get it through the
compiler
completly (or linker, I can't remember)
> Surely, but what do you gain with that, there still needs to be a lot of
> code written for every platform and it can still be extremely difficult to
> get all the different versions work together.
I gain network support, which means faster renders. I know that there are some tools
around
that help you to distribute renders over more machine, but they are not cross
platform.
Sure a lot of code needs to be written, but writing a ray tracer involves writing lots
of
code.
As far as I know the network interfaces on Unix and win32 are quite similar, just a
few
calls different. I don't know about MacOS, but MacOS X should be similar again, since
it is
a BSD unix. And endianess problems are well understood and all operating systems with
a
tcp/ip stack provide functions for it (or at least should).
> > 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.
>
> There is nothing but the user interface that is specific to the platform,
> of course some minimal interface is always needed.
To me the user interface is optional as well, I can use any editor I like for writing
pov
code. It is the rendering core that matters and if written in c or c++ is should be
pretty
portable I guess.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Thomas <tho### [at] gmxnet> wrote:
> : Maybe a little competition for POV is good thing.
>
> They have a long way to go if they want to even start competing with
> POV-Ray 3.5 :)
I agree with you, but by that time maybe pov 4.0 has a long way to go..... who
knows.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas wrote:
>
> I have tried it (for a very long time) but I never managed to get it through the
compiler
> completly (or linker, I can't remember)
What compiler?
What code did it stumble over?
>
> I gain network support, which means faster renders. I know that there are some tools
around
> that help you to distribute renders over more machine, but they are not cross
platform.
> Sure a lot of code needs to be written, but writing a ray tracer involves writing
lots of
> code.
>
> As far as I know the network interfaces on Unix and win32 are quite similar, just a
few
> calls different. I don't know about MacOS, but MacOS X should be similar again,
since it is
> a BSD unix. And endianess problems are well understood and all operating systems
with a
> tcp/ip stack provide functions for it (or at least should).
>
I think these things were discussed quite enough, i'm sure you are welcome
to implement an universal platform independent parallel rendering module
for Povray, but the problems that will occur are much more than just byte
order and network protocols. PVMPov has quite a lot of problems to deal
with and it uses an already made and well tested system.
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 wrote:
> > I gain network support, which means faster renders. I know that there are some
tools around
> > that help you to distribute renders over more machine, but they are not cross
platform.
> > Sure a lot of code needs to be written, but writing a ray tracer involves writing
lots of
> > code.
> >
> > As far as I know the network interfaces on Unix and win32 are quite similar, just
a few
> > calls different. I don't know about MacOS, but MacOS X should be similar again,
since it is
> > a BSD unix. And endianess problems are well understood and all operating systems
with a
> > tcp/ip stack provide functions for it (or at least should).
As Christoph said, this is more complex. If you start this way, you will
end implementing conversion routines (64/80/128 bit float, 32 bit chars,
etc...), servers ensuring that messages get through the network so that
client apps do not have to care when a computer is shut down, control
and notification protocols, data packing... And you'll finish with a
library close to PVM (or MPI, this is not about religion ;-), but with
less features and much less tests. These libraries have been around for
such a long time...
Now if PVMPov hasn't been ported to dos 2000 and its familly, well, I
dunno. According to comp.parallel.pvm ng I read sometimes, people
usually have trouble running pvm on windos, but usually they end up with
something working. AFAIK nobody could ever get it to simply _link_. As I
always said, I would be happy to help people port pvmpov (and of course
prefferably pvmegapov) to other platforms. But before starting to debug
something, you need at least to get an executable.
> I think these things were discussed quite enough, i'm sure you are welcome
> to implement an universal platform independent parallel rendering module
> for Povray, but the problems that will occur are much more than just byte
> order and network protocols. PVMPov has quite a lot of problems to deal
> with and it uses an already made and well tested system.
Well, yes and no. Yes, PVM and POVRay both have a good user base and are
well known. But pvmpov remains a terrible hack because it had to place
hooks and asynchronism in a very sequential code. Their approach towards
this is a good one. But writing it will allow to easily implement
anything new in the future is definitely crap.
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 31 May 2001 20:08:50 +0000, Francois Dispot
<woz### [at] club-internetfr> wrote:
>BTW I won't comment their assertion that parallel radiosity is not
>possible with POV-Ray ;-)
LOL, you had to step in, didn't you? ;-)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3B16A91A.54D12A9A@gmx.de>,
Christoph Hormann <chr### [at] gmxde> wrote:
> 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.
I don't think it's that bad...no more so than any other curved surface.
Recursively subdividing the sides of a tetrahedron or octahedron seems
to perform pretty well. You don't have as much control over the
resolution, but the triangles are fairly even in size. Add in smoothing
of normals, and there isn't much of a problem.
> Newly generating the mesh with every change of viewpoint, ...
Why? The viewpoint doesn't affect the geometry of the scene...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> I don't think it's that bad...no more so than any other curved surface.
> Recursively subdividing the sides of a tetrahedron or octahedron seems
> to perform pretty well. You don't have as much control over the
> resolution, but the triangles are fairly even in size. Add in smoothing
> of normals, and there isn't much of a problem.
I think tesselating a smoothly curved surface is always bad to some
extend.
>
> > Newly generating the mesh with every change of viewpoint, ...
>
> Why? The viewpoint doesn't affect the geometry of the scene...
>
Because the needed accuracy of tesselation depends on the viewpoint, if
this is not taken into account, visible corners will occur.
You can of course create a quite 'foolproof' tesselation of a sphere with
- let's say - 1000 triangles, but in certain situations also this won't be
enough and in other situations it would be far less efficient to use a
1000 triangle mesh instead of a simple 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
|
|
| |
| |
|
|
|
|
| |
|
|
