 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 05 Dec 2001 20:21:23 GMT, ken### [at] uniplan it (Angelo 'kENpEX' Pesce) wrote:
> Just take any 3d modelling program ...
...
> make povray a "professional" level raytracer
Are you talking about pov as modeller or raytracer ? IMO It is rule of modeller
to represent nurbs, spheres etc. as meshes. It is rule of raytracer to support
meshes and primitives. POV is raytracer not modeller.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0ea20f.10207128@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) 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... 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!)?
The function VM in 3.5 is exactly that. It would even support hooking in a
really just-in-time compiled function, if any team member would have the
time to write a JIT. As you know, Sun took years to develop their JIT, but
unfortunately the JVM/JIT combination is not appropriate for functions
because it is optimized for "abstraction" (I can't think of a better work
also abstraction isn't what I really want to say) rather than maximum speed.
To design a VM and JIT which is optimized only for speed of basic operations
has, afaik, not ever been done so far. Even worse, there is hardly any
literature about VM and JIT compiler design. As you see, with the resources
and knowledge available today are limited, and you can't expect the POV-Team
to do all the necessary research in their free time...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0eb820.15856185@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> As my main hobby is optimizing stuff, I know that it's really hard :P
Keep in mind this famous quote:
"We should forget about small efficiencies, say about 97% of the time;
premature optimization is the root of all evil." - Donald E. Knuth
POV-Ray is only 15 years old, many of its features are even younger. We
should really not start to optimize for the little things before all the
code has been cleaned up.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
: Is it like "all platforms are windows and need aupgrade to xp" ?
Yes, and everyone uses MS Word as text editor (so sending them .doc files
is always ok). And of course every "professional" graphician uses Photoshop.
Every person in the world also uses IE to surf the web and OE to read their
email.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
I'm not telling that they wasted 10 years at all... As I stated
somewhere else in this postings, I admire many pov-ray artists. But
imho povray does not support the "other" type of modellers too... Now
I call this high-end just because this is the kind of stuff U see in
movies etc, but call it as you may think it's better, I'm only saying
that as I'm a softimage user, and many (many) other ppl use maya, or
3dsmax (bleah!), povray should support them better
>> 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.
As I already told U support for meshes is not enough... And I know
that I could make a patch and enjoy nurbs in povray, but as I have to
make a patch to enjoy nurbs in povray I'm saying here "please try to
support nurbs too"... :)
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)
Ok, I see that with this stuff U can do a lots of intresting things.
I'm not telling U remove primitive support in povray and do only nurbs
or subsurfs, I'm saying do them too...
>> nowdays everything is modelled with nurbs, subdivision surfaces and polygons
>Is it like "all platforms are windows and need aupgrade to xp" ?
No it's not like that... It's more like, as many ppl use windows
(replace windows with anything else, that's popular), should I support
windows too?
>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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<abx### [at] babilonorg> wrote:
>On Wed, 05 Dec 2001 20:21:23 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> Just take any 3d modelling program ...
>...
>> make povray a "professional" level raytracer
>
>Are you talking about pov as modeller or raytracer ? IMO It is rule of modeller
>to represent nurbs, spheres etc. as meshes. It is rule of raytracer to support
>meshes and primitives. POV is raytracer not modeller.
Mhmm... I think that the raytracer should support those surfaces
directly as it's hard for a modeller to do accurate tessellation. I
know if I have only one big nurbs model and an infinite plane, i can
use max tessellation and go with this... But if I have a complete,
complex scene, with many nurbs characters and a complex background, I
don't want to alter manually the tessellation parameters for every
object if it's far away or near the camera...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Dec 2001 19:28:54 -0500, Ron Parker <ron### [at] povrayorg>
wrote:
>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.
Mhm, why asm-optimization where not acceptable, and something that
involves translating stuff into native-code asm is acceptable now?
>> 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."
From the povray VFAQ:
The ***trick*** is to use averaged textures with differing normals:
When POV-Ray calculates the color of an averaged texture map, it has
to calculate the color of each texture individually before it can
average them. If the textures are reflective, it has to shoot a
reflected ray for each texture in order to get its color. The trick
exploits this behaviour in order to achieve blurred reflection by
shooting many reflected rays: The idea is to create many identical
textures but with slightly differing normals and then average them,
which causes POV-Ray to shoot a reflected ray for each one of them.
So you can implement this ***trick*** like this:
#declare BlurAmount = .2; // How blurred the reflection should be
#declare BlurSamples = 40; // How many reflected rays to shoot
object
{ MyObject
texture
{ average texture_map
{ #declare Ind = 0;
#declare S = seed(0);
#while(Ind < BlurSamples)
[1 pigment { ObjectPigment } // The pigment of the object here
finish { ObjectFinish } // The finish; should have
reflection
normal
{ bumps BlurAmount
translate <rand(S),rand(S),rand(S)>*10
scale 1000
}
]
#declare Ind = Ind+1;
#end
}
}
}
>> 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.
I know that this is more a stuff for 3rd party developers... But since
is a so important feature mabye it should be in the povteam todo
list... (also because I know that if a 3rd party dev. will make that
tool surely U won't add it to the current distro, even if it's so
important... Mhmm)
>> 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?
Flame war... it seems too much for a simple, polite, discussion about
some topics of povray development... Well if someone here thinks that
this is a flame war I'll go away, that wasn't my objective, and if I
have to flame to say my opinion about povray features, and to say that
imho there is something that is still lacking, well I really don't
want to...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>: 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... :)
I'm not depressed at all... But since it's impossible to see a tech
faq, a document about inner workings, a to-do or a wish list and
everything seems so "secret" to me, how could I know that those where
already features somewhat planned or that pov-team was aware of
them?????
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Dec 2001 11:13:27 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> I'm only saying
> that as I'm a softimage user, and many (many) other ppl use maya, or
> 3dsmax (bleah!), povray should support them better
But ... povray supports them better.
Povray has well documented SDL which is independent platform for modelers.
Moray works this way, many apps work this way.
IMO it is not rule of pov-team to write good plugins for other apps to export
scripts. IMO it is politic of high-expensive apps to not support _free_
renderers. But it is personal opinion.
> > > 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.
>
> As I already told U support for meshes is not enough... And I know
> that I could make a patch and enjoy nurbs in povray, but as I have to
> make a patch to enjoy nurbs in povray I'm saying here "please try to
> support nurbs too"... :)
Does 3ds (or other apps) support nurbs during tracing or generate triangles
first and then perform rendering ? Why pov should support nurbs when modelers
has implemented conversion from nurbs to triangles ? I don't want to say it
shouldn't. I just think there are more important problems belonging to tracing.
With good paper I can implement nurbs via macros. With functions{} I have nearly
shader. I can't improve radiosity or media with macros or functions.
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
|
|
| |
| |
|
|
|
|
| |
|
|
