 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Margus Ramst" <mar### [at] peak eduee> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is what I meant by making it adjustable. Double_sidedness just mean you
can see the shading of the other side through the object, right? You should be
able to use filter along with it.
It all depends on how far they go with it. Perhaps it could be made into
something like irid, where you would get brackets and all kinds of cool stuff.
How about:
double_sided {
amount [float]
color [vector]
}
Filtering and transmittence should be part of the color and be seperate from the
double_sided keyword. Translucency is just filtered opacity really. The color
would specify the color of the lighted portion of the other side of the
surface. The amount would be the brightness. I don't think a shadow color
would be neccesary, but maybe that could be thrown in.
-Mike
> 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
|
|
| |
| |
|
|
|
|
| |
