In article <41d86f9a$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > Ah, but the parser can be used the SDL to generate multiple objects, each 
> > needing to be parsed as well.
> 
> Erm, I wouldn't think so. I think when people unfamiliar with POV-Ray 
> talk about "parsing", they're talking about basically understanding the 
> tokens in the source and the syntactic interrelationships between them.
> 
Well.. Yeah, but I am trying to describe 'why' it takes a lot of time. 
Even tokenizing doesn't overcome the processing needs to build something 
complex, it just means the parser is now running something closer to JIT 
type stuff. Its still executing code that isn't 'part' of the actual 
engine in the while loop, until it finally starts making pixels.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Bernd Fuhrmann wrote:
> Andrey Skvortsov wrote:
> 
>> I think you are wrong and really underestimate current povray 
>> capabilities!  What you have written (except discussed namespaces)  
>> can be done without a problem right   now. Not exactly the way you 
>> wrote but similar, there are such things in Povray called objects... 
>> RTFM.
> 
> 
> Write the Fine manual!
> 
> POV-Ray help->Index->object:
> 
> ---
>  Object
>     2.5.11.23 Object Pattern
> 
>           adding texture to
>               1.2.1.5 Adding Texture to an Object
>           describing
>               1.2.1.4 Describing an Object
>           keyword
>               2.5.11.23 Object Pattern
>           modifiers, quickref
>               2.8.9 Object Modifiers
>           pattern
>               2.5.11.23 Object Pattern
> ---
> So what part of the manual does describe how objects can solve my 
> problems? What part does give the hint?
> 
>> You can create your arrays of humans and pass the through the mesh() 
>> and    not too ugly.
> 
> 
> Argh, arrays! I demand structs or real OOP. Sorry but this isn't 
> acceptable for me.
> 
> Regards,
> Bernd Fuhrmann
Help is not fantastic, I think so too.

I meant simple CSG
say you can write:

#declare myhuman = union{sphere .... box.. tringle ....etc }
it's not yet going to be shown. And then "instantinate" it like

object{myhuman}
object{myhuman {....some modification, other textures,position etc}}


well it's not like c++

class HumanMaker
{
	HumanMaker(....)
public:
	box
protected:
	sphere
private:
	....
	DoSomething()
	TranslateSomeWhere(..)
}

HumanMaker Human1;  //should this make the object appear on the screen?

Should we also implement overloaded functions and operators and all 
other advanced C++ stuff? :))

Current SDL mimic this class/object, but you cannot access your boxes 
spheres (primitives) in the CSG, of course, that would give us more 
power and have eaten more memory!
Although the thing is that OOP code is slower for parsing and this is 
very important for 3d modeling, because you want FAST. I even think 
there are people who would wish to simplify current SDL to achieve 
faster parsing times (or whatever needed). I personaly wanted it, 
playing with objects, containing millions of primitivies (strange 
attractors)! Parsing is killingly slow and memory consumption is 
enormous for such extremes.
But programming convenience and ability to share modules (classes) is 
very attractive.
So that is totally a compromise and currently it's not too bad.

Warp has a good point here.

Andrey Skvortsov

Post a reply to this message

Perhaps this will help to understand:
http://en.wikipedia.org/wiki/Compiler#Compiler_front_end


Regards,
Bernd Fuhrmann

Post a reply to this message

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Then in your opinion for example Lisp and Prolog are not true
> > programming languages?
> > 
> I hate them, yes.

  How does you hating them affect in any way the fact whether they are
true programming languages or not?

  That's like saying that you hate toyotas and thus toyotas are not cars.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> It might be worthwhile to consider the use of an existing scripting 
> language that's designed to be embedded in other programs, and use that 
> for the scripting language.

  That has been considered many times, but doesn't seem to be a good
solution.
  POV-Ray needs a language specific for POV-Ray. Using a generic
programming language will make many things too awkward and hard to
use (too many things will have to be kludged).
  Besides, optimally the new language will somewhat resemble the
current one so that the learning curve will not be as steep. Most
POV-Ray users have never used any other language and learning a
new language which is similar to the current SDL will be easier
than learning a completely different language.

-- 
#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 news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:

> It would be better to 
> develop some kind of library for that programming language that would
> be used by most people who want to develop extensions that cannot be
> done properly with POVRay SDL.

Something like:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451

Ingo

Post a reply to this message

In article <41d86f9a$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Once you get to the point of *interpreting* what "#while" means, you're 
> past the parsing stage. POV-Ray may call that "parsing", but it isn't. 
> It's executing the specification. In other words, if the OP wants to do 
> something like add a namespace to some selected number of variables, you 
> don't have to understand a "while" loop to find all the variables you're 
> going to change, any more than emacs needs to understand SDL to 
> search-and-replace spheres with something else.

When POV says it's parsing, it's really parsing. POV executes the scene 
file as it parses it, rather than parsing into an intermediate form to 
be executed later. This is one of the reasons it is so slow, and one 
thing which badly needs improvement in POV4...it crawls around the input 
source files while generating the scene. The body of a loop is actually 
parsed once per iteration. Then there's a postprocessing stage where 
stuff like photons and radiosity are precalculated, basically "filling 
in the blanks" of the generated scene, and then you get to the rendering 
stage.

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

ingo wrote:
> in news:41d9bf11@news.povray.org Bernd Fuhrmann wrote:
> 
> 
>>It would be better to 
>>develop some kind of library for that programming language that would
>>be used by most people who want to develop extensions that cannot be
>>done properly with POVRay SDL.
> 
> 
> Something like:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205451
> 
> Ingo

Yes. I don't know Python good enough, but I think something like that. 
Perhaps with slightly more features or better internal structure, but I 
really don't know Python good enough to decide that. Just a feeling in 
my stomach that this can be done better.

Thanks for the hint. Btw: What is you opinion of a facility like it is 
shown in that Python code piece?

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> 
>>It might be worthwhile to consider the use of an existing scripting 
>>language that's designed to be embedded in other programs, and use that 
>>for the scripting language.
> 
> 
>   That has been considered many times, but doesn't seem to be a good
> solution.
>   POV-Ray needs a language specific for POV-Ray. Using a generic
> programming language will make many things too awkward and hard to
> use (too many things will have to be kludged).
>   Besides, optimally the new language will somewhat resemble the
> current one so that the learning curve will not be as steep. Most
> POV-Ray users have never used any other language and learning a
> new language which is similar to the current SDL will be easier
> than learning a completely different language.
> 
I don't understand that one. Why should people _need_ to learn new 
languages. If there is just a frontend that is able to create SDL code 
they'd still have SDL code to work with. They won't be able to 
effectively modify it but they aren't now either in many cases (those 
that are just to hard to be treated with common SDL).

Regards,
Bernd Fuhrmann

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Then in your opinion for example Lisp and Prolog are not true
>>>programming languages?
>>>
>>
>>I hate them, yes.
> 
> 
>   How does you hating them affect in any way the fact whether they are
> true programming languages or not?

It doesn't. "Being a true programming language" is not defined. If you 
mean Turing-complete was a good sign of true programming languages just 
have a look at brainfuck (http://www.muppetlabs.com/~breadbox/bf/). No 
sane person will use that language to code any serious software. So you 
wouldn't consider that a real programming language. On the other hand: 
What if you used such a programming language for 40 years and you could 
do things faster with that awkward programming language then with any 
other? You'd certainly consider it a real programming language. So what? 
It's a matter of opinion. So why should we argue about it?

But there are still facts: Some things just save you a lot of time, like 
OOP. Modularization is important. So we should have a good look at all 
those little nice features of all kinds of programming languages that 
allow a better form of modularization. These things should go into 
POVRay SDL or any officially recommended frontend for it.

>   That's like saying that you hate toyotas and thus toyotas are not cars.

Come on. I did'nt say that. They are considered real programming 
languages by many people. I know that. But I still don't like them. It's 
just my opinion. Call it a feeling. I once had to do a couple of things 
with Scheme and I was really pretty upset because of certain things. So 
I will not consider them as a true alternative for C(++) for my 
programming work. Other people will think different. I can live with 
that (as long as I don't have to mess up with their code).

Regards,
Bernd Fuhrmann

Post a reply to this message