 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 15:24:36 -0500, Warp <war### [at] tag povrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>:>> Just if U have a system
>:>> without dynamic plugin support you'll have to recompile povray with
>:>> every plugin you need and then you can render every scene you want.
>:>> This is what povray *ACTUALLY* does
>
>: Of course you are not aware of them... This is only because it was a
>: feature proposal...
>
> You said "this is what povray *ACTUALLY* does". Now you say it was only
>a proposal, not something povray is actually doing..
Please re-read this thread, as U seem to be the only one that did not
understand this... I was saying that you should not matter about
portability in a (future) modular povray as for the plattforms where
dynamic loading is impossible or not implemented you can always use a
static plugin system, that is much like the actual shading system in
povray, so you don't loose anything in doing that, you just gain
something if the plattform is supported
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 14:51:05 -0500, Ron Parker <ron### [at] povrayorg>
wrote:
>Please, is it too much to ask that you actually spell out the words "you"
>and "people"?
I know my english is poor, and as I'm replying to lots of posts, many
will contain typos too... Sorry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> :> Show us some lightflow images which can't be done in POV-Ray.
>
> : I advise "lightflow" searching at povray.binaries.images first :-)
>
> Granted, Lightflow can do pretty impressive things faster than povray
(ie.
> if you try to simulate the same image with povray it can take a lot
longer).
> However, the same holds in the other direction as well. And I'm pretty
sure
> that there are awesome images made with povray which are either impossible
or
> extremely slow to do with lightflow.
> Besides, AFAIK povray is usually faster than lightflow in many things.
I prefer POV (basically for both its flexibility and general quality), but I
wouldn't say that POV is faster than Lightflow without any real comparison.
You must admit that, although simple, these examples and their rendering
times are quite impressive: http://max3d.3dluvr.com/news.php?n_id=204.
BTW I must admit that I haven't managed to find a good lightflow gallery
(with *real* images, not just tests) yet.
--
Jonathan.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 15:31:40 -0500, Warp <war### [at] tagpovrayorg> wrote:
>W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
>:> Show us some lightflow images which can't be done in POV-Ray.
>
>: I advise "lightflow" searching at povray.binaries.images first :-)
>
> Granted, Lightflow can do pretty impressive things faster than povray (ie.
>if you try to simulate the same image with povray it can take a lot longer).
>However, the same holds in the other direction as well. And I'm pretty sure
>that there are awesome images made with povray which are either impossible or
>extremely slow to do with lightflow.
> Besides, AFAIK povray is usually faster than lightflow in many things.
No hope... I don't think so... povray is faster than lightflow only if
U use basic primitives like spheres etc, because lightflow tesselates
them. But in real scenes (the ones you get with a modelling program)
you don't use spheres, cylinders etc, but polygons, nurbs, b-splines,
and subdivision surfaces. In those things lightflow is faster...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Dec 2001 21:19:23 GMT, Angelo 'kENpEX' Pesce wrote:
> On 4 Dec 2001 14:51:05 -0500, Ron Parker <ron### [at] povrayorg>
> wrote:
>
>>Please, is it too much to ask that you actually spell out the words "you"
>>and "people"?
> I know my english is poor, and as I'm replying to lots of posts, many
> will contain typos too... Sorry
That's not a typo, it's a conscious decision. This isn't a chat room.
You don't need to say "U" and "ppl". It just makes it hard to read whatever
you're trying to say.
Followups to off-topic...
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Dec 2001 21:58:42 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0d32ab@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
>> Besides, AFAIK povray is usually faster than lightflow in many things.
>
>POV-Ray is capable of real-time raytracing. I have shown it is possible
>with the plain 3.5 source code - the result is visible in the Windows and
>Mac about boxes as easter egg...
Wow!
Have U seen realtime raytracing demos like naturesuxx, naturestillsuxx
etc? How does povray compare to those rtrt engines? (of course I know
that povray is not a realtime raytracer) Can U tell me what kind of
optimizations are included in povray 3.5 and how much speed gain you
get over the previous version?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 4 Dec 2001 22:19:03 +0100, "JRG" <jrg### [at] hotmailcom> wrote:
>Warp wrote:
>> W³odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
>> :> Show us some lightflow images which can't be done in POV-Ray.
>>
>> : I advise "lightflow" searching at povray.binaries.images first :-)
>>
>> Granted, Lightflow can do pretty impressive things faster than povray
>(ie.
>> if you try to simulate the same image with povray it can take a lot
>longer).
>> However, the same holds in the other direction as well. And I'm pretty
>sure
>> that there are awesome images made with povray which are either impossible
>or
>> extremely slow to do with lightflow.
>> Besides, AFAIK povray is usually faster than lightflow in many things.
>
>I prefer POV (basically for both its flexibility and general quality), but I
>wouldn't say that POV is faster than Lightflow without any real comparison.
>You must admit that, although simple, these examples and their rendering
>times are quite impressive: http://max3d.3dluvr.com/news.php?n_id=204.
>BTW I must admit that I haven't managed to find a good lightflow gallery
>(with *real* images, not just tests) yet.
A long time ago I did that comparison. I also compared other
raytracers (currently I have used those renderers both for work and
fun:
lightflow/megapov/povman/bmrt/mentalray-softimage/lightwave/renderpark/mcppov/virtualight/brazil/vivid/photorealistic
renderman)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d39b7@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Care to tell us how it is activated?-)
On Windows, look into the Windows source code (you have access to that part
of the depot, don't you?). For Macs it won't help you because I am going to
keep that source code part for myself and I am not going to tell you more
than that it is there in the about box, accessible via an obvious key
combination.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d3e15@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:
> I prefer POV (basically for both its flexibility and general quality), but I
> wouldn't say that POV is faster than Lightflow without any real comparison.
> You must admit that, although simple, these examples and their rendering
> times are quite impressive: http://max3d.3dluvr.com/news.php?n_id=204.
> BTW I must admit that I haven't managed to find a good lightflow gallery
> (with *real* images, not just tests) yet.
The question would be how many triagles were used in that scene. Without
that piece of information it is impossible to say if the speed is impressive
or not.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Dec 2001 22:43:22 +0100, Thorsten Froehlich wrote:
> In article <3c0d39b7@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
>> Care to tell us how it is activated?-)
>
> On Windows, look into the Windows source code (you have access to that part
> of the depot, don't you?). For Macs it won't help you because I am going to
I thought that was going to be a secret on Windows, too, but there it is.
Maybe it won't be in the unofficial source, though. Perhaps we should move
this discussion to a place where everyone has source access, so as not to
arouse undue jealousy.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm trying EVERYTHING!
What about a simple (raytraced of course) Doom clone where you can shoot the
members of the POV team? ;)
--
Jonathan.
"Thorsten Froehlich" <tho### [at] trfde> ha scritto nel messaggio
news:3c0d437b$1@news.povray.org...
> In article <3c0d39b7@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
> > Care to tell us how it is activated?-)
>
> On Windows, look into the Windows source code (you have access to that
part
> of the depot, don't you?). For Macs it won't help you because I am going
to
> keep that source code part for myself and I am not going to tell you more
> than that it is there in the about box, accessible via an obvious key
> combination.
>
> 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, 4 Dec 2001 22:53:49 +0100, JRG wrote:
> I'm trying EVERYTHING!
Don't try too hard; the answer is right there in the text somewhere.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d3e96.31659740@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> Wow!
> Have U seen realtime raytracing demos like naturesuxx, naturestillsuxx
> etc?
I checked out some (not sure about the names) but had a problem running a
lot of them (might be that they don't run in Windows DOS boxes). The ones I
got to run were fairly impressive on one hand, but not that much if one
knows how simple some of the effects are if only the scene geometry is known
in advance...
> How does povray compare to those rtrt engines? (of course I know
> that povray is not a realtime raytracer) Can U tell me what kind of
> optimizations are included in povray 3.5 and how much speed gain you
> get over the previous version?
Actually, I could even do it with POV-Ray 3.0. I did it for 3.5 just
because I needed some Easter egg so I deactivated some optimizations I
wasn't sure if they would allow me to change the camera or light source
without rebuilding the scene or other side effects (I could have looked into
the code to find out, but didn't bother). Consequently I am only using
bounding box optimization because those don't depend on camera or light
positions. With this particular optimization the scene is already fairly
equal in computation time when using between five to ten primitives and only
gets slower/faster with more primitives as the screen fills up. Of course,
turning off reflection and phong shading nearly doubles the speed...
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:
>
> It is not impossible that some general tesselation routine would be added
> in the future.
> (Of course tesselation is slower than one may believe, and the meshes can
> take huge amounts of memory, so the feasibility of tesselating a whole
> scene can be sometimes dubious.)
>
I doubt this will be of universal usability, the memory requirements can
be enormous. With increasing processor speed isosurfaces become more and
more usable as an alternative in many cases too.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d3e96.31659740@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> Have U seen realtime raytracing demos like naturesuxx, naturestillsuxx
OK, I looked this one up and saw some pictures. I have to say it is indeed
more impressive than all other demos i have seen before. Of course, it
still requires DOS mode direct hardware access :-( Unfortuantely I am
forced to draw to the screen using a Mac OS system function and Chris has to
use a Windows system function. This is kind of drawing has some difficult
to overcome speed problem...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Dec 2001 23:22:01 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0d3e96.31659740@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> Have U seen realtime raytracing demos like naturesuxx, naturestillsuxx
>
>OK, I looked this one up and saw some pictures. I have to say it is indeed
>more impressive than all other demos i have seen before. Of course, it
>still requires DOS mode direct hardware access :-(
?!? They are windows demos, they use directX
If you want to be impressed more, download fresnel2 (it requires a
fast 3d openGL card) or rtrt intros by spinningkids and by mfx
>Unfortuantely I am
>forced to draw to the screen using a Mac OS system function and Chris has to
>use a Windows system function. This is kind of drawing has some difficult
>to overcome speed problem...
If that's the problem with your easter egg, just download the tinyPTC
library... :) It's available for maaaaaaany plattforms, and it will
give U an high performance display window (directx, videoforwindows or
gdi for windows, dunno for others, of coz directx is the faster way)
>
> Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Angelo 'kENpEX' Pesce" <ken### [at] uniplanit> wrote:
> ?!? They are windows demos, they use directX
> If you want to be impressed more, download fresnel2 (it requires a
> fast 3d openGL card) or rtrt intros by spinningkids and by mfx
Could you please give me some URLs?
--
Jonathan.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: It's not dubious at all, as many other raytracers do that...
So instead of having 1 million spheres take about 50 Megs of memory,
you want them tesselated so that they will take 1 Gigabyte of memory?
: It's
: feasible, but I don't think it will be done for povray
Why not? I don't see any reason why it couldn't be implemented in the future.
Tesselating finite objects is not impossible (you just need to know its limits
and you have to be able to trace it, and that's exactly what raytracing does).
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d5211.36647845@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> ?!? They are windows demos, they use directX
> If you want to be impressed more, download fresnel2 (it requires a
> fast 3d openGL card) or rtrt intros by spinningkids and by mfx
I downloaded and tried naturesuxx on a Celeron 400 running under Win ME with
128 MB. At 320*240 with all features enabled it didn't get over 10
frames/second, which I don't exactly consider "realtime". Granted, the
graphics card is from a previous PC and with 2 MB of DRAM. However, at
320*240 that shouldn't be a bandwidth bottleneck. I will try it on a faster
system tomorrow...
> If that's the problem with your easter egg, just download the tinyPTC
> library... :) It's available for maaaaaaany plattforms, and it will
> give U an high performance display window (directx, videoforwindows or
> gdi for windows, dunno for others, of coz directx is the faster way)
Well, it is just an Easter egg coded in less than 250 lines total. Anything
else would just bloat the code. Of course it can be done much faster with
much more code and time...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0d53f6@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:
>> ?!? They are windows demos, they use directX
>> If you want to be impressed more, download fresnel2 (it requires a
>> fast 3d openGL card) or rtrt intros by spinningkids and by mfx
>
> Could you please give me some URLs?
I got fairly fast links to download the two mentioned demos from
<http://www.oroboro.com/rafael/project/raytracetext.html>. He has a link to
the creators of the demo as well. For more demos try www.scene.org (slow
http, at least for me, and their ftp servers are full). Otherwise google
really helps!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: But in real scenes (the ones you get with a modelling program)
: you don't use spheres, cylinders etc, but polygons, nurbs, b-splines,
: and subdivision surfaces. In those things lightflow is faster...
So by your definition, these are not "real scenes":
http://www.irtc.org/ftp/pub/stills/2001-04-30/aseafort.jpg
http://www.irtc.org/ftp/pub/stills/2000-04-30/drunkpat.jpg
http://oz.irtc.org/ftp/pub/stills/1997-12-31/travieso.jpg
And I have yet to actually see measurements of identical triangle mesh
scenes rendered significantly faster in lightflow than in povray.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I guess he was referring to another market. BTW who cares whether Lightflow
is faster than POV-Ray or not?
--
Jonathan.
"Warp" <war### [at] tagpovrayorg> ha scritto nel messaggio
news:3c0d5dea@news.povray.org...
> Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
> : But in real scenes (the ones you get with a modelling program)
> : you don't use spheres, cylinders etc, but polygons, nurbs, b-splines,
> : and subdivision surfaces. In those things lightflow is faster...
>
> So by your definition, these are not "real scenes":
>
> http://www.irtc.org/ftp/pub/stills/2001-04-30/aseafort.jpg
> http://www.irtc.org/ftp/pub/stills/2000-04-30/drunkpat.jpg
> http://oz.irtc.org/ftp/pub/stills/1997-12-31/travieso.jpg
>
> And I have yet to actually see measurements of identical triangle mesh
> scenes rendered significantly faster in lightflow than in povray.
>
> --
> #macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
> rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
> ],13),8)-3,10>#end blob{N(array[6]{11117333955,
> 7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: On Windows, look into the Windows source code
Ah... Kewl.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Agh! What text? I don't have access to the source and even if I did I
wouldn't know what to look for...
8-[
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 4 Dec 2001 22:53:49 +0100, JRG wrote:
> > I'm trying EVERYTHING!
>
> Don't try too hard; the answer is right there in the text somewhere.
>
> --
> #macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_
z)R(-z _-z)
> R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro
S(_)9-(_1-
> _)*(_1-_)#end#macro Z(_1 _
__)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
> rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate
x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 4 Dec 2001 20:03:25 -0500, Mahalis wrote:
> Agh! What text? I don't have access to the source and even if I did I
> wouldn't know what to look for...
The text on the about box. It was hard to find for me too, initially.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce wrote in message <3c0cc693.932849@news.povray.org>...
>On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>>: Another option (a better one imho because it's lots faster and
>>: easier to develop too) is to use a shader-plugin architecture
>>
>> Dynamically loadable plugins and portability are mutually exclusive.
>>Not likely to happen. (Include files are a different thing, if that's what
>>you were talking about.)
>
>The standard unix version can discard
>this feature (and just rely on static linked shaders, this means that
>if U want to add a shader you have to recompile pov
Please explain how to do dynamically-loaded shaders using VMS. I
occasionally use my school's server to do renderings, and I don't want to
spend 15-20 minutes recompiling POV-Ray every time I want to use a new
shader.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message ...
>On Tue, 4 Dec 2001 22:53:49 +0100, JRG wrote:
>> I'm trying EVERYTHING!
>
>Don't try too hard; the answer is right there in the text somewhere.
Yep. I like. Real-time ray-tracing, right there in POV-Ray.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 18:16:28 -0500, Warp <war### [at] tagpovrayorg> wrote:
> Why not? I don't see any reason why it couldn't be implemented in the future.
I like (IIRC by Chris Huff at p.u.p) proposition to add method Tesselate to
general objects method. Then there could be one general tesselation routine and
some specialized for simplest primitives.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 04 Dec 2001 21:16:13 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> It's not dubious at all, as many other raytracers do that...
Please create 1.000.000 spheres as separated meshes (not clone or another
referrence) and tell us memory size of it.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I thought that was going to be a secret on Windows, too, but there it is.
> Maybe it won't be in the unofficial source, though. Perhaps we should
move
> this discussion to a place where everyone has source access, so as not to
> arouse undue jealousy.
Touch late for that :)
--
Rick
Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 18:16:28 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: It's not dubious at all, as many other raytracers do that...
>
> So instead of having 1 million spheres take about 50 Megs of memory,
>you want them tesselated so that they will take 1 Gigabyte of memory?
>
>: It's
>: feasible, but I don't think it will be done for povray
>
> Why not? I don't see any reason why it couldn't be implemented in the future.
>Tesselating finite objects is not impossible (you just need to know its limits
>and you have to be able to trace it, and that's exactly what raytracing does).
Because it seems that ppl here don't like the idea...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 09:10:47 +0100, W³odzimierz ABX Skiba
<abx### [at] babilonorg> wrote:
>On Tue, 04 Dec 2001 21:16:13 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> It's not dubious at all, as many other raytracers do that...
>
>Please create 1.000.000 spheres as separated meshes (not clone or another
>referrence) and tell us memory size of it.
mhm why should I do such a crazy thing? Let's talk about real world
problems, not about a scene of 1.000.000 spheres, if I have to render
that monster, probably I'll make my own sphere-raytracer...
Spheres, quartics, infinite planes etc are just something used in old
raytracing shows (four sphere and a reflective checkerboard plane
image? no thanks), nowdays everything is modelled with nurbs,
subdivision surfaces and polygons
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 5 Dec 2001 01:56:28 -0500, "Mark Wagner"
<mar### [at] gtenet> wrote:
>
>Angelo 'kENpEX' Pesce wrote in message <3c0cc693.932849@news.povray.org>...
>>On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>>>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>>>: Another option (a better one imho because it's lots faster and
>>>: easier to develop too) is to use a shader-plugin architecture
>>>
>>> Dynamically loadable plugins and portability are mutually exclusive.
>>>Not likely to happen. (Include files are a different thing, if that's what
>>>you were talking about.)
>>
>>The standard unix version can discard
>>this feature (and just rely on static linked shaders, this means that
>>if U want to add a shader you have to recompile pov
>
>Please explain how to do dynamically-loaded shaders using VMS. I
>occasionally use my school's server to do renderings, and I don't want to
>spend 15-20 minutes recompiling POV-Ray every time I want to use a new
>shader.
Please, tell me a thing. Now can U add a shader to your povray without
applying a complex patch and recompiling? NO
So such a plugin-modular architecture will only make povray better for
some plattforms, but you won't notice any difference because, actually
you just can't add a new shader without recompiling. The point is, if
U don't complain about this problem now, why should U complain about
it later? And btw using a modular design, adding shaders will be
easier with the static-linked-model too. Also if U plan to add a new
shader every day (but I don't think so, so U should not recompile pov
so often) you can just do an incremental build, and U won't spend
15-20 minutes every time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 00:24:21 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0d5211.36647845@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> ?!? They are windows demos, they use directX
>> If you want to be impressed more, download fresnel2 (it requires a
>> fast 3d openGL card) or rtrt intros by spinningkids and by mfx
>
>I downloaded and tried naturesuxx on a Celeron 400 running under Win ME with
>128 MB. At 320*240 with all features enabled it didn't get over 10
>frames/second, which I don't exactly consider "realtime". Granted, the
>graphics card is from a previous PC and with 2 MB of DRAM. However, at
>320*240 that shouldn't be a bandwidth bottleneck. I will try it on a faster
>system tomorrow...
>
>> If that's the problem with your easter egg, just download the tinyPTC
>> library... :) It's available for maaaaaaany plattforms, and it will
>> give U an high performance display window (directx, videoforwindows or
>> gdi for windows, dunno for others, of coz directx is the faster way)
>
>Well, it is just an Easter egg coded in less than 250 lines total. Anything
>else would just bloat the code. Of course it can be done much faster with
>much more code and time...
tinyPTC is really tiny... 3-4kb of additional compiled code... and not
much more of source --> www.gaffer.com or .org...
>
> 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, 4 Dec 2001 23:53:28 +0100, "JRG" <jrg### [at] hotmailcom> wrote:
>"Angelo 'kENpEX' Pesce" <ken### [at] uniplanit> wrote:
>> ?!? They are windows demos, they use directX
>> If you want to be impressed more, download fresnel2 (it requires a
>> fast 3d openGL card) or rtrt intros by spinningkids and by mfx
>
>Could you please give me some URLs?
for you and everyone else -------------->
http://www.acm.org/tog/resources/RTNews/demos/overview.htm
this is a comprehensive collection of rtrt intros
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4 Dec 2001 18:36:11 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: But in real scenes (the ones you get with a modelling program)
>: you don't use spheres, cylinders etc, but polygons, nurbs, b-splines,
>: and subdivision surfaces. In those things lightflow is faster...
>
> So by your definition, these are not "real scenes":
>
>http://www.irtc.org/ftp/pub/stills/2001-04-30/aseafort.jpg
>http://www.irtc.org/ftp/pub/stills/2000-04-30/drunkpat.jpg
>http://oz.irtc.org/ftp/pub/stills/1997-12-31/travieso.jpg
No those are not... :P
Those are some fine examples of what ppl can do with lots of patience
and they are really really great. But no professional graphician will
do a scene using those math primitives. Just take any 3d modelling
program and try to find a perfect sphere primitive... they will output
a triangle mesh or a nurbs surface... :P
Of course all the features I added in my wish list where intended to
make povray a "professional" level raytracer. I hope that this fine
piece of opensource software someday will make this next step towards
being the definitive renderer...
> And I have yet to actually see measurements of identical triangle mesh
>scenes rendered significantly faster in lightflow than in povray.
As I told U I did those benchmarks, and other comparisons too...
>
>--
>#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
>rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
>],13),8)-3,10>#end blob{N(array[6]{11117333955,
>7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 5 Dec 2001 00:47:53 +0100, "JRG" <jrg### [at] hotmailcom> wrote:
>I guess he was referring to another market. BTW who cares whether Lightflow
>is faster than POV-Ray or not?
Well this tells us that there's still room for improvement in povray
speed, and as speed==quality (do I have to say it again?
speed==quality) mabye (imho) it's something that should be
investigated before adding new fancy and rarely used features to it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: Because it seems that ppl here don't like the idea...
Who doesn't like the idea?
What people don't like is the idea of replacing *everything* with tesselated
meshes.
Tesselating has its uses, but it should be *optional*. And optional in
a per-object basis.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: Spheres, quartics, infinite planes etc are just something used in old
: raytracing shows (four sphere and a reflective checkerboard plane
: image? no thanks), nowdays everything is modelled with nurbs,
: subdivision surfaces and polygons
Really? Guess what was used in this image:
http://www.irtc.org/ftp/pub/stills/2000-04-30/drunkpat.jpg
If you guessed "mainly boxes, cylinders, spheres, blobs, etc", then you
guessed right.
Does this image look to you as an "old raytracing show"?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
:>I guess he was referring to another market. BTW who cares whether Lightflow
:>is faster than POV-Ray or not?
: Well this tells us that there's still room for improvement in povray
: speed,
How so? AFAIK POV-Ray is usually faster than lightflow. I have yet to see
a proof of the contrary.
: speed==quality
You still haven't explained this. What the h*** has speed to do with image
quality?
The quality of the image has nothing to do with rendering speed. The image
will come identical independently of how long it takes to create it.
What affects image quality are the algorithms used by the program and the
data provided by the user of the program. Speed has absolutely no effect on
the final image.
: it's something that should be
: investigated before adding new fancy and rarely used features to it...
New features seldom slow down the renderer.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: But no professional graphician will
: do a scene using those math primitives. Just take any 3d modelling
: program and try to find a perfect sphere primitive... they will output
: a triangle mesh or a nurbs surface... :P
: Of course all the features I added in my wish list where intended to
: make povray a "professional" level raytracer.
I don't understand why making a program "professional" means in practice
removing 90% of its functionality, devolving it to a degree that no-one can
use it directly.
POV-Ray supports very fast meshes. What else do you want? Use your bloody
modeller and make all the meshes you want, then render them with povray. What
else do you want?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0e7c89.599326@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> nowdays everything is modelled with nurbs,
> subdivision surfaces and polygons
All of which get broken down into triangles so graphic accelerators can show
you a fast preview. If you had ever looked at more than just the absolute
basic parts of POV-Ray you would have noticed blobs, sors and other more
complex object types that are far superior when modeling organic shapes than
any kind/implementation of nurbs.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0e7d94.866669@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> So such a plugin-modular architecture will only make povray better for
> some plattforms, but you won't notice any difference because, actually
> you just can't add a new shader without recompiling. The point is, if
> U don't complain about this problem now, why should U complain about
> it later? And btw using a modular design, adding shaders will be
> easier with the static-linked-model too. Also if U plan to add a new
> shader every day (but I don't think so, so U should not recompile pov
> so often) you can just do an incremental build, and U won't spend
> 15-20 minutes every time...
If you had ever looked at the source code you would know that it is fairly
modular (well, as modular as a 1980s C program could be)...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> : speed==quality
>
> You still haven't explained this. What the h*** has speed to do with image
> quality?
I think his idea is that a good raytracer should be faster at a potentially
lower quality of the resulting image; contrary to POV-Ray's philosophy of
allowing (optional) maximum quality at the any expense of render time. Of
course POV-Ray isn't like BMRT, so such a suggestion is pointless as the
resulting program would no longer be POV-Ray and that is why it doesn't make
sense to you (nor does it make much sense to me, my explanation is only a
guess)...
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 Wed, 05 Dec 2001 22:10:48 +0100, Thorsten Froehlich wrote:
> In article <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
>> : speed==quality
>>
>> You still haven't explained this. What the h*** has speed to do with image
>> quality?
>
> I think his idea is that a good raytracer should be faster at a potentially
> lower quality of the resulting image
I think he's saying that the faster the raytracer, the more image quality
you can get in a given amount of time. For example, if POV were twice as
fast, you could crank down the AA threshold a bit and still keep a comparable
render time.
But then, I'm not reading his posts as Vanna has stopped selling me vowels
to go with them.
--
#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{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Dec 2001 15:31:00 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: Because it seems that ppl here don't like the idea...
>
> Who doesn't like the idea?
>
> What people don't like is the idea of replacing *everything* with tesselated
>meshes.
> Tesselating has its uses, but it should be *optional*. And optional in
>a per-object basis.
Well, if U want to keep the normal object and add a jolly-good support
for tesselated meshes, that's really fine!!! :))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 22:00:08 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0e7c89.599326@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> nowdays everything is modelled with nurbs,
>> subdivision surfaces and polygons
>
>All of which get broken down into triangles so graphic accelerators can show
>you a fast preview. If you had ever looked at more than just the absolute
>basic parts of POV-Ray you would have noticed blobs, sors and other more
>complex object types that are far superior when modeling organic shapes than
>any kind/implementation of nurbs.
I'll reply to you and to warp here, about this question...
You're really, really, really, really wrong if U think that organic
shapes or anything above amatorial level graphics is made with such
primitives. I know that there are many *FINE* images done with that
stuff. I agree that there are many *FINE* artists that use that tools.
But this is not what high-end graphician want. Why? I can tell you
why...
Such primitives are impossible or really difficoult to animate, are
really difficoult to control and require too much time, experience and
experiments to get them look right. If U don't have any schedule you
can affod doing a fine image with only spheres, but if so U can even
do an image with an hex-editor... The main mistake between what I say
and what many ppl here think is that we are thinking of two different
scenarios. I want to say it again, I'm not saying that IRTC artists
are lame or something like that. In fact, if you're really trying to
make some art, it does not matter how do U make it, and my favourite
3d artist (not modeller not graphician, artist) is gilles Tran, who as
you will surely know, is a povray user. What I'm trying to say is that
povray could be well suited for high-end gfx too if someone will add
support for a few things...
Now, again about primitives. You can think everything you want about
this, but I can tell you that 99% of the organic models in high-end
gfx is made with nurbs or subdivision surfaces (subdivision surfaces
are "new", mhm no they are not "new" but only recently they have seen
implementation in 3d modellers, and they are really better than
nurbs). Having a raytracer without support for those stuff is really a
mistake imho, supporting this stuff means more or less supporting
tesselated meshes (I know that it's possible to raytrace nurbs
directly but I think it's slow), that's why most of high-end
raytracers (where for high-end I mean something that's used in real,
professional, productions) just support triangle meshes...
Of course supporting both stuff will not hurt at all... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 22:01:00 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0e7d94.866669@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> So such a plugin-modular architecture will only make povray better for
>> some plattforms, but you won't notice any difference because, actually
>> you just can't add a new shader without recompiling. The point is, if
>> U don't complain about this problem now, why should U complain about
>> it later? And btw using a modular design, adding shaders will be
>> easier with the static-linked-model too. Also if U plan to add a new
>> shader every day (but I don't think so, so U should not recompile pov
>> so often) you can just do an incremental build, and U won't spend
>> 15-20 minutes every time...
>
>If you had ever looked at the source code you would know that it is fairly
>modular (well, as modular as a 1980s C program could be)...
Yep. So you can agree that it will not be a big mistake if a support
for dynamic module loading is added, where possible...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Dec 2001 16:15:10 -0500, Ron Parker <ron### [at] povrayorg>
wrote:
>On Wed, 05 Dec 2001 22:10:48 +0100, Thorsten Froehlich wrote:
>> In article <3c0e86ee@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>>
>>> : speed==quality
>>>
>>> You still haven't explained this. What the h*** has speed to do with image
>>> quality?
>>
>> I think his idea is that a good raytracer should be faster at a potentially
>> lower quality of the resulting image
>
>I think he's saying that the faster the raytracer, the more image quality
>you can get in a given amount of time. For example, if POV were twice as
>fast, you could crank down the AA threshold a bit and still keep a comparable
>render time.
>
>But then, I'm not reading his posts as Vanna has stopped selling me vowels
>to go with them.
This is actually the point. Again, I'm thinking about povray as a
renderer that professional 3d gfxers can work. Now such a gfxer, that
has to finish a project in a tight schedule, can't wait a night for
every rendering. And is this is slightly possible for still images,
for animations speed is really really equal to image quality as you
know that you'll have only a fixed amount of time per frame (for
example, 3 mins) for rendering, and then you have to adjust your scene
complexity to fit this requirement... Now, I'm not telling you, remove
quality from povray!!! This is stupid. I'm not telling you make a bad
renderer, the only thing that means to me is speed... But I'm trying
to say that if I have to spend x hours to add a new fancy quality
option (for example, a new caustic method that is hard to implement
and boosts quality in almost no image at the expense of a lot of
rendering time), mabye this time can be re-invested into optimizing
povray... It's only a matter of priority, it seems to me that povray
is focusing a lot into adding fancy rendering options (ok, but tell me
what movie you've seen with radiosity and caustics... again I have to
tell that most stuff is made with photorealistic renderman, a tool
that is not capable of doing correct reflections!!! Why??? Because
most people believe that they can live even without this stuff, if
without it I can have a blazing fast render that lets me use a 10mb
nurbs model in my scene) and not into optimizing rendering speed...
So again, quality is good, but who cares about blurred reflections and
distribuited raytracing with radiosity and photonmapping, if I can
apply it only to spheres???
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Dec 2001 15:47:23 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: But no professional graphician will
>: do a scene using those math primitives. Just take any 3d modelling
>: program and try to find a perfect sphere primitive... they will output
>: a triangle mesh or a nurbs surface... :P
>: Of course all the features I added in my wish list where intended to
>: make povray a "professional" level raytracer.
>
> I don't understand why making a program "professional" means in practice
>removing 90% of its functionality, devolving it to a degree that no-one can
>use it directly.
Read my previous post... I'm not telling you to remove anything, just
to switch the priority list...
> POV-Ray supports very fast meshes. What else do you want? Use your bloody
>modeller and make all the meshes you want, then render them with povray. What
>else do you want?
Meshes are really not enough... At least I should have nurbs surfaces
(yep it's different, as having direct nurb support in the renderer
means that it will adjust tessellation adaptively, I can't
retessellate my model every frame if it's near or far from the
camera...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
