 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Apache" <apa### [at] yahoo com> wrote in message
news:3c96143c$1@news.povray.org...
>
> 3.
> Force Intel to build a hardware povray version: PnR (Plug 'n Render)
> --
AMD Athlon XP already does that! (XP= eXtraPov, oh yeah baby!)
Maan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c95fd1b@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> So we reduce the number of reserved keywords by 0 and we force the parser
> to make a much more complicated task (it starts by creating a union, but
> in the middle of parsing it suddenly has to convert it to merge).
The goal is not to reduce the number of keywords, where did you get that
idea? I'm talking about simplifying the syntax.
And it wouldn't be nearly as complex as you imply...actually, it would
probably be simpler, they already share most of their code. You wouldn't
want to convert from one type of object to another, that *would* be a
stupid way to do it.
> Same problem. Number of reserved keywords are reduced by 0 and the parser
> has to change the lathe to a sor (which might be a bit complicated).
Not complicated at all, and I'm not trying to reduce the number of
keywords.
> You said that this would simplify the syntax. I don't see how. If all of
> them are made into one sweep primitive, we end up getting one reserved
> keyword more than currently. I don't see how this makes anything simpler.
Stop counting reserved keywords, it is useless.
One shape rather than three. Easier to maintain, easier to learn, easier
to extend with additional sweep types.
> > Smooth triangles could be made part of ordinary
> > triangles.
>
> And how do we differentiate between them?
Smooth triangles have normals, obviously.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c96143c$1@news.povray.org>,
"Apache" <apa### [at] yahoocom> wrote:
> 1.
> I think we should port povray to Java instead. And then we should start a
> render farm that runs on java-enabled phones. So many people with java
> enabled phones, you wouldn't believe it!
There is already at least one Java raytracer, you know...
> 3.
> Force Intel to build a hardware povray version: PnR (Plug 'n Render)
Do you really want it from Intel? I think I'd like Motorola or AMD
better. Intel would probably end up rendering spheres as boxes or
something... ;-)
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c960fd3@news.povray.org>, "Hugo" <hua### [at] post3teledk>
wrote:
> I took his ideas seriously. Some people thinks in a way we don't understand
> but it's not necessary to make fun of them and risk hurting them.
The parts about ASM and forward raytracing could be blamed on ignorance,
but the WinAmp plugin, Lego brick and Shreck primitives...well,
everything else about it gives it away as a joke, obviously enough that
no smileys are necessary. Laughing at someone's joke isn't making fun of
them.
> Maybe he is a boy.
This really doesn't look like it was written by some little kid. The
vocabulary and level of knowledge really doesn't match...how many
*adults* do you know who know about assembler, refraction,
dodecahedrons, buckyballs, and forward vs. backwards raytracing, or use
words like deprecated and intuitiveness?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Apache wrote:
> 2. And additionally we should start thinking about porting povray
> to commodore 64. I bet many people use their commodore 64 on a
> daily basis. They'd be very grateful if you'd do the job.
You mean there ISN'T a C64 version of POV?! For shame...
- Tim Cook
http://empyrean.scifi-fantasy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Sir Charles W. Shults III" <aic### [at] cflrrcom> wrote in message
news:3c960032$1@news.povray.org...
>
> Cheers!
>
CJH is getting it in the ear as well. I think someone got out of bed the
wrong side this a.m.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> The goal is not to reduce the number of keywords, where did you get that
> idea?
From this:
> I'm talking about simplifying the syntax.
More keywords means more complex syntax. Less keywords means simpler syntax.
Although the number of keywords does not change with the proposed change,
the number of keywords you _need to write_ in order to get a merge increases
by one. This means that when you want a merge, you need to write to keywords
instead of one.
This only increases complexity.
Why "union { make_it_merge_instead ... }" would be simpler than just
"merge { ... }" ?
>> Same problem. Number of reserved keywords are reduced by 0 and the parser
>> has to change the lathe to a sor (which might be a bit complicated).
> Not complicated at all, and I'm not trying to reduce the number of
> keywords.
Again, you need to write two keywords when one would suffice. Why writing
*both* keywords, ie "lathe" and "sor" would be simpler than writing just
one, "sor"?
> One shape rather than three. Easier to maintain, easier to learn, easier
> to extend with additional sweep types.
One shape with three different options. I don't see how that is easier
to learn or use.
What you propose is basically the same as forcing the user to put
"object { }" around each primitive he writes. You don't do that, do you? Why?
>> > Smooth triangles could be made part of ordinary
>> > triangles.
>>
>> And how do we differentiate between them?
> Smooth triangles have normals, obviously.
So the parser needs to read three vectors, and if there are additional
vectors, it has to change the meaning of the three already read vectors.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sir Charles W. Shults III <aic### [at] cflrrcom> wrote:
> It is interesting that you seem to really take offense to my opinion,
> and then resort to attempts at insult.
It's just that I really don't understand what is the idea behind making
the POV-Ray parser more limited and harder to use. I don't see any advantage
in this.
I don't understand why some people seem to think that versatility is a
bad thing, when it isn't.
I use the POV-Ray features rather extensively, and it would deprive me of
many great tools if they were taken away all of a sudden.
It would be different if the extra features were an overburden (eg. they
would make rendering slower), but they aren't.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Maybe he is a boy.
>
> This really doesn't look like it was written by some little kid. The
> vocabulary and level of knowledge really doesn't match...how many
> *adults* do you know who know about assembler, refraction,
> dodecahedrons, buckyballs, and forward vs. backwards raytracing, or use
> words like deprecated and intuitiveness?
You have some good points, but on the other hand, there are "outsider"
people. I remember my own childhood. I got hooked on programming when I was
8 years old.. I got more isolated from other children than the majority.. I
learned a lot about computers, but I was still a child.. So I knew a lot of
technical words, but my ideas were not always those of an adult.
And it's possible my "isolation" has made me less skillled to understand
jokes.. :o)
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
> A common beginner's mistake. Try:
>
> // decrease step for higher quality
> #local Step = 20;
> intersection{
> box{0,1 translate -0.5}
> #local M = 0;
> #while(M <= 360)
> #local N = 0;
> #while(N <= 360)
> plane{x,1/2 rotate z*M rotate y*N}
> #local N = N + Step;
> #end
> #local M = M + Step;
> #end
> pigment{Red}
> }
ROTFLMAO!!!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
