Chris Huff wrote:
> 
> I think it's safe to say that most of the reason for choosing C++ is to
> allow making the source code fully object-oriented.

Is there any other?  

Other than being allowed to use // comments.


-- 
Francois Labreque | In the future, performance will be measured
    flabreque     | by the size of your pipe.
        @         |             - Dogbert, on networking
   videotron.ca

Post a reply to this message

In article <3A69F1CD.EBAC06D2@videotron.ca>, Francois Labreque 
<fla### [at] videotronca> wrote:

> > I think it's safe to say that most of the reason for choosing C++ is to
> > allow making the source code fully object-oriented.
> 
> Is there any other?  
> 
> Other than being allowed to use // comments.

The const keyword, stricter type checking, and overloaded 
functions...probably a couple others. Some might like the memory 
management better, you can use classes to wrap functions and data 
together even if you aren't doing OOP.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> I briefly considered this exact feature

Hmm...

> but there is no way I could do it. Maybe when POV 4.0 is
> available, and the source code is fully object-oriented

I expected that.

> Or a pigment map of several portal_pigments, and use the
> function pattern to change portals...(just use a single
> value as the function, it would act like the "solid" pattern)

I like our mutual understanding... :)

> The syntax would be pretty easy though...just something like
> the camera: the last world defined is the one that gets used,
> and you would be able to #declare them to allow you to refer
> to them from other worlds.

I don't think it makes sense to declare a world. I would rather just assign
each world an ID.
Maybe like:

world {
   WORLD_ID
   ...anything inside the world goes here...
}

Later you could add more things to the same world by using the ID of an
already existing world:
world {
   WORLD_ID
   ...add more things to the same world...
}

I envision the cameras being the keys to the worlds. Multiple cameras could
be located in each world, and each camera would have an ID.

world {
   WORLD_ID
   camera {CAMERA_ID ...}
   camera {CAMERA_ID ...}
}

Lastly you would define which camera to use as the active one. I don't know
how this would be done, maybe:

global_settings { camera CAMERA_ID }

The world in which the active camera is located is the active world. Default
would be to use the last defined camera.

For all portals you could specify which world should be the "target" for the
portal. If nothing is specified the current world would be default. (Where
"current" means the world in which the portal is located.)

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a6a02e7@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> I don't think it makes sense to declare a world. I would rather just 
> assign each world an ID.

My reasoning was that identifiers are only added to the with #declare, 
#local, #macro...and that there wasn't a good reason to change that. 
Also, the "keyword {IDENTIFIER" syntax is used in POV already, for 
creating a copy of something already defined, and this would cause 
needless confusion. "world {RedWorld" looks like it is creating a copy 
of RedWorld.

Maybe each world would be limited to a separate file, and imported like 
this:
#world WorldIdentifier "worldFile.pov"
But I would prefer the syntax that treats each world more like an object.

PS: "world" or "universe"? The latter seems more specific, but the first 
is shorter...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> My reasoning was that identifiers are only added to the with
> #declare, #local, #macro...and that there wasn't a good
> reason to change that.
> I would prefer the syntax that treats each world like an object.

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.

Once a world is created I think it should indeed "exist" (though not
necessarily visibly), and not just be waiting to be called.

> 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

How about this?
It could also be used like:

#world (WorldIdentifier)
   #include "worldfile.pov"
#end

> 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...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Chris Huff wrote:
> 
> I briefly considered this exact feature, but there is no way I could do
> it.

Couldn't it be done as an extension of the light_groups philosophy? E.g. if the
the camera ray hits an object that is not in the camera's "world group" the
intersection is discarded; a portal would (among other things) redefine the
camera's group id, so further testing along this ray is done for a different
"world group".

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

In article <3A6B3E85.303666C0@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Couldn't it be done as an extension of the light_groups philosophy? 
> E.g. if the the camera ray hits an object that is not in the camera's 
> "world group" the intersection is discarded; a portal would (among 
> other things) redefine the camera's group id, so further testing 
> along this ray is done for a different "world group".

I think that would slow down the rendering of the world being directly 
rendered, possibly by a lot. It also would probably lead to some highly 
confusing multi-world files.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a6ac143@news.povray.org>, "Rune" <run### [at] inamecom> 
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] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I think that would slow down the rendering of the world being directly
> rendered, possibly by a lot. It also would probably lead to some highly
> confusing multi-world files.
> 

Why? Only an intersection test would be done for objects not in the camera's
group - no reflections, lighting, textures, volume etc. Granted, it would still
be slower, but I don't think the performance hit would usually be that bad.
And why would the files be confusing? The way I see it, the syntax should look
pretty much the same as files using light_groups (new syntax), perhaps also with
a "global" modifier for blocks that are always rendered.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

In article <3A6B58FE.5D934F76@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Why? Only an intersection test would be done for objects not in the 
> camera's group - no reflections, lighting, textures, volume etc. 
> Granted, it would still be slower, but I don't think the performance 
> hit would usually be that bad.

An intersection test can be quite costly...think about where most of the 
slowdown of complex CSG or isosurface scenes is coming from. But you 
shouldn't even need an intersection test, just skip checking the object 
at all if the object's world ID doesn't match the current world ID...but 
it is still an unnecessary piece of work to be done, especially for 
adding features later...the coder would have to write code for handling 
which universe their object/effect is in. And memory use would 
increase...assuming a limit of 256 "worlds", by one additional byte for 
each object/camera/light/glow/global_settings/any other entity in the 
scene, ...which could add up to a lot, especially with highly complex 
CSG objects.
Having each "world" be separate would allow essentially unlimited number 
of worlds (not that anyone is likely to have more than 256...), have 
lower memory overhead, eliminate any extra work during rendering, etc...
Extending the separation into the syntax means simpler parsing code, 
easier to understand scenes, and would allow easily combining of scenes 
that weren't originally written to support multiple worlds (you would 
just include the scene file in it's own world {} block).
But of course all this is theoretical, since work on POV 4.0 hasn't even 
started yet and we have no idea how different the scene language will be.


> And why would the files be confusing? 

A jumble of cameras/lights/objects/global settings each belonging to a 
different scene? Files get complex enough as it is...and it makes sense 
to group the stuff for each virtual universe together. It just seems 
like it would be easier to use...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message