Rainer Mager wrote:
> 
>     One other thought I've had was going back to the interpreted idea
> mentioned above. I was wondering if a very small, tightly coded, minimum
> feature-set of ray tracing could be written and compiled and from that set
> additions are added. I do not know enough about the details of a ray tracer
> to say too much more but it seems there are things in POV that need not be
> in the core of the program. For example, shouldn't there be a more flexible
> way to define objects such that there need not be so many different types?

Hmmm... no.  More flexible means more features means more types of objects.
What do you want?  To always start with a sphere and have to deform it into
the object you want?  Always define your objects as an isosurface?  Use only
triangle mesh objects?  I don't think many people would be happy.

If you think POV has too many options/objects/textures, take a look at 3DS
MAX... the features there (especially when you add plugins) are practically
endless (MAX gave me a headache the first time I used it, but I think the
multitude of features are quite useful).

My opinion:  more object types = more flexibility and speed = better system.

> Yes, yes, I know, this would cause a speed hit on the rendering but I'm
> wondering if that could be minimized via the scener parser/compiler.
> Similarly, all of the warps, turbulations, media, etc should be able to be
> emilimated via a very basic system. Perhaps something that allows flexible
> object definitions, flexible light definitions, and flexible texture
> definitions, and the camera of course. After all isn't that all we need?
> Every pov scene is simply objects with textures, light (maybe with texture),
> and the camera (maybe with textures). Even media can just be objects with
> textures.

Well, technically it's in the object's interior, not it's texture.

>     If those 4 things could be broken down into a very basic definition then
> everything else could be built on top of that in some scripting language. If
> those basics were optimized enough in the main code then perhaps the later
> scripting slowness would not be too bad.

In raytracing, it think that it's safe to say that EVERYTHING should be
optimized, not just the very basic stuff.  Slowness is never "not too bad",
unless there is no other way to solve the problem.

-Nathan Kopp

Post a reply to this message

Oh, I forgot to say...

I LOVE the idea of a brand new scripting language for POV with an old
compatibility-wrapper put over it!  I don't think the current syntax
really has what it takes to get things done, since it can't access
and the properties of object instances or access many rendering
engine features.

-Nathan

Post a reply to this message

> 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


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