POV-Ray : Newsgroups : povray.programming : URGENT: FRAME structure Server Time
28 Jul 2024 20:25:20 EDT (-0400)
  URGENT: FRAME structure (Message 62 to 71 of 81)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Mikael Carneholm
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 11:36:04
Message: <39A14C62.D82D43FC@ida.utb.hb.se>
Thorsten Froehlich wrote:

> To go back to the simplicity of parser features in earlier versions, i.e. no
> macros and so on.  Even remove the declare statement.
>
> Then, start from there and add the same features from scratch to be more
> restrictive and combine it with a simple and powerful programming language
> that can be fully integrated into the scene description much more
> dynamically.  Details and features would have to be analysed very well in
> advance, but then it might offer fantastic abilities.  Just image to be able
> to create one object which can exist a million times just by a procedural
> definition.  To keep this simple and easy to comprehend and fast to render,
> a lot more would have to be done and researched, but I think something like
> this is possible.

Why remove something that's working just fine, and while doing so (removing,
i.e.), making lots of scene files unusable at the same time that you're forcing
the whole POV community to learn a completely new language?

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse


Post a reply to this message

From: Chris Huff
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 12:02:19
Message: <chrishuff-54AE37.11033921082000@news.povray.org>
In article <39A14C62.D82D43FC@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Why remove something that's working just fine, and while doing so 
> (removing, i.e.), making lots of scene files unusable at the same 
> time that you're forcing the whole POV community to learn a 
> completely new language?

Because it is not working just fine?
It is sometimes more difficult to do things than it should be, and a 
rewrite of the language from it's basics could make it easier to learn. 
It has had things piled on it which it wasn't designed for at the 
beginning, and has many clumsy areas which force you to do things in an 
inefficient way. A new language could mean shorter, easier to read, 
write, and understand scene files.
It might even be possible to do this and still support the existing 
language to a degree. People would have to learn the new one, but the 
basic concepts should be quite similar.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><


Post a reply to this message

From: Chris Huff
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 12:08:22
Message: <chrishuff-0B977C.11094221082000@news.povray.org>
In article <39a1245e@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Then, start from there and add the same features from scratch to be 
> more restrictive and combine it with a simple and powerful 
> programming language that can be fully integrated into the scene 
> description much more dynamically. 

Do you have a specific programming language in mind as the inspiration 
for this?


> Details and features would have to be analysed very well in advance, 
> but then it might offer fantastic abilities.  Just image to be able 
> to create one object which can exist a million times just by a 
> procedural definition.  To keep this simple and easy to comprehend 
> and fast to render, a lot more would have to be done and researched, 
> but I think something like this is possible.

This sounds like a very interesting proposal, but it would really have 
to be done right. Maybe it should be a translator at first, which 
produces a .pov scene file from the new language, that way, you could 
experiment with changes to the new language with more freedom. This is 
the approach I am going to attempt CSDL with...that is, if I ever get 
going with Bison and Flex.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><


Post a reply to this message

From: Chris Huff
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 12:26:51
Message: <chrishuff-6BBA8D.11281121082000@news.povray.org>
In article <39a124bd@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Last time I checked it was over $1200 with no student discount in sight 
> :-(

Ouch...is it actually used for anything?


> It depends, one can get used to it...

I guess I will have to wait for the public beta and see what it is like 
first-hand...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><


Post a reply to this message

From: Mikael Carneholm
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 12:37:46
Message: <39A15AD6.E1467907@ida.utb.hb.se>
Chris Huff wrote:

> It might even be possible to do this and still support the existing
> language to a degree.

Of course, you're right. My assumption was that implementing OO shouldn't
be so hard that it would require a complete rewrite, but it may still be
true that it's easier to do so, even though it's not required. And just as
you said, even though the parser (and other affected parts) are rewritten
we could still keep the old syntax.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 14:17:01
Message: <39a1721d@news.povray.org>
In article <39A14C62.D82D43FC@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> Why remove something that's working just fine, and while doing so (removing,
> i.e.), making lots of scene files unusable at the same time that you're
> forcing the whole POV community to learn a completely new language?

No, not completely new.  The current problem is that POV scenes are
extremely hard to parse by any outside program (made even harder by the
programming features introduced with 3.0).  To make matters worse, these
features are hard to support without having to re-parse the scene when
rendering animations.

Additionally, in POV-Ray 4.0 a new parser will most likely be needed anyway.
Of course there should be some kind of converter from 3.5 to 4.0 scenes, and
the differences should not require to much relearning.

Anyway, nothing has been decided yet, so these are just my personal ideas
and I am not speaking for the team.


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 14:28:50
Message: <39a174e2@news.povray.org>
In article <chrishuff-0B977C.11094221082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> Then, start from there and add the same features from scratch to be
>> more restrictive and combine it with a simple and powerful
>> programming language that can be fully integrated into the scene
>> description much more dynamically.
>
> Do you have a specific programming language in mind as the inspiration
> for this?

Not really.  I know there are some high-profile US universities (i.e. MIT)
who use Scheme (a Lisp dialect) in introduction to the profession and/or
introduction to programming classes.  But it is surely not appropriate for
POV-Ray in its current form.

>> Details and features would have to be analysed very well in advance,
>> but then it might offer fantastic abilities.  Just image to be able
>> to create one object which can exist a million times just by a
>> procedural definition.  To keep this simple and easy to comprehend
>> and fast to render, a lot more would have to be done and researched,
>> but I think something like this is possible.
>
> This sounds like a very interesting proposal, but it would really have
> to be done right.

Exactly, and without having done a lot of research in this area it might be
next to impossible to do it quickly.  So one way might be to locate a
already existing language and adapt it with some minor changes, another
might be to really conduct the research, but with which resources?

> Maybe it should be a translator at first, which
> produces a .pov scene file from the new language, that way, you could
> experiment with changes to the new language with more freedom.

Yes, a translator would be necessary.  However, this would not a 'simple'
program either...


    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

From: Thorsten Froehlich
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 14:42:53
Message: <39a1782d@news.povray.org>
In article <chrishuff-6BBA8D.11281121082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> Last time I checked it was over $1200 with no student discount in sight
>> :-(
>
> Ouch...is it actually used for anything?

I don't know, but the advertisements say it supports the full set Mac user
interface features.   And keep in mind that CodeWarrior is not that
inexpensive if you are not a student either :-(

>> It depends, one can get used to it...
>
> I guess I will have to wait for the public beta and see what it is like
> first-hand...

The IBM VisualAge product line (PC only) is probably the best way you can
try it out without Mac OS X, but it is expensive and only a few companies
seem to use it.  There also used to be a IBM VisualAge for Smalltalk for
over $4000 ... I had the pleasure to play with it for a weeks a few years
back during a 10 day internship (done in high-school).  Unfortunately I
still don't know Smalltalk, but it didn't look to difficult to learn :-(


    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

From: Mikael Carneholm
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 14:47:45
Message: <39A1794B.76E9040D@ida.utb.hb.se>
Thorsten Froehlich wrote:

> No, not completely new.  The current problem is that POV scenes are
> extremely hard to parse by any outside program (made even harder by the
> programming features introduced with 3.0).

Well, that's another side of the story (?). I believe some sort of export function
that wrote a target file in a target format should be a better solution, as that
wouldn't require as strict syntax as required by an external parser. I guess that
POV's inner representation of an object is easier to export than it is for an
external program to rebuild the object from reading a scene file written by a
user, as there are as many ways of indenting and coding as there are users. A lot
of data could also get lost that way, I suppose.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse


Post a reply to this message

From: ingo
Subject: Re: URGENT: FRAME structure
Date: 21 Aug 2000 14:58:44
Message: <8F97DAD9Cseed7@204.213.191.228>
Thorsten Froehlich wrote:

>That a Smalltalk development system for the Mac does not have any space
>in my budget for the next few years :-(
>

Squeak is free.
http://www.squeak.org/

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.