Warp <war### [at] tagpovrayorg> wrote...
>   It may be "vastly superior" or it may not. The visual appealing of a
couple
> of example images doesn't tell the whole truth about the quality of the
> program itself or even the features those example images show.

Interestingly enough, when I first found out about Lightflow, I downloaded
it and reproduced a number of the example scenes in POV-Ray with little
problem.  The trick was to find how the various Lightflow parameters
corresponded to POV parameters.  I only converted a few of the example
scenes, though, because it was taking a fair amount of time.

>   And in my opinion, trying to mix up two different programs can only make
> a maintenance nightmare (besides other problems).

True, but (as I said), some of the techniques from Lightflow (such as
tesselation and displacement mapping) would be welcome additions to POV-Ray.
I just doubt that the author would want to _give_ us his code.

-Nathan

Post a reply to this message

Jacopo Pantaleoni, the programmer of lightflow, wrote me the fellowing
email. I decided to post it.
"..and, if you want, post this message on the group.. (Jacopo Pantaleoni)"

-------------------------------
Hi Jurek,

I have read your discussion.

I must say that I don't agree with all the messages
that have been exposed against my license.

The concept upon which it is based is rather simple.
If you want to use it for purely artistic purposes,
you don't have to pay for it. But if you want to
use it for commercial reasons, well, then you have
to wait for the commercial version, that will have
a cost, exactly as ALL the other commercial softwares.

In my humble opinion, this is the right distribution
politics, that should be adopted by every non Open Source
software.

It grants hobbists the right to use the software without
have to pay huge amounts of money, but, at the same time,
it grants me the right to sell my work.
Why should anyone be able to sell his art (in the form
of pictures), and then want me to give my own for free ?
I can't really understand it...

Lightflow is the fruit of hard work, and I want its
development to become my job. Is it wrong ?

Please let me know what do you think about it
(and, if you want, post this message on the group).

As regards cooperation with POV-Ray Team, someone
said that I have been in contact with them, but
I don't remember it.
If my memory is not burn out (well, this could also
be possible :) I have never had the pleasure to meet
anyone of them...

Even if I think that a cooperation would not be possible
now, because I am developing a commercial software,
this does not mean that we would not be able to speak
freely.

After all, I have been a POV-Ray user too, and I have
always thought that the POV Team has made a marvellous
piece of software... I have not made Lightflow because
I feel superior: I have made it because I wanted to
gain insight in photorealistic rendering and... because
I was very curious to see some features that POV did not
possess, such as programmable shading, trimmed NURBS,
displacement mapping and hypertextures...

Apart from this, my admiration to the POV-Ray Team!
They have started much time before me, and they have
been real pioneers.
Perhaps, without them I would have never started
anything, because I would have been a classic GUI user,
and I would have never coded my very first 3d software:
a landscape generator that exported to POV... ;)

Best Regards,
Jacopo
-------------------------

Post a reply to this message

On Fri, 07 Jul 2000 08:18:11 +0200, jurek <jur### [at] yahoocom> wrote:

>As regards cooperation with POV-Ray Team, someone
>said that I have been in contact with them, but
>I don't remember it.

To clear things up, I think it was Ken who said that the TAG have
contacted the Lightflow developers. I don't recall anything of that
regard nor do my records show it. Ken might have been thinking about
the Moonlight team but it's up to him to clear it up.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote:
: Since bicubic (and bezier) patches are already tesselated before
: rendering, wouldn't be _relatively_ easy (for programmers, not
: for me !) to apply displacement mapping to them ?

  Yes. Moving vertices around is not problem at all. Someone has only to
code it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hookflash <hoo### [at] nospamhotmailcom> wrote:
: Again, this was poor wording on my part.  I'm certain you know more
: about radiosity than I do, and I'm not being sarcastic.  However, is the
: PovRay radiosity view-independant?  Is it fast?  And, I personally think
: that tesselation might be the answer (it could at least be an option for
: the user, but I suppose 2 separate radiosity algorithms would be messy).

  Chris answered most of your questions, but here I would like to say more.

  The algorithm called "radiosity" is certainly view-independent, ie. you
can move the camera freely in an animation without having to recalculate
the radiosity data. But that's all. You can't move anything else, you can
only move the camera. If you move anything else (objects, lights...) or
change the property of any surface or light (surface color, light intensity
or color), you have to recalculate the radiosity data. So you get the
advantage only if your scene is completely static.

  There's one advantage of the stochastic method over the radiosity method.
In the radiosity method you have to calculate the brightness of _every_
surface, even if that surface is not seen (for example because there's an
object in front of it). Or if a surface is only partially seen, you still
have to calculate the illumination of the whole surface (unless there's
some clipping algorithm smart enough to clip all the invisible parts out,
which I have never heard of). This is because the illumination is calculated
before rendering, so you can't know which surface is visible and which isn't.
  In the stochastic method, however, the illumination is calculated only
in the surfaces that are seen or contribute to the illumination of visible
surfaces. Moreover, it's calculated only in the visible part of the surface
(so if you have a very big surface but only a bit of its corner is seen,
the illumination is calculated only there). This is because the illumination
is calculated while rendering, so parts of the scene which are invisible and
do not contribute to the illumination are automatically ignored.
  This, however, doesn't make the stochastic method faster, but the reason
is simply because raytracing is slow and we can do little about it. It is,
however, smarter and more efficient because it doesn't calculate needless
data. This helps it being faster than the "dumb" way where the illumination
of every surface is calculated (although you still have to shoot rays, which
is a quite slow process).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39665ac3@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Yes. Moving vertices around is not problem at all. Someone has only to
> code it.

I have attempted to add displacement mapping to meshes, but I only got 
"scrambled triangles". I think the problem is in my understanding of the 
mesh code...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: I have attempted to add displacement mapping to meshes, but I only got 
: "scrambled triangles". I think the problem is in my understanding of the 
: mesh code...

  Of course the vertices need to be moved in the direction of their normal
vectors. For non-smooth triangles those normal vectors will need to be
calculated. This causes some problems (mainly: which algorithm to use?
How about allowing the user specify some related parameters? How about
adding a smooth-the-mesh feature? And so on...)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <396669c1@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Of course the vertices need to be moved in the direction of their 
> normal vectors. For non-smooth triangles those normal vectors will 
> need to be calculated. This causes some problems (mainly: which 
> algorithm to use? How about allowing the user specify some related 
> parameters? How about adding a smooth-the-mesh feature? And so on...)

Wrong kind of displacement...I was simply trying to move the triangle 
vertices in a specific manner. The problem stems from the fact that I 
don't know what I am doing. :-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

jurek <jur### [at] yahoocom> wrote...
>
>Jacopo Pantaleoni, the programmer of lightflow, wrote me the fellowing
>email. I decided to post it.
    [clip]
> Lightflow is the fruit of hard work, and I want its
> development to become my job. Is it wrong ?
    [clip]
> Even if I think that a cooperation would not be possible
> now, because I am developing a commercial software,
> this does not mean that we would not be able to speak
> freely.

Just as I thought, Lightflow was intended to be for-profit, so this whole
discussion is somewhat of a moot point.  I agree with Jacopo that he has
every right to sell his software, and we should not think that he has any
obligation to give any of his work away for free.  (Instead, we should be
glad that he allows hobbyists to use it for free.)  Just please keep this in
mind when you compare the speed of development of Lightflow to the speed of
development of POV-Ray.

-Nathan

Post a reply to this message

Chris Huff wrote:
> 
> In article <39665ac3@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
> 
> >   Yes. Moving vertices around is not problem at all. Someone has only to
> > code it.
> 
> I have attempted to add displacement mapping to meshes, but I only got
> "scrambled triangles". I think the problem is in my understanding of the
> mesh code...
> 

I add my opinion to this matter, of which I know nothing:-)
For obtaining good displacement result, you have to subdivide your mesh
(patch, whatever) into micropolygons (to such size, that they cover one
pixel) and then apply displacement. This is how it is done in RenderMan.
Only problem here is the fact that in this case the size of geometry
will increase tenfolds. Of course, there are papers available for
caching this geometry (tesselating part of surface only when ray hits
it), so it could be managed even in case, when whole tesselated geometry
does not fit into memory. (But in this case it would be better to change
rendering order: now it is performed line-by-line, with caching it would
be better to render bucket-by-bucket (where bucket is small picture
area, e.g. with size 16x16) in order to take advantage of spatial
coherence. Or could this be done already by specifying some parameter?).
I don't know, to what size patch is tesselated in POV-Ray, if into
microtriangles (with covered size one pixel), then it should be fairly
easy. But I guess, that it is tesselated until it is flat enough,
resulting in much bigger triangles.

Post a reply to this message