 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 06 Dec 2001 13:09:24 +0100, "Thorsten Froehlich"
<tho### [at] trf de> wrote:
>In article <3c0f53e6.788389@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> 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...
>
>Ah, so the modeler can't do good tessellation and POV-Ray should magically
>be able to do a better job with the same input data?
Yes it should. Just because it's impossible for the modeller to do a
really good work, and because even if it's possible, you'll end up
with a gigabyte script and huuge parsing times even for a small
animation. That's why *nearly all* raytracers used with nurbs
modelling tools support directly nurbs as I demonstrated in another
post
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f558d.1210938@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> Mhm, why asm-optimization where not acceptable, and something that
> involves translating stuff into native-code asm is acceptable now?
It isn't that hard to understand, really...
Lets say you have a function foo. You want to write it in assembler. So
you end up with an assembler version of function foo that has to be in the
source code, right? For each and every platform you need this, and you need
to clutter all the code with it.
Contrary to this, a JIT compiler works on a provided intermediate data. It
is very clean to interface the intermediate format interpreter/VM with a
platform specific optional compiler. You do not need to clutter the source
code of every platform. And you force no platform dependent code into the
platform independent code.
Get the difference?
Of course, somebody previously told you the answer to this already: If you
can improve an algorithm, from say O(n^2) to O(log n) you gain far more than
one or two percent you would get from writing the O(n^2) algorithm in
assembler. However, with assembler you introduce unnecessary and unreadable
clutter for no good reason this way.
Get the difference now?
If not, try to think about Donald E. Knuth's famous quote again.
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 <3c0f558d.1210938@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
>>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:
I think he won that argument, Warp ;-)
While we are at it, I also noticed you sometimes use the politically
incorrect term "source code" for what should be called "scene description"
in your FAQ:
We don't want to confuse new users who read the FAQ to think "source code"
== "programming" == 'post in povray.programming' as we see it happen from
time to time, do we? :-) :-) :-)
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 Thu, 6 Dec 2001 12:42:12 -0500, Alessandro Coppo <a.c### [at] iolit> wrote:
> It came to me that displacement mapping is almost like isosurfaces. For
> example, a displacement mapped sphere is an isosurface described by
> a sphere + displacement function. So I would not call it impossible (or
> only for meshes) but "just" computationally heavy.
Displacement mapping is also partially possible with primitives without
transformation to meshes or isosurfaces. I made deform-patch last year and it
worked just like transformations are performed. It curves ray instead of
geometry. But as I said it were partialy possible becouse it required
"bi-directional" displacements.
http://news.povray.org/povray.binaries.animations/15150/
http://news.povray.org/povray.binaries.animations/15155/
http://news.povray.org/povray.binaries.animations/15156/
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 <3c0f558d.1210938@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> Mhm, why asm-optimization where not acceptable, and something that
>> involves translating stuff into native-code asm is acceptable now?
>
>It isn't that hard to understand, really...
>
>Lets say you have a function foo. You want to write it in assembler. So
>you end up with an assembler version of function foo that has to be in the
>source code, right? For each and every platform you need this, and you need
>to clutter all the code with it.
so let's say that I have mhm affine.c code in the source tree... doing
this i'll "clutter" the source by adding an affine_486.s, affine_586,
affine_mac etc... ok, right...
>Contrary to this, a JIT compiler works on a provided intermediate data. It
>is very clean to interface the intermediate format interpreter/VM with a
>platform specific optional compiler. You do not need to clutter the source
>code of every platform. And you force no platform dependent code into the
>platform independent code.
so let's say that I have an interpreter.c code in the source tree. jit
means that I need also, for some plattforms, a jit_x86, a jit_mac, a
jit_amiga etc... mhm no I feel stupid, I can't catch the difference
>Get the difference?
>Of course, somebody previously told you the answer to this already: If you
>can improve an algorithm, from say O(n^2) to O(log n) you gain far more than
>one or two percent you would get from writing the O(n^2) algorithm in
>assembler. However, with assembler you introduce unnecessary and unreadable
>clutter for no good reason this way.
Of course. We agree. It's fine. But after U implemented something that
looks *final* why you can't do the second step?
>Get the difference now?
>If not, try to think about Donald E. Knuth's famous quote again.
Premature. Now I want to know, are U going to change ray-sphere
intersection? Do U see new techniques to do 3d vector cross product?
dot product? Matrix-vector product? I agree mabye it's premature to
optimize new algorithms or something that is still in research stage.
But how about the kernel math routines? Mabye I'm blind but I don't
think that optimizing such routines is asm (routines that are used
everywhere in the code and that could lead to a general speedup) is
premature not dumb... And if U think that using asm in basic 3d math
routines will not give U a reasonable speed up because the compiler
know how to do everything, well I can give U some of my code and you
can re-do some checks that I have already done...
> 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 <3c0f56d1.1535610@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> 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?????
The source code is open for you to see, so there is no secret.
I think this thread alone is a very good example to explain why there is no
completely open discussion of the development of POV-Ray or a completely
open development. There would simply be too many people who only tell those
who actually implement feature that something is easy or that it should be
implemented this way or that way. However, so rarely do the people who do
all the discussion actually do any work. They just keep everyone from
working while contributing nothing usable.
To summarize my, and only my opinion, which has been formed based on the
many, many discussion that went like this one, from the newbies with three
month of programming experience thinking they can help, from those who
distributed some of the messiest source code I have seen as patch for
POV-Ray, I say:
With the kind of help that is offered it will be really difficult to adopt a
more open development model for POV-Ray 4.0. With public contributions of
the current quality, unless constantly verified by others (read: the
POV-Team) we would end up with an insane mess and nothing remotely useable
as a ray-tracer.
Yes, this is my opinion. I won't change it. I am just letting everybody know
what I see as a major problem.
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 <3c0f58f7.2085159@news.povray.org> , ken### [at] uniplanit (Angelo
'kENpEX' Pesce) wrote:
> Well mabye this is the politic of high-expensive apps (dunno, I don't
> see this politic, but mabye it is, or if it isn't it will be :P), and
> I know that pov-team should not work to maya or softimage exporters.
> But they could extend the SDL so that writing such exporters is easier
> and comfortable...
But there is absolutely no feature missing in POV-Ray that you would need to
successfully export those formats to POV-Ray. If nodboy has done it so far
you can hardly blame POV-Ray for it.
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 Thu, 06 Dec 2001 13:23:48 +0100, Thorsten Froehlich wrote:
> In article <3c0f558d.1210938@news.povray.org> , ken### [at] uniplanit (Angelo
> 'kENpEX' Pesce) wrote:
>
>>>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:
>
> I think he won that argument, Warp ;-)
Except he was replying to me, and I created this so-called "trick." It's
not a trick.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c0f5c5b@news.povray.org> , Alessandro Coppo <a.c### [at] iolit>
wrote:
> little more than 20/40 lines
You obviously never looked into the POV-Ray source code. Hardly any of the
proceduaral textures (which is _basically_ what you call shader) is complex
at all. They are very simple 5 to 20 line C functions, even the fractal
patterns are...
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 <3c0f56d1.1535610@news.povray.org> , ken### [at] uniplanit (Angelo
>'kENpEX' Pesce) wrote:
>
>> 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?????
>The source code is open for you to see, so there is no secret.
I know what there is into povray, I wanted to know where povray will
go...
>I think this thread alone is a very good example to explain why there is no
>completely open discussion of the development of POV-Ray or a completely
>open development. There would simply be too many people who only tell those
>who actually implement feature that something is easy or that it should be
>implemented this way or that way. However, so rarely do the people who do
>all the discussion actually do any work. They just keep everyone from
>working while contributing nothing usable.
I agree with you... you're right... But an interface between povray
team and povray users is necessary, otherwise how can U know that a
feature is more or less wanted? The first problem that I see is that I
can't know the future of povray development... I U tell me, we are the
developers, we will do x,y,z and we can't change our mind now, if U
want p,q,r do it yourself I can accept this. But if I don't know what
are the plans for the next povray how can I make a good choice?
Better, I think povray team should tell via a faq that:
we will do x,y,z
we are thinking to do l,m,n but it's hard because of...
we will not do p,q,r because of...
if U want that do it yourself
So I will know not only what you're doing but also why you're not
doing something else, and I can propose U to do things only if they
are not in the todo/nottodo list... Also if I have (I or someone else
this is obvious) an idea on the l,m,n things that solve a problem and
make them more easy, I can tell U... Is this wise? I think so...
>To summarize my, and only my opinion, which has been formed based on the
>many, many discussion that went like this one, from the newbies with three
>month of programming experience thinking they can help, from those who
>distributed some of the messiest source code I have seen as patch for
>POV-Ray, I say:
>With the kind of help that is offered it will be really difficult to adopt a
>more open development model for POV-Ray 4.0. With public contributions of
>the current quality, unless constantly verified by others (read: the
>POV-Team) we would end up with an insane mess and nothing remotely useable
>as a ray-tracer.
I'm not a povray developer so I can't discuss about that. I don't care
to discuss about that too. there are many "open" projects, povray is a
bit more "closed" but hey, that's not my project, I can't decide...
>Yes, this is my opinion. I won't change it. I am just letting everybody know
>what I see as a major problem.
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
