Here's another issue that may get us before it's over --- memory.

It's very easy to create a scene --- one building, let alone a whole
city! --- that can consume all available memory even on a well endowed
machine.  Any good trees or plants will definitely be a problem.

I think that it's important to stress to all of the "builders" to be
frugal in their designs.  Perhaps some hard limitations on how much
the "Peak Memory Allocated" value in POV can go up when their scene is
included in a benchmark/baseline file (such as your basic city file
with no one else's scene's included).

Another possiblity, although not a simple one, is to establish a
standard for LOD (Level of Detail) control in the scene and all of its
components.  In such a scheme, when the camera position was mor than a
certain distance away from a given object (or perhaps a whole block)
that object (or in the case of blocks, multiple objects in that block)
would either not be parsed into the scene or would have simpler, less
detailed objects parsed in.   This would allow greater freedom in
creating detailed, memory-pig objects that could be seen in a close-up
render ( or a  fly-through or a walk-through ).  but would not consume
memory when it wasn't necessary.

Perhaps someone out there has already worked out the details of a LOD
control mechanism in POV that we could adopt.

  George

-----------
George Hunt --- Raytracer Obsessivo
http://ourworld.compuserve.com/homepages/lightsword
102### [at] compuservecom
-----------

Post a reply to this message

Hi Everyone,

Well, lots of ideas and opinions have been put forward here, and I
would like to gather them all together before changing the rules for
POVRayCity.  The main issues, as I see it are :-

1: Scale.  Is 1 unit =25m to tight?  If so what about 1 unit = 10 m,
or  1 unit = 1 m.?

2: Detail level.  I understand and share the concerns about the amount
of detail, and how this could affect rendering as the city grows.
Especially, as has been mentioned, when people start to grow trees
etc.  Personally I favour the idea of "distance from camera" related
detail levels,( as described by Fran Firman) but it would have to be
done in such a manner that relatively inexperienced contributors could
understand.  I also think that the "distance would have to be
definable in one place so that people can easily tweak it to suit.

3: The Plane (grass in the basement)  I'll cut a hole in it, and give
a box as a standard floor which people can cut through and build
around as they wish.

4: Are the plots the right size ?  At current scale they are about 225
m square.

5: It has been pointed out that excluding image maps will be a real
pain for certain things.  How best can these be controlled so as to
avoid duplicate file names?

6: There are several include files which people heve written and
released for public use.  I am happy for these to be included in the
baseline to save people duplicating them, and to make it easier for
everyone in general.
I am happy to add anything that a contributor asks for, as long as the
author has no objections, assuming that it is not too vast.

Good ideas are always welcome, and may be stolen if not nailed down
:-))

Bye for now,

Michael

Post a reply to this message

On Fri, 12 Dec 1997 21:41:10 GMT, mic### [at] enterprisenet (Michael
Kent) wrote:

>5: It has been pointed out that excluding image maps will be a real
>pain for certain things.  How best can these be controlled so as to
>avoid duplicate file names?
I would suggest two things.  One is that all submissions be in a zip
file, even if it is is only one file.  Second, the main directory for
the project would contain only the main scene file and any common
includes that you decide to make part of the project.  Each
contributor would have a single subdirectory off of that main
directory and all files originating with a given author would exist in
his or her directory.

  This eliminates the problem of filename collision, allows a good way
of segregating each contributors pieces of the project and it is
easily facilitated by the ZIP file idea using the "save extra folders
info" (at least that's what it's called in WinZip32 




>1: Scale.  Is 1 unit =25m to tight?  If so what about 1 unit = 10 m,
>or  1 unit = 1 m.?

If those are the choices, I'd go with the last one, 1unit = 1 m.

>2....  I also think that the "distance would have to be
>definable in one place so that people can easily tweak it to suit.

Not sure what you mean by this.

>3
  Good

>4:
  Fine with me

>6:
 OK


-----------
George Hunt --- Raytracer Obsessivo
http://ourworld.compuserve.com/homepages/lightsword
102### [at] compuservecom
-----------

Post a reply to this message

Hi everyone...

Michael Kent wrote:

<--Snip-->
> 
> 5: It has been pointed out that excluding image maps will be a real
> pain for certain things.  How best can these be controlled so as to
> avoid duplicate file names?
> 
Since every person who wants to build in the city will be assigned their
own place to build and the city is a grid, one solution to naming all
files needed would be to introduce a kind of coordinate system wich
could be used to create a naming convention, for example all files for
the first plot north and east of origo could be prefixed: n1e1, and then
if everyone would name their main file in that way ( n1e1.inc ) it would
be a very simple task including everything in the main cityfile. 

Also there would be no problem with plots covering more than one block (
eg n1-3e1-2.inc ). Anything you wanted could then be appended to the
filename: n1-3e1-2_really_fancy_texturemap.png or whatever.

Well, it's a thought...

//Hans

Post a reply to this message

mic### [at] enterprisenet (Michael Kent) wrote:

>Hi Everyone,
>
>Well, lots of ideas and opinions have been put forward here, and I
>would like to gather them all together before changing the rules for
>POVRayCity.  The main issues, as I see it are :-
>
>1: Scale.  Is 1 unit =25m to tight?  If so what about 1 unit = 10 m,
>or  1 unit = 1 m.?

I would suggest 1 unit = 1 [foot, meter, yard, whatever]. One to one
makes it easier to calculate in your head.

>2: Detail level.  I understand and share the concerns about the amount
>of detail, and how this could affect rendering as the city grows.
>Especially, as has been mentioned, when people start to grow trees
>etc.  Personally I favour the idea of "distance from camera" related
>detail levels,( as described by Fran Firman) but it would have to be
>done in such a manner that relatively inexperienced contributors could
>understand.  I also think that the "distance would have to be
>definable in one place so that people can easily tweak it to suit.

It looks like there have been a number of reasonable suggestions so
far. 

>3: The Plane (grass in the basement)  I'll cut a hole in it, and give
>a box as a standard floor which people can cut through and build
>around as they wish.

A Box sounds good. This would allow for differing 'lawns', basements,
and even underground utility runs.

>4: Are the plots the right size ?  At current scale they are about 225
>m square.

If you change the scale you might want to change the plots to a
'round' number, i.e. 200m sq., again just to make calculations 'in the
head' easier. Although the present system gives you nice even
coordinates yet still leaves space for the 'roads'.

>5: It has been pointed out that excluding image maps will be a real
>pain for certain things.  How best can these be controlled so as to
>avoid duplicate file names?

As has been suggested elsewhere go with a subdirectory structure for
each plot. I would suggest using first initial, middle initial, then
last name, i.e. 'jsfetzik' in my case. It is less likely then just
initials to repeat, but still gives things the 'personal' touch that
coordinate based names would not.

I would also suggest that the same naming convention be used for a
persons objects to be consistent, i.e. jsfetzik_object1.

>6: There are several include files which people heve written and
>released for public use.  I am happy for these to be included in the
>baseline to save people duplicating them, and to make it easier for
>everyone in general.
>I am happy to add anything that a contributor asks for, as long as the
>author has no objections, assuming that it is not too vast.

This sounds like a good idea. I am sure many of these will get used.
Tell everyone that you will take requests. If more then 2 people
request the same include I would consider it for addition. You might
want to make the inclusion conditional in the main file so that
someone can 'turn them off' by just changing one setting.


>Good ideas are always welcome, and may be stolen if not nailed down
>:-))

Might I suggest some form of macro for a plots coordinates. So that
you can relocate a plot without needing to can the 'residents' files.
I am not experienced enough with POV to know how easy or useful this
would be, but it sure could save headaches later.

Post a reply to this message

John S. Fetzik wrote:
> 
> >5: It has been pointed out that excluding image maps will be a real
> >pain for certain things.  How best can these be controlled so as to
> >avoid duplicate file names?
> 
> As has been suggested elsewhere go with a subdirectory structure for
> each plot. I would suggest using first initial, middle initial, then
> last name, i.e. 'jsfetzik' in my case. It is less likely then just
> initials to repeat, but still gives things the 'personal' touch that
> coordinate based names would not.
> 
> I would also suggest that the same naming convention be used for a
> persons objects to be consistent, i.e. jsfetzik_object1.
> 

Bit of a problem with naming the objects with your initials. I think
some of the newbies might be using modellers and don't have a clue as to
how to edit pov files, ie. they did'nt bother reading some of the pov
docs because they are too lazy ;-), so they won't be able to name the
objects themselves unless their modeller allows them to name the objects
within itself...am I making any sense?

Cheers, Matthew

Post a reply to this message

> Bit of a problem with naming the objects with your initials. I think
> some of the newbies might be using modellers and don't have a clue as to
> how to edit pov files, ie. they did'nt bother reading some of the pov
> docs because they are too lazy ;-)

Hey!!!  I resemble that remark!

Jerome "I Love ED" O'Neil

Post a reply to this message

Starting with moray?!  I started and still use raw pov code.  Moray is too
confusing.

~Kardal~

Matthew Mc Clement wrote:

> John S. Fetzik wrote:
> >
> > >5: It has been pointed out that excluding image maps will be a real
> > >pain for certain things.  How best can these be controlled so as to
> > >avoid duplicate file names?
> >
> > As has been suggested elsewhere go with a subdirectory structure for
> > each plot. I would suggest using first initial, middle initial, then
> > last name, i.e. 'jsfetzik' in my case. It is less likely then just
> > initials to repeat, but still gives things the 'personal' touch that
> > coordinate based names would not.
> >
> > I would also suggest that the same naming convention be used for a
> > persons objects to be consistent, i.e. jsfetzik_object1.
> >
>
> Bit of a problem with naming the objects with your initials. I think
> some of the newbies might be using modellers and don't have a clue as to
> how to edit pov files, ie. they did'nt bother reading some of the pov
> docs because they are too lazy ;-), so they won't be able to name the
> objects themselves unless their modeller allows them to name the objects
> within itself...am I making any sense?
>
> Cheers, Matthew

Post a reply to this message

Kardal wrote:
> 
> Starting with moray?!  I started and still use raw pov code.  Moray is too
> confusing.
> 
> ~Kardal~
> 

Yup, you're right, moray is to confusing. I myself tried and then
stopped using it almost immediately. Can't get used to the interface.
Now, Amapi, thats a modeller that has an awesome interface and is free
for a whole year under Linux(generous shareware??). Unfortunately it
only exports pov meshes....well, theres nothing to it, emacs, here I
come!!!!

Cheers, Matthew

Post a reply to this message

Matthew Mc Clement wrote:

> Kardal wrote:
> >
> > Starting with moray?!  I started and still use raw pov code.  Moray is too
> > confusing.
>
> Yup, you're right, moray is to [sic] confusing. I myself tried and then
> stopped using it almost immediately. Can't get used to the interface.

Obviously you've never seen AutoCAD.  THAT's confusing.  Moray is the
least-confusing CAD interface I've ever seen, and I'm very surprised to find
this opinion voiced.  What is it that you find so confusing?  (I'm a
Moray-for-Windows beta-tester, BTW.)

jbm!

Post a reply to this message