in news:418ac51b$1@news.povray.org Florian Brucker wrote:

> If you add a exec-command (to execute external programs), it would 
> enable us to write the database support as a inc-file, a method which
> I would prefer (not dependant on database-type, etc.). Of course 
> introducing an exec-command creates a big new potential for malicious
> pov scripts.

There was a patch by Dan Connoly (will he ever finish his bike-shop?).
It made it into the superpatch and was removed in later versions
because of security. 

Very often I wished there was still such an option, but when you think
a bit about what you want to achieve in a scene, it is almost always
possible to do it with the pre/post/scene/frame commands. About the
only exception is if you want external programs to do things based on
random based featuure of SDL during parsing the scene itself. Even if
there was an exec option, it would still be "tedious" to start and stop
an external application many times until you have the desired result. 

Would it technically be possible to add some kind of dynamic pipeline
exec thing to POV-Ray? So you can call an application once and if it
needs some more data it just asks "Hey POV, shoot a ray in that
direction and return me the following data ..." until a final
conclusion is reached and it can return the right data back to SDL. 

Regarding databases, a few months ago I did a few ultra simple tests 
using POV-Ray to write SQL to a file, then use the post frame command to 
start a Python script that reads it an queries the database. Then this 
script does something with the resulting data and writes it as a SDL 
parsable script to file. 


Ingo

Post a reply to this message

in news:cjameshuff-66B0E8.20321304112004@news.povray.org Christopher
James Huff wrote: 

> I don't see why it would be any better than simply allowing the user
> to keep a data structure for the next frame. What benefit does a
> database give you?

I don't realy know, that's why I'm asking. 
 
> No, it wouldn't benefit particle systems. A general database system 
> would be too slow for that kind of thing.

I can see that it would be slower than some dedicated particle program,
would it also be slower than an SDL implementation. What if we're
dealing with "millions" of spheres bouncing down a mountain? SQLite can 
keep the database in memory, so no disk action to slow us down.

> However, some more versatile data structures (easily modifiable
> arrays, lists, sets, and dictionaries) would be very useful. Also
> things like point sets and other more specialized structures...

They are high on my ever growing POV-whislist, especialy dictionaries. 


But what I'm realy interested in is, what could an embedded (or ODBC) 
database add to POV-Ray. 

Ingo

Post a reply to this message

in news:418bb6fd$1@news.povray.org Darren New wrote:

> I would think it would be more helpful in POV-Ray 4.x or later, where 
> one could (for example) query a database for a collection of points and 
> turn them into a mesh more easily.

Mesh' is one of the thing I thought about. What if I put all the mesh data 
in a database. Could I optimese a mesh2 faster there than by doing it in 
SDL? A specialised program, like Warp's meshcompressor would be even 
faster.

What about modifing mesh's? Connecting vertices with bones and moving 
those?

Would a database be an intermediate between a pure (slow) SDL script and a 
dedicated (fast) external program in cases where is dealt with a lot of 
data?

Just interested,

Ingo

Post a reply to this message

In article <418bbfba$1@news.povray.org>, jbe### [at] ifrancecom says...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Patrick Elliott wrote:
> | Except databases go beyond simple I/O. For instance, a smart system
> could
> | read in the contents of a .inc file to the database (or the
> equivalent),
> | which will only be used in an animation in say 50 frames out of
> 100, then
> | only read that back in from the DB 'when' it is needed, rather than
> | parsing the entire file each time. I suspect that is a bit harder to
> | manage currently, if it is even possible.
> 
> 	You mean, something like that?
> 
> #if ((clock > 0.25) && (clock < 0.75))
> ~  #include "foo.inc"
> #end
> 
Wasn't sure if you could or not. Still, there may be other cases..

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <Xns9598D42098418seed7@news.povray.org>, ing### [at] tagpovrayorg 
says...
> in news:418bb6fd$1@news.povray.org Darren New wrote:
> 
> > I would think it would be more helpful in POV-Ray 4.x or later, where 
> > one could (for example) query a database for a collection of points and 
> > turn them into a mesh more easily.
> 
> Mesh' is one of the thing I thought about. What if I put all the mesh data 
> in a database. Could I optimese a mesh2 faster there than by doing it in 
> SDL? A specialised program, like Warp's meshcompressor would be even 
> faster.
> 
> What about modifing mesh's? Connecting vertices with bones and moving 
> those?
> 
Yep. That would be a big one. Static data is easy enough to deal with, 
but even writing out to a file to re-read the next time through has 
disadvantages, not the least which being the shear number of files you 
end up with if you wanted to be safe and place every object, texture, 
etc. in its own separate include. You might have to animate or modify any 
one of them. Its not impossible to do now, just often extremely 
inconvenient.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <Xns9598D30B5E378seed7@news.povray.org>,
 ingo <ing### [at] tagpovrayorg> wrote:

> > No, it wouldn't benefit particle systems. A general database system 
> > would be too slow for that kind of thing.
> 
> I can see that it would be slower than some dedicated particle program,
> would it also be slower than an SDL implementation. What if we're
> dealing with "millions" of spheres bouncing down a mountain? SQLite can 
> keep the database in memory, so no disk action to slow us down.

Unless the SDL data structure is very poorly designed...I don't think 
the array implementation is that terrible, and it could be fixed if it 
were. Accessing a built in array structure will be faster than a 
database query. Databases are vastly more powerful, but you don't need 
any of their features for a particle system, and they come at a cost in 
efficiency.


> > However, some more versatile data structures (easily modifiable
> > arrays, lists, sets, and dictionaries) would be very useful. Also
> > things like point sets and other more specialized structures...
> 
> They are high on my ever growing POV-whislist, especialy dictionaries. 

It would allow something that someone else mentioned, a kind of 
user-defined structure...just define your structures as dictionaries, 
with the name of a member being its key. You could easily extend this to 
allow JavaScript style objects. You could even extend it to all the 
built-in objects.


> But what I'm realy interested in is, what could an embedded (or ODBC) 
> database add to POV-Ray. 

I don't think it'd add anything. The two things I can think of are 
building a scene from data already in a database, and filling a database 
with data generated during scene parsing. Both could be easily done with 
file I/O and/or external scripts. (Though I do think that also needs to 
be improved.)

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

A better use for "is" might be checking whether two objects are really 
references to the same one. The more traditional word is "isa":
if(SomeObject isa union)

Also, the parentheses around the foreach parameters don't really do 
anything. Anyway, an alternative I prefer uses a structure called a 
block which is similar to a function passed as a parameter. A syntax 
based on C++ or Java might look a bit like:

MyUnion.foreach( #(Obj){...do stuff with Obj} );

The thing is, this gives you many more possibilities. You could create 
foreach() methods for your own data structures, you could use blocks to 
give comparison functions to sort algorithms, etc...

If numbers are first class objects, that makes some other things much 
easier as well. Say you have a .. operator that makes a list from a 
given start and end value:

(3..7).foreach( #(n){debug(n)} );

Or say numbers have a "times()" method that calls a block n times:

5.times( #debug("Hello!") );

Personally, I prefer the syntax I used in Sapphire, based off languages 
like Self and Smalltalk:

(3..7) foreach: #(n){debug(n)};

5 times: #debug("Hello!");

However, this is likely to just look too weird to most people...took me 
a while to decide I preferred it. It tends to be more self documenting, 
though:

foo.setColorRGB(0.2, 0.6, 0.8);

would translate to:

foo setColorR:0.2 G:0.6 B:0.8;

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

> MyUnion.foreach( #(Obj){...do stuff with Obj} );
[...]
> (3..7).foreach( #(n){debug(n)} );
[...]
> 5.times( #debug("Hello!") );

Even Better!

> foo.setColorRGB(0.2, 0.6, 0.8);
>
> would translate to:
> 
> foo setColorR:0.2 G:0.6 B:0.8;

Hm. Looks strange :) I think the missing brackets make it harder to 
read, even with this pretty simple expression. But your example looks 
like it supports named parameters, that's a nice thing, coupled with 
optional parameters:

#macro MyMacro(Length,Height,Width,optional Color) #end

MyMacro(Length = 10, Width = 5, Height = 3)
MyMacro(Length = 10, Color = rgb .5, Width = 5, Height = 3)


Florian
-- 
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/

Post a reply to this message

In article <418ccc45$1@news.povray.org>,
 Florian Brucker <tor### [at] torfboldcom> wrote:

> > foo.setColorRGB(0.2, 0.6, 0.8);
> >
> > would translate to:
> > 
> > foo setColorR:0.2 G:0.6 B:0.8;
> 
> Hm. Looks strange :) I think the missing brackets make it harder to 
> read, even with this pretty simple expression. But your example looks 
> like it supports named parameters, that's a nice thing, coupled with 
> optional parameters:
> 
> #macro MyMacro(Length,Height,Width,optional Color) #end
> 
> MyMacro(Length = 10, Width = 5, Height = 3)
> MyMacro(Length = 10, Color = rgb .5, Width = 5, Height = 3)

It actually developed this way:
I'm most used to C++, so I'll do it like this:

foo.setColorRGB(0.2, 0.6, 0.8);

Hmm, named parameters would be useful, and would give a useful 
equivalent to overloading:

foo.setColor(R: 0.2, G: 0.6, B: 0.8);

You know, that part of the name outside doesn't really need to be 
divided from the part inside...

foo.(setColorR: 0.2 G: 0.6 B: 0.8);

That looks weird, and the dot isn't really needed. If I just take it out 
though, it'll look too much like a function call. Here we go...

(foo setColorR: 0.2 G: 0.6 B: 0.8);

Ah, the parentheses don't give anything to single statements, so make 
them optional.
Huh. Looks a lot like Objective C and Smalltalk.

(Actually, the last two syntaxes are both allowed in Sapphire.)

However, the method you suggested has one possible additional benefit: 
you can specify the parameters in any order. Especially useful when 
there are several default parameters...C++ requires you to specify all 
parameters up to the last one specified, this would allow you to skip 
them when the defaults are fine.

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

Gilles Tran wrote:

> 
> 
> I have wondered several times about a built-in ODBC connectivity in the SDL 
> (rather than an embedded database). 
> 

And a CVS client ;)

Post a reply to this message