 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all,
I've had some thoughts recently on ways to improve (IMHO) POV-Ray and I
was wondering what others think. I realize that not all of these ideas are
original and I'm not trying to take credit for them all. Also I feel that
POV-Ray is a great program as is and I'm not trying to criticize it, I just
think it could be made even better.
1. Pre-parsing / POV Binary format: I think it would be very, very useful
if POV-Ray supported some sort of compiled binary format for scene files and
that this format was well defined and documented. There are a number of
benefits this could give which will be discussed below.
2. Object orientedness: I've often felt that POV-Ray is screaming to make
its scene language more object oriented. I think something like the
following would be very useful (this is not 100% thoughtout yet):
mySphere = new sphere( <0,0,0>, 1.5 );
mySphere.Texture = myTexture;
myNewSphere = mySphere;
mySphere.Scale = x*2;
myNewSphere.Scale = y*2;
while( intersects( mySphere, myNewSphere ) ) {
mySphere.x += 0.01;
}
Further, I think that if idea 1 (POV Binary format) was implemented than
this OO idea is not necessarily work that the POV-Ray team needs to do. If
someone else created a new POV scene language that correctly compiled into
the binary format then that would give a lot of flexibility.
Although, in theory, someone could write a new scene language parser now
that generates normal POV scene language I think this idea would be a lot
cleaner and easier in the long term.
3. Simplified Render Engine: If the above ideas were implemented then I
think the POV render engine could/should be simplified a bit. It would only
need to read/parse the binary format and then produce the output file. I
think that it should also have some abilities to interact with other process
to give real-time statistics information or whatever.
4. On a different track, I'd also really like to see POV-Ray have the
ability to reflect light. I know this is a difficult and time consuming
calculation but it's something I've wished for for a long time.
I think that one of the real short comings of POV-Ray right now is how
difficult it is to "know" about an object created in a scene, especially for
object interactions. At the same time I don't think the ability to do this
should be forced into the render engine. Given a clean, well defined render
engine then any outside idea could be implemented.
Thoughts, comments?
--Rainer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 29 Jul 1998 11:25:00 +0900, Rainer Mager <rvm### [at] cyber adjp> wrote:
>Hi all,
>1. Pre-parsing / POV Binary format: I think it would be very, very useful
>if POV-Ray supported some sort of compiled binary format for scene files and
>that this format was well defined and documented. There are a number of
>benefits this could give which will be discussed below.
This does sound like a good idea, so long as the format is extensible and
flexible.
>
>2. Object orientedness: I've often felt that POV-Ray is screaming to make
>its scene language more object oriented. I think something like the
>following would be very useful (this is not 100% thoughtout yet):
>
> mySphere = new sphere( <0,0,0>, 1.5 );
> mySphere.Texture = myTexture;
> myNewSphere = mySphere;
> mySphere.Scale = x*2;
> myNewSphere.Scale = y*2;
> while( intersects( mySphere, myNewSphere ) ) {
> mySphere.x += 0.01;
> }
Surely you didn't mean to scale your spheres by zero in two dimensions.
There is a big difference between saying "scale the object by 2" and "set the
scale of the object to 2," and that difference isn't apparent in this syntax.
Also, you're slipping in a new function (intersects) that would be a
tremendous chore to write, object oriented or not. Collision detection with
the kind of primitives POV-Ray provides is not easy at all.
By the way, you can approximate this now, except for the dubious intersects
function with:
#declare mySphere = sphere{ <0,0,0>, 1.5 }
#declare mySphere = object {mySphere texture myTexture}
#declare myNewSphere = object {mySphere}
#declare mySphere = object {mySphere scale x*2} // gives a warning
#declare myNewSphere = object {myNewSphere scale y*2} // this too
> Although, in theory, someone could write a new scene language parser now
>that generates normal POV scene language I think this idea would be a lot
>cleaner and easier in the long term.
Actually, as you see, it's not hard to translate what you wrote into POV code,
but the result probably takes a lot longer to parse.
> I think that one of the real short comings of POV-Ray right now is how
>difficult it is to "know" about an object created in a scene, especially for
>object interactions. At the same time I don't think the ability to do this
>should be forced into the render engine. Given a clean, well defined render
>engine then any outside idea could be implemented.
When you put the ability to know about an object into POV-Ray, you're not
putting it into the render engine. You're putting it into the parser. For
example, my object bounds patch at http://www2.fwi.com/~parkerr/traces.html
is mostly a patch to express.c, the part of the parser that deals with
expressions. The only difference between the way it is now and the way it
would be if the parser were split off is one of compile time and (I hate to
say it) run time. Yes, splitting off the parser would actually SLOW POV
DOWN as it writes the sometimes-massive binary representation to disk and
then reads it back.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
["Rainer Mager" <rvm### [at] cyberadjp>]
| Thoughts, comments?
Yeah.
| mySphere.Scale = x*2;
Do you see Scale here as a function or an attribute of mySphere?
It seems unclear to me if Scale is cumulative or not.
--
A penny for your thoughts.
Mine are more expensive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Do you see Scale here as a function or an attribute of mySphere?
>It seems unclear to me if Scale is cumulative or not.
I guess scale should be a public function that changes a private variable.
Therefore it would, presumably, be cumulative.
I guess you could rewrite my previous method as:
mySphere.Scale( <2, 1, 1> );
Given this there should probably be a way to reset the scale (and other)
values to a default:
mySphere.ResetScale;
or perhaps:
mySphere.Scale( 0 );
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You have some good points here and as I said this isn't all 100% thought
out.
Ron Parker wrote in message <35bf2617.0@news.povray.org>...
...
>Surely you didn't mean to scale your spheres by zero in two dimensions.
>There is a big difference between saying "scale the object by 2" and "set
the
>scale of the object to 2," and that difference isn't apparent in this
syntax.
>
>Also, you're slipping in a new function (intersects) that would be a
>tremendous chore to write, object oriented or not. Collision detection
with
>the kind of primitives POV-Ray provides is not easy at all.
You're right I made a mistake on that scale it should have been:
mySphere.Scale = <2, 1, 1>;
or even:
mySphere.Scale( <2, 1, 1> );
Regarding the intersects function, I realize this is a non trivial matter
especially for other more complex shapes than the sphere. This is why I
propose the functionality be put into the parser instead of the render
engine.
>Actually, as you see, it's not hard to translate what you wrote into POV
code,
>but the result probably takes a lot longer to parse.
In some cases I agree completely. Some other objects, however, would be much
harder to translate accurately. Blobs, interior effects, and some of the
higher order mathematical functions come to mind.
>When you put the ability to know about an object into POV-Ray, you're not
>putting it into the render engine. You're putting it into the parser. For
>example, my object bounds patch at http://www2.fwi.com/~parkerr/traces.html
>is mostly a patch to express.c, the part of the parser that deals with
>expressions. The only difference between the way it is now and the way it
>would be if the parser were split off is one of compile time and (I hate to
>say it) run time. Yes, splitting off the parser would actually SLOW POV
>DOWN as it writes the sometimes-massive binary representation to disk and
>then reads it back.
I don't fully agree with this. If the parser saved the scene as a well
constructed binary format scene then I believe POV could parse that file
much more quickly than it can the current file. In order to acheive this
speed-up, though, I think some other rewriting of POV would be necessary. I
haven't looked at the code buy I remember I created a scene once that had
about 30,000 objects and required about 30MB of RAM to render (regardless of
the resolution). This meant that POV was allocating an average of 1k per
object. When I considered the actual information POV should have to remember
about each object I thought that there must be a lot of waste in there
somewhere.
Part of that scene was 4 trees. Each tree contained about 5000 objects
but each tree was also identical (just rotated and positioned differently).
I think there should probably be some way for POV to handle objects that are
the same in a more memory effecient manner.
Again, I haven't looked at the code but I think some vast improvements
in parsing could be accomplished.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
