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