 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> Johannes Hubert wrote:
>
> > And the "non-programmers" would get a language for which the manual
> > would actually be *thinner* than it is now, a language that is more
> > approachable and easier to learn (because frankly I think, that many of
> > you here who advocate POV-Script as an easy language to learn have lost
> > perspective a bit, since you alreay *know* POV-Script: sure, newbies
> > *can* learn POV-Script, but the language is far from being easy to learn
> > and could be much more so in my opinion).
>
> It's obvious that there's a general consensus about the fact that the pov
> syntax,
> having evolved from a simple scene description language to a "programming"
> language has now problems of its own. And you're right, it was never easy to
> learn, and I know of people who downloaded pov and were scared right away.
> However, I think that the original construct "primitive transform texture",
> written in such a way, is very intuitive. I know of teachers who use it at
> school
> to teach maths to kids. I guess it's intuitive because it's close to actual
> language :
> "the sphere is big and blue".
>
> My own ventures in OO programming and other advanced programming indicate
> that, though there's no discussion on the necessity of it when it comes to
> programming efficiency, it also requires a *much higher* level of abstract
> thinking.
> This may be natural to full-time programmers, but for many people
> (including me) these ways of thinking are extraordinary hard, if not
> impossible, to grasp. Many of the concepts discussed in this thread
> (or in the programmers' wish lists) are simply out of my intellectual reach.
Time to add my own two cents, I suppose.
The POV scene language is a bit of an engineering nightmare, since its
usefulness is more or less inversely proportional to its ease of use.
(As is usually the case with such things.) Fortunately for us, you're
not required to access *all* of the complexity to use the language; you
can define very simple scenes very easily without having to mess with
any of that "weird programming stuff".
I don't think we need to add a zillion ways of doing the same thing;
this is almost certainly the idea of some well-meaning but foolish
programmer who thinks that POV should look more like a "real language"..
as if he has the authority to decide what that is. What we DO need is
some polish. This is a raytracer meant for end users, not a
correspondence course in computer science. Either the package should
include a comprehensive set of tutorials (particularly on things like
isosurfaces, realistic skies and water, media, lighting techniques and
complicated crap like that), or it should be provided as a separate download.
And it would be nice if POV-Ray had some sort of plugin architecture so
that if someone wanted to hard-code a tree-generator or fur-generator to
save parsing time, rendering time, and/or memory, they could do it.
Patches could use the same architecture, since they would basically work
the same way (extension to the parser and some custom code to do the
actual work). It wouldn't prevent you from using #includes, and since no
casual user is going to be able to figure out how those things work
anyway, if it's that important to be able to modify the plugins, the
creators could always provide source code.
Finally, it's my opinion that the POV language is *already* OO. I would
love for anyone who disagrees to explain to me how
object
{
dimensions { foo }
transformation { foo }
texture { pigment { foo } }
texture { pigment { foo } normal { foo } }
whatever { foo }
}
...is in *any* way fundamentally different from something like
object.dimensions = foo
object.transformation = foo
object.texture[0].pigment = foo
object.texture[1].pigment = foo
object.texture[1].normal = foo
object.whatever = foo
--
Xplo Eristotle
http://start.at/xplosion/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CAA340.E350695A@pacbell.net>, lin### [at] povray org
wrote:
> The Devil made me do it...
Uh-oh, you had better start running your self diagnostics and virus
detection routines more often.
> Absolutely not. I have no patience for positioning 30,000 objects
> by hand in a GUI modelling program.
I said a tree *generator*...I didn't say anything about hand placing all
the objects.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
True, but what if you had to type:
ediBatchFile->Text = ediBatchFile->Text + "There is more..";
wouldn't you like to have to type only:
ediBatchFile->Text += "There is more..";
you even don't have to copy & paste, then.
--
Regards,
Sander
Matt Giwer <jul### [at] ijnet> schreef in berichtnieuws
38C994D0.C4A06309@ij.net...
> OK. Any what is the value beyond saving a few keystrokes?
>
> The time required for extra keystrokes is the last thing that
> worries even the best of programmers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> If you have a few features to request, then go ahead and request them!
> One of the reasons features are not added is that nobody says they want
> them. You way there are other things you would consider more important
> than syntax streamlining, what are they? You mention clouds, oceans,
> fur, etc but didn't really give much information on what you want to see.
Before we had many people doing patches, the common idea was to not
bother the pov-team with feature requests (and the pov-team is very shy,
for good reasons) and, in fact, most of what have appeared in the development
of pov were very logical improvements. The other problem is that
non-programmers can't tell what's possible from what isn't and may be afraid
to look silly.
Want some ideas ? I've got a trunk full of them...
Clouds : we don't have presently a good system to make them.
Apart the old bozo/granite method (which works
very well sometimes), the 2 current methods (media and multiple planes)
share the same problems : they take ages (forget about using them in large
resolution pictures), may look grainy and they're basically scene-dependent.
These methods have led to impressive pictures but they're very difficult to set
up.
However, I'm pretty sure that something like a cloud
pattern with its specialized parameters would do (think of the brick pigment).
It wouldn't need to interact with the environment (only with the light position
and color) and we wouldn't be able to fly through.
But it would be enough for all the scenes that needs a realistic sky background
that doesn't look too much painted over.
Of course, it would come with cloud structures (cumulus, cirrus etc.),
variable fluffiness, and maps for the most common cloud effects
(white bright clouds, storm clouds, sunset clouds, silver lining etc), and it
could be animated. Several cloud layers could be added.
Ocean and water : some on-the-fly height-field generation would do, provided it
gives the proper aspect of a 3D ocean surface. Add a foam and spray ability
too...
It could be animated.
Tree generation : if someone has a PhD about this, it should be possible
to create a general purpose tree growth model (Cf PlantStudio for a general
purpose
plant model) whose parameters could be stored in text files (and provided
with the general pov distribution). There would be a tree fonction that would
call
the model parameters and be fed some variables :
tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)
Look at AMAP for instance
http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
Pov would then generate a mesh, but like in Nathan Kopp's implementation
of radiosity and photon map, you could save the optimized mesh between
sessions.
Other stuff :
- a specialized pattern for dirty walls and concrete. There's no way to
properly
add marks and splotches in a way that doesn't seem regular (unless you use
image_maps, or add layers and layers and layers)
- a way to project a pigment on a particular spot of an object (some sort of
decal ;
to do this with pov now it's necessary to cut out the part, apply the pigment
and reinsert the part)
- a improved brick pattern, that would allow for not-so-square bricks not
fouled up by turbulence
- a snake scales pattern (used directly, or through uv mapping)
- a cracks pattern (there's one in Leveller)
Hmmm. I guess that's enough wishful thinking for tonight !
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Of course, it would come with cloud structures (cumulus, cirrus etc.),
>variable fluffiness, and maps for the most common cloud effects
Variable fluffiness, that sounds so cool. =)
Ah, I'm to tired...
--ll
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CAC206.1E895C99@inapg.inra.fr>, Gilles Tran
<tra### [at] inapginrafr> wrote:
> Before we had many people doing patches, the common idea was to not
> bother the pov-team with feature requests (and the pov-team is very
> shy, for good reasons) and, in fact, most of what have appeared in
> the development of pov were very logical improvements. The other
> problem is that non-programmers can't tell what's possible from what
> isn't and may be afraid to look silly.
That is one of the things the TAG team is for, to get feature requests,
filter out the outrageous, useless, or impossible ones(like, um, a
graphical modelling interface as an example.), and let the POV-Team know
this is a desired feature.
> Want some ideas ? I've got a trunk full of them...
Good, maybe some will get on my to-do list. :-)
> Clouds : we don't have presently a good system to make them.
> Apart the old bozo/granite method (which works very well sometimes),
Actually, I kind of like wrinkles for clouds.
> the 2 current methods (media and multiple planes) share the same
> problems : they take ages (forget about using them in large
> resolution pictures), may look grainy and they're basically
> scene-dependent. These methods have led to impressive pictures but
> they're very difficult to set up.
Using media with method 3 sampling gets rid of the graininess and is
faster(it is much like the old atmosphere or halo), and any method which
does 3D clouds is going to be slow. You aren't going to get much faster
than media method 3.
> However, I'm pretty sure that something like a cloud pattern with its
> specialized parameters would do (think of the brick pigment).
> It wouldn't need to interact with the environment (only with the
> light position and color) and we wouldn't be able to fly through. But
> it would be enough for all the scenes that needs a realistic sky
> background that doesn't look too much painted over. Of course, it
> would come with cloud structures (cumulus, cirrus etc.), variable
> fluffiness, and maps for the most common cloud effects (white bright
> clouds, storm clouds, sunset clouds, silver lining etc), and it
> could be animated. Several cloud layers could be added.
Maybe just a general "sky" feature, which would replace(or enclose?) the
current sky_sphere and rainbow.(I consider "background" to be a separate
feature from these) You could add cloud layers, and adjust density,
type, etc. Maybe also stars, nebulae, aurora's, etc. There would also be
a "sun_light", which wouldn't illuminate the scene but would affect the
clouds. This would greatly simplify that part of the feature.
> Ocean and water : some on-the-fly height-field generation would do,
> provided it gives the proper aspect of a 3D ocean surface. Add a foam
> and spray ability too...
> It could be animated.
Height fields using the pattern feature in MegaPOV can be animated. By
"on-the-fly", do you mean parse-time or render-time? The "pattern"
feature is parse-time, isosurfaces can be used to get render-time height
fields. As for the foam and spray...I have been wondering what a
particle system syntax could be like.
> Tree generation : if someone has a PhD about this, it should be
> possible to create a general purpose tree growth model (Cf
> PlantStudio for a general purpose plant model) whose parameters could
> be stored in text files (and provided with the general pov
> distribution). There would be a tree fonction that would call the
> model parameters and be fed some variables :
> tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)
>
> Look at AMAP for instance
> http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
> Pov would then generate a mesh, but like in Nathan Kopp's implementation
> of radiosity and photon map, you could save the optimized mesh between
> sessions.
"the result of tens of years of research in plant growth simulation."?
I think a growth simulating algorithm like this would be a little
excessive. And what about different leaf types? And fruit/flowers/seed
pods/willow branches?
The usual recursive growth algorithm should be enough, if you modify it
so you can specify "avoidance regions" occupied by an object which the
plant would grow around. Something like this:
plant {
base_position VECTOR
start_radius FLOAT
recurse_depth INTEGER
max_branches INTEGER // maximum number of times to branch per "node"
branch_probability FLOAT
//the probability the algorithm will branch at each "node"
max_branch_angle FLOAT
radius_scale FLOAT // the factor the radius decreases by each level
direction VECTOR // specifies the direction growth starts in
gravity VECTOR // causes the plant to grow against or with gravity
gravity_change VECTOR
// allows the gravity effect to change, so for example,
// tips of branches grow upwards more than main branches
random_seed SEED // allows you to get a specific plant
leaf_object {...}
trunk_texture {...}
avoidance_object {...}
// The plant will "grow" to avoid penetrating this object.
// Use union here to avoid multiple objects.
}
Of course, there would be default values for all of these...
> Other stuff :
> - a specialized pattern for dirty walls and concrete. There's no way
> to properly add marks and splotches in a way that doesn't seem
> regular (unless you use image_maps, or add layers and layers and
> layers)
My blob pattern could be useful for this, it is included in MegaPOV. You
could hand place the splotches or make a macro or just a loop to create
them automatically.
> - a way to project a pigment on a particular spot of an object (some
> sort of decal ; to do this with pov now it's necessary to cut out the
> part, apply the pigment and reinsert the part)
You could use the object pattern to confine the pattern to a specific
place. The object pattern is included in MegaPOV. You might also be able
to do what you want with the blob pattern.
> - a improved brick pattern, that would allow for not-so-square bricks not
> fouled up by turbulence
I don't like the brick pattern at all...I just use real bricks. :-)
> - a snake scales pattern (used directly, or through uv mapping)
Don't forget fish scales. I think this is possible with a combination of
texture maps and repeat warp, or with function patterns, but a
specialized pattern might be useful.
> - a cracks pattern (there's one in Leveller)
Hmm, have you tried agate? Or kinds of turbulence?
Or are you looking for a branching type of crack, that looks sort of
like lightning? That could be done with the blob pattern and a macro or
two.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine wrote:
>
> Tor Olav Kristensen wrote:
>
> > How about making the editor do the re-typing for the lazy ones?
>
> 1) What if you want to change it later? You have to do it twice.
> 2) People can use whichever syntax they prefer.
> 3) If more and more fancy features are added to the editor it will consume more
> resources.
> a) I'm not saying I don't like column-select and all that; very useful!
> b) I don't like it when the computer modifies my work.
> 4) :-p
People can press whatever keys they like.
So if you preferred not to hit that function key, then the computer
wouldn't modify your work...
;-b
Tor Olav
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmmm...Your for loops looks like c-syntax to me.
Would you suggest that one allowed similar things
to be allowed in a for-loop declaration in the
POV-language that one allows in C?
E.g. initialize several variables, call other
functions/macros within the declaration itself etc. ?
If not, then I my opinion is that one should
choose another syntax for the for-loop that doesn't
make the users believe that the same rules applies
as in C.
And: Wouldn't it be better that the control
variable(s) in a for-loop is local to the for-loop?
Tor Olav
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html
Chris Huff wrote:
>
> In article <38C816BE.35E35A1C@hotmail.com>, Tor Olav Kristensen
> <tor### [at] hotmailcom> wrote:
>
> > But what if the loop control variable is a vector that is shared
> > between several nested loops? (See my example macro below.)
> >
> > Would this be possible with nested for-loops?
>
> It would be possible, but not necessarily the best way to do it.
> Something like this:
>
> #macro ObjectSplit(Thing, Point1, Point2, nnv)
> // Cuts an object into several "box"-parts
> // Result is returned in an array of such parts
>
> //#local nnv = <nx, ny, nz>;
> #local ThingArray = array[nnv.x][nnv.y][nnv.z]
> #local dPoint = (Point2 - Point1)/nnv;
>
> #for(Cntv = <0,0,0>; Cntv.z < nnv.z; Cntv.z += 1)
> #for(Cntv.y = 0; Cntv.y < nnv.y; Cntv.y += 1)
> #for(Cntv.x = 0; Cntv.x < nnv.x; Cntv.x += 1)
> #local ThingArray[Cntv.x][Cntv.y][Cntv.z] =
> intersection {
> object { Thing }
> box { Point1 + dPoint*Cntv, Point1 + dPoint*(Cntv+Unitv) }
> }
> #end // for
> #end // for
> #end // for
>
> ThingArray
>
> #end // macro ObjectSplit
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I particularly like the ideas posted above of adding the C-style FOR loops
and
>such. I would find these particularly helpful as I am just getting my feet
wet
>with C programming and I could work on my C coding with POV.
I mentioned how great for-loops would be about a year ago. My idea was
rejected at the time. I personally prefer writing
#for(C,C<N,C++)
[block]
#end
to writing
#declare C = 0;
#while (C<N)
[block]
#declare C = C + 1;
#end
And I think that it would help a lot of code to look cleaner. What the heck,
why not make it so you write for-loops, but POV reads it in like a while
loop for its own internal purposes?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Like what? I really don't know what you mean...
>Do you want a goto statement or something?
<cringe> <shudder>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
