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).
 

> >
> >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 !

> 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.

> 
> >: 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.

> 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. 

> 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.

> 
> >: 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. 


> 
> >: 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!
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!)

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).

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!


> 
> >: 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.

> 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.

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...

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