"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

Christopher James Huff wrote:
> In article <pan### [at] NOSPAMml1net>,
>  Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:
>>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.
> 
> 
> Not practical. There is no standard way of loading object code on 
> different platforms, and the code itself would have to be compiled for 
> the platform the scene is to be rendered on. Including a compiler along 
> with POV would be a lot of effort, and distributing precompiled code 
> would create compatibility problems.

You know this one as always bugged me, the whole not practical thing.

For a guess the library author would have a compiler and it only takes
on willing person per platform to compile it for others. So that not to 
much of a problem really. The lack of a complier would only effect
people want to use a libraries features for a platform that one one has 
complied it for which is no different to those who want to use a 
Unofficial version of Pov in the same scenario.

The object code loading thing. Yes there is no standard way to do this, 
so you create one. All You'd need to do is pull back a C++ object so it 
does not need to be to complex does everything dlopen can do API. Simply 
wrap dlopen and LoadLibrary and that would cover Linux, Mac OSX and 
Windows.
something like

#define dsoOpen(x) dlopen(x, RTLD_NOW);
#define dsoGetSymbol(x,y) dlsym(x, y)
#define dsoError()  dlerror()
#define dsoClose(x)  dlclose(x)

and windows ...

#define dsoOpen(x) LoadLibrary(x)
#define dsoGetSymbol(x,y) GetProcAddress((HINSTANCE )x, y)
#define dsoError()  GetLastError()
#define dsoClose(x)  FreeLibrary(x)

If anything more fancy is required for other OS's then that
platform's dso* code become actual functions. The Mac
version could use the CFBundles? stuff directly for example.


The library exports functions that return a new instance
of a class, which inherits from a predefined povray class.
You could have a povFunction classes which return a float,
povPigment classes that return rgbft etc or one class which
has evaluateAsFloat, evaluateAsPigment etc methods

void *perlins_noise(void){
     return new myPerlinFunctionClass();
}

There will need to be extensions to SDL to..

Load the library,
Identify the class required and its type if there are different classes 
     for different functionality,
Pass the parameters to a 'setParmaters' method. Perhaps something like a 
color_map using keyed pairs.

dso {
  function
  "/path/to/library"
  "perlins_noise"
  parameter_map {
    ["octaves" 6]
    ["frequency 2.0]
  }
}

All the code is from memory so I may have got the function names or 
usage wrong, but I can't see why it wouldn't work from a technical point 
of view.

Dave

Post a reply to this message