 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Mar 2002 06:53:17 -0500, Warp wrote:
> Ron Parker <ron### [at] povray org> wrote:
>> floats or vectors?
>
> Floats. (Of course that will create a cube, but as I said, transformations
> can make it a box of any shape, and place and orient it in any way.)
>
> Thinking about it, it actually doesn't need any floats at all. Just
> create a unit-cube by default and let the transformations do the rest.
> So in fact it requires 0 floats.
Yeah, but then we'd accuse you of being a Moray sympathizer.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I assumed that we can apply a transformation matrix to any object,
including
> the box.
in this case you have to count the transformations to the box.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thinking about it, it actually doesn't need any floats at all. Just
> create a unit-cube by default and let the transformations do the rest.
> So in fact it requires 0 floats.
So you need no memory at all since all is done in the transformations. just
few bytes to distinguish between a base-sphere, a base-box, a base-cone
.....
the most complex scene only needs few bytes then.
For the same reason we can recursively compress a file until it is 1bit in
size (which is the information -the file is there-).
regards
SY
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> in this case you have to count the transformations to the box.
But as the original claim was that six floats is enough, that would only
make an axis-aligned box, which is rather limiting.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But as the original claim was that six floats is enough, that would only
> make an axis-aligned box, which is rather limiting.
You are right, I missed typing the "at least".
So you won. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, that's very interesting stuff. I was thinking about some kind of JIP
(Just In time Parsing) for POV-Ray. (I have been scanning and browsing
through the source code today.) Only those parts of the scene that get
intersected by rays should be parsed. But this will only pay off with really
huge scenes with very large amounts of complex csg objects or other bounded
objects.
"Vahur Krouverk" <vkr### [at] comtradeee> wrote in message
news:3C7### [at] comtradeee...
> majucatur wrote:
> > Hi.
> >
> > I have a question for you, well, I'm developing a ray-tracing program
and
> > I need help with the aspect of the memory allocation. I define my
objects in
> > special structures, each object is allocated in memory dynamically, you
> > know, with memalloc and free, but the question is: How can I optimize
this?,
> > I want to use the less memory possible, because with objects like mesh
or
> > series of thousand objects consumes a lot of RAM memory, I don't know
how
> > POV-Ray uses the memory to its objects, but certainly it can trace
scenes
> > with a lot of complex objects without problem...
> >
> > Should I put everything in memory?, primitives, mesh, textures, etc.
or
> > exist a technique to use more efficiently my resources.
> If you want to render more geometry than fits into memory, then only
> option is to cache it (if you don't want to leave it to op. sys.
swapping).
> One paper I know about it could be found:
> http://graphics.stanford.edu/papers/displace/
> Google should help in finding similar papers.
> Other option is to optimize geometry. Latest Siggraph papers ('00 IIRC)
> have number of various optimizations described.
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3df2960d@news.povray.org>,
"Apache" <apa### [at] yahoocom> wrote:
> Hey, that's very interesting stuff. I was thinking about some kind of JIP
> (Just In time Parsing) for POV-Ray. (I have been scanning and browsing
> through the source code today.) Only those parts of the scene that get
> intersected by rays should be parsed. But this will only pay off with really
> huge scenes with very large amounts of complex csg objects or other bounded
> objects.
The only way to tell if part of the scene will be visible is to parse
it. If you haven't parsed an object you have no information about it to
judge visibility from. Some kind of progressive parsing where you parse
some information, determine visibility, and conditionally continue
parsing would be possible, but speedup would be minimal, and the
description language would be barely human readable. The result would
probably be much slower because of the work for determining if the
object affects the final image.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote:
> The only way to tell if part of the scene will be visible is to parse
> it. If you haven't parsed an object you have no information about it to
> judge visibility from. Some kind of progressive parsing where you parse
> some information, determine visibility, and conditionally continue
> parsing would be possible, but speedup would be minimal, and the
> description language would be barely human readable. The result would
> probably be much slower because of the work for determining if the
> object affects the final image.
You could do a bounding-sphere at the beginning of each element. The parser
could then scan past the element quickly by checking open and close braces.
It would store the center and radius of the element. Determining if the
element needs to be checked for ray collision is then simply a matter of
comparing the distance from the center of the bounding-sphere to the ray
with the radius of the bounding-sphere. If it needs to be checked, the
parser would go back and read the entire element.
--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697
-- www.respower.com -- 500+ GHz Supercomputer Starting At USD$0.50/GHz*Hour
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3eaeff00$1@news.povray.org>,
"Early Ehlinger" <ear### [at] respowercom> wrote:
> You could do a bounding-sphere at the beginning of each element. The parser
> could then scan past the element quickly by checking open and close braces.
> It would store the center and radius of the element. Determining if the
> element needs to be checked for ray collision is then simply a matter of
> comparing the distance from the center of the bounding-sphere to the ray
> with the radius of the bounding-sphere. If it needs to be checked, the
> parser would go back and read the entire element.
This would require a bounding object to be specified for every object,
and for the parser to save the entire text of each object associated
with each bounds until it parses it, which will likely take more memory
than the parsed object. This would just slow things down, eat up memory,
and make things difficult for the user, as well as making the source
code much more complex. And it adds yet another way for people to make
mistakes, the manually specified bounding. POV originally used manual
bounding, there's a reason it was automated.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> In article <3eaeff00$1@news.povray.org>,
> "Early Ehlinger" <ear### [at] respowercom> wrote:
>
> > You could do a bounding-sphere at the beginning of each element. The parser
> > could then scan past the element quickly by checking open and close braces.
> > It would store the center and radius of the element. Determining if the
> > element needs to be checked for ray collision is then simply a matter of
> > comparing the distance from the center of the bounding-sphere to the ray
> > with the radius of the bounding-sphere. If it needs to be checked, the
> > parser would go back and read the entire element.
>
> This would require a bounding object to be specified for every object,
> and for the parser to save the entire text of each object associated
> with each bounds until it parses it, which will likely take more memory
> than the parsed object. This would just slow things down, eat up memory,
> and make things difficult for the user, as well as making the source
> code much more complex. And it adds yet another way for people to make
> mistakes, the manually specified bounding. POV originally used manual
> bounding, there's a reason it was automated.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/
Plus any side-effects (assignmets to global variables) would have to be
moved outside of objects.
OTOH it might be able to create an infinite number of objects:
#macro sph
union{
bounded_by{sphere{0,0.9}}
sphere{0,1 material{hollow_glass}}
sph
scale 0.9
}
#end sph
would be parsed as:
macro, aha... blah,blah,blah... ends here.
oh, we call it: union, bounded by a 0,0.9 sphere. Nice.
....
Oh, there's something unknown in this sphere, it is:
an union, let's see it.
It contains a sphere, it's made of thin glass.
Oh, there's another union here. I't bouded by a 0,0.81 sphere. We don't need
it now.
....
That might come in handy :-)
Maybe this could be activated selectively, e.g. by a
hold{container,containment} object. Rendering hold{c_er,c_ent} would mean:
if the ray hits the c_er it parses the c_ent. It effectively suppresses an
infinite (transfinite?) recursion. Until being hit it looks just like an
object lucky enough not to be hit yet. Easy to learn, hard to master.
BTW, the reality behaves just like that: a particle doesn't know its
position until you ask it (uncertainty principle) and it behaves
differently depending on when do you observe it (quantum interference).
The hold doesn't know its contents until you ask it (uncertainty principle)
and the time for it to be parsed(observed) may affect the results greatly.
This way you can e.g. make a ray sensor that only contains itself AND counts
the photons, possibly triggering something. You can even create multiple
detectors to store the ray position, even to a file.
I can see great possibilities in conditional parsing, especially transfinite
number of objects (fractals, lattices), with no fear of losing speed if used
well. The worst you can do is to create an infinite loop, which is already
simple to do.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
