Peter Popov <pet### [at] usanet> wrote...
> : strict variable types

I think that the non-programmers might balk at this.  I like the way that
renderman handles this by linking in to existing languages and thus only
providing core functionality instead of syntax.  However, for good or bad,
POV is not currently heading in that direction.

A minimal amount of stricter variables might be good, but I personally lean
more towards looser variable types.  For efficiency reasons (as you pointed
out), it might be a good idea to allow the user to specify a few
smaller/faster variable types.  But careful attention would have to be paid
to making it easy to use.  Therefore, many paradigms from other programming
languages (C/C++ especially) should not be used because the are not easy to
learn and often difficult to use.  Sure, they might be easy for most of us
in _this_ group, but there will be far more non-programmers who will not
want to have to worry about what type of variable they need to use to get
the precision they want.

Therefore, I would probably just add integer types (maybe char, but most
likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

> : promotion

Promotion is currently automatically done when needed.  I like that approach
better.  Sure, automatic type casting can lead to unexpected results if the
coder doesn't pay attention to what they're doing, but if there the number
of variable types is kept to a minimum, and a logical promotion sequence is
used, then this can greatly ease the task of the coder.

> : hash variables
> For example,
> Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
> they mean the same to the parser.

Current POV code:

#declare Peter_Popov = 155;
#declare ABC=Posters[Peter_Popov];

Maybe what you're looking for is this:
#declare ABC=Posters["Peter_Povpov"];

> : media emission/absorption color map

I agree.

> : patterned turbulence, turbulence_map

I agree.

> : spotlight scale

I'm not quite sure how to code this, but it sounds rather useful.

> : polygonal spotlight

My first thought is to use projected_through.  Do that with an area light
and you get realistic falloff, although I realize that doing such would not
be as fast as what you are proposing.

> : better alpha channel support

I agree.

> : displacement mapping for patterns

Sounds interesting.

> : chop pieces off with bounding

Use CSG.

> : leave original textures when CSGing

Probably won't work as well as you'd expect.  But I don't want to dismiss it
without looking closely.  It is potentially a very useful idea and may not
be as difficult to implement as I am imagining.  I would definately say that
it should be a special option for backwards compatibility reasons.

> : seeded randomness for area_light and aa jitter

As mentioned by Chris, this may not be possible.

> : zero text object thickness

Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
pattern would be better.  This way you could apply the TTF object to another
infinitely thin object (such as a disc) and use filter/transmit to get the
clear part.

> : on error do something useful (skip frame etc.)
>
> OK this one I admit is a bad habit I have from my BASIC years :)

Actually, your example looks quite a bit like an exception-handling block,
and I see a lot of potential usefullness in it.

> : Additional BRDF models

I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
models.

-Nathan

(I speak for myself and not for the POV-Team.)

Post a reply to this message

I have one more suggestion (or the modification of a feature):

  When you write something to, for example, the #warning stream, the given
string is printed there ok.
  However, if you try to print something to the #error stream, nothing is
printed, but the parsing stops and povray shows some lines where the "error"
occurred.
  This is quite useless if you have something like:

#error concat("Expected value between ", str(minval,0,0), " and ",
              str(maxval,0,0), ", but ", str(value,0,0), " was specified.")

  Showing that helps no-one. However, printing that message and stopping
(without showing any source code) would be more useful.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38b81aa4@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Peter Popov <pet### [at] usanet> wrote...
> > : strict variable types
> 
> I think that the non-programmers might balk at this.  I like the way 
> that renderman handles this by linking in to existing languages and 
> thus only providing core functionality instead of syntax.  However, 
> for good or bad, POV is not currently heading in that direction.

Maybe we should make a separate language just for us programmers with a 
converter to .pov files. :-)
Bad idea, I know. Unless there was an editor which automatically 
"compiled" to POV and rendered the scene, it would just be too clumsy a 
system to use. Maybe give POV two different parsers? Or make that 
possible in a later version while rewriting the source?


> A minimal amount of stricter variables might be good, but I 
> personally lean more towards looser variable types.  For efficiency 
> reasons (as you pointed out), it might be a good idea to allow the 
> user to specify a few smaller/faster variable types.  But careful 
> attention would have to be paid to making it easy to use.  Therefore, 
> many paradigms from other programming languages (C/C++ especially) 
> should not be used because the are not easy to learn and often 
> difficult to use.  Sure, they might be easy for most of us in _this_ 
> group, but there will be far more non-programmers who will not want 
> to have to worry about what type of variable they need to use to get 
> the precision they want.

This is true...maybe types aren't such a good idea, even though they 
would be useful in some of the more complex include files and scenes.
However, I would like to see #declare and #local only be used to 
*create* variables, with either another keyword(#let?) or no keyword at 
all required to modify a variable, something like:
#declare K=0;// creates a variable K
#let K=K+1;// adds 1 to the variable K
K=K+1;// adds 1 to the variable K
This would make a lot of the includes easier to read and maintain, and 
would make debugging easier, since it is clearer where a variable is 
first created.


> > : displacement mapping for patterns
> 
> Sounds interesting.

I think the pattern-vector_map approach would be best for this...any 
other ideas?


> > : zero text object thickness
> 
> Sounds good for rendering speed reasons.
> On the other hand, maybe a TTF pattern would be better.  This way you 
> could apply the TTF object to another infinitely thin object (such as 
> a disc) and use filter/transmit to get the clear part.

Something like this? :-)
pigment {
    object {
        text {ttf "crystal.ttf", "my testing text", 1, 0
            translate -z*0.001//to avoid co-incident surface problems
        },
        color White filter 1, color Blue
    }
}
My object pattern was originally a text pattern, it was just more 
versatile to let it use any object.


> > : Additional BRDF models
> 
> I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
> models.

I agree too, now that I have an idea of what one is...but what would a 
good syntax be? And how well would they coexist?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
> This is true...maybe types aren't such a good idea, even though they
> would be useful in some of the more complex include files and scenes.
> However, I would like to see #declare and #local only be used to
> *create* variables, with either another keyword(#let?) or no keyword at
> all required to modify a variable, something like:
> #declare K=0;// creates a variable K
> #let K=K+1;// adds 1 to the variable K
> K=K+1;// adds 1 to the variable K
> This would make a lot of the includes easier to read and maintain, and
> would make debugging easier, since it is clearer where a variable is
> first created.

Personally, I disagree.  For non-compiled, scripting languages, I like
features such as automatic variable creation and run-time scoping.
I don't like #declare and #local.  I like $ and % instead.  ;-)

$k=0;
$k=k+1;

Run-time scoping, loose variable types, and automatic creation of variables
are 'features' of scripting languages.  This is different from compiled
procedural languages, but 'different' does not necessarily mean 'wrong'.

Finally, because of the way POV's scene-description language is defined,
your example of the assignment with neither #declare or #let would probably
cause ambiguity in the parser, and fixing that would likely lead to
backwards compatibility issues.

See p.t.s-f for an example of run-time scoping.

-Nathan

Post a reply to this message

>I think that the non-programmers might balk at this.

I wouldn't mind if you could make it so that both types of users could work
happily: that is, for POV to support both syntaxes, this way

#declare Whatever = something;

would be just as valid as

#declare Whatever = (int) something;

Of course, this would mean that the programmers would have to be nice enough
to provide dual versions of their files for those who couldn't understand C.
Although, maybe non-programmers wouldn't mind in the case that you had an
include that does something that greatly benefits from these specific
variable types and they had to reason to read the include, just #include it
and enjoy the benefits. Right?

Post a reply to this message

On 26 Feb 2000 13:14:43 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

>  There are three similar things: Bounding, clipping and the intersection CSG.
>They functions are, however, very different and should not be confused.
>  What you are talking about, actually, is this:
>
>  intersection
>  { object { MyObject }
>    object { BoundingObject }
>    bounded_by { BoundingObject }
>  }
>
>  Since it can be done, and it's very intuitive, it should not be changed.
>It should, however, be documented better.
>  For some reason I have never had any confusion about these three things.

I have not either. Perhaps you have missed my main point, and it is
textures. Imagine you have this:

intersection
{ union
  { sphere { -x, 1 pigment { Red } }
    sphere { x, 1 pigment { Blue } }
  }
  box { <-3,0,-2>, <3,2,2> }
}

Now, there is no simple way to make the surfaces of the spheres that
show up after being chopped off preserve their texture. They get the
texture of the box, which in this example is default or black. If
this:

union
{ sphere { -x, 1 pigment { Red } }
  sphere { x, 1 pigment { Blue } }
  bounded_by { box { <-3,0,-2>, <3,2,2> } }
}

worked in the desired way it would make certain tasks easier. Either
that, or the way CSG works could be modified for the purpose.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On Sat, 26 Feb 2000 13:22:22 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Therefore, I would probably just add integer types (maybe char, but most
>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

These should suffice, really. And at first I didn't realize the
problems a person with no programming background might run into when
working with unsigned types. You're right, leave'em out.

>> : promotion
>
>Promotion is currently automatically done when needed.  I like that approach
>better.  Sure, automatic type casting can lead to unexpected results if the
>coder doesn't pay attention to what they're doing, but if there the number
>of variable types is kept to a minimum, and a logical promotion sequence is
>used, then this can greatly ease the task of the coder.

I will have to trust you on this one because you're the programmer,
not me :)

>Maybe what you're looking for is this:
>#declare ABC=Posters["Peter_Povpov"];

Yes, of course you're right, a string used as an index is what I had
in mind.

>> : polygonal spotlight
>
>My first thought is to use projected_through.  Do that with an area light
>and you get realistic falloff, although I realize that doing such would not
>be as fast as what you are proposing.

I think Stephan Ahonen was working on such an extension for Blender
(I'll have to check my ICQ message archive). I'll see if I can get him
(or whoever it was who worked on that project) share some source.

>Use CSG.

I'm just giving this idea up because it is not a really good one.

>> : leave original textures when CSGing
>
>Probably won't work as well as you'd expect.  But I don't want to dismiss it
>without looking closely.  It is potentially a very useful idea and may not
>be as difficult to implement as I am imagining.  I would definately say that
>it should be a special option for backwards compatibility reasons.

My heart is filled with hope :)

>> : seeded randomness for area_light and aa jitter
>
>As mentioned by Chris, this may not be possible.

Use the pixel coordinates as a seed and there you go!

>> : zero text object thickness
>
>Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
>pattern would be better.  This way you could apply the TTF object to another
>infinitely thin object (such as a disc) and use filter/transmit to get the
>clear part.

Also, support for '\n' and '\t' in text objects (and for '\t' in
strings) would be useful. Stuff like justification would probably be
overkill (and can be done with a macro anyway).

>> : on error do something useful (skip frame etc.)
>>
>> OK this one I admit is a bad habit I have from my BASIC years :)
>
>Actually, your example looks quite a bit like an exception-handling block,
>and I see a lot of potential usefullness in it.

Really? But that would involve return codes for most operations etc.
Also, what would happen if this block in included, or even worse,
overlaps, a #while..#end, #if..#end or even a #macro..#end block?

>> : Additional BRDF models
>
>I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
>models.

Ditto to that.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

In article <O1+4OE0dCXqQafXKqfXLL1aqGEUo@4ax.com> , Peter Popov 
<pet### [at] usanet>  wrote:

>>Therefore, I would probably just add integer types (maybe char, but most
>>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.
>
> These should suffice, really. And at first I didn't realize the
> problems a person with no programming background might run into when
> working with unsigned types. You're right, leave'em out.

When using only integer types, I think the whole thing can be hidden from
the user and POV-Ray automatically determines the type (floating-point or
integer). This allows for hiding the type from the user, and in loop, etc
even new users would get the benefit without ever having to deal with
variable types.

For a #declare (of a so far undefined variable) just check if the value is
an integer and then store it as such.  I.e. "#declare MyFoo = 1" is an
integer, but neither would be "#declare MyFoo = 1.0" or "#declare MyFoo =
1.8542".  Now, whenever a floating-point result is to be assigned to this
integer, promote "MyFoo" to floating-point (for backward compatibility!).

User control can still be available, i.e. introducing two functions to
eliminate the common operations that should create floating-point results:
For division offer a Pascal style "div" function (or even operator), and to
still allow mixing integer and floating-point math without forcing promotion
to floating-point for the result, an "int" function which can be placed
around any section of a function, for example "#declare MyFoo = 1; #declare
MyFoo = 8084 div 7 + MyFoo - (int(sin(45) * 10) * MyFoo;" would still give
in an integer result.

During evaluation this should still be possible with (nearly?) no runtime
penalty.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

Margus Ramst wrote in message <38B711FF.1E959678@peak.edu.ee>...
>Some wishes arising from my current projects:
>
>Dynamic arrays. In POV, arrays are the best way to acces large datasets,
but the
>size of the array has to be declared before any data is inserted. The thing
is,
>you often don't know how much data will be generated. And manually resising
a
>100,000 element array is inefficient, to say the least.


I've been working on "malloc", "realloc", and "free" macros.  However, the
current version of "realloc" is very slow, since it works by creating a new
array and copying the old one into it.

Mark

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: I have not either. Perhaps you have missed my main point, and it is
: textures. Imagine you have this:

: intersection
: { union
:   { sphere { -x, 1 pigment { Red } }
:     sphere { x, 1 pigment { Blue } }
:   }
:   box { <-3,0,-2>, <3,2,2> }
: }

  But that's not possible. Suppose that the radiuses of the spheres are
a bit larger (so that the spheres overlap). What's the color of the
overlapping part?
  On the other hand, even in your example: How can povray know which one
is the right sphere to get the color from? It only has knowledge of the
intersection of the ray with the box. It would have to somehow decide which
sphere is the right one. I don't know how povray works in this matter, but
it might be difficult to see which sphere is the right one. It's more difficult
if the spheres overlap or one sphere is completely inside the other.
  And besides, bounding is not intended for that kind of functionality.
Boundind is intended only for speeding up the rendering.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message