 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 13 Apr 1999 22:22:40 +0300, Margus Ramst <mar### [at] peak eduee> wrote:
>OO wasn't exactly what I was talking about here. More along the lines of the
>modular design concept. While I am by no means familiar with the
>technicalities, I am under the impression that integrating new features
>(processes, objects etc.) is more difficult than it need be. You tell me,
>you know better.
Adding new objects, assuming you can provide the necessary functionality
for them, is simplicity itself. Likewise with new textures and warps. The
only thing most people might have trouble with is adding keywords to the
parser, but even that isn't really all that hard if you follow the existing
examples. Unless you're doing something like the isosurface patch that
makes massive parser changes, but even those hook into the existing code
in relatively few places.
Adding new functions, like trace() or min_extent(), is fairly easy. Again,
these are small parser changes that are easy once you know where to make
them.
Adding new global functionality like U-V mapping or displacement mapping or
nonlinear transforms, however, requires a change to every object type. Even
in a more modular world, this would still be the case. If I need to add a
"give me a triangle mesh" function to the base class, I will either need
a default implementation of it, or someone will have to add it to each and
every derived class. From a non-OO, modular standpoint: if I add that function
to what's expected from an object, every plugin will have to change. The
issue here, for those who have worked with COM or CORBA or Java, is that the
*interface* to an object is changing and requires all implementations of that
interface to change. Nathan has gone the default-implementation route with
the UV patch, and I suspect the displacement stuff, if it is ever added, will
be done similarly. That part could be made easier with a modular or OO
approach, in that you'd only have to change the nondefault implementations.
I don't see any way of making the rest easier, though.
Other patches like dispersion and photon mapping and blurred reflection and
so forth are fairly localized already to whatever piece of functionality
they affect (all lighting code, in these cases.) Modularity wouldn't help
much there, because the code in question is already in only one place.
Another (potential) kind of patch adds functionality to the language itself,
like the old #macro patch. These are purely parser changes, and some are
easier than others. I don't know of any current examples of such patches.
Finally, there are patches like my motion-blur patch that change lots of
fundamental data structures. Modularity won't help much there.
Perhaps what we need more than modularity is documentation of how patches are
done. I think DSW is working on that, but I'm sure he could use our help.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Margus Ramst" <mar### [at] peakeduee> writes:
> Roland Mas wrote in message ...
[...]
> > Variable IOR means bent rays, which is kind of a huge piece of work
> >to do. I agree on the use of these features, though.
> >
>
>
> I suppose this _could_ be simulated with volume sampling, like in
> media. But that's my uneducated guess.
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.
Would be nice, though :-) For all of us who had to model the path of
a laser in a fiber, by writing a C program...
--
Roland Mas
Autumn leaves are brown... And the sky is gray...
-- California Dreaming (The Mamas and the Papas)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <3713af5d.0@news.povray.org>...
>
>Perhaps what we need more than modularity is documentation of how patches
are
>done. I think DSW is working on that, but I'm sure he could use our help.
This would indeed be invaluable. I only wish I could help. But I'm afraid I
can't. Until it is complete - or I manage to familiarize myself with the
inner workings of POV in some other manner - I will defer any further
arguments over the goods and ills of POV's sructure.
I still think a plugin architecture would greatly facilitate implementing
many new features. But I will not start this dispute all over again.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Margus Ramst wrote:
>
> I still think a plugin architecture would greatly facilitate implementing
> many new features. But I will not start this dispute all over again.
And I still agree with you and later this summer might start working on
something. (I think Ron was going to play with something related to this
too).
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
For all of you who dislike the concept of object oriened POV script, I think
one thing should be clarified. At least some of us are proposting a semi-
object oriented language... where we implement the encapsulation and (in a
wierd way) inheritence, but NOT data hiding. That means you can access
parts of an object but you don't have to do so through methods.
The main reason I want to do this is because I think that for POV go get
better for animation, it needs to be able to do an entire animation from
a single script WITHOUT RE-PARSING BETWEEN FRAMES!!!!!
How would this look?
-----------------
#declare myCam = camera{...}
#include "big_tree_macro_takes_forever_to_parse.inc"
#declare myTree = object{MakeTree() translate ...}
#declare fr=0;
#while (fr<10)
myCam.translate <...> // translate acts like a method
#declare myCam.angle = ...; // angle acts like a property
clearFrame() // special function that clears all objects from scene
global_settings{...} // global settings for this frame
// now we put our objects in the scene
camera{ myCam } // use the new camera settings
object{ myTree } // and no need to re-parse the tree
// now we render
RenderFrame(fr) // a special function that renders the frame (filename
// based on the parameter
#declare fr=fr+1;
#end
--------------------
Now, I want to make a comment about that statement were translate acted like
a method. You see, in some ways I'm beginning to think that POV should
follow the same ideology as Perl. The April 1999 Communications of the ACM
has a great article by Larry Wall (original author of Perl) called "The
Origin of the Camel Lot in the Breakdown of the Bilingual Unix".
The article talkes about the Perl community (which reminded me much of the
POV community). Larry Wall also talked about how Perl was designed to be
a language like a human spoken/written language... one that is kind of
ad-hoc and NOT minimalistic like so many other languages.
A quote from the article: "People who hype orthogonality should be
sentanced to draw everything with an Etch-a-Sketch."
I found the article very enlightening, since I have in the past been
pro-minimalistic, thinking a grand-unified-appoach would be best.
So, maybe we should let the POV scripting language evolve in a way that,
as somebody else mentioned, makes sense to the humans, and then we'll
force the computer to understand. ;-)
In a previous post I mentioned that I would appreciate a re-write of the POV
language... but as I've thought about it more, the POV scene description
languate is pretty good... some of the things that have been suggested
would actually be going BACK to POV version 1.0 syntax... it must have
been changed for a reason (because people didn't like it the old way).
I've done quite a bit of programming inside POV, and it is really
relatively easy to add functionality to POV. Adding new keywords to
the parser is really simple, IMHO. Adding new objects is also
relatively easy (and orthogonal... yes, I still have quite a bit of OO
blood in me).
Adding the photon map was alot easier that many of you probably think it
was. It required very localized changes to the core of POV. And I
really doubt if the photon mapping could have been implemented via a
plug-in of any sort unless someone had thought of it when designing the
plug-in interface.
Well, that's my current thoughts on the topic.
One last thing... I really don't like typing #declare... I've got some
ideas on how to 'fix' this, but they should go in a different thread.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, Chris Young says that adding an optional double_sided shaded keyword to
finish is being considered. If it could be given an amount, you got yourself
some translucency!
-Mike
Lance Birch wrote:
> I agree with all your thoughts... nuf said :)
>
> Oh, and add translucency to the list of new features ;-) he he he Sorry,
> but I just couldn't resist it!
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
> For a totally different experience, visit my Chroma Key Website:
> Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
er... sure about that? I don't know, wouldn't that just mean that the
object has kind of like a double sided thickness? I mean, translucency is
something that carries THROUGH the object...
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind
Mike wrote in message <371### [at] aolcom>...
>Hey, Chris Young says that adding an optional double_sided shaded keyword
to
>finish is being considered. If it could be given an amount, you got
yourself
>some translucency!
>
>-Mike
>
>Lance Birch wrote:
>
>> I agree with all your thoughts... nuf said :)
>>
>> Oh, and add translucency to the list of new features ;-) he he he
Sorry,
>> but I just couldn't resist it!
>>
>> --
>> Lance.
>>
>> ---
>> For the latest 3D Studio MAX plug-ins, images and much more, go to:
>> The Zone - http://come.to/the.zone
>> For a totally different experience, visit my Chroma Key Website:
>> Colorblind -
http://www.fortunecity.com/skyscraper/parallax/359/colorblind
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
>
> er... sure about that? I don't know, wouldn't that just mean that the
> object has kind of like a double sided thickness? I mean, translucency is
> something that carries THROUGH the object...
What do you mean by "through" the object? Maybe you do want media?
Or maybe what you're looking for is a mixture of double-sided shading
and a bit of filter/transparancy (or no_shadow).
I think that the double_sided keyword should take a float value that is
used to attenuate the shading for the 'wrong' side. That would add a
bit more flexibility.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That's true but it's not the right effect, and media takes too long to
render (while it can be used to make the effect). What I was saying is just
make it an entirely separate feature to media while being in the interior
statement... (because it's like media, but it'd be a separate algorithm to
calculate it...)
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://www.fortunecity.com/skyscraper/parallax/359/colorblind
Nathan Kopp wrote in message <3714E69D.6DD677E7@Kopp.com>...
>Lance Birch wrote:
>>
>> er... sure about that? I don't know, wouldn't that just mean that the
>> object has kind of like a double sided thickness? I mean, translucency
is
>> something that carries THROUGH the object...
>
>What do you mean by "through" the object? Maybe you do want media?
>Or maybe what you're looking for is a mixture of double-sided shading
>and a bit of filter/transparancy (or no_shadow).
>
>I think that the double_sided keyword should take a float value that is
>used to attenuate the shading for the 'wrong' side. That would add a
>bit more flexibility.
>
>-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The main reason I want to do this is because I think that for POV go get
> better for animation, it needs to be able to do an entire animation from
> a single script WITHOUT RE-PARSING BETWEEN FRAMES!!!!!
>
Yeah!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
