 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Daniel Beeston wrote in message <34a84806.4540198@news.povray.org>...
>Why not just add in a W vector?
I think the 4th vector is T (time).
Eric Freeman
--
"Either this man is dead or my watch has stopped."
- Groucho Marx
http://www.geocities.com/SiliconValley/Heights/2354/
http://www.datasync.com/~reba/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And we already have that in POV
--
Please also reply by E-mail.
Please remove the 'no spam' # from my address when replying by E-mail
Eric Freeman <eri### [at] geocities com> schreef in artikel
<34c7da88.0@news.povray.org>...
>
> Daniel Beeston wrote in message <34a84806.4540198@news.povray.org>...
>
> >Why not just add in a W vector?
>
>
> I think the 4th vector is T (time).
>
> Eric Freeman
>
> --
> "Either this man is dead or my watch has stopped."
> - Groucho Marx
>
> http://www.geocities.com/SiliconValley/Heights/2354/
> http://www.datasync.com/~reba/
>
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Robert J Becraft wrote:
> Brook Monroe wrote:
> >
> > The Y axis is UP? What country did YOU study geometry in? <G> This is
> > going to ruddy well make things difficult to produce in Moray, you know.
> >
>
> Yes. Hold up sheet of paper. Draw x-y graph... x goes across the
> bottom, y goes up the page... now add z... that goes on sheets of paper
> placed in front of or behind your first page.
>
> Y is UP.
>
> Regards,
> Robert J Becraft
> aka cas### [at] aolcom
Study format of U.S. Geological Survey data. X and Y comprise map surface,
Z is altitude. We're building a city--geography, not geometry. I rest my
case.
jbm!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Brook Monroe wrote:
> Robert J Becraft wrote:
>
> > Brook Monroe wrote:
> > >
> > > The Y axis is UP? What country did YOU study geometry in? <G> This is
> > > going to ruddy well make things difficult to produce in Moray, you know.
> > >
> >
> > Yes. Hold up sheet of paper. Draw x-y graph... x goes across the
> > bottom, y goes up the page... now add z... that goes on sheets of paper
> > placed in front of or behind your first page.
> >
> > Y is UP.
> >
> > Regards,
> > Robert J Becraft
> > aka cas### [at] aolcom
>
> Study format of U.S. Geological Survey data. X and Y comprise map surface,
> Z is altitude. We're building a city--geography, not geometry. I rest my
> case.
>
> jbm!
I say who cares. What's important is that our scenes look good.
Maybe there should be a separate POV-City for those who want to do it the other
way. I'd be willing to manage it, and I could usually update it once a day, if
needed.
Opinions?
~Kardal~
http://www.geocities.com/SiliconValley/2352/povpage.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just some ideas I have.....
So have it so that everybody uses the vartiable "Detail" to be able to
remove parts, or the detail of the parts of their scene,
Ie, have say detail = 1 to be the highest, and so one down.
so for my current scene I could say something like
#if(Detail <3)
do the fence
#else
do some boxes that approximate the fence
#end
So if the Detail level is 2 or more then the fence will be created in all of
it's glory, or just four boxes that will go where the fence is.
Now if all the plots use the same method for the detail, then you could have
the Detail level defined at the top and have the value trickle down through
the plots.
Another way of doing the detail, so that everybody stays with in the same
boundies, would to make the detail level a distance, so if this part of the
plot is only move into the higher detail level if the camera is within X
units of the object.
To do this, have the camera position defined as a vector = CameraPos
Then inside each plot use the vlength(thisobjectpos-CameraPos) to provide a
dist from the object inside the plot to the camera, so with the above
example I could change that to,
#if(vlength(FencePos-CameraPos)<5) // 5 units
lets show the whole fence
#else
just use the less detailed version
#end
Anyway this is just an idea.......
Now for something slightly different.....
For a river... Would this work...
Create a heightfield, flip it upside down. This would now define the river
bed.
Intersect it with a blue box that has been textured etc, and this would give
the water flowing through the river. I think ??? Not sure . Haven't tried...
Now for the axis bit. I use the left-handed system, as I have always used a
text editor, and never bothered with a modeler. For me I have always thought
of Y as height, Don't know why, just have so for me I find it easier that
way.
And for the diminsions - I use 1 unit = 1 meter, so to make it work within
the system of 1 unit = 25 meters, I have defined a var called ScaleValue = 1
/25, and at the bottom of my file put
#declare FransPlot =
union {
object {bit1}
object {bit2}
.......
scale ScaleValue
translate PlotPos
}
Now when I'm testing my plot I define a var called Testing and use in my
plot file
#ifdef(Testing)
#declare ScaleValue = 1
#else
#declare ScaleValue = 1/25
#end
etc.
BTW the usable unit range I have found in POVRay is ~ 1,000,000
Objects that are further than 1,000,000 units away from the camera
disappear, no matter how large they are. Most of the time for a small object
when it is 1,000,000 units away you wouldn't be able to see it anyway, but
if there is a large object like (eg a sun/planet) then suddenly is goes
away. I don't know yet what the smallest part of a unit that is useable, but
I don't think 25 meters to 1 unit is unrealistic. This should mean that you
could model down to around the 1cm region, or (.00004 of a unit), and that
is alot more resolution than I will probably need.
Also if you wanted to do a more detailed part of your own plot on your own
page, then change the above ScaleValue to 1 and render and wot ever you
modeled at.
Just my thoughts on the subject
Till next time.... Fran.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Great thinking, suits me fine if ever I'm going to design a plot.
But young lads not up to that sort of thinking might burn a fuse there
;-) ye know who I'm talking about I guess.
Fran Firman wrote:
> #if(Detail <3)
> do the fence
> #else
> do some boxes that approximate the fence
> #end
> #if(vlength(FencePos-CameraPos)<5) // 5 units
> lets show the whole fence
> #else
> just use the less detailed version
> #end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
