 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
***POV-TEAM*** Thorsten Froehlich <tho### [at] trf de> wrote:
:> Perhaps the problem is that people don't know/remember who is a povteam
:> member and who isn't, so their posts don't stand out of the mass?
: So you are suggesting we put ***POV-TEAM*** in our name? ;-)
Well, although apparently more a joke than a serious proposition, it
MIGHT be an idea to be considered after all... :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Ken <tyl### [at] pacbellnet> wrote:
> : I don't know about fancy APIs but tesselation would be a useful
> : feature.
>
> But worth the efforts?
I believe so, yes.
--
Ken Tyler - 1400+ POV-Ray, 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 <3964cdb4@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> But the tesselation process would eat at least some of that gained time.
> Tesselation is not free.
And it is even worse if you have to go to virtual memory to hold the
tesselated object. But still, if you have the RAM, certain objects could
benefit, and preview renders wouldn't have to be at a high mesh
resolution.
However, I agree that it isn't a badly needed feature.
> How can you be sure that a tesselated version of a (complicated) object
> completely contains the original object?
I don't really understand what you mean by this...if you are talking
about the "placeholders" for objects that can't be tesselated, they
could be scaled to fit the bounding boxes.
> : Infinite objects are more of a problem...a plane could be two triangles
> : with the vertices at the largest distance POV can handle
>
> Bad idea. Try to translate that by y*0.01 :)
Hmm, transforms might cause problems, but they might not...and anyway, a
triangle is just a clipped plane, right? Just have the "tesselated" mode
for a plane be "do nothing", and generate a warning.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6 Jul 2000 12:57:40 -0400, Warp wrote:
>Ken <tyl### [at] pacbellnet> wrote:
>: I don't know about fancy APIs but tesselation would be a useful
>: feature.
>
> But worth the efforts?
It'd allow export to inferior file formats and answer a VFAQ.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> It'd allow export to inferior file formats and answer a VFAQ.
...and displacement mapping, and subdivision surfaces, and...
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> The Ellis Family <cel### [at] voyageurca> wrote:
>
> Somehow I feel your article quite irritating and provocative. Don't know
> exactly why, but it seems to be rude and lack politeness.
I tried very hard to word my message in such a way that no-one would
take offense... I guess I failed. I certainly wasn't trying to be rude
or impolite.
> 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.
Lightflow is only superior to PovRay in *certain areas* (those were my
exact words), and I didn't mean to suggest that the Lightflow example
images were the only proof of this.
> Perhaps no offense is intended here, but still this is a hit under the
> belt. This is low.
No offense was intended and, looking back, perhaps I should have worded
it differently.
> Come on. This is insulting. You clearly don't know what you are talking
> about.
Admittedly, my programming skills aren't exactly spectacular, but I'm
not an idiot either (on rare occassions, I *do* know what I'm talking
about;-).
> Distributed rendering: This has been discussed before. It has several
> problems.
Of coarse it has several problems, but it's not impossible. Anytime you
download a file or fill out a registration form online, you are engaging
in *cross-platform networking through a well-defined protocol*. The
well-defined protocol is key, but, imho, that would be the only
stumbling block.
> Accessible api: You mention it as if it was laziness or incapacity that have
> stopped the povteam from making a povray api. No, that's not the reason and you
> should know it. Read the povray licence and the several articles about the
> issue to see why there isn't a povray api.
No offense, but this is one aspect of the PovRay license I do not like.
But, I can't blame the PovTeam for protecting there interests.
> "Real" radiosity: This again. What the h*** is with this "real" radiosity?
> There's no such a thing as "real" radiosity. All the algorithms for calculating
> diffuse interreflection of light are only approximations, as any rendering
> technique is.
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).
> So these are pretty bad examples. Sorry.
It's not your fault;-)
>> PovRay *needs* an accessible api
> No, it doesn't. Why it should?
Why should we be limited to using PovScript? What if I want to use a
more powerful scripting lang, such as Python, or even something
proprietary? With no api, I would have to write a translator, and
having to parse a scene twice would really slow things down (for complex
scenes). Also, an api would be cleaner & faster for 3rd party
front-ends/modellers.
> : Every 2 or
> : 3 weeks, the PovTeam could report on the progress of the next release
> : (is this too much to ask?).
>
> They have a good reason to not to do this. They have done it in the past
> and got problems with it.
What problems (this must have been before I entered the PovRay scene).
I'm sure these problems could be solved.
Hookflash
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <396### [at] nospamhotmailcom>,
hoo### [at] nospamhotmailcom wrote:
> Lightflow is only superior to PovRay in *certain areas* (those were my
> exact words), and I didn't mean to suggest that the Lightflow example
> images were the only proof of this.
It would help if you gave examples of which areas it is superior
in..."surface engine" isn't enough information.
Also, LightFlow seems to be limited to one platform, and was designed
from the start with a certain direction in mind. This is why some of
these features were possible.
POV, on the other hand, has to be cross-platform, and has an aging code
base which makes it very difficult to do some of these things(one reason
for the 4.0 C++ rewrite, which may make some of these things possible).
> > Distributed rendering: This has been discussed before. It has several
> > problems.
>
> Of coarse it has several problems, but it's not impossible. Anytime you
> download a file or fill out a registration form online, you are engaging
> in *cross-platform networking through a well-defined protocol*. The
> well-defined protocol is key, but, imho, that would be the only
> stumbling block.
The protocol may be cross-platform, but the code to use it probably
isn't. That portion of the code would have to be rewritten for every
platform to be supported. Then you still have the problems of sharing
radiosity/photon data, error handling, etc.
So you see, it isn't as simple as finding the right protocol...
> 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).
It is view dependant, and it is not too slow(with the MegaPOV fixes, of
course). And tesselation is not the answer. As has been explained many
times, there are some objects which just can't be reduced to polygons or
patches.
> >> PovRay *needs* an accessible api
> > No, it doesn't. Why it should?
>
> Why should we be limited to using PovScript? What if I want to use a
> more powerful scripting lang, such as Python, or even something
> proprietary? With no api, I would have to write a translator, and
> having to parse a scene twice would really slow things down (for complex
> scenes). Also, an api would be cleaner & faster for 3rd party
> front-ends/modellers.
Why shouldn't you be limited to POV-Script? It is the input format for
POV-Ray, and is designed for that purpose. It supports every single
feature in POV-Ray.
You are welcome to use those languages...all you have to do is have them
output POV-Script and render it with POV-Ray.
Also, an API has some of the same problems as distributed
rendering...you have to do it in a platform independant way. Add the
problems of support...all of these have been discussed before.
The POV Team has very good reasons for this portion of the license and
for not including this feature, it wasn't just an arbitrary choice.
> What problems (this must have been before I entered the PovRay scene).
> I'm sure these problems could be solved.
Basically, people get upset when they don't get what they feel is
promised, whether it is free or not, whether it was actually promised or
not. The same reason many companies refuse to give release dates and
definite feature lists. People got upset when a version of POV-Ray was
delayed past it's release date or didn't have a feature they wanted, and
some of them got quite irrational.
And these problems were solved...by not giving this type of information
out. Now there is the problem of people clamoring for more information.
:-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Warp wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > : I don't know about fancy APIs but tesselation would be a useful
> > : feature.
> >
> > But worth the efforts?
>
> I believe so, yes.
This make me think of something...
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 ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> ...definite feature lists. People got upset when a version of POV-Ray was
> delayed past it's release date or didn't have a feature they wanted, and
> some of them got quite irrational.
Irrational is putting it mildly. I heard that some users of the program
were sending e-mail to the team that was both rude and insulting.
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ah, so you consider lightflow better than povray.
In some ways yes, in some ways no. I seriously respect it. I'll tell you
that.
> Tesselation
Exporting to other formats, for example.
> and fancy apis? What for?
I have no idea. I just said that to indicate that eventually, the POV-Team
might get around to adding APIs. I just tossed in "fancy" to make it sound
better. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
