 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b1609e6@news.povray.org>,
"Gail Shaw" <gsh### [at] monotix coza> wrote:
> I don't even want to think about writing code to tesselate any isosurface.
Actually, any object that has an inside and outside, and a finite volume
can be tesselated, for example by using the marching cubes or marching
tetrahedrons algorithms. Warp's tesselation patch is an example of this.
However, the meshes don't use triangles very efficiently, and high
amounts of detail require *huge* meshes.
PS: I think even shapes without an inside can be tesselated, as long as
you can figure out if the surface is between any two points.
--
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3b164ee8@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> it can be scanline rendering or raytracing; it doesn't care
You imply the rendering algorithm used to apply the radiosity light model
does not matter. Are you really sure this holds true in case of raytracing?
Do the light models for reflection and refraction really work if you just
see the radiosity data as a surface color variation? Would it be applied
prior or after the reflection/refraction is calculated? I am just
wondering, if you are not sure - no problem, I am asking because I don't
know but would be interested in knowing because I never saw any written
description of the classic radiosity being used with recursive raytracing.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> This is an interesting "our program is better than POV-Ray but it isn't".
> Fancy words, but mostly crap.
> ...
> Modern my ass.
>
> PS: Yes, every time someone makes a stupid claim of something being "better"
> than POV-Ray, I see red.
> This is not because I think POV-Ray is perfect and the best renderer
> possible in every aspect, but it's because I consider it completely stupid
> to start comparing different renderers and say that one is better than
> the other. Every renderer is good in its own field of expertise and every
> renderer is good for certain things. There's no such a thing as a renderer
> which is better than another renderer.
Another approach is to look at what can be done to improve things. When
a good idea exists, why not implementing it? This is how we got our
patches, and finally why we'll have 3.5 "soon". There is a "bright" side
at benchmarking, but their (mindcraft-like) approach is definitely dumb.
BTW I won't comment their assertion that parallel radiosity is not
possible with POV-Ray ;-)
--
__ __ __ __ _
| | / \ / / |_ / |/
\/\/ \__/ /_ /_ |__ \_ |\
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
>
> A reasonable approximation of a sphere isn't hard. A sphere's geometry
> is well defined.
A reasonable tesselation of a sphere is quite a difficult thing IMO.
Enough triangles that no corners are visible with the current camera
position and angle and not to much that it does not need too much memory.
Newly generating the mesh with every change of viewpoint, ...
Of course these things also apply for other objects, but most other things
do not need to be that totally smooth.
> The problem I can see with isos expecially is that they
> don't
> have a well defined geometry and can look like anything.
>
> I don't even want to think about writing code to tesselate any isosurface.
>
I don't see that much principal difference between a sphere and an
arbitrary isosurface apart from the fact that you can parametrize a sphere
and thereby have a way for tesselating it.
I recently read an article about tessellation of isosurfaces (in
March/April issue of IEEE Computer Graphics and Applications) and it's not
that difficult, the method Warp uses in his tesselation patch for example
works equally good (or bad) on conventional objects and isosurfaces.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<jer### [at] atosorigincom> wrote:
> The 'sturm' keyword is such a case (probably the only one), where the default
> choosen was speed against accuracy (it apply to sor, some lathe, blob, cubic,
> poly, some prism and quartic).
Actually, this is not the case. Any platform and library could provide a
square root that provides the same precision as the you get with "sturm" *.
It is just that on most platforms this is not done by default and POV-Ray
contains code that works around this compiler/library/platform limitation.
Kind of a platform specific hack you can add to your scenes, just that it is
necessary on all current desktop platforms.
I would also expect the precision of the default square root to be good
enough on platforms that support 128 bit floating-point arithmetic. Then
"sturm" would not be needed at all.
Thorsten
* Yes, we are talking about polynoms here, but internally POV-Ray uses
"sqrt" to find the roots, while "sturm" switches to the sturmian sequence to
solve it. Effectively, the limited precision of "sqrt" is one of the
problems together with the use of some other library functions such as "cos"
and "acos" which are frequently based on approximations in C libraries...
____________________________________________________
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chr### [at] povrayorg> , Chris Huff
<chr### [at] maccom> wrote:
> Actually, any object that has an inside and outside, and a finite volume
> can be tesselated
You should say "finite surface" just to make sure you cover certain odd
functions.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
it was the amount of crap they had written, and the use of pov files that
made me wonder if they had just snaffled pov and tweaked it a little.
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31 May 2001 10:02:16 -0400, Warp wrote:
> This is an interesting "our program is better than POV-Ray but it isn't".
>Fancy words, but mostly crap.
You missed one. Features: NURBS? How do you do NURBS with POV SDL?
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 30 May 2001 22:44:18 +0100, Rick [Kitty5] wrote:
>is there an official line on this, as in a way its pov, but not pov?
This isn't me speaking in any official capacity, but.. um... what is the
license on colors.inc?
At first glance, though, their parser looks okay. They can't have used
any POV code, because they're missing some tokens that have been there
since 2.2 and before.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On 31 May 2001 10:02:16 -0400, Warp wrote:
> > This is an interesting "our program is better than POV-Ray but it isn't".
> >Fancy words, but mostly crap.
>
> You missed one. Features: NURBS? How do you do NURBS with POV SDL?
>
As far as i have seen from the sample scenes included, there is nothing
like a NURBS object, they probably just represent spheres etc. internally
as NURBS.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
