> Actually MAX 3, from what I've seen of it, has a new interface which is more
> like Maya...  I really don't see the problem with it's current interface
> though, I thought it was quite intuitive... but then again, that's me!  LOL,
> and I'm strange!

_I_ didn't find it intuitive. Also, MAX3, AFAIK has several interchangeable
interfaces, from what a friend told me, he got this info. from a beta tester.

> I'm not sure now how anyone can really compare MAX to something like LW or
> Bryce... because MAX is just so much more advanced!!!  (well, OK, that's in
> my very bias opinion... ;-)

I never said that Bryce or Lightwave compare to MAX in power, just that their
interfaces are MUCH more user-friendly.

Post a reply to this message

Yeah, I know someone who has a copy of the beta already :)

--
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

Maya, well, it's good... not the BEST, but as good as you'll get in that
price range...

It has an extremely advanced, automated and fast character animation system
and also very advanced NURBS modelling techniques... Inverse Kinematics,
Dynamics system... It has soft-body animation too, so you can get really
realistic characters... It's particle systems are HIGHLY advanced, they can
model water, liquids, interparticle reaction, fire, smoke etc... It is also
built to run on SGI, and generally software designed for SGI is more
expensive inherently because it takes longer to develop for such a platform
(to take advantage of the G-Pipelines and advance graphics acceleration).

There are more expensive programs of course, I'm just speaking of a
particular range here...

Basically it's the top of the high-end graphics range, then there is like
the
"ultra-expensive-we-designed-this-for-ourselves-because-we-have-millions"
range... Like Pixar and ILM :-)

--
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

"Eugene Arenhaus" <chi### [at] netvisionnetil> writes:

> Here are some thoughts about what POV-Ray 4 could look like.

I've read all this over and over, and I still have the same remarks.
I cannot believe I have kept in such a bad mood for the last five
days, so I guess at least a bit of what I'm about to say is right.

> However, like it happens with many software products that have a
> long development history, it has reached a state where updating and
> adding new features poses a serious problem due to feature conflicts
> and architectural shortcomings.

  Huuh?  See the number of patches that are published these days?

> This is why I am making this bold proposal:
> 
> POV 3 should not be used as direct ancestor for POV 4.  Instead, POV
> 4 should be developed with different principles in mind, aiming at
> greatest flexibility and easy extension of the product. Backward
> compatibility with previous versions should not be considered a
> major requirement: POV 3 is reaching its limit, it's time for
> breakthrough.

  Whaaaat?  Are you *really* meaning that?  Backwards compatibility
not to be considered a major requirement?  Makes me jump on my seat
each time I read that.  How dare you speak of easy extension if you
abandon backward compatibility?

>  Hierarchical, layered object model
> 
> Currently, objects in POV are self-contained entities. Each can be
> declared with a special command, often with a unique set of
> properties.  Some of those properties are universal to all objects,
> such like colors and transforms; but many are used uniquely, like
> height maps in height field object. This leads to many little but
> nasty inconsistencies and incompatibilities, and even duplicate
> features (POV essentially has two surface-of-revolution objects, for
> instance.)

  Why is it so, in your mind?  Lemme think...  Maybe because it's the
way it is in real life.  A real object has a shape and a material.  A
raytraced object has a model for its shape (to be chosen in a set of
different models) and a model for its material (including texture,
interior, refraction etc.).  Different properties mean different
implementations. 

> The proposed model, on the contrary, would allow all objects use any
> properties freely and interchangeably.

  Yeah, like you're going to use a center and radius for a texture
map.  Or a area_light for a sphere.

[...]

> Bringing such consistency to the object model is of great importance 
> for flexibility available to the end user. For example, currently we 
> have texture maps and normal maps. (Add the height maps to it, these 
> are still another thing.) Normal maps, in turn, have special parameters 
> to control their slope, which are different from other control 
> parameters in POV.

  Of course they have!  They are different things!  Why would you want
them to behave like an atmosphere?

> With new ideology in action, we'll have only one map object to do
> all these things. We'd simply say that color channels must use one
> map, bump channel must use another map, and slope must use yet
> another map - or the same as others.

  Yes, that should have been done ages ago.  Give those haloes a slope
map!  They need it!  What for?  Uh, lemme think...  Consistency with
normal maps, that's it.  Ah, but then the quadric primitive also needs
atmospheric attenuation, doesn't it?

> (No more specially preparing image files for height fields.)

  You'll have to forgive me for that, but that sounds like one of the
biggest pieces of nonsense I've ever heard.  How do you intend to
generate height fields without specially prepared images?  Randomly?

> What's yet more important, this approach would easily allow to map
> *any* parameter. For example, it'd be possible to have turbulence
> parameter varying but a map, having turbulence gradients (an actual
> user request), or having a variable mapped IOR, for hot-air effects,
> using the same mechanism as with other mapping.

  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.

> Effective implementation of this principle would require a certain 
> change in the set of POV primitives: they would become simpler and 
> smaller; instead of being individual big machines capable of doing many 
> things they would be more like machine parts that can do only one 
> little action but also be used to assemble many machines. For example, 
> instead of having separate object for a height field, there would be a 
> special displacement map primitive applicable to geometry, and 
> turbulence parameter could be handled as separate primitive as well, 
> applicable to textures and texturable in turn. Possibilities are 
> endless.

  Sounds to me like simplicity just gets killed on the way.

>  Implementation issues 
[...]
> The actual objects would simply implement this interface, not 
> necessarily in full. For example, it makes sense that geometry objects 
> would handle ray intersections and distance computations, while texture 
> objects would handle colors. Layering these primitives would compose 
> the final objects that handle all channels through calls to underlying 
> objects.

  So you want, instead of having each object perform the task it's
meant for, to have any object perform any operation *at all*.  I still
cannot understand.

>  Full-featured object-oriented scripting
> 
> Scripting language technically might come along with scene description 
> language, but it's desirable that the scene description language itself 
> should be implemented as such. 

  Whaaat?  Object-oriented scene description language?

> We are speaking of a real interpreter here, with function calls and
> user objects.  (The current macro language is already a step in that
> direction, and it should be taken further.)

  Wake up man, you're *describing scenes*, not programming!  Is life
object oriented?  Are your car and fridge objects with attributes and
methods?  How often do you call the tap.open() or the window.close()
functions? 

> This would largely eliminate the problems with making complex
> objects, and make for smaller and cleaner scene files.

  Yes, of course.  Replace every single parameter with a function
call.  You call that readability?  And small?

Sphere Left_Eye_Ball is
  Radius : Float := 1.0;
  Center : Vector3 := <0.0,0.0,0.0>;
  Texture := new Texture_Type;
  Texture.Pigment := new Pigment_Type;
  Texture.Pigment.Type := Bozo;
  Texture.Pigment.Turbulence := new Map_Type;
  Texture.Pigment.Turbulence.Type := Gradient;
  Texture.Pigment.Turbulence.Direction := <1.0,0.0,0.0>;
  Texture.Pigment.Turbulence.Map := new Map;
[...]
end Sphere;

> Another important benefit from scripting would lie in possibility to 
> write custom functions for POV primitives, eliminating need for 
> external software. Macro language is already used very widely, but this 
> would make many more things possible - from implementing custom shaders 
> to making new custom primitives from scratch. This would also largely 
> eliminate the need for patches and plug-ins (the feature being hard to 
> implement due to cross-platform incompatibilities).

  And dramatically slow down the parsing and tracing.  Remember,
compilers were invented some time ago to produce fast code.

> It is essential that the script would provide the user with full
> access to the object interface. Script must allow the possibility to
> check surface parameters, cast rays, check intersections and so on.

  Could be nice.

>  Dynamic modular internal architecture

  Yeah, object oriented programming, in a word.

> In conclusion
> 
> This proposal comes from six years of designing the object-oriented
> software, and three years of using POV (along with other 3D software
> packages) - the experiences of the first applied to the frustrations
> of the second.

  Er...  Does this conclude anything?

  This text sounds to me like it's full of ideas.  I'm afraid most of
them are bad ones, though.  Let's sum them up.

- Abandon backward compatibility.  This is a *huge* contradiction of
  all programming principles.  (Unless of course you work for
  Microsoft, but that is not my point.)  Abandoning compatibility
  means throwing all external programs to the dustbin.  You can't
  seriously do that.
- Unify primitive interfaces.  This implies to switch from a realistic
  model (based on how the world works) to a programmingly nice model
  (based on how abstract object oriented programs work).  No, no, no,
  the raytracer uses models inspired from reality, not models that
  make it easy to program!
- Object oriented scene description language.  Means complexity.  You
  cannot expect a beginner or even a programmer to support all the
  hassle of object oriented programming just to describe a scene.
  Boy, if the scene comes from an object oriented vision of life, then
  use a scripting language to generate your scene, such as Perl or
  Python!  Programming is out of the range of a *description*
  language. 

  My conclusion: you're trying to make the raytracer stick to a very
abstract programming model rather than to how it works (remember, it's
used to simulate the way light behaves in a given environment).
You're trying to make the program an abstract one, instead of making
it easy to use.  You're trying to make POV-Ray a programming language
instead of keeping it a raytracer.

  I want to keep POV-Ray as an engine to trace!  Complex scenes are
described by complex files, and if I do not want to write complex
files then I use Perl.  With all the objects that I need.  I want to
be able to use my old Perl scripts with the new POV-Ray.  I want to be
able to write quick-and-dirty scenes without those objects.  I want to
describe scenes as they are (objects with textures) and not as they
are represented inside the engine.  And I want them to be represented
as they are and not according to some abstract and confuse model, so
that I can write new primitives when I need them.

  Ladies and gentlemen, thank you for your attention.

P.S: I have only six months of object oriented programmation behind
me (alright, that was only C++, but many consider it to be a real OO
language), many years of POV-Ray, and although I still don't see why
there is such a buzz about OO programming, all my frustrations in
POV-Ray scene description language have been solved by the -i-
option.  The #while, #for and other directives are rarely used by me.
-- 
Roland Mas

A man walks into a bar.  Bang.

Post a reply to this message

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

Roland Mas wrote:

 Yes, of course.  Replace every single parameter with a function

> call.  You call that readability?  And small?
>
> Sphere Left_Eye_Ball is
>   Radius : Float := 1.0;
>   Center : Vector3 := <0.0,0.0,0.0>;
>   Texture := new Texture_Type;
>   Texture.Pigment := new Pigment_Type;
>   Texture.Pigment.Type := Bozo;
>   Texture.Pigment.Turbulence := new Map_Type;
>   Texture.Pigment.Turbulence.Type := Gradient;
>   Texture.Pigment.Turbulence.Direction := <1.0,0.0,0.0>;
>   Texture.Pigment.Turbulence.Map := new Map;
> [...]
> end Sphere;
>

No, no, no.....this is not what it should be like. Look, I bet you have done
this a couple of times:

#declare SomeSphere=sphere{
    <0,0,0>, 0.5
    pigment{color rgb <1,0,0>}
}

object{
    SomeSphere
    // added rotations, tranlations etc.
}

This is already pretty close to OO scripting!  (SomeSphere is the "class" and
it is instanced with object{})
Now, what we can't do with the current version is this:

#declare SomeSphere.position=SomeSphere.position+<0,1,0>;
#declare SomeSphere.radius=1.5;
#declare SomeSphere.pigment=pigment{color rgb<0,0,1>};

This could be very useful.

AND, it should be fully backwards compatible with previous versions (1-3),
i.e, you should still be able to do like this...

sphere{
    <0,0,0>, 0.5
    pigment{color rgb <1,0,0>}
}

...to see a red sphere render on your screen (as the "instant" instance of
the "class" sphere{} it actually is, when you think of it...).
It's only, it would be nice to be able to access the different attributes via
dot(.) notation.

POV scripting has always been a simplified programming language - let's keep
it so.
Introducing OO scripting in POV should be done in the same spirit - powerful,
yet simplified.
POV spirit. THE spirit.

Regards,

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Mikael Carneholm <sa9### [at] idautbhbse> writes:

> This is already pretty close to OO scripting!  (SomeSphere is the
> "class" and it is instanced with object{})

Sure.  Why change that?

> Now, what we can't do with the current version is this:
> 
> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;

#declare SomeSphere = object { SomeSphere translate y }
Does exactly it.

> #declare SomeSphere.radius=1.5;

I'm not sure it really cannot be done.

> #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};

#declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
Does exactly it.

Anyway, what's the use of all that?  Want to have another sphere,
redeclare it.  Or better, if it's another sphere, use another object.
-- 
                                                         Roland Mas

Post a reply to this message

Roland Mas wrote in message ...
>
>  Huuh?  See the number of patches that are published these days?
>

Indeed. But there are a number of very useful things, like non-linear
transformations, which, IMHO, can't be done - not without very substantial
core modifications.


>
>  Whaaaat?  Are you *really* meaning that?  Backwards compatibility
>not to be considered a major requirement?  Makes me jump on my seat
>each time I read that.  How dare you speak of easy extension if you
>abandon backward compatibility?
>


I tend to agree, backward compatibility is important. Otherwise, the work of
many people, in the form of plugins, tutorials etc. would come to nothing.
But this should not be a dogma. Some compatibility will have to be
sacrificed, and has been sacrificed before, to facilitate future
improvements.

>> (No more specially preparing image files for height fields.)
>
>  You'll have to forgive me for that, but that sounds like one of the
>biggest pieces of nonsense I've ever heard.  How do you intend to
>generate height fields without specially prepared images?  Randomly?
>

Internally. This is already possible in the Superpatch. In essence, you
assign a height pattern, like a normal pattern. No need to create a separate
scene, plane, orthographic camera etc., render it and use the resulting
bitmap for the heigtfield.

>  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.

>
>> We are speaking of a real interpreter here, with function calls and
>> user objects.  (The current macro language is already a step in that
>> direction, and it should be taken further.)
>
>  Wake up man, you're *describing scenes*, not programming!  Is life
>object oriented?  Are your car and fridge objects with attributes and
>methods?  How often do you call the tap.open() or the window.close()
>functions?
>

You could call it programming (well, scripting). How much so, depends on the
particular user. And of fourse POV _objects_ are objects, and can be
instanced with different attributes. But I know too little about OOP to make
any definitive case here.

Margus

Post a reply to this message

On Tue, 13 Apr 1999 20:09:27 +0300, Margus Ramst <mar### [at] peakeduee> wrote:
>Indeed. But there are a number of very useful things, like non-linear
>transformations, which, IMHO, can't be done - not without very substantial
>core modifications.

Even if POV were completely object-oriented internally (which it will
be, someday) non-linear transformations (and other displacements) would
still require substantial modifications.  You still have to modify every
object, whether they're real "objects" or just the simulated "objects"
they are now.

Post a reply to this message

Ron Parker wrote in message <37138cb5.0@news.povray.org>...
>
>Even if POV were completely object-oriented internally (which it will
>be, someday) non-linear transformations (and other displacements) would
>still require substantial modifications.  You still have to modify every
>object, whether they're real "objects" or just the simulated "objects"
>they are now.
>

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.

Margus

Post a reply to this message

On Tue, 13 Apr 1999 22:22:40 +0300, Margus Ramst <mar### [at] peakeduee> 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

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

I agree with what you said except for:

> Translucency is just filtered opacity really.

Because it isn't... remember translucency is depth dependant...

--
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 in message <3715eac5.0@news.povray.org>...
>I agree with what you said except for:
>
>> Translucency is just filtered opacity really.
>
>Because it isn't... remember translucency is depth dependant...
>


Filter and transmit would be, too, in RL. In POV you just have to add light
attenuation to the object for this to happen.

Margus

Post a reply to this message

True, but the double_sidedness would be a fast trick.  Depth could be
simulated with nothing more that a varied illumination from the other side.
What I'm thinking of is like a leaf or a curtain.  If there was a way to
specify how much of the illuminated side of the surface shows through, things
like the viens in a leaf or the weave in cloth could be simulated.

Perhaps an opacity_map could be specified within double_sided {} :)

-Mike

Lance Birch wrote:

> I agree with what you said except for:
>
> > Translucency is just filtered opacity really.
>
> Because it isn't... remember translucency is depth dependant...
>
> --
> 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

> Adding new objects, assuming you can provide the necessary functionality
> for them, is simplicity itself.

	As I see it, it's not the fact the POV in written in 
	C that makes it troublesome to provide a patch.  It's
	the monolithic parser - you can't add parsing functionality
	without hitting the code for every other type of 
	primitive.   I'd like to see some work towards 
	modularising the parser.  I think it can be done...

-- 
Nigel Stewart (nig### [at] eisanetau)  http://www.eisa.net.au/~nigels/
Postgrad Research Student, RMIT University, Melbourne, Australia
All extremists should be taken out and shot.

Post a reply to this message

On 13 Apr 1999 16:55:57 -0500, par### [at] my-dejanewscom (Ron Parker)
wrote:

[snip]
>Finally, there are patches like my motion-blur patch that change lots of
>fundamental data structures.  Modularity won't help much there.
>
Any chance of coercing you into putting your web site in a sig line?
I'm going to have to start searching for this motion-blur patch and
docs.. Hmm, will check Twyst's site first...


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

On Wed, 14 Apr 1999 00:20:46 -0400, Nathan Kopp <Nat### [at] Koppcom>
wrote:

>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!!!!!
>
Oh boy. Calms down to avoid calling  Nathan "God". OK, I'm ready.

You know, that idea isn't half bad. I could seriously make use of that
:)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

On Wed, 12 May 1999 18:26:43 GMT, Cliff Bowman wrote:
>On 13 Apr 1999 16:55:57 -0500, par### [at] my-dejanewscom (Ron Parker)
>wrote:
>
>[snip]
>>Finally, there are patches like my motion-blur patch that change lots of
>>fundamental data structures.  Modularity won't help much there.
>>
>Any chance of coercing you into putting your web site in a sig line?
>I'm going to have to start searching for this motion-blur patch and
>docs.. Hmm, will check Twyst's site first...

You'll find it there.  It's not on my website anyway.  But before you
can convince me to put my web site in a sig line, you'll have to convince
me to have a sig line.

Post a reply to this message

On 12 May 1999 17:40:35 -0500, par### [at] fwicom (Ron Parker) wrote:

>On Wed, 12 May 1999 18:26:43 GMT, Cliff Bowman wrote:
>>On 13 Apr 1999 16:55:57 -0500, par### [at] my-dejanewscom (Ron Parker)
>>wrote:
>>
[snip]
>>Any chance of coercing you into putting your web site in a sig line?
>>I'm going to have to start searching for this motion-blur patch and
>>docs.. Hmm, will check Twyst's site first...
>
>You'll find it there.  It's not on my website anyway.  But before you
>can convince me to put my web site in a sig line, you'll have to convince
>me to have a sig line.

Well - I was kind of hoping for a two-in one deal. You know, get you
to use your web site *as* your sig line.

Any news on when the 3.1e sources might be avilable for "patchers" to
tack their code into? Not that I'm finding 3.1a and 3.1e render scenes
differently (not much they don't!)


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:370CBD92.582CBC9E@Kopp.com...
>
> >
> > Instead of multiple unique objects to handle, it's suggested to use a
> > single consistent object model for everything from geometry to
> > textures.
>
> I disagree.  I think a distinction must be made between objects,
materials,
> pigments, finishes, ...
>
> Looking at it from OO again, "a sphere HAS A material" is true, not
> "a sphere IS A material".  However, "a sphere IS A object" would be
> correct.
>

    This true, but it's also valid to say :

    "a sphere IS_A scene_element"
    "a material IS_A scene_element"

and you then can have :

    "a sphere HAS_A material"

    Just because two objects are derived from the same root object it
doesn't necessarily mean that they have an IS_A relationship.
--
Scott Hill : sco### [at] cyberlifecouk
Software Engineer (and all round nice guy)
Author of Pandora's Box : Watch this space.
Work homepage : http://www.cyberlife.co.uk

"We will decide what the news is. The news is what we tell you it is." - The
Fox TV network.

Post a reply to this message

Anthony Bennett <ben### [at] panamaphoenixnet> wrote in message
news:371### [at] panamaphoenixnet...
> I actually have a friend with 2.5. But, I don't know, I just don't like
the
> interface, never found it friendly. Now, Bryce and Lightwave, that is a
nice
> interface! You understand immediately how to use them. Too bad I don't
have a
> couple thousand just lying around...


    Too bad somebody isn't willing to give me £25K a year for writing
Pandora's Box (my not-so-soon to be freeware modeller for POV).
    I know I'm biased, but boy is it looking like it's going to be cool (If
it ever actually gets done (looking less and less likely as "the new job"
keeps getting in the way)). Nice intuitive UI (it'll work just the way _you_
want to it work!) and a powerful, yet flexible (and probably
over-ambitious), feature set.

    (Details on the web just as soon as a) I get my self a web-site and b)
they're ready for publishing (things are still too fluid for that)).

--
Scott Hill : sco### [at] cyberlifecouk
Software Engineer (and all round nice guy)
Author of Pandora's Box : Watch this space.
Work homepage : http://www.cyberlife.co.uk

"We will decide what the news is. The news is what we tell you it is." - The
Fox TV network.

Post a reply to this message

On Fri, 09 Apr 1999 15:02:45 +0200, Mikael Carneholm
<sa9### [at] idautbhbse> wrote:


>This is exactly what I didn't mean: It should _not_ be totally re-written, just
>expanded with some new possibilities. It would be _optional_ to have attributes
>in an object, and it would be _optional_ to have methods for an object. You could
>still do like you're used to, like this:
>
>box{
>  <>,<>
>  texture{}
>}
>
>...and it would still render as a beautiful box, without first being declared as
>a "class" and instanced with object{}. But, I personally would like to have the
>option to declare it like this:
>
>#declare MyBox=box{
>  <>,<>
>  texture{}
>
>  attribute speed;
>  attribute direction;
>
>  #macro Move()
>    translate speed*direction
>  #end
>}
>
>What I miss most is being able to access the different parts of an object like
>the position, size, texture etc. If those were accessable via dot
>notation(.position, .size, .texture etc) things would light up a great deal.
>
>Once again, do not remove the backward-compability, just add some new features
>that expands the scripting language and that can be used _optionally_.

I don't object to object orientation in principle, although I despise
the long-winded dot notation.  I would indeed like to have access to
the properties of an object, preferably via additional keywords and
functions.  My big problem with this proposal is that, if you dump the
old syntax for an OO version, you lose too many people who can't
handle the transition.  If you keep both syntax styles the POV parser,
already getting unwieldy, will become such a PITA that the pace of
expansion and development will slow radically and things that do get
written will have multitudes of painful bugs.  You might as well just
hire Microsux to write the next version of POV! :)

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

Jerry Anning wrote:
> 
> I don't object to object orientation in principle, although I despise
> the long-winded dot notation.  I would indeed like to have access to
> the properties of an object, preferably via additional keywords and
> functions.  My big problem with this proposal is that, if you dump the
> old syntax for an OO version, you lose too many people who can't
> handle the transition.  If you keep both syntax styles the POV parser,
> already getting unwieldy, will become such a PITA that the pace of
> expansion and development will slow radically and things that do get
> written will have multitudes of painful bugs.  You might as well just
> hire Microsux to write the next version of POV! :)
> 

I kind of agree... but since when is dot notation long-winded?  A dot,
being a single character, is about as short as you can get.  What I
dislike is having to put "#declare" in front of all assignment statements.
It's worse than the LET in very old versions of BASIC.

In some ways I wish the entire POV language could be cleaned up (but this
could cause a lack of backwards compatibility)... and I think that the
object-oriented ability to change properties of an instance of an object
is a MUST, since I think that we should be able to do animation within
a single script (without the need to re-parse!!!!) by changing an
attribute of a single object and re-rendering.

-Nathan

Post a reply to this message

On Fri, 09 Apr 1999 22:27:53 -0400, Nathan Kopp <Nat### [at] Koppcom>
wrote:

>Jerry Anning wrote:
>> 
>> I don't object to object orientation in principle, although I despise
>> the long-winded dot notation.
>
>... but since when is dot notation long-winded?  A dot,
>being a single character, is about as short as you can get.  What I
>dislike is having to put "#declare" in front of all assignment statements.
>It's worse than the LET in very old versions of BASIC.

I've just seen too many pathological specimens that look like:
Object.box.face.vertical.x_axis_normal.left.ColorVector.red.Increment(.2)
I exaggerate, but the point should be clear.  "#declare" irritates me
too.  I suppose that in my perfect world everything would be an APL
one-liner....

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

>I suppose that in my perfect world everything would be an APL
>one-liner....

Wow at least one person did not forget APL beauties ....
Another goody with APL : you don't have to store the sources : anyway nobody
can understand it even yourself as soon as you have pushed the <Return< Key.
:-)
(no joke : I loved this crazy, magic language, even the name is great :A
Programming Language)

Philippe

Post a reply to this message

Eugene Arenhaus wrote:
> 

> Hi.
> 

> Here are some thoughts about what POV-Ray 4 could look like.
> 


Hi!

What you write seem to me like a very good idea even
though there have been many negative responses in this 

newsgroup. A somewhat different suggestion rather than 

to implement your comments in a rewritten povray 4 

would be to gather a few (4-5) raytracer programmers 

and create a completely new (free!) raytracer based on
the experience we have drawn from povray. The concept 

would be the same, a scriptable raytracer engine based
on a formal language rather than a GUI, but one would 

get the chance to implement everything in a "cleaner" 

and more OO etc way...

I have been thinking for quite some time about 

implementing a povray like raytracer (not sharing any 

piece of code!) to face both the problems you mentioned
in your earlier comments and to get a chanche to 

implement a few other conceptual ideas (I will not dvelve
into those here, the posting would become very large 

otherwise). I think a clean restart on a completely 

separate program (with a completly different name and 

not using a single line of pov code or anything the like) 

would be the best since it probably would take a long 

time before the program becomes good and popular with 

users (the conceptuall ideas, both yours and mine,will 

probably have to evolve before they become 

"user-friendly". Syntax,Semantics etc will need to 

change) and facing such major changes as you proposed 

it would be best if users and developers don't see it 

as just another version of Povray.

Two negative aspects of creating a new raytracer would 

be that the math's have to be redone (immoral and 

illegal to reuse code from povray) and the risk of not 

becoming popular among the users.

So to the conclusion... are you interested in writing a 

*new* raytracer? If so I would be happy to discuss design 

issues and brainstorm features. Is anyone else (serious) 

interested in writing a *new* raytracer? It's an enourmous
task to do so but it would realy be fun...

/ Mathias Broxvall
  Student @ Linköping University . Sweden

Post a reply to this message

On Sun, 11 Apr 1999 14:11:00 +0200, Mathias Broxvall
<x99### [at] idaliuse> wrote:

>So to the conclusion... are you interested in writing a 
>*new* raytracer? If so I would be happy to discuss design 
>issues and brainstorm features. Is anyone else (serious) 
>interested in writing a *new* raytracer? It's an enourmous
>task to do so but it would realy be fun...

Someone else obviously is... see 
http://www.gnu.org/software/panorama/panorama.html

Post a reply to this message

Roland Mas wrote in message ...
>
>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.
>


Well, "slooooooowwww" would be one of the first words I'd use to describe
raytracing in general :)

Margus

Post a reply to this message

Roland Mas wrote:
> 
> Mikael Carneholm <sa9### [at] idautbhbse> writes:
> 
> > #declare SomeSphere.radius=1.5;
> 
> I'm not sure it really cannot be done.

I don't think it can be.  If it can, let me know!

-Nathan

Post a reply to this message

#declare a sphere with radius = 1 , location <0, 0, 0>and then scale it!
object
    {
        SomeSphere
        scale 1.5
        translate y
    }

Just to give the answer, I don't believe it's the best way to work with POV

Philippe

Nathan Kopp a écrit dans le message <37140FC2.5FA863D6@Kopp.com>...
>Roland Mas wrote:
>>
>> Mikael Carneholm <sa9### [at] idautbhbse> writes:
>>
>> > #declare SomeSphere.radius=1.5;
>>
>> I'm not sure it really cannot be done.
>
>I don't think it can be.  If it can, let me know!
>
>-Nathan

Post a reply to this message

Spider jumps in. Decloaked.

Ok, I've kept myself out of this thread too long .-)

Actually, some very good ideas has come, but the OO scripting is one oof my
favourites(and translucency:-)

Here goes.


Roland Mas wrote:
> 
> Mikael Carneholm <sa9### [at] idautbhbse> writes:
> 
> > This is already pretty close to OO scripting!  (SomeSphere is the
> > "class" and it is instanced with object{})
> 
> Sure.  Why change that?
Good.

 
> > Now, what we can't do with the current version is this:
> >
> > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> 
> #declare SomeSphere = object { SomeSphere translate y }
> Does exactly it.
Sure, but you can't do 
#declare SomeSphere.position.y = SomeSphere.position.x;
#declare SomeSphere.position.x = SomeSphere.position.z;

without a biiig hazzle.
 

> > #declare SomeSphere.radius=1.5;
> 
> I'm not sure it really cannot be done.
yes, but to change an objects propertised based on it's current properties.
that's where the OO mode will come in as a GREAT aid.
 
> > #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};
> 
> #declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
> Does exactly it.
yes, but if I want a nifty shader done on the object depending on its position?
That would turn out pretty nasty(Sure, use a texture, but that woudln't suit in
all cases. (ie. the whole objects pigment depends on it y value(gradient y) )
 
> Anyway, what's the use of all that?  Want to have another sphere,
> redeclare it.  Or better, if it's another sphere, use another object.
It's not another sphere. It's the SAME sphere. That's the point with oo. 


> --
>                                                          Roland Mas

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Spider <spi### [at] bahnhofse> writes:

> > > Now, what we can't do with the current version is this:
> > >
> > > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> > 
> > #declare SomeSphere = object { SomeSphere translate y }
> > Does exactly it.
> Sure, but you can't do 
> #declare SomeSphere.position.y = SomeSphere.position.x;
> #declare SomeSphere.position.x = SomeSphere.position.z;

True, even if I can't see the use of such a thing.

> yes, but if I want a nifty shader done on the object depending on
> its position?  That would turn out pretty nasty(Sure, use a texture,
> but that woudln't suit in all cases. (ie. the whole objects pigment
> depends on it y value(gradient y) )

I'm afraid I don't understand that sentence.

> > Anyway, what's the use of all that?  Want to have another sphere,
> > redeclare it.  Or better, if it's another sphere, use another object.
> It's not another sphere. It's the SAME sphere. That's the point with
> oo. 

If it's the same, why did you declare it wrongly in the first place?
Declare it with the correct parameters...
-- 
Roland Mas

It would be hard to be deader without special training.
  -- Theatre of Cruelty (Terry Pratchett)

Post a reply to this message

On Wed, 14 Apr 1999 14:05:41 +0200, Spider <spi### [at] bahnhofse> wrote:
>> > Now, what we can't do with the current version is this:
>> >
>> > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>> 
>> #declare SomeSphere = object { SomeSphere translate y }
>> Does exactly it.
>Sure, but you can't do 
>#declare SomeSphere.position.y = SomeSphere.position.x;
>#declare SomeSphere.position.x = SomeSphere.position.z;
>
>without a biiig hazzle.

I've said it before and I'll say it again: if you need access
to the position of the sphere, put it in a variable when you know
it, then use the variable later.  Yes, this is simplistic.  Yes,
it's not as sexy as having lots of dots (the most-used word of 1997
was dot, after all.)

>> Anyway, what's the use of all that?  Want to have another sphere,
>> redeclare it.  Or better, if it's another sphere, use another object.
>It's not another sphere. It's the SAME sphere. That's the point with oo. 

There's no use to moving the spheres around unless you have the ability 
to save the scene for use in the next frame.  If that's what you want
to do, you already have semi-persistent variables with the read/write 
stuff, though in principle I'm opposed to persistent variables anyway, 
since they sorta kill any scalability-across-a-network an animation 
might have had.

Post a reply to this message

Roland Mas wrote:
Ok, here I go again :-)
 
> Spider <spi### [at] bahnhofse> writes:
> 
> > > > Now, what we can't do with the current version is this:
> > > >
> > > > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> > >
> > > #declare SomeSphere = object { SomeSphere translate y }
> > > Does exactly it.
> > Sure, but you can't do
> > #declare SomeSphere.position.y = SomeSphere.position.x;
> > #declare SomeSphere.position.x = SomeSphere.position.z;
> 
> True, even if I can't see the use of such a thing.
Ok, but it was the point that was meant. The possibility to access an objects
current position without having to use a variable for each value. I know I am
lazy, but I still want to be able to do this:
light_source {
  location camera.location
  colour rgb 1
  shadowless
  spotlight
  point_at camera.look_at
  radius...
}
Without declaring the variables 
#declare scCameraLocation = <-1200, 105, 1000>;
#declare scCameralookAt = <...>;

and so on..

And the other places it would be nice in can be a include file accessing the
camera postition for placing items, (like a lens-flare) as well as light_sources
positions. (now here is a hazzle, how to access the RIGHT light_source ? add
them in an array? Give them a name identifier?

> > yes, but if I want a nifty shader done on the object depending on
> > its position?  That would turn out pretty nasty(Sure, use a texture,
> > but that woudln't suit in all cases. (ie. the whole objects pigment
> > depends on it y value(gradient y) )
> I'm afraid I don't understand that sentence.
If you take a look at my world macro, the boxes have an height value. 
if I take  this a few steps further, and want to give more objects a pigment
depending on the distance from the camera, I'd either have to declare all the
object points in variables(arrays) or start adding vlength(pos-campos)
everywhere. This is just one use that hits me now.

> 
> > > Anyway, what's the use of all that?  Want to have another sphere,
> > > redeclare it.  Or better, if it's another sphere, use another object.
> > It's not another sphere. It's the SAME sphere. That's the point with
> > oo.
> 
> If it's the same, why did you declare it wrongly in the first place?
> Declare it with the correct parameters...
But that's the nasty point...
It may not be possible to do so at all, but to have to go with #declares, yes.
say I want to use simpsons method to integrate a point on a curve. (it's a
recursive algorithm, using the last values for computing) 
just one idea for use.

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Ronald L. Parker wrote in message >Someone else obviously is... see
>http://www.gnu.org/software/panorama/panorama.html
>

I agree wholly about the compatibility issue. Panorama might be the greatest
raytracer in the world, but as it uses a completely different scene
language, I cannot use ANY POV-Ray code/macro/snippet etc... so this ends
the question.

About the syntax issue: one might preprocess an OO scene language into the
POV-Ray one, adding a new language without harning back compatability. By
the way, C++ started just a C preprocessor. When the raytracing community
eventually settles on a POV-Ray++ language (you heard it here first ;-)  )
then it can be embedded in the official program.

In the past i have written posting which have generated quite a good deal of
flames. I was not meaning to steal anybody code (I am a programmer and I do
not like thieves) or messing around. I was proposing extensions which might
give raise to improvements WITHIN the overall accepted framework of POV.

a.c### [at] iolit

Post a reply to this message

On Tue, 27 Apr 1999 12:10:11 +0200, Alessandro Coppo <a.c### [at] iolit> wrote:
>
>Ronald L. Parker wrote in message >Someone else obviously is... see
>>http://www.gnu.org/software/panorama/panorama.html
>>
>
>I agree wholly about the compatibility issue. Panorama might be the greatest
>raytracer in the world, but as it uses a completely different scene
>language, I cannot use ANY POV-Ray code/macro/snippet etc... so this ends
>the question.

You must have missed the part where it mentioned that someone is writing
a POV-script frontend for it.

Post a reply to this message

Spider wrote:

> Ok, but it was the point that was meant. The possibility to access an objects
> current position without having to use a variable for each value. I know I am
> lazy, but I still want to be able to do this:
> light_source {
>   location camera.location
>   colour rgb 1
>   shadowless
>   spotlight
>   point_at camera.look_at
>   radius...
> }
> Without declaring the variables
> #declare scCameraLocation = <-1200, 105, 1000>;
> #declare scCameralookAt = <...>;

> and so on..

Nice to see someone else who has realised the usefulness of OO scripting. As I said:
what I miss most when writing include files for POV-Ray, is the possibility to
access attributes of different objects like the camera, a lightsource or whatever.
What's more, I'd like to be able to access the current frame number, the initial
clock, the final clock etc - i.e, all the INI file settings. So I think a keyword
for the next version of POV would be 'accessible' as in 'all attributes are now
accessible'.

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Ron Parker wrote in message <3725e41b.0@news.povray.org>...
>You must have missed the part where it mentioned that someone is writing
>a POV-script frontend for it.

From what I know, the real problem is that Panorama engine does not support
many features of POV e.g. I think that there is nothing comparable to all
the media bells and whistles (VERY beatiful and VERY slow).

Anyway, I again advise NOT to select a new language for version 4 but to
experiment with preprocessors and frontends. When there will be a general
agreement, add the new language.

Alessandro Coppo
a.c### [at] iolit

Post a reply to this message

On 13 Apr 1999 18:57:55 +0200, rol### [at] casimirrezelenstfr (Roland
Mas) wrote:

>Mikael Carneholm <sa9### [at] idautbhbse> writes:
>
>> This is already pretty close to OO scripting!  (SomeSphere is the
>> "class" and it is instanced with object{})
>
>Sure.  Why change that?

?? Surely the scripting in POV 3.1 is pretty similar to that in 3.0,
or even the first version of POV scripting. why did they change it? To
improve on it's functionality.

>> Now, what we can't do with the current version is this:
>> 
>> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>
>#declare SomeSphere = object { SomeSphere translate y }
>Does exactly it.

Not quite, I suspect. Isuspect the OOP example would change the
position property of the pre-defined object "SomeSphere" (which could
of course consist of googillions of sphere and/or other objects rather
than just 1 sphere) rather than creating a new object. Where memory is
tight or the object complex (or both) it might well be preferable to
adjust the properties of the object rather than declaring a whole new
object, or keeping texture, location, object etc. etc. seperate and
only combining them at "object placement time" (far more complex and
liable to user error IMO).

>> #declare SomeSphere.radius=1.5;
>
>I'm not sure it really cannot be done.

As long as the SomeSphere object is just a single sphere, seems easy
enough to do in POV script as is.

>> #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};
>
>#declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
>Does exactly it.

Again, I could be wrong but I suspect the OOP line is modifying the
properties of an existing object where you are specifying how to
create an object with such-and-so properties (providing, IIRC, that it
isn't already textured/coloured).

>Anyway, what's the use of all that?  Want to have another sphere,
>redeclare it.  Or better, if it's another sphere, use another object.

Not necessarily ideal. Take making an asteroid out hundreds of
randomly jittered sperical blob components as an example. Simly
adjusting the texture might make a cloud of asteroids easier to do
than re-declaring each asteroid - especially if (for any reason) each
asteroid is meant to be identical in actual shape (oh it can be done -
but tedious for the modeller and computer alike).

Pov already has some dot notation. I'm not particularly familiar with
the POV scene description language, or very adept with it, but I'm
sure I've seen .x, .y, and .z used to retreive co-ordinate
information. What's the political argument against extending this
(already present) style of object data access?


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

On Wed, 12 May 1999 18:26:41 GMT, Cliff Bowman wrote:

>>> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>>
>>#declare SomeSphere = object { SomeSphere translate y }
>>Does exactly it.
>
>Not quite, I suspect. Isuspect the OOP example would change the
>.position property of the pre-defined object "SomeSphere" 

...

>it might well be preferable to
>adjust the properties of the object rather than declaring a whole new
>object

You're not declaring a whole new object.  Since you're putting it in
the same place, the old one gets destroyed and the new one takes its
place.  The only thing that might be optimized better is the fact that
while the object {...} block is open, there are two copies of the object
in memory.


>Not necessarily ideal. Take making an asteroid out hundreds of
>randomly jittered sperical blob components as an example. Simly
>adjusting the texture might make a cloud of asteroids easier to do
>than re-declaring each asteroid - especially if (for any reason) each
>asteroid is meant to be identical in actual shape (oh it can be done -
>but tedious for the modeller and computer alike).

For this were macros invented.

Post a reply to this message