In article <fn8p50ta2ivd6k65j01uk2a79jouffbrna@4ax.com>,
 Lutz Kretzschmar <lut### [at] stmuccom> wrote:

> > Something like this could be done in a pure raytracer, but I don't think 
> > it can be done with POV-Ray's radiosity, reflections and refractions ...
> I agree with that, it would probably be quite hard.

There is another raytracing algorithm that only follows single rays into 
the scene, randomly choosing between reflection or refraction when 
necessary. A single ray per pixel obviously won't give very good 
results, but the idea is to do multiple rays from within each pixel, 
doing antialiasing at the same time. This could just be left to run 
indefinitely. Radiosity could be done by a type of blurred reflection, 
and the first few passes could collect data to determine which parts 
would benefit most from more rays. In theory, this method concentrates 
most rays in the more "shallow" portions of the scene, the number of 
rays not exploding with increasing depth as it would if it followed 
every reflected or transmitted ray.

Photons would still have to be generated at the beginning, and rendering 
started over when more photons are shot. The same would go for POV-style 
radiosity, which would probably be far more efficient than the blurred 
reflection method.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> I still hope Parse_String() gets replaced with an 
> internal preprocessor directive, though...it doesn't quite work 
> perfectly.

  Certainly. The current implementation is a bit clumsy.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <405cbe16@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> I remember that patch, it looked very good, I'd like to see Ember if its
> publicly available.

Not yet. I'm thinking of just shoving what I have out the door...got too 
many projects just sitting on my hard drive.


> We use a raytracer we are used to long waits :-)
> I just think dog slow is better than not at all.

I don't think you quite understood how slow I meant. Someone (Slime?) 
built a JavaScript raytracer that might make it clearer...I mean too 
slow to be practical. These languages just aren't designed for any kind 
of speed, particularly not at floating-point heavy calculations.


> The problem, when you right right down to the basics is, I would like
> it to be easier to add 'features' without the pain of having to break
> out the pov source, work out how the parser works and where to plug
> in your own code and syntax.

Well, that will almost certainly never happen. You should take care to 
design a good syntax, I see no reason to make it easier to get away 
without doing so.


> My personal interest is textures, and what I in particular would
> want was Turing complete functions, that can return colours or
> vectors or floats depending on their use and can be used anywhere
> a colour or vector or float is used. By that I mean colour functions
> could be used for pigments, vector functions for for warps. Oh
> yes and this functions should have access to as much information
> about the render as possible, not just x,y,z, the point where
> the object was placed. The vector the ray is coming from, the
> current colour of the object it the texture is layered. And
> those are the one that I can think of of the top of my head.

All of that should eventually be possible with the SDL.


> Yes SDL can be extended by someone else, but they might do do the 
> feature 'I' need.

Same goes for any other language. So what?


> > However, it would add another thing to do when porting POV to a new 
> > platform
> 
> Most of the languages already have a cross-platform embedding API's, 
> even parrot.

That doesn't matter. Even common libraries like libjpeg cause some 
trouble. Adding this would complicate the matter of building POV on a 
new platform or in a new development environment.


> > another external thing that the developers have no control 
> > over, and we would have to support it. 
> 
> As you would have to support language extensions, thats a no win situation.

Except that those language extensions would be under the control of the 
POV developers. If there's a bug, it can be fixed.


> And this is for the interpreted
> > languages you mentioned...compiled plugins *would* require a development 
> > environment.
> 
> Well there's no way compiled plugins needing a development environment
> The advantage comes form a simplified API.

I'm not sure what you're saying. Compiled plugins *would* need a 
development environment.


> Not all the scripting languages are interpreted,parrot for example is 
> JIT'ed so any language used with parrot is JIT'ed.

You are making the assumption that the JIT compiler is anywhere near as 
good as whatever C++ compiler POV is built with, and that the results 
will be at all efficient. And that the JIT is supported on all platforms.


> Difference of opinion there. I think the parser code is quite difficult 
> to get into, especially to a new pov developer. There's a sub thread 
> about it somewhere in this big thread.

It's not. Just look at what other code does to see how it works. It can 
be problematic if you're doing something unusual, but the parsing code 
for typical objects, patterns, or textures is extremely simple.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Wed, 17 Mar 2004 07:04:42 -0500, Christopher James Huff wrote:

>In article <mo6g501d7c7cm15eim39k64mhug29jjf3v@4ax.com>,
> Peter Popov <pet### [at] vipbg> wrote:
>
>> This comes up quite often and the problems with it are well known. But
>> what do you think of XML? The scene structure is internally very well
>> defined and there are no ambiguities, so XML with a proper doctype (or
>> whatever is applicable for XML that defines the various tags and their
>> parameters etc.) might actually have its use, even maybe for limited
>> exporting from POV to other formats.
>
>Bloated, the resulting files would be huge, and it adds another layer of 
>parsing. A binary format would be much faster to load, and far more 
>compact. I don't like XML...I do like the concept behind it, but I think 
>the execution sucks.

Then you will like <http://tinyurl.com/ypna3>

-- 
Andreas

Post a reply to this message

In article <naur509406budks81g7i9g12oe5cql5bhv@4ax.com>,
 Andreas Kaiser <aka### [at] nurfuerspamde> wrote:

> >Bloated, the resulting files would be huge, and it adds another layer of 
> >parsing. A binary format would be much faster to load, and far more 
> >compact. I don't like XML...I do like the concept behind it, but I think 
> >the execution sucks.
> 
> Then you will like <http://tinyurl.com/ypna3>

Well, that's more about the "everything looks like a nail" effect, 
misapplication rather than the bad design of XML, and that's not the 
first time I've seen it, but yes, I liked it...seems a bit appropriate 
to the discussion.

I wonder where POV-Script was...probably looking at something shiny. 
Maybe playing with ball bearings and an old chessboard.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Wed, 17 Mar 2004 19:01:19 -0700, Patrick Elliott
<sha### [at] hotmailcom> wrote:

>You can however insert  more code into the global scope or even 
>use some functions in the languages to dynamically change the 
>code as it runs by loading a text file and passing it to the 
>engine to execute. I have no idea how this is done though.

I use this all the time in a database engine I am using at work. It
supports stored procedures in its own funky language and the whole
thing can be compiled, but there is a language construct which allows
one to run code directly even from within a compiled file. I use this
a lot for debugging and trying out new code because it spares me from
compiling with every little change.

I think the way they do it is they include the language parser with
the virtual machine which handles the bytecode-compiled application.
Both seem to work nicely together and operate in the same scope and
namespace, so for example one can spawn a dialog at runtime, type in
some code to be executed, and resume execution, and the parsed code
will have integrated well (variables, data etc.)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On 17 Mar 2004 06:04:46 -0500, Warp <war### [at] tagpovrayorg> wrote:

>Peter Popov <pet### [at] vipbg> wrote:
>  I think that the idea of dumping an object to binary format is to
>save space and that it's very quick to load. XML does not.

XML is pretty strict grammatically and hence an efficiently written
XML parser should be quite faster than an efficiently written SDL
parser. Besides, in many situations part of the rendering code is used
for parsing. Think about grass on a hill - trace() against an
isosurface...

Think of it also from another perspective - the VFAQ about exporting
POV objects to other software. XML parsers are widely available and so
are tools for converting to various 3D formats, so eventually creating
such a converter would be made easier.

Still, just my two Eurocents' worth.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Christopher James Huff wrote:
> Bloated, the resulting files would be huge, 

But thats not the point, The ability to get scenes onto other platforms is,
and XML (no matter how bloated the files may be) is ideal.

-- 
Rick

Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037

PGP Public Key : http://pgp.kitty5.com

Post a reply to this message

In article <406004bf@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com> 
wrote:

> Christopher James Huff wrote:
>> Bloated, the resulting files would be huge,
>
> But thats not the point, The ability to get scenes onto other platforms is,
> and XML (no matter how bloated the files may be) is ideal.

To the contrary, as has been discussed in the "Random thoughts about povray
and xml" thread.

    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

Rick [Kitty5] wrote:
> Christopher James Huff wrote:
> 
>>Bloated, the resulting files would be huge, 
> 
> 
> But thats not the point, The ability to get scenes onto other platforms is,
> and XML (no matter how bloated the files may be) is ideal.

No, if there was an existing file format widely supported for this 
purpose that uses xml that would be a valid argument, if not xml would 
probably be a guarantee that hardly any program will add an import 
function for such a format when introduced by POV.

If you don't believe this give me a counterexample: an xml file format 
introduced by a free program that got accepted by commercial 
applications as an universal data exchange format.

If you are referring to xml being 'easily' translatable into arbitrary 
other formats - just write a converter for the most common proprietary 
formats.  If such a converter existed it would surely be acceptable to 
deal with GB sized xml files as in-between format but i don't see a 
chance of this happening.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message