In article <3B08FAAA.71D1F86D@gmx.de>, chr### [at] gmxde says...
> Probably not in this case, but for a complex CSG it could be useful, just
> imagine a lot of macro generated trees...
That is what I thought of.
You can generate a couple of braches, from this a couple of trees and 
from these a wood... this is only possible when reusing existing objects, 
otherwise memory requirements would be far too high.
(last winter I upgraded to 256 MB just to be able to render a single 
christmas tree :-))

Lutz-Peter

Post a reply to this message

I just read about this in an article about how they did some plants for
Shrek. They copied a base object multiple times, and only transformed it in
various ways. Also, for the trees, the leaves are generated by random number
sequences and applied/tesselated only in the renderer, thus the trees use
very little memory. They're meshes of course, but I don't see why this can't
work for all objects. I can't wait till I learn to program...

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: I can't wait till I learn to program...

  You sound like you expect to learn to program C in a couple of weeks and
go right away and modify the POV-Ray source code.
  Learning programming in such an extent that you are able to easily and
nicely modify a program like POV-Ray requires years of programming
experience (preferably from good sources of information).

  Many novice programmers have the funny misconception that they just
learn how to write programs with a programming language and they can
just right away write a Quake clone from the scratch.
  Programming is just a tool. Knowing the syntax of a programming language
doesn't give you automatically the knowledge to make big programs.
  It's comparable to knowing how to write mathematical formulas and think
that you could right away deduce the Maxwell equations from basic mathematical
and physical axioms. Or that you could write a best-seller book because you
know how to write english.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3b0a49fc@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Many novice programmers have the funny misconception that they just
> learn how to write programs with a programming language and they can
> just right away write a Quake clone from the scratch.
>   Programming is just a tool. Knowing the syntax of a programming language
> doesn't give you automatically the knowledge to make big programs.

I agree with all you said, but you didn't provide much help :-)

And C/C++ is a very advanced tool.  It is not the best way to learn
programming this way, especially if you just want to do it for fun or as a
hobby.  As you say, there is far more to programming than just learning the
syntax.  You need to learn how to put your ideas into a certain structure,
from an abstract idea into a practical implementation.  This is the hardest
to learn, and even after years you will continue learn more.  C/C++ will not
give you a fast start with this because it allows far more freedom than any
beginner can comprehend without experience.  This is in particular true when
it comes to debugging.

I don't want to suggest Basic because the main thing out there is Visual
Basic and it has little to do with the original idea of Basic (to be easy to
learn and use by novice programmers).   While a classical late 1980s
home-computer basic interpreter would probably be best, the hardware is a
bit outdated...

Pascal is still one of the most viable alternatives, and for PCs Borland's
Turbo Pascal (especially the DOS version) has easy and fast integration of
graphics.  As a language it is much "cleaner" than C/C++, and it enforces
more structure and structured thinking about a program.  On the other hand
it is fully compiled and as fast as C/C++, but easier to learn and debug,
especially without a human tutor.  Regarding books and other information,
there should be plenty in your local library.  Especially good books about
C/C++ are very expensive and hard to find in libraries...

Last but not least, as Warp said, the programming language is just a "tool",
and if you know how to use one tool it is very easy to learn how to use
another.  For learning how to use a class of tools you should really not
pick the most advanced tool out there - it will be a lot of frustration and
very little "fun" if you do so!


    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

>You sound like you expect to
>learn to program C in a couple
>of weeks and go right away and
>modify the POV-Ray source code.

That's more-or-less the plan. :)

<snip>

Thank you for taking the time to tell me this, Warp. I'm quite aware of it.
I just feel this urgency to learn the syntax so I can at least start
understanding the POV source. I know it won't be instant, but I will
understand little by little, right. And the sooner I get it, the sooner I
can help. I really do want to help make POV a better program. It's already
great, but has much room for improvement.

Post a reply to this message

On Tue, 22 May 2001 08:13:01 -0600, Tony[B] wrote:
>I just feel this urgency to learn the syntax so I can at least start
>understanding the POV source.

The syntax is the easy part.  You could probably understand the syntax now,
given that you understand POV-script and can cope with some of the other 
ideas that have been bounced around in places like this group (access to 
members, for loops, etc.)  But knowing the syntax is only a very small part
of understanding the POV source code.  Knowing the basic raytracing 
algorithm is a big part, and knowing how stuff is laid out internally 
(especially tokenize.c, parse.c, and parse.h) is a very big part.

>can help. I really do want to help make POV a better program. It's already
>great, but has much room for improvement.

Heretic! :)

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

On 22 May 2001 07:14:05 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  It's comparable to knowing how to write mathematical formulas and think
>that you could right away deduce the Maxwell equations from basic mathematical
>and physical axioms. 


laws, too.

>Or that you could write a best-seller book because you
>know how to write english.
                   ^^^^^^^

No bestsellers from you yet, eh, Warp? :)))


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: Thank you for taking the time to tell me this, Warp. I'm quite aware of it.
: I just feel this urgency to learn the syntax so I can at least start
: understanding the POV source. I know it won't be instant, but I will
: understand little by little, right. And the sooner I get it, the sooner I
: can help. I really do want to help make POV a better program. It's already
: great, but has much room for improvement.

  As Ron said, it may not be as easy as that.

  Until you have the years of programming experience needed for this,
perhaps the best way is to just suggest your ideas to someone who knows
POV-Ray source code well and ask if he could do it.
  Knowing the inner workings of POV-Ray (even if you don't know how to
program it) can be of great help when suggesting ideas because this way
you already know the possibilities and limitations (and possible work-arounds
for them) when you suggest the idea.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Peter Popov <pet### [at] vipbg> wrote:
:>Or that you could write a best-seller book because you
:>know how to write english.
:                    ^^^^^^^

: No bestsellers from you yet, eh, Warp? :)))

  You mean it should be "English"?
  I always get confused because in Finnish language names are written with
lowercase letter (country names with capital letter, as in English). For
example Finland (as a country) is written in Finnish as "Suomi", but
Finnish (as language) is written "suomi" ("Finnish language" would be
"suomen kieli").

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On 22 May 2001 11:38:39 -0400, Warp wrote:
>  Until you have the years of programming experience needed for this,
>perhaps the best way is to just suggest your ideas to someone who knows
>POV-Ray source code well and ask if he could do it.

Nah, the best way is to find someone on IRC or AIM or ICQ or whatever who
does know the innards but might not have the time to actually do it, and
ask for advice whenever you get stuck.  That's how some of what's in MegaPOV
and soon POV 3.5 got written.

It also helps to have that person, or another person, check over what you've
done an look for gotchas afterward.  Getting someone to do it for you is
a good way to never learn anything.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message