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

<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