> how do you define a box with 2 floats? even length, height and depth would
> already need 3!

  I assumed that we can apply a transformation matrix to any object, including
the box.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 5 Mar 2002 06:53:17 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> 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