On Tue, 15 Jan 2002 11:23:14 -0500, Christopher James Huff <chr### [at] maccom>
wrote:
> > AFAIK parsing functions are not connected with rendering functions 
> > for objects, initializing functions for data etc. Have you checked 
> > this ?
>
> Since POV 4.0 hasn't even been started yet, he would have some 
> difficulty doing so...

What I understand from his post he propose new syntax with the same output
image. So no problem to replace parsing functions with current 3.1 or future
3.5. Almost everything in 3.5 comes as patch on 3.1. The point was to make patch
on 3.1 (later 3.5) or any 3rd party utylity (like yours CSDL) to support 4.0.

> > Writing new parser without changing other stuff is
> > IMO no more difficult than organizing MegaPOV by Nathan and/or
> That used the existing parser.

I mean effort not function.

> > IMO no more difficult than adding shader by Vahour.
> I think that used an existing parser, which he added to POV.

As above.

> > Somehow Chris Huff started with new syntax.
>
> I'm writing an entirely new interpreter, but I'm not writing a POV 
> patch... CSDL is a 3rd party utility, though it will be capable of 
> running command-line programs like POV-Ray and will have a scene 
> description library that can output POV script.

And it's great idea to propose new things this way. Working versions...

ABX

Post a reply to this message

In article <atl84u8632rgr5ka4rajo53d23tagqsejd@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> What I understand from his post he propose new syntax with the same 
> output image. So no problem to replace parsing functions with current 
> 3.1 or future 3.5. Almost everything in 3.5 comes as patch on 3.1. 
> The point was to make patch on 3.1 (later 3.5) or any 3rd party 
> utylity (like yours CSDL) to support 4.0.

Some things aren't possible to do cleanly, you have to hack around the 
existing source code, and some of the proposals affected the deepest 
parts of the rendering code. It isn't always feasible to have something 
to demonstrate, he would probably have to make a mockup of a renderer.
The output image may be the same, but that doesn't really matter...


> > > Writing new parser without changing other stuff is
> > > IMO no more difficult than organizing MegaPOV by Nathan and/or
> > That used the existing parser.
> I mean effort not function.

Writing a parser is a bit harder than writing code to use an existing 
parser. ;-)


> And it's great idea to propose new things this way. Working versions...

But to do what he is talking about would require extensive integration 
with the renderer, so a "working version" would essentially be a new 
renderer...CSDL is quite a bit simpler, being just a language.
However, what he's doing by making an in-depth description of his ideas 
and testing them out here is just as good as a working prototype.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>
(currently struggling with the expression parser for CSDL)

Post a reply to this message

Eugene
I see your points and I see how helpful they are.  Years ago, there was a
package made expressely for POVRAY.  I forgot the name of the package, but
it was written in a C - like language and it came with its 'compiler' that
'compiled' the scene written in it into a POVRAY script.  The language was
functional as it was heavily influenced by the C language but it implemented
every thing you mentioned.
So, I can see the power of what you are talking about.  And of course I do
not mean it by way of attacking POVRAY (I have been using POVRAY since the
Eighties), but by way of generating interesting ideas.
Maan

"Eugene Arenhaus" <eug### [at] avalon-netcoil> wrote in message
news:3C4157D0.2F4BB129@avalon-net.co.il...
> Well, hello again, and thank you for taking interest -
>
>  I feel I need to answer a few reoccurring questions and gripes. :)
>
>  First: Again, I did not mean to bash POV. I merely wanted to provide
> food for thought, not for target practice. :) Please try to not feel as
> if I am assaulting your favorite program (language, feature, etc.) -
> that was never my meaning.
>
>  Second: Yes, you are right, I am most likely not up to date with the
> cutting edge development done on POV 3.5, and for that I apologize. I am
> much more experienced with software design in general than with this
> particular program... My chief experience was with POV 3.1. Thank you
> for your comments. Still, my goal was to think of a broad picture, not
> to peck on particular features or tricks.
>
>  Third. No, it is not going to be a "completely different" language. In
> fact, it can be made to reuse most scene files with at worst some minor
> tweaking, if that goal is set. (With POV team saying themselves they
> aren't going to make POV4 100% compatible with version 3 - thou who hast
> not sinned... :) )
>
>  And last... the goal of the post was, again, to provide a broader
> picture as food for thought. I am not saying that there's no way to do
> [X] in POV for any given [X] - the idea was to eliminate the need for
> obscure, unintuitive, kludgy ways of doing that [X] for sake of an easy,
> flexible way of doing it. There is difference between having to write a
> whole program in POV script and merely plugging several objects
> together, don't you agree? What I meant that the design similar to what
> I outlines would really facilitate both making scenes and writing
> patches, and it seems that similar thoughts are not mine alone, if your
> corrections to my "gripes" are an indication - POV does move in that
> very direction.
>
> Thank you all.

Post a reply to this message

In article <3c45a6dc@news.povray.org>,
 "Maan M. Hamze" <mmh### [at] pleiadesnet> wrote:

> I see your points and I see how helpful they are.  Years ago, there was a
> package made expressely for POVRAY.  I forgot the name of the package, but
> it was written in a C - like language and it came with its 'compiler' that
> 'compiled' the scene written in it into a POVRAY script.  The language was
> functional as it was heavily influenced by the C language but it implemented
> every thing you mentioned.

Are you sure it wasn't just a patch for POV-Ray, or one of the many 
discussions about scene language improvements? I've never heard about 
this, but my CSDL project is extremely similar...
Any more information? This sounds very interesting (for obvious reasons).

(Capitalization nitpick: "POV" is an acronym for Persistance Of Vision, 
but "Ray" is just an abbreviated form of "Raytracer".)

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c45a6dc@news.povray.org>,
>  "Maan M. Hamze" <mmh### [at] pleiadesnet> wrote:
>
> > I see your points and I see how helpful they are.  Years ago, there was
a
> > package made expressely for POVRAY.  I forgot the name of the package,
but
> > it was written in a C - like language and it came with its 'compiler'
that
> > 'compiled' the scene written in it into a POVRAY script.  The language
was
> > functional as it was heavily influenced by the C language but it
implemented
> > every thing you mentioned.
>
> Are you sure it wasn't just a patch for POV-Ray,

Yes I am sure it was not.  I was one of the alpha and later beta testers.
You describe the scene in a C like language (including types, varibales
etc...), run it through the 'compiler' and get a an .obj file then 'link
into a .pov file.  In order to create animations, this was a breeze as you
were able to use equations and conditions in a C like manner.
This was years and years ago and I just do not know what happened to the
project.  One of the countless many useful projects that were swept aside.
Maan

Post a reply to this message

In article <3c473b8e$1@news.povray.org>,
 "Maan M. Hamze" <mmh### [at] pleiadesnet> wrote:

> Yes I am sure it was not.  I was one of the alpha and later beta testers.
> You describe the scene in a C like language (including types, varibales
> etc...), run it through the 'compiler' and get a an .obj file then 'link
> into a .pov file.  In order to create animations, this was a breeze as you
> were able to use equations and conditions in a C like manner.
> This was years and years ago and I just do not know what happened to the
> project.  One of the countless many useful projects that were swept aside.

Do you know if it was ever distributed over the internet? Do you have 
any idea what it was called or where it was available? I'd be very 
interested in seeing what they had...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

I'll investigate and see if anything can be found.  The problem is that the
project never made it through the first beta and I do not believe it was
ever released over the internet.  I can not even remember the name of the
project.  I was contacted by the developer along with other povray users
(the developer got our names from the comp.graphics.raytracing newsgroup
which was heavily composed of povray posters).  Then he sent us the alpha
release to test then one beta test then that was it.
Maan
PS:  Hope some other testers follow this povray newsgroup.  In this case,
hope they can give more information in case they have kept anything related
to this project.

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c473b8e$1@news.povray.org>,
>  "Maan M. Hamze" <mmh### [at] pleiadesnet> wrote:
>
> > Yes I am sure it was not.  I was one of the alpha and later beta
testers.
> > You describe the scene in a C like language (including types, varibales
> > etc...), run it through the 'compiler' and get a an .obj file then 'link
> > into a .pov file.  In order to create animations, this was a breeze as
you
> > were able to use equations and conditions in a C like manner.
> > This was years and years ago and I just do not know what happened to the
> > project.  One of the countless many useful projects that were swept
aside.
>
> Do you know if it was ever distributed over the internet? Do you have
> any idea what it was called or where it was available? I'd be very
> interested in seeing what they had...
>
> --
>  --
> Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In my company, we use to face to that kind of dilemma: languae compatibility
versus empowered functions.

When new features are mainly enhancement of the previous version, we
generally choose to keep compatibility.

From time to time we intend to make real innovation. in this case, there is
no compatibility, to get freedom and be able to work from scratch. But we
create automated translators, with about 95% of success, and warnings for
the 5% remaining, asking for user manual action. (Of course, 95% is the
worst case our costumers accept, and so far it is our minimum target.)

Chaps




news:of5r3u8nmsovrb46njc9t4orun4dvrgj8c@4ax.com...
> On Thu, 10 Jan 2002 15:09:43 +0200, Eugene Arenhaus
<eug### [at] avalon-netcoil>
> wrote:
>
> > Here's my two cents.
>
> It's rather two thousands.
>
> > Comments, discussion, corrections, additions are welcome.
>
> Not to much
>
> > We believe that basing PoV4 internal design on the following four
> > principles should be sufficient to achieve this goal:
>
> Who is we ?
>
> > 1. Unified, interchangeable scene object model
>
> Unified ? Is 3ds format somehow unified? If you want POV reader just write
it.
> Specification is available.
>
> > 2. Complete accessibility of object properties from scene description
language
>
> Smart scripting gives it to you
>
> > 3. Instancing support
>
> ?
> Are you talking render farms ? It was discussed many times.
>
> > 4. Full scripting to replace macros
>
> I partially understand what it means but probably yes.
>
> > Example 1.
> > Example 2.
> > Example 3.
>
> Do you know POV 3.5 features ? Please study it.
>
> > I (let's drop the formal "we" now)
>
> Finally, I don't like choirs ;-)
>
> > Therefore, we suggest
>
> Again ?
>
> > May the possibilities never end!
>
> Seems you have big knowledge about languages. Try to write parser for your
> syntax and converter to old syntax. If everything is possible then it
should be
> too. What you suggest is very radicolous change of SDL and imo it is
different
> language. If it is good enough and gives the same possibilities why force
so
> many povers to learn all things/tricks again ? Why break all exporters to
> disallow POV 4 rendering ? Why break all old include files ? Some people
still
> work with POV 2 scripts.
>
> ABX
> --
> #declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb
1}}
> union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{
//ABX
>
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)
}
> contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient
1}}//POV35

Post a reply to this message

don't forget that you can use insert ( with povwin at least), cut & paste
with all editors, and what about an helped editor as you can have with
visual?

Chaps.

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C4### [at] gmxde...
>
>
> Eugene Arenhaus wrote:
> >
> > [...]
> >
> > Well... my reason for interest in POV is essentially my interest for
> > complex software design, which has shifted in the past three years to
> > hierarchies of interacting polymorphic objects in particular.
> >
>
> I like to seriously suggest you one thing:
>
> Before starting to think about radical changes in the design of POV-Ray,
> it would be really a good idea to get some experience in actually using
> POV.  I think everyone currently involved in POV-Ray development has
> either notable own experience in using it or has frequent communication
> with those using it.
>
> > [...]
> >
> > Sorry, this is not true. The language may be whatever we make it, to
> > begin with. No need to stick with what I wrote. :)
> >
> > By the way, more keywords is not necessarily a bad thing, if they are
> > intuitive. Which is mor readable:
> >
> >  sphere { <0,0,0>, 1 }
> >
> > or
> >
> >  sphere { center <0,0,0> radius 1 } ?
> >
> > Readability is a great thing to have, don't underestimate it. And use of
> > words like "radius" is not so out of line with existing syntax which
> > after all uses words like "texture" already....
>
> 'Write-ability' is an important issue too and most people here will
> probably agree that writing
>
> sphere { 0, 1 }
>
> is much easier and in this case IMO much faster to read too.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

> the only big thing removed I remeber is halo{} - and I'm sure there was reason

There is. It was pants.

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message