Christopher James Huff wrote:
 
> Well, first, you should be aware that there won't be any official
> discussion about POV 4 from the POV Team until POV 3.5 is finished.

Of that I am well aware. It was merely provided as food for thought. 

I am more than content with waiting. :)
 
> > Example 1.
> > PoV3 has a camera object that is used to render the scene. However, it
> > cannot be used in no other form in the scene, so making a scene that has
> > a television screen viewing the same scene requires trickery with image
> > maps and double-pass rendering, or even recreating copies of the scene.
> Well, the camera isn't really an object, it's more of a setting, like
> global_settings. You can move it around, but you can't texture it and
> you can't see it.

And why not? It does produce raster output, which can be used as texture
UV map if we render it then save the image and use it in another scene,
n'est pas? So why not let it be used as texture UV map without all that
hassle?
 
> Your example, 3 red circles on a cylinder, is quite possible...even with
> POV 3.1, though it is a lot easier with 3.5. And CSG has no side-effects
> on color.

Must have been my personal blunders, then... in my experience with 3.1,
I was not successful with making precisely those three circles that
would either protrude visibly from the cylinder as other cylinders, or
else show rendering artifacts - but not look like they were "painted on
surface".

> > for instance, it would enable the artist to use texture values to
> > control size and positioning of the objects, where currently it has
> > to be done either using random numbers or external programs.
> This can be done already in POV 3.5.

Good. 
 
> > PoV3 only has limited macro support, with parameters strictly
> > precalculated and support of true functions absent.
> What do you mean "precalculated"? And in what ways have you been limited
> by POV macros?

Can I make a macro that would calculate a macro that I would pass it in
a parameter?

> BTW, POV 3.5 supports "true functions" that can be evaluated at render
> time when necessary.

My goal was to propose a "streamlined" version of what already is there. 

I am very sorry if I seemed as if I only wanted to peck on features.
 
> > We suggest that the only and sole data type used by PoV4 should be a
> > vector.
> Well, I'd suggest 4: vector, scalar, character, object. The "object"
> type would be objects in the OOP sense, not shapes. 

I would say that scalar is merely a 1-dimensional vector.

Character/string and object are okay, certainly. Object type would be
needed to link the scene object together anyhow.

> The library would include a standard "string" object to handle characters, "file"
objects,
> etc.

Naturally.

> Anyway, you might want to look at the CSDL draft I will post in
> povray.off-topic...it is a simulation description language I'm working
> on which will have a library for POV-Ray scene description.

Could you please tell when you post it?

Post a reply to this message