|
![](/i/fill.gif) |
In article <3a6ac143@news.povray.org>, "Rune" <run### [at] iname com>
wrote:
> Normally when something #declared is called, a copy of it is created.
> For a world that would use way to much memory. Some other approach
> should be found.
I don't see the problem...the memory is going to have to be allocated
for it anyway, and if the user makes another variable with the "world
{WorldIdentifier" syntax, they probably are expecting to get a copy.
There would normally be just one copy, though...
And you are still thinking in terms of how POV currently does
stuff...since it is practically impossible until POV 4.0's C++ rewrite,
things might change a lot.
> Once a world is created I think it should indeed "exist" (though not
> necessarily visibly), and not just be waiting to be called.
Of course.
> > Also, the "keyword {IDENTIFIER" syntax is used in POV
> > already, for creating a copy of something already defined
> > Maybe each world would be limited to a separate file, and
> > imported like this:
> > #world WorldIdentifier "worldFile.pov"
>
> I see the point although I'd prefer a solution where a world didn't
> have to be in a separate file. Currently no features in POV-Ray
> *require* separate files (except images etc.). Include files are
> optional and never required.
>
> #world (WorldIdentifier)
> ...anything goes here...
> #end
This looks good, with the exception of the parentheses...the macro
syntax would be similar, though the world wouldn't take parameters and
wouldn't be "called". How about:
#world WorldIdentifier |(optional file name)|
...scene stuff here...
#end
However, you wouldn't be able to build on a "base" world with this
syntax...you would have to put the base world in an include file.
With the "world as object" syntax, you could do something like:
#declare BasicWorld = world {...checkered plane and bozo sky...}
#declare GreenWorld = world {BasicWorld ...green reflective sphere...}
#declare RedWorld = world {BasicWorld ...red reflective sphere...}
#declare ChromeWorld = world {BasicWorld ...chrome reflective sphere,
portals to RedWorld and GreenWorld}
world {ChromeWorld}
It would basically be a "super union" that could include global
settings, local variables, cameras, etc...
Variables in each world could be accessed with dot notation:
GreenWorld.FrontCamera, for example. The portal pigment could let you
specify what world you want the rays to reappear in.
> > PS: "world" or "universe"? The latter seems more specific,
> > but the first is shorter...
>
> I think "universe" is too specific, at least the scientific sense of
> the word. The feature would probably often be used just to make
> different "sets" "stages" or "scenes". Actually I think "scene" would
> be better than both "world" and "universe" if it wasn't for the fact
> that POV-Ray files are often referred to as "scene-files" which would
> cause confusion...
How would "universe" be too specific? It describes exactly what is
happening...multiple virtual areas whose contents are completely
isolated from each other except were they refer directly to something
from another scene.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |