 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0e9dcf.9118910@news.povray.org> , ken### [at] uniplan it (Angelo
'kENpEX' Pesce) wrote:
>>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...
No, I can't. In fact I would probably be the front line getting all the
annoyed or confused Mac users when they find a scene that doesn't render.
Of course they would want me to port it. Now imagine some idiot designing a
module for Windows using some Windows API functions (if they are useful or
needed, is not up to me but to the idiot). Those scene would no longer work
anywhere but on Windows. What a perfect world that would be - there would
be no more portability concerns ;-)
Or, maybe I should draw a line in the sand and say:
This feature will only make it into POV-Ray over my dead body!
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 23:32:40 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>In article <3c0e9dcf.9118910@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>>>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...
>
>No, I can't. In fact I would probably be the front line getting all the
>annoyed or confused Mac users when they find a scene that doesn't render.
>Of course they would want me to port it. Now imagine some idiot designing a
>module for Windows using some Windows API functions (if they are useful or
>needed, is not up to me but to the idiot). Those scene would no longer work
>anywhere but on Windows. What a perfect world that would be - there would
>be no more portability concerns ;-)
>
>Or, maybe I should draw a line in the sand and say:
>This feature will only make it into POV-Ray over my dead body!
> POV-Ray on the web: http://mac.povray.org
Ok, I understand that there are problems with it, but as this is a
really needed feature imho we should try to find a workaround... Why
not trying to make a fast, compiled script support (in a
meta-bytecode, like renderman). Or better, why not integrate renderman
shader support into povray (povman rulez!)?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mhmmm I got many, many interesting replyies to my post, even more than
I expected. Sorry for the (small) flames, sorry for some lame
questions and for my bad english... I feel it's time to update my
personal wish list now, so I'll repost it :P
1) Programmable shaders
So I've understood that having something like compiled-plugins is not
possible with povray... Now what? the only alternative I can think of
is making them with scripts, mabye supporting directly the renderman
specification (povman is great)... The problem with this is that's
really really harder to do, and to do it fast! Mabye a compiled script
(like renderman system) should be used, something like java-vm...
2) Focus more on rendering speed than on adding new rendering
algorithms for the future
3) Support for nurbs surfaces and subdivision surfaces, with
automatic, adaptive tessellation (rulez!)
4) Blurred reflection, I think this can be done adaptively (shoot more
rays if reflection hit is far away, or better, shoot rays until max
ray hit distance is smaller than a threshold), motion blur (really
needed for animations). I was thinking that photon mapping can be done
adaptively too, but I don't want to talk about this as I don't know
how it's going to be implemented in pov3.5. Adaptive DOF, the same
stuff as above...
5) compiled scene-scripts support. Why I added this again??? Because
it's really useful if you want to do:
6) a rendering strip distribuiton server/client tool (external) over a
tcp/ip network... It would be nice to have also things like load
balancing (if U have a faster script-loading support you can affod
subdividing the scene into fine strips to do better balancing), client
hotplugging/deplugging/error-managment, multiple scene support
7) displacement mapping
8) particle system? fur/hair system? neural-network genetic-algorithm
auto-scene-generation-system-that-even-does-the-coffee-while-waiting-for-rendering??
mabye I'm asking tooo much :P but well, if U don't ask...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
: Ok, I understand that there are problems with it, but as this is a
: really needed feature imho we should try to find a workaround...
You have still failed to explain why it's "a really needed feature".
--
#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:
: 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???
Only to spheres? You talk as if povray didn't support meshes. Or if this
support was really slow.
Well, how wrong you are, my friend!
Actually I made a little test today with povray. I downloaded a really big
model from 3dcafe.com: http://www.3dcafe.com/models/dragon3.zip
It has 100400 triangles (50204 vertices), which is a nice size to test with.
I converted it to mesh2 with 3DWin.
I made this image with povray 3.5:
http://www.cs.tut.fi/~warp/dragon.png
It took 10 minutes 30 seconds to render in my 1.2GHz Athlon.
Please note the blurred-reflecting floor (which you say is not possible
with povray 3.5).
If I turn off the blur of the reflection, then the scene takes only
4 minutes to render.
If I turn off the area lights, then it takes just 1 minute 30 seconds to
render. The resulting image is the following:
http://www.cs.tut.fi/~warp/dragon_simple.png
Carefully note the really high-quality antialiasing I used to create the
image (eg. clearly seen in the borders of the shadow of the model in the
above picture). I achieved this by using the antialiasing method 2 (with
method 1 the image above takes less than a minute to render, but the
quality of the antialiasing is visibly worse).
I rendered those images at 640x480 with +a0.3 +am2 +fn
I suppose that lightflow could reach these render times achieving at least
the same quality, but it would be really interesting to see some results.
The source of that scene (if you want to get the coordinates of the camera,
lights, floor and model) can be found at:
http://www.cs.tut.fi/~warp/dragon.zip
(Note: The zip-file is 3.5 Megs in size due to the huge mesh.)
--
#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:
: 1) Programmable shaders
A nice feature which we all look forward to having some day.
: So I've understood that having something like compiled-plugins is not
: possible with povray... Now what? the only alternative I can think of
: is making them with scripts, mabye supporting directly the renderman
: specification (povman is great)... The problem with this is that's
: really really harder to do, and to do it fast!
If PRMan and other renderers can do it fast, why not povray?
: Mabye a compiled script
: (like renderman system) should be used, something like java-vm...
Well, of course.
(Currently functions are byte-compiled and executed by a VM, so it would
really be just an extention to the current VM implementation.)
: 2) Focus more on rendering speed than on adding new rendering
: algorithms for the future
Of course speed is a really important issue. The problem is that it's not
as easy as it may sound. POV-Ray already uses very advanced optimization
techniques for speed (vista buffers, lights buffersm bounding box hierarchies,
octrees for meshes...). Getting even more speed can be really complicated,
and require quite a lot of research on high-end algorithms.
: 3) Support for nurbs surfaces and subdivision surfaces, with
: automatic, adaptive tessellation (rulez!)
Perfectly possible. Not at all improbable some day.
: 4) Blurred reflection
You can already do blurred reflection (see my other post where I show
an example). You can also make blurred refraction currently as well.
Besides, I think that the idea of not including the megapov blurred
reflection is that the team wants to implement something more general and
versatile, which can used not only for blurred reflection, but for many,
many other related things as well.
: Adaptive DOF, the same stuff as above...
Povray's focal blur *is* adaptive. What do you think those 'confidence'
and 'variance' values are for?
: 5) compiled scene-scripts support.
This is practically identical to request 1.
: 6) a rendering strip distribuiton server/client tool (external) over a
: tcp/ip network...
This has been taken into account long time ago. Be assured that every
possibility will be carefully studied. (It's not like the developers wouldn't
*want* to add support for that).
: 7) displacement mapping
Not possible.
(Well, possible for meshes, but then you need to tesselate the objects.)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Actually I made a little test today with povray. I downloaded a really big
>model from 3dcafe.com: http://www.3dcafe.com/models/dragon3.zip
> It has 100400 triangles (50204 vertices), which is a nice size to test with.
Really big? It does not seem so big to me, one of my first models
yeeeeeeeears ago (a c64, done on a p90, 8mb of ram with lightwave 4)
was only 50% of that size... Btw it's still something to test...
>I converted it to mesh2 with 3DWin.
> I made this image with povray 3.5:
>http://www.cs.tut.fi/~warp/dragon.png
>
> It took 10 minutes 30 seconds to render in my 1.2GHz Athlon.
> Please note the blurred-reflecting floor (which you say is not possible
>with povray 3.5).
Well, as U say in your faq (i believe it's yours, am I right), it is
possible using a trick... As U surely know many things are possible in
this world... For example, I could do oop with plain C, but I don't
say that C is an OOP language or that is supports OOP...
> If I turn off the blur of the reflection, then the scene takes only
>4 minutes to render.
> If I turn off the area lights, then it takes just 1 minute 30 seconds to
>render. The resulting image is the following:
>http://www.cs.tut.fi/~warp/dragon_simple.png
>
> Carefully note the really high-quality antialiasing I used to create the
>image (eg. clearly seen in the borders of the shadow of the model in the
>above picture). I achieved this by using the antialiasing method 2 (with
>method 1 the image above takes less than a minute to render, but the
>quality of the antialiasing is visibly worse).
>
> I rendered those images at 640x480 with +a0.3 +am2 +fn
>
> I suppose that lightflow could reach these render times achieving at least
>the same quality, but it would be really interesting to see some results.
I'll try to convert that and I'll tell you the resoult ok?? Or mabye
I'll do something else and send the scene to you, mabye with form
(that has a support for povray output too) as I'm experimenting with
it lately (but I've only used vivid3 to raytrace form scenes)
> The source of that scene (if you want to get the coordinates of the camera,
>lights, floor and model) can be found at:
>http://www.cs.tut.fi/~warp/dragon.zip
>
>(Note: The zip-file is 3.5 Megs in size due to the huge mesh.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Dec 2001 18:23:29 -0500, Warp <war### [at] tagpovrayorg> wrote:
>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: Ok, I understand that there are problems with it, but as this is a
>: really needed feature imho we should try to find a workaround...
>
> You have still failed to explain why it's "a really needed feature".
Because I'm sure that maaany intresting shaders will be made if we
make an easy system to do them. Just check out how many shaders you
can find for renderman, or how many shader collections there are for
raytracers that support pluggable shaders (mentalray,lightwave, or mhm
do U know/remember the essence collection for imagine??). Just think
about cloud shaders, skin (translucent) shader, special effects,
cel-look shaders, improved local reflection models... With renderman
shaders you can even replicate fur...
Also this is a feature that is not common among freeware raytracers
(and not so common among commercial raytracers too) so povray could
make another big step toward being the definitive renderer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
:> You have still failed to explain why it's "a really needed feature".
: Because I'm sure that maaany intresting shaders will be made if we
: make an easy system to do them.
The context of my comment was about makind system-dependant dynamically
loadable plugin-libraries, not shaders.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ah, by the way, I want to repeat here that I'm not really saying: pov
should be as fast or be like *paste_here_another_good_renderer*, I'm
just saying, let pay more attention to speed issue
>> Actually I made a little test today with povray. I downloaded a really big
>>model from 3dcafe.com: http://www.3dcafe.com/models/dragon3.zip
>> It has 100400 triangles (50204 vertices), which is a nice size to test with.
>Really big? It does not seem so big to me, one of my first models
>yeeeeeeeears ago (a c64, done on a p90, 8mb of ram with lightwave 4)
>was only 50% of that size... Btw it's still something to test...
>>I converted it to mesh2 with 3DWin.
>> I made this image with povray 3.5:
>>http://www.cs.tut.fi/~warp/dragon.png
>>
>> It took 10 minutes 30 seconds to render in my 1.2GHz Athlon.
>> Please note the blurred-reflecting floor (which you say is not possible
>>with povray 3.5).
>Well, as U say in your faq (i believe it's yours, am I right), it is
>possible using a trick... As U surely know many things are possible in
>this world... For example, I could do oop with plain C, but I don't
>say that C is an OOP language or that is supports OOP...
>
>> If I turn off the blur of the reflection, then the scene takes only
>>4 minutes to render.
>> If I turn off the area lights, then it takes just 1 minute 30 seconds to
>>render. The resulting image is the following:
>>http://www.cs.tut.fi/~warp/dragon_simple.png
>>
>> Carefully note the really high-quality antialiasing I used to create the
>>image (eg. clearly seen in the borders of the shadow of the model in the
>>above picture). I achieved this by using the antialiasing method 2 (with
>>method 1 the image above takes less than a minute to render, but the
>>quality of the antialiasing is visibly worse).
>>
>> I rendered those images at 640x480 with +a0.3 +am2 +fn
>>
>> I suppose that lightflow could reach these render times achieving at least
>>the same quality, but it would be really interesting to see some results.
>I'll try to convert that and I'll tell you the resoult ok?? Or mabye
>I'll do something else and send the scene to you, mabye with form
>(that has a support for povray output too) as I'm experimenting with
>it lately (but I've only used vivid3 to raytrace form scenes)
>
>> The source of that scene (if you want to get the coordinates of the camera,
>>lights, floor and model) can be found at:
>>http://www.cs.tut.fi/~warp/dragon.zip
>>
>>(Note: The zip-file is 3.5 Megs in size due to the huge mesh.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
