 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony Bennett <ben### [at] panama phoenixnet> wrote in message
news:371### [at] panamaphoenixnet...
> I actually have a friend with 2.5. But, I don't know, I just don't like
the
> interface, never found it friendly. Now, Bryce and Lightwave, that is a
nice
> interface! You understand immediately how to use them. Too bad I don't
have a
> couple thousand just lying around...
Pandora's Box (my not-so-soon to be freeware modeller for POV).
I know I'm biased, but boy is it looking like it's going to be cool (If
it ever actually gets done (looking less and less likely as "the new job"
keeps getting in the way)). Nice intuitive UI (it'll work just the way _you_
want to it work!) and a powerful, yet flexible (and probably
over-ambitious), feature set.
(Details on the web just as soon as a) I get my self a web-site and b)
they're ready for publishing (things are still too fluid for that)).
--
Scott Hill : sco### [at] cyberlifecouk
Software Engineer (and all round nice guy)
Author of Pandora's Box : Watch this space.
Work homepage : http://www.cyberlife.co.uk
"We will decide what the news is. The news is what we tell you it is." - The
Fox TV network.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Apr 1999 15:02:45 +0200, Mikael Carneholm
<sa9### [at] idautbhbse> wrote:
>This is exactly what I didn't mean: It should _not_ be totally re-written, just
>expanded with some new possibilities. It would be _optional_ to have attributes
>in an object, and it would be _optional_ to have methods for an object. You could
>still do like you're used to, like this:
>
>box{
> <>,<>
> texture{}
>}
>
>...and it would still render as a beautiful box, without first being declared as
>a "class" and instanced with object{}. But, I personally would like to have the
>option to declare it like this:
>
>#declare MyBox=box{
> <>,<>
> texture{}
>
> attribute speed;
> attribute direction;
>
> #macro Move()
> translate speed*direction
> #end
>}
>
>What I miss most is being able to access the different parts of an object like
>the position, size, texture etc. If those were accessable via dot
>notation(.position, .size, .texture etc) things would light up a great deal.
>
>Once again, do not remove the backward-compability, just add some new features
>that expands the scripting language and that can be used _optionally_.
I don't object to object orientation in principle, although I despise
the long-winded dot notation. I would indeed like to have access to
the properties of an object, preferably via additional keywords and
functions. My big problem with this proposal is that, if you dump the
old syntax for an OO version, you lose too many people who can't
handle the transition. If you keep both syntax styles the POV parser,
already getting unwieldy, will become such a PITA that the pace of
expansion and development will slow radically and things that do get
written will have multitudes of painful bugs. You might as well just
hire Microsux to write the next version of POV! :)
Jerry Anning
clem "at" dhol "dot" com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
>
> I don't object to object orientation in principle, although I despise
> the long-winded dot notation. I would indeed like to have access to
> the properties of an object, preferably via additional keywords and
> functions. My big problem with this proposal is that, if you dump the
> old syntax for an OO version, you lose too many people who can't
> handle the transition. If you keep both syntax styles the POV parser,
> already getting unwieldy, will become such a PITA that the pace of
> expansion and development will slow radically and things that do get
> written will have multitudes of painful bugs. You might as well just
> hire Microsux to write the next version of POV! :)
>
I kind of agree... but since when is dot notation long-winded? A dot,
being a single character, is about as short as you can get. What I
dislike is having to put "#declare" in front of all assignment statements.
It's worse than the LET in very old versions of BASIC.
In some ways I wish the entire POV language could be cleaned up (but this
could cause a lack of backwards compatibility)... and I think that the
object-oriented ability to change properties of an instance of an object
is a MUST, since I think that we should be able to do animation within
a single script (without the need to re-parse!!!!) by changing an
attribute of a single object and re-rendering.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Apr 1999 22:27:53 -0400, Nathan Kopp <Nat### [at] Koppcom>
wrote:
>Jerry Anning wrote:
>>
>> I don't object to object orientation in principle, although I despise
>> the long-winded dot notation.
>
>... but since when is dot notation long-winded? A dot,
>being a single character, is about as short as you can get. What I
>dislike is having to put "#declare" in front of all assignment statements.
>It's worse than the LET in very old versions of BASIC.
I've just seen too many pathological specimens that look like:
Object.box.face.vertical.x_axis_normal.left.ColorVector.red.Increment(.2)
I exaggerate, but the point should be clear. "#declare" irritates me
too. I suppose that in my perfect world everything would be an APL
one-liner....
Jerry Anning
clem "at" dhol "dot" com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I suppose that in my perfect world everything would be an APL
>one-liner....
Wow at least one person did not forget APL beauties ....
Another goody with APL : you don't have to store the sources : anyway nobody
can understand it even yourself as soon as you have pushed the <Return< Key.
:-)
(no joke : I loved this crazy, magic language, even the name is great :A
Programming Language)
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eugene Arenhaus wrote:
>
> Hi.
>
> Here are some thoughts about what POV-Ray 4 could look like.
>
Hi!
What you write seem to me like a very good idea even
though there have been many negative responses in this
newsgroup. A somewhat different suggestion rather than
to implement your comments in a rewritten povray 4
would be to gather a few (4-5) raytracer programmers
and create a completely new (free!) raytracer based on
the experience we have drawn from povray. The concept
would be the same, a scriptable raytracer engine based
on a formal language rather than a GUI, but one would
get the chance to implement everything in a "cleaner"
and more OO etc way...
I have been thinking for quite some time about
implementing a povray like raytracer (not sharing any
piece of code!) to face both the problems you mentioned
in your earlier comments and to get a chanche to
implement a few other conceptual ideas (I will not dvelve
into those here, the posting would become very large
otherwise). I think a clean restart on a completely
separate program (with a completly different name and
not using a single line of pov code or anything the like)
would be the best since it probably would take a long
time before the program becomes good and popular with
users (the conceptuall ideas, both yours and mine,will
probably have to evolve before they become
"user-friendly". Syntax,Semantics etc will need to
change) and facing such major changes as you proposed
it would be best if users and developers don't see it
as just another version of Povray.
Two negative aspects of creating a new raytracer would
be that the math's have to be redone (immoral and
illegal to reuse code from povray) and the risk of not
becoming popular among the users.
So to the conclusion... are you interested in writing a
*new* raytracer? If so I would be happy to discuss design
issues and brainstorm features. Is anyone else (serious)
interested in writing a *new* raytracer? It's an enourmous
task to do so but it would realy be fun...
/ Mathias Broxvall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 11 Apr 1999 14:11:00 +0200, Mathias Broxvall
<x99### [at] idaliuse> wrote:
>So to the conclusion... are you interested in writing a
>*new* raytracer? If so I would be happy to discuss design
>issues and brainstorm features. Is anyone else (serious)
>interested in writing a *new* raytracer? It's an enourmous
>task to do so but it would realy be fun...
Someone else obviously is... see
http://www.gnu.org/software/panorama/panorama.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roland Mas wrote in message ...
>
>Yes, sure. But it would anyway imply a huge lot of calculations,
>because the ray is bent all along its path and not just on a few
>points of it. Which means: a *big* number of samples. Each of them
>needing to calculate a ior local gradient. Sloooow.
>
Well, "slooooooowwww" would be one of the first words I'd use to describe
raytracing in general :)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roland Mas wrote:
>
> Mikael Carneholm <sa9### [at] idautbhbse> writes:
>
> > #declare SomeSphere.radius=1.5;
>
> I'm not sure it really cannot be done.
I don't think it can be. If it can, let me know!
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
#declare a sphere with radius = 1 , location <0, 0, 0>and then scale it!
object
{
SomeSphere
scale 1.5
translate y
}
Just to give the answer, I don't believe it's the best way to work with POV
Philippe
>Roland Mas wrote:
>>
>> Mikael Carneholm <sa9### [at] idautbhbse> writes:
>>
>> > #declare SomeSphere.radius=1.5;
>>
>> I'm not sure it really cannot be done.
>
>I don't think it can be. If it can, let me know!
>
>-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
