Tyler Eaves <tyl### [at] NOSPAMml1net> wrote in 
news:pan### [at] NOSPAMml1net:


> 
> 8. A C(++) API
>     This is another way of acheiving some of the above speed-related 
>     goals. Allowing creating a pov-scene by linking against the API,
>     giving code that builds a binary to render the scene. The ultimate
>     for CPU intensive stuff.
> 

I would much rather see the perl module povray.pm ;)

use povray;
my $result = povray->render(  AA => 0.3,
                              AM => 2,
    	    	    	    	    	etc, etc...
                           );



-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:4058306d@news.povray.org...
> John VanSickle <evi### [at] hotmailcom> wrote:
> > POV-Ray is a renderer.
>
>   POV-Ray is more than a renderer.
>

yes, POV-Ray is a modeler

*ducks*

Post a reply to this message

Hi Christopher James Huff, you recently wrote in povray.general:

> Not really practical, at least not in the way you describe. It would be 
> either extremely slow or outrageously memory consuming, or both. 
> Lightwave probably uses some form of scanlining for this, and just 
> refines lighting maps...POV can not do this, being a raytracer and not 
> using light maps.
Actually it also raytraces. Take a look here
http://www.worley.com/fprime.html
Specifically, the 2nd movie. As for being slow.... well this plugin is
absolutely amazing, at least from the demos...

It's sort of a Mosaic mode on steroids.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

In article <4057ea45@news.povray.org>, tho### [at] trfde says...
> In article <MPG.1ac147e51c2d571d9899e7@news.povray.org> , Patrick Elliott 
> <sha### [at] hotmailcom>  wrote:
> 
> > One thing that would be very helpful in byte code is 'parse once, run
> > multiple times'.
> 
> This is impossible with the current POV-Ray SDL because it offers
> self-modifying and self-generating capability.
> 
Self modifying isn't necessarily a major problem, "if" done right. The 
problem with the existing implementation is that it can't really do so. I 
wouldn't say self modification *and* bytecode is an impossibility. Most 
things like Java and VBScript use byte code too. 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.

It does admittedly complicate things I admit.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

> I would much rather see the perl module povray.pm ;)
> 
> use povray;
> my $result = povray->render(  AA => 0.3,
>                               AM => 2,
>     	    	    	    	    	etc, etc...
>                            );
> 
> 
> 

Good idea. Shouldn't be such a great problem, though. Except you want 
some really fancy features like inserting every object via Perl:

povray->scene->add_sphere(0,1);

Even that would be possible, but don't worth the effort IMHO. A module 
for calling POV-Ray with different options would be fine. Nice features 
would also be OO-access to the stats etc. Perhaps it's time to do some 
Perl again :)

Florian

Post a reply to this message

Warp wrote:
> 
> John VanSickle <evi### [at] hotmailcom> wrote:
> > POV-Ray is a renderer.
> 
>   POV-Ray is more than a renderer.

It's a way of life!

> Besides, what's wrong with wanting POV-Ray to be faster? I thought we
> all wanted that.

I didn't say I objected to POV-Ray running faster; my point, which I
should have stated more explictly, is that given the limited lifespan
of the average POV-Team member, their time may be better spent on
things dealing with rendering, rather than parsing.

Regards,
John

Post a reply to this message

On Thu, 18 Mar 2004 17:37:01 -0700, John VanSickle wrote:

> Warp wrote:
>> 
>> John VanSickle <evi### [at] hotmailcom> wrote:
>> > POV-Ray is a renderer.
>> 
>>   POV-Ray is more than a renderer.
> 
> It's a way of life!
> 
>> Besides, what's wrong with wanting POV-Ray to be faster? I thought we
>> all wanted that.
> 
> I didn't say I objected to POV-Ray running faster; my point, which I
> should have stated more explictly, is that given the limited lifespan
> of the average POV-Team member, their time may be better spent on
> things dealing with rendering, rather than parsing.
> 
> Regards,
> John

I'm not so sure that's true. The rendering engine has gotten to the point
where you practically have to *be* a POV-Team member to know all the
capabilites, much less understand them. Faster parsing helps everyone,
especially those of us who like toying with animation.

Post a reply to this message

Tyler Eaves <tyl### [at] nospamml1net> wrote:
> The rendering engine has gotten to the point
> where you practically have to *be* a POV-Team member to know all the
> capabilites

  Actually I wouldn't be surprised if not all team members know every
single detail POV-Ray is capable of... not deeply enough to use it
fluently, at least... :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <405abcf0@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Actually I wouldn't be surprised if not all team members know every
> single detail POV-Ray is capable of... not deeply enough to use it
> fluently, at least... :)

But we know where to look things up in the manual, so nobody ever sees us
asking questions ;-)

    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 <9evh50h8d2std7lnadaihmkncf219vig1r@4ax.com>,
 Lutz Kretzschmar <lut### [at] stmuccom> wrote:

> Actually it also raytraces.

Well, it certainly uses scanline algorithms heavily. The type of 
radiosity in POV Ray can give very different results at lower qualities, 
you'd have to re-render the image after refining the radiosity data.


> Take a look here
> http://www.worley.com/fprime.html
> Specifically, the 2nd movie. As for being slow.... well this plugin is
> absolutely amazing, at least from the demos...

You can easily tell that the main rendering uses scanlining by the fact 
that it renders the scene object-by-object. Raytracing is probably just 
another layer that gets composited in...this isn't the case for POV.

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 
would require a lot of re-raytracing, and I have doubts about the 
photons...adding to a kd-tree is a problem, though there is a bkd tree 
that could solve this problem. You could do it in stages, producing 
progressively higher quality renders, but that would require either very 
good planning or a very smart adaptive algorithm to avoid wasting time 
on things that make no difference. Perhaps "fingerprinting" the scene by 
rendering a few hundred pixels from it to compare with previous versions 
would work.

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