I'm know about POV since its creation, POV 0.5b,
and even DKB trace. The first ray tracing program I
ever used was DBW render. but since PovRay 3.1 was
out I stopped looking into it, mainly because I become
more interested in realtime rendering (OpenGl and clever
use of it to simulate reflection, and even radiosity).

   My question goes to the POV-Team in general, I would
like to know what kind of features have a chance to appear
in the next Major version of POV (4.0??). I know a 3.5
version is planned that will compile all unofficial
interesting patches (like the one with photon maps ).

   Precise question follows:

        - Will it exist an API allowing to use POVRay
          in a programmatically mode, for instance, POV
          could exist as a python module (like lightflow).
          It could be proprietary but it will be good to
          overcome some parts of the parser when used in
          conjunction with diverses pov front-end object
          generators or modelers.

        - Can we expect an preview mode using OpenGL (I'm
          aware that the tessalation of all objects existing
          in pov will be difficult, and infinity ojects also...)

        - Will the photon map be improved to perform optimised
          global illumination and shadows optimisation ?

        - Is there an official binary format of scene file
          planned ?

        - Extended particle system for simulating fur or grass?

    I was looking in Softimage Twister specifications and several
reviews from it, I finded this very innovative, I was so entousiastic
about it, that I dreamed to see a free rendering package going in the
same direction...

    I hope that a free package could be as ambitious as twister
(layer rendering, interactive renderer with object hierachy, etc).

    Nevertheless, and even if POV is not going that way, I would
like all the contributing people for such a fantastic initiative.



PS: My english is weak, sorry...

Post a reply to this message

All that I know is that POV-Ray 4.0 will, more than anything else, be
rewritten in C++, to clean house and organize things better and allow for
easier expansion. That's all I've been informed of. Do any of the TAGies
have a clue?

Post a reply to this message

TonyB wrote:
> 
> All that I know is that POV-Ray 4.0 will, more than anything else, be
> rewritten in C++, to clean house and organize things better and allow for
> easier expansion. That's all I've been informed of. Do any of the TAGies
> have a clue?

About the only thing anyone knows about the release of POV-Ray v4.0 is
that it is supposed to be the C++ rewrite. We are still trying to get
the POV-Team to tell us what will be included in the v3.5 release :)

TAGies ?

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Claude Mench wrote:

> 
>    My question goes to the POV-Team in general, I would
> like to know what kind of features have a chance to appear
> in the next Major version of POV (4.0??). I know a 3.5
> version is planned that will compile all unofficial
> interesting patches (like the one with photon maps ).

 I am not speaking for the POV-Team, and most of your questions fall
into the catagory of feature requests, but I will try to answer some
of your questions for you anyway...

 
>    Precise question follows:
> 
>         - Can we expect an preview mode using OpenGL (I'm
>           aware that the tessalation of all objects existing
>           in pov will be difficult, and infinity ojects also...)

This is not likely. POV-Ray uses it's own algorithms to perform raytracing.
Even with the promises of support for raytracing functions, and hardware
support for future versions of the OpenGL standard, I doubt the POV-Team
will want to invest in the time and program overhead to offer support for
these features. These are good features for a GUI modelling environment
but they are not really all that good for a dedicated raytracing engine.
 
>         - Will the photon map be improved to perform optimised
>           global illumination and shadows optimisation ?

As far as I know the author of these functions in POV-Ray is working
on these issues even now. How soon he will optimize them to his own
satisfaction is anyones guess.
 
>         - Is there an official binary format of scene file
>           planned ?

  Last I heard (Chris Young - Plans for POV-Ray 3.5 and beyond) the POV-Team
has no plans for the support of a binary scene format. It has been discussed
in detail but the final decision was to not add support for this in any near
future release.
 
>         - Extended particle system for simulating fur or grass?

Several people have posted scenes in the binaries.images group on this
server using media for both hair and fur. It takes some dedcated work
on the users part to make it work but it's already possible.


-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Mon, 6 Dec 1999 15:42:52 +0100, "Claude Mench"
<c.m### [at] adilinstrumentscom> wrote:

>Can we expect an preview mode using OpenGL (I'm
>aware that the tessalation of all objects existing
>in pov will be difficult, and infinity ojects also...)

  Is OpenGL a working standard among all of the platforms supported by
POV-Ray (Mac, Windows, Unix versions, MS-DOS)?

  For quick previews I think the existing quality (+q) settings suffice
for most scenes.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

In article <6hoo4s481b4ia7r882l9qsfsb81ss7auhk@4ax.com>, Alan Kong 
<ako### [at] povrayNO-SPAMorg> wrote:

>   Is OpenGL a working standard among all of the platforms supported by
> POV-Ray (Mac, Windows, Unix versions, MS-DOS)?

It is available on the Mac, although I think it requires an accelerator 
card(there isn't even a way to emulate a card, as far as I know).
I would hate to have POV require a 3D accelerator card, and get no 
benefit from having one other than a preview mode.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Claude Mench <c.m### [at] adilinstrumentscom> wrote:
: more interested in realtime rendering (OpenGl and clever
: use of it to simulate reflection, and even radiosity).

  If you are talking about environment mapping to simulate reflection and
light maps to achieve radiosity, then there's nothing strange with them
(of course it's not trivial to make them efficient, but the idea behind them
is quite simple). Most of the current 3D-games use both techniques to
achieve a kind of "fake" reflection (with env. mapping) and radiosity
(with light maps).
  Of course there are limitations: Environment mapping is not an accurate
reflection and radiosity using light maps works only in static scenes (you
can't move anything, no objects, no light sources, nothing).

:         - Can we expect an preview mode using OpenGL (I'm
:           aware that the tessalation of all objects existing
:           in pov will be difficult, and infinity ojects also...)

  You answered your own question. Converting all the primitives to
triangles is not a trivial task and probably not worth the efforts.
  And even when OpenGL is a standard, it's not part of the ANSI C++ standard.
Adding support for it would make povray platform-dependant.

:         - Will the photon map be improved to perform optimised
:           global illumination and shadows optimisation ?

  Nathan is the best one to answer this question.
  I have understood that using photon mapping for global illumination is
pretty inefficient and that the current radiosity method (with the fixes made
in uvpov) is a lot more efficient.
  The good thing about the current stochastic method is that the radiosity
samples are calculated only where they are needed. Almost every sample taken
will affect the illumination of the image even a little. With photon mapping
lots of photons will be shot in vain; they will just end somewhere in the scene
where they do not affect anything.

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

>  And even when OpenGL is a standard, it's not part of the ANSI C++
standard.
>Adding support for it would make povray platform-dependant.


I think Mesa brings OpenGL to the few platform that do not already have it.

All my questions are related to what I saw from Twister. I think a
progressive
refinement display from openGL with texturing to radiosity after a while of
computation, would clearly be better than multiples tries at quality Q1
trough QR.
But all this is relevant only in an interactive environnement. I understand
clearly that my wishes have no utility if the renderer runs on a render
farm.

>  I have understood that using photon mapping for global illumination is
>pretty inefficient and that the current radiosity method (with the fixes
made
>in uvpov) is a lot more efficient.

    I understand cleary the opposite after reading much publications about
radiosity. Try http://graphics.lcs.mit.edu/~henrik/papers/ to read the
original
photon maps papers. Every monte-carlo radiosity, hierachical, or
hierarchical
with substructuring seems beatten by the photon map technique.

> With photon mapping lots of photons will be shot in vain; they will just
> end somewhere in the scene where they do not affect anything.

I'm not sure to understand you, in photon mapping photons are not
shoot anywhere, they are shot only in a direction of an object, never
in a direction where is nothing.


Thank's for your answer.

Post a reply to this message

Claude Mench <c.m### [at] adilinstrumentscom> wrote:
:> With photon mapping lots of photons will be shot in vain; they will just
:> end somewhere in the scene where they do not affect anything.

: I'm not sure to understand you, in photon mapping photons are not
: shoot anywhere, they are shot only in a direction of an object, never
: in a direction where is nothing.

  Suppose that the object is hidden behind other objects and in such position
that it doesn't affect the illumination of other objects.
  Photon mapping would calculate the illumination of _every_ surface, even
if that surface is not visible nor it participates in the illumination of
the scene. If a surface is partially hidden, photon mapping will calculate
the illumination of the whole surface although it wouldn't be necessary.
  Stochastic raytracing only calculates the illumination of visible
surfaces and those surfaces that participate in the illumination. Even with
partially visible surfaces it only calculates radiosity for the visible parts
and leaves the hidden parts alone (unless this hidden part reflects light
to another visible surface).

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

Nieminen Juha wrote:
> 
> Claude Mench <c.m### [at] adilinstrumentscom> wrote:
>...
> :         - Can we expect an preview mode using OpenGL (I'm
> :           aware that the tessalation of all objects existing
> :           in pov will be difficult, and infinity ojects also...)
> 
>   You answered your own question. Converting all the primitives to
> triangles is not a trivial task and probably not worth the efforts.
>   And even when OpenGL is a standard, it's not part of the ANSI C++ standard.
> Adding support for it would make povray platform-dependant.

What a bizzare answer.  The OpenGL API doesn't have anything to do with
the ANSI C++ standard.  If you want to call OpenGL functions from your
C++ code, you will find it quite easy to do.  Also, as far as being
cross platform, if you don't have drivers provided with your system you
can always use Mesa (yes, even on Macs, DOS, ...).

As far as tesselating all prims, it may be tedious but certainly not
impossible.  Other renderers manage to do it.  Given the number of times
this question comes up, it is certainly worth consideration. 
Personally, I think the preview thing belongs in a modeller rather than
a back-end renderer like POV-Ray, but it's not out of the question.

Xander

Post a reply to this message

I'm happy to see finally someone from the pov-team here.
It seems that asking what features could be in POV4.0 or even
only the direction in wich POV goes toward is not a question
that can get an answer...

>As far as tesselating all prims, it may be tedious but certainly not
>impossible.  Other renderers manage to do it.  Given the number of
>times this question comes up, it is certainly worth consideration.

    You where the maker of polyray, which had a Z-Buffer renderer,
so I think you have a good knowledge of this item. In polyray
this code exist for quite a number of primitives, because if I
remember well polyray had many primitives.

>Personally, I think the preview thing belongs in a modeller rather
>than a back-end renderer like POV-Ray, but it's not out of the question.

    I do not see Povray as only a back-end renderer, as I think
in the PC or Mac version much people use the editor and periodicly
during the scene editing do test renders.

Post a reply to this message

>> And even when OpenGL is a standard, it's not part of the 
>> ANSI C++ standard.  Adding support for it would make 
>> povray platform-dependant.
> 
> What a bizzare answer.  The OpenGL API doesn't have anything 
> to do with the ANSI C++ standard.  

	Go easy on Ken.  He might not be familiar with OpenGL,
	he might not even be a programmer, but he is quite a
	enthusiastic and productive POV-ray kind of a guy,
	and very helpful to have around.

	OpenGL is a well-established standard, and given that
	Microsoft have spent 4 years trying to kill it, it
	is here to stay.  It is safe to regard OpenGL as about
	as portable a realtime 3D rendering API as you're 
	going to get.  Microsoft failed in their attempt to
	"invent 3D graphics" in the way they are seen to have
	invented graphical user interfaces.  OpenGL means
	that you can write modelling software that will work
	across different platforms.  Microsoft doesn't like 
	it of course - look at the way they perverted Java.

	I think that the "front-end" GUI could use a rethink
	in terms of making better use of the quality settings
	and user interface to refine the scene.  I find that
	the current setup is more convenient than the command
	line, but well short of what's possible.  For example,
	I'd like to have common options available as drop-down
	lists on the toolbar, so I can switch resolution and
	quality without having to nagivate the whole list of
	canned combinations.  Also, I'd like to select an area
	of the viewport to be recalculated at better quality and/or
	resolution.  I particularly dislike having to edit the INI
	file, to customise my setting for possibly only one
	render.

	And, (while I'm being wishful) I'd like to have a history
	so that I can check for side effects, or simply reflect
	on whether the image is progressing the way I'd imagined
	it should.

	These ideas do not involve huge amounts of development,
	maintenance, or bug-fixing.  They are simply making
	better use of the current infrastructure.

	It's not the tesselation of primitive that is the
	challenge for OpenGL rendering, it's the CSG and
	flexibility of POV texturing that would be a big
	challenge to achieve.  I've worked for 4 years 
	commercially on a solid modelling engine, and there
	is no way that I'd tackle one as a hobby.  :-)
	Raytracing is not polygon-oriented, and trying to
	have the best of both severely complicates things.
	If someone decides that "super-quartic-hemispherical-
	hybrid-nurbs-bezier-patches" make a very useful modelling
	primitive, they would also have to ponder the implications
	of having to tesselate it, and worry about the volumetric
	represetation.
	
> Personally, I think the preview thing belongs in a modeller rather than
> a back-end renderer like POV-Ray, but it's not out of the question.

	Xander, keep in mind that the POV-ray "mentality"
	is intentionally different to modellers or 
	beasts like 3D Studio.  I have the distinct
	impression that the POV team intentionally target
	a very specific scope of functionality in order
	to keep the software reasonably small and keeping
	the team small, friendly and familiar.  Compare
	POV-ray development to say, KDE or Gnome.  KDE is
	an exciting development effort, but very chaotic.
	I think that in the long term, POV-ray will be
	overtaken by a larger-scale, more open development
	model - but I doubt that the POV team will be too
	upset - they are not trying to kill microsoft, or
	become the next media darling, or foster a huge
	following of novice users.  
	
	But then, I really don't know much - treat this
	as pure speculation.  

	And, as a final thought - it is much easier to 
	toss ideas around as being desirable, feasible,
	or the way to go, but something else entirely
	to do the work yourself, or convince someone 
	on the POV team of your dream.  Everyone wants
	to dream their own dream, and that's especially
	how it should be if people arn't getting paid.

	I mean this from both sides of the coin - 
	people like you and me that say "hey, I know something
	about software/graphics/whatever, and POV really
	lacks xyz...." and others that react against
	"changing the paradigm for no good reason".
	POV is free in the "free beer" sense, but not
	in the "hey guys, do this" sense.  It's their
	baby, and they prefer to pleasently surprise us
	from time to time. 

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to read your email."

Post a reply to this message

On Wed, 08 Dec 1999 01:38:01 +0900, Nigel Stewart wrote:
>	Go easy on Ken.  He might not be familiar with OpenGL,
>	he might not even be a programmer, but he is quite a
>	enthusiastic and productive POV-ray kind of a guy,
>	and very helpful to have around.

Xander's reply was to Warp, not Ken.  To reply to Warp in my own
way, I'd say that my impression is that while the POV-Team strives
for portability, there are some features that aren't and can't be
portable.  If ANSI-standard C was the only rule by which things got
added, there would be no preview display, or Mac GUI, or Windows
GUI, or DOS help screens, or x-povray, or...  you get the idea.  
OpenGL seems fairly widespread, so I would say that if an OGL 
preview deserves to be shot down it deserves to be shot down on its 
own merits as a feature rather than because OGL isn't available on 
the DOS or Amiga platforms.  That's just my opinion, though; I may
be in the minority.

>	And, as a final thought - it is much easier to 
>	toss ideas around as being desirable, feasible,
>	or the way to go, but something else entirely
>	to do the work yourself, or convince someone 
>	on the POV team of your dream.  

Um... Xander is on the POV-Team, and is also the author of Polyray,
which does successfully tesselate lots of different objects.  If he
decided to do so, he could probably do most of the necessary code 
for tesselation in his sleep.  

FWIW, I think tesselation of primitives would be a fairly useful 
feature, too, and not just for OGL preview.  I still think the OGL 
preview wouldn't be much faster than current preview methods, given
the parse time, but I see lots of other uses for being able to make
triangles out of primitives.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker wrote:

> On Wed, 08 Dec 1999 01:38:01 +0900, Nigel Stewart wrote:
> >       Go easy on Ken.  He might not be familiar with OpenGL,
> >       he might not even be a programmer, but he is quite a
> >       enthusiastic and productive POV-ray kind of a guy,
> >       and very helpful to have around.

Thanks for the support anyway :)

> ... but I see lots of other uses for being able to make triangles
> out of primitives.

Displacement mapping comes to mind...

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <chrishuff_99-9C557C.20515406121999@news.povray.org> , Chris Huff
<chr### [at] yahoocom>  wrote:

> It is available on the Mac, although I think it requires an accelerator
> card(there isn't even a way to emulate a card, as far as I know).
> I would hate to have POV require a 3D accelerator card, and get no
> benefit from having one other than a preview mode.

No, it should run without an accelerator :-)


     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 Tue, 07 Dec 1999 09:21:41 -0800, Ken <tyl### [at] pacbellnet> wrote:

>> ... but I see lots of other uses for being able to make triangles
>> out of primitives.
>
>Displacement mapping comes to mind...

...and virtual light sources, global ilumination maps, morphing, UV
mapping...


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> On Tue, 07 Dec 1999 09:21:41 -0800, Ken <tyl### [at] pacbellnet> wrote:
> 
> >> ... but I see lots of other uses for being able to make triangles
> >> out of primitives.
> >
> >Displacement mapping comes to mind...
> 
> ...and virtual light sources, global ilumination maps, morphing, UV
> mapping...

...and longer parsing times and more memory consumption. Don't forget those.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Tue, 07 Dec 1999 14:43:13 -0800, Ken <tyl### [at] pacbellnet> wrote:

>
>
>Peter Popov wrote:
>> 
>> On Tue, 07 Dec 1999 09:21:41 -0800, Ken <tyl### [at] pacbellnet> wrote:
>> 
>> >> ... but I see lots of other uses for being able to make triangles
>> >> out of primitives.
>> >
>> >Displacement mapping comes to mind...
>> 
>> ...and virtual light sources, global ilumination maps, morphing, UV
>> mapping...
>
>...and longer parsing times and more memory consumption. Don't forget those.

There's no such thing as a free lunch :(


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

>...and virtual light sources, global ilumination maps

??? Explain how triangles make this possible.

Post a reply to this message

First, I want to state that I have not yet used twister, so I don't know
exactly which features your are referring to.

Claude Mench <c.m### [at] adilinstrumentscom> wrote...
>
>         - Will it exist an API allowing to use POVRay
>           in a programmatically mode, for instance, POV
>           could exist as a python module (like lightflow).
>           It could be proprietary but it will be good to
>           overcome some parts of the parser when used in
>           conjunction with diverses pov front-end object
>           generators or modelers.


Not in version 3.5.  Whether this is done in future versions is unknown.
However, the wording of POV-Ray's license currently does not allow this (to
avoid the exploitation of POV-Ray).

>         - Can we expect an preview mode using OpenGL (I'm
>           aware that the tessalation of all objects existing
>           in pov will be difficult, and infinity ojects also...)

If tesselation of all primatives is done, then this would definately be a
possibility.  However, POV-Ray is primarily a ray-tracing engine, so this
would likely not be a priority.  As was mentioned, using a preview mode
(with quickcolor, no refraction or reflection, minimal lighting, etc.) can
render many scenes quite quickly.

>         - Will the photon map be improved to perform optimised
>           global illumination and shadows optimisation ?

I do plan to extend photon mapping to work with global illumination.  There
are a variety of misunderstandings with how photons work with the current
global illumination model (instead of replacing it).  Anyway, yes, I am
working on that.

I will likely no use photons for shadow optimizaiton.  More recent papers by
Jensen downplay the actual worth of this technique.  To quote from Jensen's
SigGraph '99 course notes: "Using a derivative of the photon map method we
can compute shadows more effciently using shadow photons [Jensen95c]. We do,
however, not normally use this approach since it can lead to artifacts in
the shadows (that are very noticeable to the eye)."

>         - Is there an official binary format of scene file
>           planned ?

Not for version 3.5.  The past policy has been not to have a binary format
for platform-specific reasons.  However, it is my opinion that a
platform-independent binary would be possible and would make sense.

>         - Extended particle system for simulating fur or grass?

The POV scripting language can support much of this.  Some features are
being added (such as the trace() function) which help.  If this could be
done much more efficiently with a built-in object, then it is possible that
it might be added in the future.

>     I was looking in Softimage Twister specifications and several
> reviews from it, I finded this very innovative, I was so entousiastic
> about it, that I dreamed to see a free rendering package going in the
> same direction...
>
>     I hope that a free package could be as ambitious as twister
> (layer rendering, interactive renderer with object hierachy, etc).

Some of these features (such as layered rendering) probably wouldn't be
built directly into the rendering engine.  However, support for them could
be incorporated into the engine (such as z-buffer output) so that external
interactive programs could offer these features.

Remember when comparing POV to other products that POV is only the rendering
engine.  Twister, for example, is a combination of Softimage's Mental Ray
rendering engine with their modeling environment.  To compare apples to
apples, POV should be compared to Mental Ray (in which case, MR still has
featuers that have not yet been implemented in POV).

-Nathan

Post a reply to this message

>Remember when comparing POV to other products that POV is only the
rendering
>engine.  Twister, for example, is a combination of Softimage's Mental Ray
>rendering engine with their modeling environment.  To compare apples to
>apples, POV should be compared to Mental Ray (in which case, MR still has
>featuers that have not yet been implemented in POV).


    Twister is not the modelling part of sumatra if I understand weel
all my readings. twister is only the rendering user interface, this
interface is there to allows an interactive rendering. It is a modeller
in the sense that you can move, rotate, scale objects, but not really
model individual complex objects. When you place your objects rendering
the global scene is quite helpfull. It is really at this moment you need
rendering. I think that this is the natural way that a successfull
renderer should go nowadays.

    Thank's for your answer, I read your papers about the photon mapping
in UVPov and also Jensens original one. I have one question, You are use
your own sampling method for light ray with your spiral sampling and said
that Jensens methods gives noisy results. But the images i've seen from
Jensen are not noisy. Does your sampling method give an performance hurt
compared to Jensen's ?

    I'm really interested to learn or be aware of the techniques that
could make a production renderer more and more realistic. For now production
renderers where everytime scanline. Twister goes further and introduce
global illumination and generalized ray tracing in a production
renderer. It uses photon maps and a very good progressive raytracing
rendering. My interrest for photon map is that they seem to be the
solution for an acceptable global illumination technique in term of
performance hurt.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: If ANSI-standard C was the only rule by which things got
: added, there would be no preview display, or Mac GUI, or Windows
: GUI, or DOS help screens, or x-povray, or...  you get the idea.  

  I know, but I think that that extra stuff doesn't need very much
modifications to the povray core code.
  However, I think that an OpenGL preview mode would require a lot of changes
in the povray core.

: OpenGL seems fairly widespread, so I would say that if an OGL 
: preview deserves to be shot down it deserves to be shot down on its 
: own merits as a feature rather than because OGL isn't available on 
: the DOS or Amiga platforms.  That's just my opinion, though; I may
: be in the minority.

  OpenGL is not available in this SparcStation 5 either...

: FWIW, I think tesselation of primitives would be a fairly useful 
: feature, too, and not just for OGL preview.  I still think the OGL 
: preview wouldn't be much faster than current preview methods, given
: the parse time, but I see lots of other uses for being able to make
: triangles out of primitives.

  You are right of course. If someone can do it easyly, then that's great.
  The only problem I see is that you can't tesselate every primitive in
povray (mainly the infinite ones, like planes and polys).

  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
to objects?
  Changing the location of triangle vertices is not real non-uniform
transformation.

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

On Tue, 7 Dec 1999 19:10:16 -0500, "TonyB"
<ben### [at] panamaphoenixnet> wrote:

>>...and virtual light sources, global ilumination maps
>
>??? Explain how triangles make this possible.

For a virtual light source approach to rendering caustics, there are
three step:

1. Find the mirror image of each light source in the plane of each
triangle of the object(s) that will generate the caustics. This is
done only once, after parsing is done and before rendering.

2. For each point you want to calculate the caustics for, see how many
of those virtual light sources are visible through their respective
triengles, i.e. if the ray from the point in question to the virtual
source passes through the triangle

3. Sum up and do a weighted average of the results

One of the papers I read about radiosity and using a global
ilumination map described a similar approach. I don't recall specifics
but basically the approach was to build the illumination map of an
object using UV mapping and global ambient lighting was then done
similar to environment mapping.

Another very good use of fully tesselated objects is relatively easy
collision detection.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On 8 Dec 1999 04:02:34 -0500, Nieminen Juha
<war### [at] punarastascstutfi> wrote:

>  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
>to objects?
>  Changing the location of triangle vertices is not real non-uniform
>transformation.

According to Von Neumann's theorem, any renderer can :)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On 8 Dec 1999 04:02:34 -0500, Nieminen Juha wrote:
>  Btw: Are there _any_ renderer that can do _real_ non-uniform transformations
>to objects?
>  Changing the location of triangle vertices is not real non-uniform
>transformation.

There is a paper out there somewhere - can't remember whether I saw it on the 
web or in an old ACM publication - that talks about methods for tracing curved
rays.  It's still not perfect, because it essentially traces the curves as a
series of line segments, but at least it doesn't require tesselation.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: There is a paper out there somewhere - can't remember whether I saw it on the 
: web or in an old ACM publication - that talks about methods for tracing curved
: rays.  It's still not perfect, because it essentially traces the curves as a
: series of line segments, but at least it doesn't require tesselation.

  Perhaps this kind of non-uniform transformation could be possible with
povray?

  Btw, why is not possible to scale an object so that the scale changes
linearly along an axis? I don't remember the name if this transformation,
but it's the one that can convert a cylinder into a cone.
  I think that it's a linear transformation. I line transformed this way
is still a line after the transformation. Should be perfectly possible
in povray. If this is so, wouldn't it be a good idea to add this kind
of transformation?

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

On 8 Dec 1999 09:22:48 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: There is a paper out there somewhere - can't remember whether I saw it on the 
>: web or in an old ACM publication - that talks about methods for tracing curved
>: rays.  It's still not perfect, because it essentially traces the curves as a
>: series of line segments, but at least it doesn't require tesselation.
>
>  Perhaps this kind of non-uniform transformation could be possible with
>povray?
>
>  Btw, why is not possible to scale an object so that the scale changes
>linearly along an axis? I don't remember the name if this transformation,
>but it's the one that can convert a cylinder into a cone.
>  I think that it's a linear transformation. I line transformed this way
>is still a line after the transformation. Should be perfectly possible
>in povray. If this is so, wouldn't it be a good idea to add this kind
>of transformation?

It's a perspective transformation.  It's not linear, in that 
f(A)+f(B) != f(A+B).  I'm not sure it transforms lines to lines, 
either.  Consider the (2d) perspective transformation f(x,y) = xy.  
If you transform a line parallel to the X axis, such as y=2, then 
you get a line in return (y=2x).  If you transform a line parallel 
to the Y axis, you also get a line in return.  But what happens 
when you transform the line y=x?  By my calculations, you get y=x*x, 
which is not a line.

For another thought experiment, assume that you have a transformation 
that can turn a cylinder into a cone.  What would it do to the 
resulting cone?  If it leaves it a cone, then the transformation 
isn't invertible, because there's some cylinder that maps to the same 
cone.  If it makes it anything else, then what does it do to a line 
that lies in the surface of that cone?

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

We would need some sort of scale_map or something, wouldn't we?

scale {y scale_map {[0 <1,1>][.25 <1,.25>][1 <.25,1>]}}

Where x, y, or z would establish the linear part of the scaling, and the
scale map would modify the other two axices.

Post a reply to this message

Ron Parker wrote:
> It's a perspective transformation.  It's not linear, in that
> f(A)+f(B) != f(A+B).  I'm not sure it transforms lines to lines,
> either.

If it's perspective, it does! For example, can you remember of a scene with
a "normal" camera were an object's straight edge turned curved <he he> in
the image? (I know this is no proof, but I know perspective is line-> line).

> Consider the (2d) perspective transformation f(x,y) = xy.
> If you transform a line parallel to the X axis, such as y=2, then
> you get a line in return (y=2x).  If you transform a line parallel
> to the Y axis, you also get a line in return.  But what happens
> when you transform the line y=x?  By my calculations, you get y=x*x,
> which is not a line.

I'll dig in my school notes and find some math about perspective, such as
main properties of transformation, transform matrix (wich is 4x4 with
homogenous coordinates). I'll post that sometime next week...

> For another thought experiment, assume that you have a transformation
> that can turn a cylinder into a cone.  What would it do to the
> resulting cone?  If it leaves it a cone, then the transformation
> isn't invertible, because there's some cylinder that maps to the same
> cone.  If it makes it anything else, then what does it do to a line
> that lies in the surface of that cone?


I think it turns a cone into an _other_ cone. Line-> line.



Povingly


Philippe

Post a reply to this message

On Thu, 9 Dec 1999 11:07:49 +0100, Philippe Debar wrote:
>> For another thought experiment, assume that you have a transformation
>> that can turn a cylinder into a cone.  What would it do to the
>> resulting cone?  If it leaves it a cone, then the transformation
>> isn't invertible, because there's some cylinder that maps to the same
>> cone.  If it makes it anything else, then what does it do to a line
>> that lies in the surface of that cone?
>
>I think it turns a cone into an _other_ cone. Line-> line.

But you can find a cylinder that also maps to that other cone.  (proof: there
is a plane where the scale factor perpendicular to the axis is 1. The 
intersection of the cone with this plane is a circle.  Since the intersection 
of the cylinder with the plane is also a circle, and since the scale factor is 
1, the desired cylinder has the same radius.)  If a cone truly does map to a 
different cone, the transform isn't invertible and thus POV can't use it.  
But, as I'll show, it doesn't actually map a cone to another cone so this 
argument is from false assumptions.

As proof that it doesn't map a cone to a cone, try the following script.  
There are three commented lines in the code.  The first one is the equation 
for a cylinder, so that you can verify that the given transform maps a 
cylinder to a cone.  The line after it is the equation for a cone (the one 
it maps the cylinder to, in fact.) As written, the code generates a cone.

The second commented line is an identity transform.  If you uncomment it 
and comment the line after it, you may verify that the code does produce a 
cone.  As written, it transforms each point using a scale factor equal to 
the distance along the Y axis from the origin, except it doesn't change the 
Y coordinate.  You'll see that this transform maps a cone to the SOR of a 
parabola, so it doesn't map all lines to lines.

The third commented line is a different interpretation of the idea "scale 
by an amount equal to the distance along an axis from the origin."  You'll 
see that while it does map a cone to a cone (the same cone, in fact), it 
maps a cylinder to a paraboloid, so it doesn't map lines to lines either.

------------ cut here --------->8========
camera { location <0,1,-5> look_at y }
light_source {-5*z rgb 1}
#declare H = 0;
#while ( H < 2 )
  #declare T = 0;

  //#declare X = 1;   // a cylinder
  #declare X = H;   // a cone
  
  #while ( T < 360 ) 
    #declare Loc = vrotate( <X,H,0>, T*y );
    
    // #declare NewLoc = Loc; // identity transform
    #declare NewLoc = <Loc.x*H,Loc.y,Loc.z*H>; // NL trans 1
    //#declare NewLoc = <Loc.x*H,Loc.y*H,Loc.z*H>; // NL trans 2
    
    sphere { NewLoc, .05 pigment {color red 1}}
    #declare T=T+2;
  #end
  #declare H = H + .05;
#end                
------------ cut here --------->8========

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Claude Mench <c.m### [at] adilinstrumentscom> wrote ...
>     Thank's for your answer, I read your papers about the photon mapping
> in UVPov and also Jensens original one. I have one question, You are use
> your own sampling method for light ray with your spiral sampling and said
> that Jensens methods gives noisy results. But the images i've seen from
> Jensen are not noisy. Does your sampling method give an performance hurt
> compared to Jensen's ?

I have been able to get OK results with pure random shooting, but I always
had to shoot a very large number of photons.  Using my jittered spiral
technique, I am able to get very good results with few photons.  If
anything, it should offer better performance than a totally random method
(or even a weighted monte-carlo method).

I still don't know exactly how Jensen got the good results that he got with
his monte-carlo photon tracing.

-Nathan

Post a reply to this message

Sorry, I can't spent much time thinking about this here at work... :(
I'll "work" on this this week-end.
On first read, I didn't quite follow the math, but I think it will become
much clearer tomorrow (I have quite important work things on my mind right
now)

Please hold <Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...



Philippe

Post a reply to this message

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...
</Vivaldi's Dmin concerto>
Sorry, I had very little time this week-end (and I still had no time to try
other newsreaders either)
:-(

And I have no time now... :-( :-( :-(

<Vivaldi's Dmin concerto> Ta di da ta tii tadaa tee daa...

Philippe

Post a reply to this message

On Mon, 6 Dec 1999 15:42:52 +0100, "Claude Mench"
<c.m### [at] adilinstrumentscom> wrote:

>        - Is there an official binary format of scene file
>          planned ?
>

Well, a .zip compressed archive with filenames taken with a bit of
care (8+3 lowercase names) seems (at least for me) pretty standard
between platforms. ;-)

Post a reply to this message

In article <sbvf5sgo1utia3vic03fgnad8ohe86gb8g@4ax.com>, Joaquin Hierro 
Diaz <jhi### [at] cticsices> wrote:

> Well, a .zip compressed archive with filenames taken with a bit of
> care (8+3 lowercase names) seems (at least for me) pretty standard
> between platforms. ;-)

Hmn, would it be useful or feasible to allow POV to read .zip files 
directly? Are there any license restrictions on .zip compression, or any 
other reason this wouldn't be done?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> Hmn, would it be useful or feasible to allow POV to read .zip files
> directly? Are there any license restrictions on .zip compression, or any
> other reason this wouldn't be done?

I don't know if there are any license restrictions on the zip format
(which, I believe, was invented by PKWare in their PKZip product).
However, if PKZip (and the zip file format) uses LZW compression,
there is indeed a huge legal stink going on. Unisys is claiming that
anyone who uses, creates, downloads, or otherwise even thinks about
any software that reads, writes, translates, or otherwise processes
practically anything that even touches LZW needs a written license
from them. Their Web site includes in this blanket statement such things
as the PDF file format used by Adobe Acrobat, Postscript-2, the
V.42bis modem technology, and others. If one were to add the ability
to read LZW-compressed material into POV-Ray, the way the Unisys site
reads, the authors of the code, the users of the resultant program,
and anyone who downloaded an image created with the code would be
liable for patent infringement litigation.

Read all about it at http://www.unisys.com/unisys/lzw

(BTW, according to the GNU Web site, this whole stink is why GNU
zip was created, to get around legal entanglements with the
compress program, which uses LZW. This is also why their site
boasts of using no GIF files, as GIF files use LZW compression.)

Post a reply to this message

Steve Martin wrote:
> 
> > Hmn, would it be useful or feasible to allow POV to read .zip files
> > directly? Are there any license restrictions on .zip compression, or any
> > other reason this wouldn't be done?
> 
> I don't know if there are any license restrictions on the zip format
> (which, I believe, was invented by PKWare in their PKZip product).
> However, if PKZip (and the zip file format) uses LZW compression,
> there is indeed a huge legal stink going on. Unisys is claiming that
> anyone who uses, creates, downloads, or otherwise even thinks about
> any software that reads, writes, translates, or otherwise processes
> practically anything that even touches LZW needs a written license
> from them. Their Web site includes in this blanket statement such things
> as the PDF file format used by Adobe Acrobat, Postscript-2, the
> V.42bis modem technology, and others. If one were to add the ability
> to read LZW-compressed material into POV-Ray, the way the Unisys site
> reads, the authors of the code, the users of the resultant program,
> and anyone who downloaded an image created with the code would be
> liable for patent infringement litigation.
> 
> Read all about it at http://www.unisys.com/unisys/lzw
> 
> (BTW, according to the GNU Web site, this whole stink is why GNU
> zip was created, to get around legal entanglements with the
> compress program, which uses LZW. This is also why their site
> boasts of using no GIF files, as GIF files use LZW compression.)

POV-Ray already uses LZW (support for GIF's as heightfields).  I'm not
sure we have a written agreement with Unisys, since that feature
predates my joining the team.  I'll ask.  If it becomes a serious
problem, we also support PNG heightfields.

POV-Ray also uses (as part of PNG support) zlib, which includes
functions that provide support for GNU zipped files.  The gzip manual
page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
that should be completely clear of problems.

That handles feasibility.  So, how useful do people think such a thing
would be?

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> POV-Ray also uses (as part of PNG support) zlib, which includes
> functions that provide support for GNU zipped files.  The gzip manual
> page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
> that should be completely clear of problems.
> 
> That handles feasibility.  So, how useful do people think such a thing
> would be?
> 
> -Mark Gordon

I know one suggestion comes up from time to time and that is the ability
to zip image files on the fly for animation work. This is especialy true
for file types like .tga and .bmp which do not offer built in compression
methods. I have heard a couple of people mention that this can already
be done with shell commands but it would be nice if it was done internaly
to reduce cycle times during high frame count animations.

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Zip Magic can do it.
Anyway, if someone is curious and doesn't know of it yet Zip Magic is at
www.mijenix.com
Not only programs in Windows but DOS utilities can see the zip "folder" as
well.  Just made a quick check and it was about a 5 times difference from
uncompressed tga files and pretty much a unnoticeable background occurance.
I don't need to save disk space at the moment but if I ever do this will do
fine I believe.

Bob

"Ken" <tyl### [at] pacbellnet> wrote in message
news:385862C6.C5CC87EA@pacbell.net...
>
>
> Mark Gordon wrote:
>
> > POV-Ray also uses (as part of PNG support) zlib, which includes
> > functions that provide support for GNU zipped files.  The gzip manual
> > page says that gzip and PKZip both use Lempel-Ziv rather than LZW, so
> > that should be completely clear of problems.
> >
> > That handles feasibility.  So, how useful do people think such a thing
> > would be?
> >
> > -Mark Gordon
>
> I know one suggestion comes up from time to time and that is the ability
> to zip image files on the fly for animation work. This is especialy true
> for file types like .tga and .bmp which do not offer built in compression
> methods. I have heard a couple of people mention that this can already
> be done with shell commands but it would be nice if it was done internaly
> to reduce cycle times during high frame count animations.
>
> --
> Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Mark Gordon wrote:

> POV-Ray already uses LZW (support for GIF's as heightfields).  I'm not
> sure we have a written agreement with Unisys, since that feature
> predates my joining the team.  I'll ask.  If it becomes a serious
> problem, we also support PNG heightfields.

Unisys' claims are fairly extensive, but many in the field believe that their
patent only applies to creation, not to using. Thus, viewing GIF might be fine
even though you need a license from them to create them. Of course, if you
belonged to a large company with some decent pockets you could actually test
this in court. Just because you are right, doesn't mean it would be cheap :-(

(Remember, I am not a lawyer. Consult your attourney for actual advice)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

[On Wed, 15 Dec 1999 21:49:26 -0500, Steve Martin <sma### [at] usitnet>]
| I don't know if there are any license restrictions on the zip format
| (which, I believe, was invented by PKWare in their PKZip product).
| However, if PKZip (and the zip file format) uses LZW compression,

It doesn't. Further more: The zip format has been supported in libz
for quite a while now, and POV-Ray already uses that.

-- 
A penny for your thoughts.
Mine are more expensive.

Post a reply to this message

> Unisys' claims are fairly extensive, but many in the field believe that their
> patent only applies to creation, not to using. Thus, viewing GIF might be fine
> even though you need a license from them to create them.

That was always my understanding, too. However, if you read their web
site
statement carefully, it gives rise to doubt. Here's an excerpt:

  "In all cases, a written license agreement or statement signed by
  an authorized Unisys representative is required from Unisys for
  all use, sale or distribution of any software (including so-called
 "freeware") and/or hardware providing LZW conversion capability
 (for example, downloaded software used for creating/displaying GIF
images)."

This would seem to indicate that Unisys expects one to get a license to
use any piece of software that displays GIFs. That would include every
Netscape and Internet Explorer user as well as the guy who buys and
uses Adobe Photoshop and the like. How about the GIMP project? Do they
have a license from Unisys? How about the users of GIMP? Do they need
one?

One would think that the developer of a piece of software would be
responsible for getting the license, and that the user wouldn't be
required to do so. However, this is also addressed by the Unisys
statement:

  "Microsoft Corporation obtained a license under the above Unisys LZW
  patents in September, 1996. Microsoft's license does NOT extend to
  software developers or third parties who use Microsoft toolkit,
language,
  development or operating system products to provide GIF read/write
and/or
  any other LZW capabilities in their own products (e.g., by way of DLLs
and
  APIs). The complete statement by Microsoft can be found at Microsoft's
  developer-oriented Web site at
http://www.microsoft.com/DEVONLY/Unisys.htm.
  Software developers and third parties who wish to include Microsoft
toolkit,
  language, development or operating system products in their own
products for
  providing GIF or any other LZW capability should contact Unisys for a
  license as instructed below. "

The way this reads, even though Microsoft got a license to implement
DLLs
that provide LZW services, the developer who uses Microsoft's pre-built
DLLs in their projects are *not* covered.

It seems to me that this whole thing is an attempt on the part of some
lawyers
at Unisys to cash in on the Web, to the detriment of its users. Reminds
me of
the guy who went to the US Trademark office and registered himself a
trademark
on the term "Linux". He then went to everyone who was using the term
(book
publishers, software retailers, outfits like Red Hat and Debian, and so
forth) and tried to extort license fees from them for the use of his
"proprietary trademark". He was unjustified, of course, and finally
(under pressure from lawyers and several others) relinquished
his rights to the term "Linux".

Post a reply to this message

On Wed, 15 Dec 1999 20:13:08 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>
>Hmn, would it be useful or feasible to allow POV to read .zip files 
>directly? Are there any license restrictions on .zip compression, or any 
>other reason this wouldn't be done?

Well, I didn't think on that theme, because as Infozip Zip programs
are free, it has been ported to more platforms than Povray
(unbelieable but true ;-)) and than in the Infozip's copying info file
(http://www.cdrom.com/pub/infozip/doc/COPYING) they say there are not
problems with using the sources (including commercial ones), it seems
an easier approximation to a 'binary' povray scene file.

I am aware than Unisys turned a bit more money-hungry recently with
the lzw theme, but AFAIK it's over commercial application which write
lzw compressed files. 

If that idea is not possible, what about a .tgz file? ;-)

(Sorry but I'm used to read more than to write in english.)

Post a reply to this message

I don't think that a patent made in the US is valid here in Finland
(moreover it's not possible to patent such a thing here even if one wanted
to; there are two reasons for this, the most important one being that you
can't patent previously published things).
  I have made a gif-viewer myself. They can sue me if they want.

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

Nieminen Juha wrote:
> 
>   I don't think that a patent made in the US is valid here in Finland
> (moreover it's not possible to patent such a thing here even if one wanted
> to; there are two reasons for this, the most important one being that you
> can't patent previously published things).
>   I have made a gif-viewer myself. They can sue me if they want.

If your country honors international patent agreements, like many civilized
countries do, there is a good chance that patents originated here will apply
in your country too. If you want links to resources of information on patent
and copyright law let me know and I will fill your email box with them :)

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Ken wrote:
> 
> Nieminen Juha wrote:
> >
> >   I don't think that a patent made in the US is valid here in Finland
> > (moreover it's not possible to patent such a thing here even if one wanted
> > to; there are two reasons for this, the most important one being that you
> > can't patent previously published things).
> >   I have made a gif-viewer myself. They can sue me if they want.
> 
> If your country honors international patent agreements, like many civilized
> countries do, there is a good chance that patents originated here will apply
> in your country too. If you want links to resources of information on patent
> and copyright law let me know and I will fill your email box with them :)
> 
> --
> Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !


Ken, you are absolutely right! The european community honors the patents
for LZW (even if I don't understand how two independent patents are
possible for the same thing, namely for IBM and UNISYS). In fact it
could be quit dangerous to ignore these patents.
On the other hand you can't get a patent for software as european patent
but as a world patent (which the europeans 
honor).
I'm no lawyer so this is what I know from the patent lectures I heard a
few years ago.

For more on the LZW patent and a way around them see 

http://burnallgifs.org/


All the best,

Marc

-- 
Marc Schimmler

Post a reply to this message

Nieminen Juha wrote:
> 
>   I don't think that a patent made in the US is valid here in Finland
> (moreover it's not possible to patent such a thing here even if one wanted
> to; there are two reasons for this, the most important one being that you
> can't patent previously published things).
	They didn't patent something that was previously published, they just
waited until it was firmly established before trying to enforce their
patent (which AFAIK makes it unenforceable at least in France, but I'm
not a lawyer...)

		Jerome
-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

>   I have made a gif-viewer myself. They can sue me if they want.

I put a freeware windows based GIF to PNG converter online about
2 years ago, and I still havn't heard from Unisys.  It simply
decodes GIF and encodes PNG - surely a violation of Unisys's vague
patent claims.  I did talk to Unisys about a license, but didn't
feel that a US$500 starting fee was very "community minded".  
(When Unisys jump on the Open Source bandwagon, they'll have a 
lot of back-peddling to do.)

I'd like to know how much Unisys bribed Netscape and Microsoft 
for their poor adoption of PNG in web browsing products.  GIF
is such an outdated hack of a file format that there is no logic
to it's continued popularity.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to censor your email."

Post a reply to this message

> > > Hmn, would it be useful or feasible to allow POV to read .zip files
> > > directly? Are there any license restrictions on .zip compression, or any
> > > other reason this wouldn't be done?

	Having done some work in this area, I can make a few comments
	on the technical feasibility, from the point of view of the
	current POV implementation.  My basic goal was to support
	scene parsing from some kind of archived format, to increase
	the granularity of managing scenes across a network.  I got
	as far as implementing a small module that treats unix tar
	files as a virtual file system - that is, you can stuff a
	whole tree of files in a .tar and it preserves long filenames,
	case sensitivity across platforms.  (For me, Win32 and Linux,
	but in principle any platform)  The result of this work is
	currently available at:

	http://www.imp.org/members/tech/rcast/rcast.html

	The issues as far as POV-ray is concerned, are as follows:

	File opening (fopen) in POV is through one global function, 
	which can easily be extended to looking inside archives.
	This function returns a file pointer (FILE *) which means 
	that you either have to extract the file into a temporary
	file on the disk, or use an uncompressed archive such as
	TAR and a return a file pointer already positioned (fseek)
	to the right location in the archive.  However, some code
	(the truetype font impementation comes to mind) involves
	fseek, and is confused by the fact that the beginning of
	the (tar) file is not the beginning of the (ttf) font file
	inside the archive.  One solution is for the truetype code
	to work on a purely relative basis.

	Supporting compressed data I think would be nasty, because
	POV is tied to file pointers (FILE *) rather than buffers
	of data.  Java or C++ style streams come to mind as being
	a neat solution - a layer of abstraction that makes no 
	distinction between a file, console stream, a network
	socket, or a compressed file.  The most obvious work around
	is to extract the archive into temporary files, which are
	cleaned up when POV shuts down.  

	A better solution would be to implement some kind of POV
	file descriptor that provides a layer of abstraction.
	POV code would then need to use a clone of the ANSI C i/o
	API so that compressed data could be supported in a
	transparent kind of manner.

	In terms of arguments about archive format - ZIP, TAR, JAR, GZ
	you're dealing with a fragmented marketplace and a legal 
	minefield.  Gzipped TAR would seem the most logical to me,
	eventhough it still seems fairly badly supported in Windows.
	ZIP is attractive from a "follow the herd" point of view.

	To summarise - yes it can be done, but there are issues
	that would need to be considered carefully.  TAR archives
	can be supported relatively easily because they are
	uncompressed.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer, Tokyo Dweller
"The Australian Government wants to censor your email."

Post a reply to this message

Nigel Stewart wrote:

> >   I have made a gif-viewer myself. They can sue me if they want.
>
> I put a freeware windows based GIF to PNG converter online about
> 2 years ago, and I still havn't heard from Unisys.  It simply
> decodes GIF and encodes PNG - surely a violation of Unisys's vague
> patent claims.

No, not surely. Many informed people believe that their patent can only
be applied to the creation of GIF images, not the reading of them. Their
claims might have creation nailed down, but my personal opinion is that
if they ever leaned on someone doing GIF-reading only, they'd end up
losing in court and thus undermine their own efforts and patents.

(remember, I am not a lawyer, nor do I play one on the web)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message