On Tue, 04 Dec 2001 15:54:46 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
> > Are you talking about something similiar to my idea from last week in
> > povray.general, right ?
> mhm mabye I can't remember well because I've read maaaaany msgs in
> those days

http://news.povray.org/povray.general/20336/

> (I'm a newbie of this ng and this is clear as many ppl
> think that i'm just another lamer, it seems).

As a newbie (in pov-community) you shuldn't mixing so much at begining. Mostly
you are talking about things already discussed. But it seems it is privilage of
newbies.

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 4 Dec 2001 10:53:11 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  Show us some lightflow images which can't be done in POV-Ray.

I advise "lightflow" searching at povray.binaries.images first :-)

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 <3c0cc693.932849@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

> if compared to stuff like lightflow or mentalray or other renderers

Remind me, what did Softimage with Mental Ray cost again?  About as much as
a mid-sized car?  Or was is a Mercedes?

    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, 04 Dec 2001 16:01:51 +0100, =?iso-8859-1?Q?J=E9r=F4me?=
Grimbert <jer### [at] atosorigincom> wrote:

>Angelo 'kENpEX' Pesce wrote:
>> 
>> On 3 Dec 2001 16:18:05 -0500, Warp <war### [at] tagpovrayorg> wrote:
>> >  Adding more scripting support is ok, not *replacing* anything!
>
>Making easier to add more pattern should be ok, 
>but dynamic loading of binary is bad for portability, unless
> you re-implement a on-the-fly compilation of source...
> but then, you stopped doing a renderer and started making a 
>  compiler/fast interpreter (p-code ? No thanks! Java, ditto).

But this is what pixar's photorealistic renderman does, and renderman
is famous (and it's the most used renderer for film stuff) just
because of its rendering speed (==quality :P) and of its shader
support

>> >
>> >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.)
>> 
>> I know... but this is a major feature so I think it could be worth the
>> work. I know that this means to make some different implementations,
>
>Search for povman : you will see a povray derivative using shader...
>  it might be useful for developing a new pattern because you need
>  not to know the internal of povray to add and use it, 
>  but IMO the official povray should have all pattern hard-coded !
I know it... It would be really nice to have the povman system in the
main povray distro!!! Actually I don't use povray 3.1, just megapov
and povman

>> but hey, I have pov-win and it seems much different to me than
>> standard command-line pov (I'm saying, there is an effort to make
>> stuff that is non portable too).
>
>Just because MS W* lack a decent editor is not a reason to stop portability.
>The front-end might be different, but scenes render the same whatever the
>platform. you're suggesting to stop that, and that's a bad idea.
I'm not suggesting to stop that at all... Just if U have a system
without dynamic plugin support you'll have to recompile povray with
every plugin you need and then you can render every scene you want.
This is what povray *ACTUALLY* does, so using plugins will only
improve povray usability for some plattforms, but not penalize the
others, as for the others the system will remain the same (of course
there should be a way to compile a "plugin" as a plugin or not without
modifing its source...)

>> >: Also it would be nice
>> >: to improve some routines (for example, intersection tests) with asm.
>> >  And drop out portability?
>> >  Besides, you are optimizing just for ONE processor, while a compiler can
>> >optimize for any new processor in the future. Compilers are not that bad
>> >at optimizing (they often do a better job than a human, specially for larger
>> >pieces of code).
>> 
>> You can keep the portable C core and make an asm version too... 
>
>This is either the Job of the compiler, or a gigantic workload.
>By the time you will be ready with the asm version, your CPU will be out-dated.
> (Next to P4 is Itanium, which is not compatible at the instruction level !
> Just ask the Mac people how they went from the M68000 to the G4... the
> OS add to have an emulator for 68000 code and new programs had both version
> compiled until it officially says that it won't run on old mac anymore)
>Moreover, for every patch, you will have to redo the work.
Of course you should recode in asm only a few routines, that won't
change easily between versions (you know, I don't think you're going
to change the ray-sphere intersection test), also if you wrote
something for p3 you don't have to think that you've wasted work just
because p4 is out (and it have a completelly different architecture),
you have just to add (someday) the support for the new cpu. And btw
there's some ppl that goes crazy for asm optimization so there can be
a team of "assemblers" that do only this stuff, I don't think that it
will take soooo much time...

>> This
>> is what happens with many "portable" project. Speed is a major issue
>> in a raytracer as speed==quality. It's really really unuseful to add
>> new features if those features are not-useabe. 
>
>You should learn patience.
>The fact is that the more power you have, the more complex the model became.
>Rendering a sphere on a plane used to be very long, so they were rendered
>in low resolution. Nowaday, the math is the same, but the CPU runs so fast
>that you can afford multiple reflective spheres, with media and other fancy
>options. 
Nope. What I was trying to say is that it's wiser to concentrate into
optimizing a renderer than into adding more complex features. For
example, radiosity,caustics,diffraction,etc etc... are complex topics
that require hard work, but they are not really useful as they
influence just a small number of images. Photorealistic renderman is
not a raytracer, it doesn't have correct reflections as it uses
reflection mapping afaik (I don't know if pixar changed something, but
at least the prman used for ToyStory was like that and I know that
prman is not a raytracer), it doesn't have radiosity nor caustics nor
those fancy things, but it's really famous and many ppl use it. Why?
Because it's fast and U can affod doing complex scenes with it in
reasonable time (you always have a time limit if you're doing
something serious).

>> Most of povray images
>> (see IRTC etc...) have a bad aliasing (imho) because of povray is
>> still slow (if compared to stuff like lightflow or mentalray or other
>> renderers)...
>
>IRTC images are in Jpeg, so they usually suffers from jpeg artefacts.
>The constraint on file size forces to have an average compression of 6:1
> (800*600 at 24 bit is 1.4 Mega, allowed is 250 ko !), so it's hard
>to judge the anti-aliasing with that compression.
jpeg artifacts usually tend to smooth out details and add noise in the
color channels, not to sharpen edges...

>> >: Also is megapov going to die when povray 3.5 final is out?
>> >  This is a really frequently asked question. The answer is: No.
>It might just be quite the opposite: a lot of patchers are awaiting
>the final 3.5 before doing more patchs.

>> >: 6) better radiosity :P
>> >  Better in which way?
>> Well, the experimental radiosity in povray 3.1 can't be called
>> radiosity really... It's something different, a fake imho. I think it
>> should use montecarlo radiosity in the future.
>B*S*. Because the radiosity in povray is not called Montecarlo, it 
>nevertheless use a lot of random rays.
>Montecarlo is a buzzword for an heuristic which use random sample instead
>of full study. 
Yes I know but afaik povray actually uses something like path tracing
(I'm not sure, so if U can also explain me this I'll be happy, as I
could not find a tech doc on povray internals) assuming that as
diffuse lighting does not change a lot over surfaces you can subsample
this stage and do linear interpolation.You know that this is not
really correct, at least you could do some adaptative evalutation
instead of a fixed grid by using a quadtree.
 
>> >: 7) displacement mapping
>> >  Please provide the algorithms for this.
>> If noone has clues on how to do this (I don't have them yet) I can
>> search... I have a few good doc. sources and I know ppl that did this
>> stuff too
>Displacement mapping is fast only with mesh.
>So, it's easily done in the other renderers, because all they know are usually
>meshes (even nurbs rendered tends to fake the rendering by tesselating the 
>nurbs as a mesh). For them, even a sphere is a mesh!
Yes I know. This is a not so lame approach by the way... Btw I replied
to that into another post.>Once that said, I have done displacement
routine for mesh in pov.

>That's easy, you input a mesh and a displacement pattern, and end up
>with a displaced mesh. (I'm waiting for the 3.5 to finish it, because
>currently, the texture does not follow the displacement, so
>strange things happened with non-plain texture!)
Well but "those" mesh renderes don't do only that... They at least try
to do an adaptive subdivision to make displacement mapping nice :P

>Wanting to Do displacement for mathematical object (as most pov object are), 
>is a kind of abberation of the mind (No offense intended for the people 
>who did it, you are great, because It has been done also for pov, 
>it was very slow but it worked).
:) Where can I find this "abberated" pov-patch??

>The only reasonnable solution would be to transform the pov-object in
>a mesh, and then do as the other renderers for displacement.
>BUT UNDERSTAND ME WELL FIRST: I do NOT want that all the pov-object be
>transformed
>in mesh, I really like the pov approach of mathematical objects!
Mhm yes, this is a matter of taste. But I also really like the power
of displacement mapping!!! :P

>> >: 8) a small rendering strip distribuition stuff over TCP/IP to set up
>> >: small rendering farms
>> >  With standard C++?
>> Again, the same portability problem... as this is a feature that is
>> really important, but not vital at all there can be a makefile option
>> that discards it or it can be made as an external tool distribuited
>> with the standard binary package...
>It's better then to have it as an independant package, provided separately.
>Best renders farms are made by sharing the disk, and then 
>calling povray for each frame on a different machine. The biggest thing
>is knowing a machine is idle and there is something to render, while
>avoiding collision.
Mhm do U know of a tool like that for povray? It would be really
useful...

>> Just another thing... Why don't include in the standard pack a few
>> selected 3rd party tools/include files? 
>You already have a lot of demo scenes. It's even bigger in 3.5 !

>> It's not a bad idea, newtek
>> does something like this for lightwave plugins (they include a bunch
>> of freeware/lite versions of 3rdparty plugins in the main distro, they
>> are REALLY useful)...
>Translation: without them, lightwave is crap and worth nothing.
Mhm, you lightwave does not deserve those words. It's one of the best
polygonal modellers around, one of the first subdivision surfaces
modeller, one of the fastest raytracers around and imho the better
raytracer around when it comes to rendering quality (and I can
remember that DigitalDomain rated lw5.6 as the second best quality
rendered in their choice).

>May I remind you that Pov want to be free and portable.
>That means that only 3rd party include would qualify, as 
>I cannot imagine distributing the source of a restricted shareware...
Well there are MANY intresting include files that really BOOST povray
rendering power...

>I hardly mastered the include file from 3.1 after a few years,
>and it seems it will take me more time for the numerous in 3.5
> (Hopefully, the help is there, with good samples !)

>FYI, the old dkbtrace (the ancestor of povray) came with a set of
>C programs to perform some operation (such as repeating an object
>with rotation and scale to produce kind of shells). Pov has since
>evolved so as that such things can be done directly in the SDL.

Post a reply to this message

<abx### [at] babilonorg> wrote:

>On Tue, 04 Dec 2001 15:54:46 GMT, ken### [at] uniplanit (Angelo 'kENpEX' Pesce) wrote:
>> > Are you talking about something similiar to my idea from last week in
>> > povray.general, right ?
>> mhm mabye I can't remember well because I've read maaaaany msgs in
>> those days
>
>http://news.povray.org/povray.general/20336/
>
>> (I'm a newbie of this ng and this is clear as many ppl
>> think that i'm just another lamer, it seems).
>
>As a newbie (in pov-community) you shuldn't mixing so much at begining. Mostly
>you are talking about things already discussed. But it seems it is privilage of
>newbies.
Well this is normal, as I can't know that things have already been
discussed! I haven't found a povray.programming faq or any other faq
that tells users why povray has some features, why other features are
discarded and stuff like that

Post a reply to this message

Angelo 'kENpEX' Pesce wrote:
> 
> mhm mabye I can't remember well because I've read maaaaany msgs in
> those days (I'm a newbie of this ng and this is clear as many ppl
> think that i'm just another lamer, it seems).

Although i think nearly everyone who answered your postings was quite
friendly it would probably be a good idea to read some of the previous
discussions on these subjects, a lot of the things you mentioned are also
covered somehow in Warp's VFAQ:

http://www.students.tut.fi/~warp/povVFAQ/

And i think it would be good to simply accept the fact that there won't be
new features introduced that only work on a few platforms, no matter if
these cover 90% of the users or not.  Same probably applies for algorithms
that require tesselation of objects.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3c0cd249.3930998@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

>>Why make the POV download take longer when you can just go download those
>>utilities yourself if you want them by following the links from our
>>linkmaster's superb link collection?
>
> Superb but huuge. It's not easy for a beginner to navigate it as links
> are not rated

We are working on that...

    Thorsten

Post a reply to this message

In article <3c0cf075.11656238@news.povray.org> , ken### [at] uniplanit (Angelo 
'kENpEX' Pesce) wrote:

> Like java class files do? IEE754 format? Using 128bit fixedpoint math?

And then just do a fread?  Try it, and you will be very surprised.  Or look
into the JVM source code and see how easy it is...

    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, 04 Dec 2001 15:46:57 GMT, Angelo 'kENpEX' Pesce wrote:
> already did that macro or this external tool... It seems to me that
> povray is a bit slow into incorporating stuff that other ppl did for
> it (for example now you're merging megapov in the official pov source
> tree, it seems, I hope you're not recoding megapov stuff...). Btw this

Of COURSE we're recoding megapov stuff.  What, you thought it was done
right?

All of this has been discussed ad nauseum before.  I will not discuss it
further.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

On Tue, 04 Dec 2001 17:37:32 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> We are working on that...

I hope for large web update with finale 3.5 release :-)

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