 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplan it> wrote:
:> 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?
The nice thing is that even if the model had 1 million triangles, the
render time wouldn't have been significantly longer (perhaps 1% longer or
so).
(Of course the biggest overhead in a 1-million-triangles model is
the parsing time, which would be about 10 times longer, so instead of
being 10 seconds as in this case, it would be about 100 seconds...)
--
#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.
I hope so too... I know it's a bit hard to do so I don't think it will
be done soon, well at least if povray team don't want to integrate
povman patch into the official povray (that is a really really good
idea imho)
>
>: 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?
well prman is not a raytracer, that's why it's so fast... I don't have
benchmarked povman and I know that bmrt is slooow so I don't know if
"other renderers" can really do it so fast :P Btw, surely it's
doable... (plus we have to remember that povray will always be a
little slower because we can't include anything that is not
portable... like a jit-compiler system for this shading-scripts for
example)
>: 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.)
Really? I didn't know that... As I sayied in another post, I would
really like to have a tech doc about povray... :/
>: 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.
As my main hobby is optimizing stuff, I know that it's really hard :P
>: 3) Support for nurbs surfaces and subdivision surfaces, with
>: automatic, adaptive tessellation (rulez!)
> Perfectly possible. Not at all improbable some day.
This is really important imho, if we want to see povray as a raytracer
for commercial modellers
>: 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.
I know, but as U can read in another reply, you can do it via a trick,
and I don't know why I should do that via a trick...
> 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.
I hope so...
>: Adaptive DOF, the same stuff as above...
> Povray's focal blur *is* adaptive. What do you think those 'confidence'
>and 'variance' values are for?
As I told in another post, I were not sure that povray did not already
have this feature
>: 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).
Actually someone proposed to make a .NET tool... I think that a java
tool will be really good, as java has networking features and it's
portable and secure for that
>: 7) displacement mapping
> Not possible.
> (Well, possible for meshes, but then you need to tesselate the objects.)
So at last I think I made a reasonable wish list here... Who knows,
mabye someone of the pov-team will listen to my wishes somedays...
Keep up the good work...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Dec 2001 00:21:18 GMT, Angelo 'kENpEX' Pesce wrote:
> little slower because we can't include anything that is not
> portable... like a jit-compiler system for this shading-scripts for
> example)
That's where you're wrong. JIT is acceptable as a platform-specific
extension, because it doesn't keep anyone from using the shaders on
a platform that doesn't have JIT yet.
> Really? I didn't know that... As I sayied in another post, I would
> really like to have a tech doc about povray... :/
Well, it's not in the source code that's accessible to the public yet
anyway; this is a new feature in 3.5.
>>: 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.
> I know, but as U can read in another reply, you can do it via a trick,
> and I don't know why I should do that via a trick...
Define "trick." You do it via a process that very closely resembles
the actual physical process that causes blurred reflection. I fail to
see how that can be considered a "trick."
> Actually someone proposed to make a .NET tool... I think that a java
> tool will be really good, as java has networking features and it's
> portable and secure for that
Such tools are the province of third-party developers. The POV-Team
works on POV, not on the various frontends for it. It's possible that
a future version will include some sort of cross-platform TCP/IP support,
if that's feasible, but nobody's making any promises.
> So at last I think I made a reasonable wish list here... Who knows,
> mabye someone of the pov-team will listen to my wishes somedays...
You've been engaged in a flame war with at least two members of the
POV-Team, and more than one member of the POV TAG. Didn't you know that?
--
#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 5 Dec 2001 19:10:40 -0500, Warp <war### [at] tagpovrayorg> wrote:
>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.
But I always talked about shaders...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
:> You can already do blurred reflection (see my other post where I show
:>an example). You can also make blurred refraction currently as well.
: I know, but as U can read in another reply, you can do it via a trick,
: and I don't know why I should do that via a trick...
Because besides being approximately as fast as in megapov (and in special
cases even faster) it gives a better result and is more versatile?
In the dragon image I used just 15 "samples" for the blurred reflection.
In Megapov that would have been way too low (the result would probably have
been really grainy). In Megapov I probably would have to bump up the samples
to something like 50, and that would have made it really slow...
With this "trick" I also have more freedom to modify the blurring (eg. I
could make it blur more in one direction than in another, which I think is
just not possible with the megapov blurred reflection).
It also allows me to use blurred refraction for the same price (while in
megapov it had to be a completely different patch).
Sure, it takes more writing, but I don't really mind. I like the versatility.
: Actually someone proposed to make a .NET tool... I think that a java
: tool will be really good, as java has networking features and it's
: portable and secure for that
That sounds like a third-party external tool, not something to be implemented
in the core povray code.
: So at last I think I made a reasonable wish list here... Who knows,
: mabye someone of the pov-team will listen to my wishes somedays...
I don't want to depress you, but I think that all of those features have
been suggested many many times before and the team is well-aware of them... :)
--
#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 wrote in message <3c0e7d94.866669@news.povray.org>...
>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...
Please explain how to do an incremental build in VMS.
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Angelo 'kENpEX' Pesce wrote in message <3c0e80f3.1729871@news.povray.org>...
>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
http://www.stmuc.com/moray/
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 19:58:40 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> >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...
Funny answer to the author of tesselation patch :-)
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 Wed, 05 Dec 2001 20:01:56 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> > 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?
You think it is crazy, but it isn't
When you have parametric equation in 2D and you want present graph of it but you
don't know appearance of this graph it is simpler to create small spheres going
step by step with parameter. The result is fast, smooth, accurate and readable.
I have not to think about otimizations with triangles, trangle creations,
trangle normals etc. For example how can I perform experimets with parameters
with other renderes when I want create graph for such simple:
x=a*cos(b)+a*b*sin(b)
y=a*sin(b)-a*b*cos(b)
> Let's talk about real world problems, not about a scene of 1.000.000 spheres
What is the real world problems? For some people real is science. When you want
to show scientific problem (for example graph) it is best to present it as set
of spheres or boxes. Of course there are math programs to make it. But which
math soft has animation features for parameters? With focal blur for better
space representation? With complex isosurface support? Cross-multiplatform ? So,
please, leave the primitives for such usage.
> if I have to render that monster, probably I'll make my own sphere-raytracer...
Remember, not everybody has such skills. And why create another aplication when
there is application with both: accurate primitives and complex meshes ? If you
are programmer and you know algorithms for nurbs, subdivision surfaces and
polygons then you can write macros to preform this "modern features". You can
even write own patch and propose it to community if you are as smart as it
sounds. Do it and show us. If it will be good and usefull it could be
implemented in official distribution just like it was with features of MegaPOV.
> Spheres, quartics, infinite planes etc are just something used in old
> raytracing shows
Check the "advanced" folder of samples distributed with 3.5, for example
abyss.pov.
> (four sphere and a reflective checkerboard plane image? no thanks)
I can be wrong but I think that pov can render some reflective spheres over
checkered planes with features for other renderes not possible.
> nowdays everything is modelled with nurbs, subdivision surfaces and polygons
Is it like "all platforms are windows and need aupgrade to xp" ?
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 Wed, 05 Dec 2001 22:20:43 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> On Wed, 05 Dec 2001 22:00:08 +0100, "Thorsten Froehlich"
> <tho### [at] trfde> wrote:
> > 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...
I can't find any question in previous post :-)
> 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...
There are some high-end graphician in pov-community. I wonder why you are
forcing so big community to think they waste last ten years.
> Of course supporting both stuff will not hurt at all... :)
And that's what POV has. Support for meshes and primitives. Make unlimited
features with SDL or own patch and enjoy 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
|
|
| |
| |
|
|
|
|
| |
|
|
