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


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