|
 |
Hi,
I'm generating rather large (40 Mb) meshes that consist of transparent and
abient triangles.
As I have limited (280 Mb) of memory in my mashine, it seems like the
computer starts to swap when the generated picture has certain properties.
Please see the "resulting" image below (best viewed in monspace) - the
charactes are actually many small trianges.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
yyyyyyyyyyyyyy
yyyyyyyyyy
yyyyy
yyy
When rendering the X's the rendering of the picture almost halts (PovRay
gets about 10% of CPU usage at best). When the tracing of the picture
reaches the y's CPU usage is about 90% and rendering goes considerably
faster. I suspect this has to do with how the triangles are layed out
in memory.
Currently my mesh generator lays out the mesh as follows:
#declare triangles = mesh2 {
vertex_vectors {
468028,
<-966, 0.644779, 0>, <-965, 0.644779, 0>, <-964, 0.654999, 0>, .......
<-965, 0.644779, 1>, <-964, 0.649919, 1>, <-963, 0.648213, 1>, .......
........
<0, 0.644779, 900>, <0, 0.644779, 900>, <0, 0.654999, 900>
// The X-axis is varied first, then the Z-axis
.......
}
face_indices {
933156,
<0, 1, 967>, <967, 1, 968>, <1, 2, 968>, <968, 2, 969>, <2, 3, 969>,
.......
}
Could someone with intimate knowledge of the PovRay mesh data structures
or other relevant experiences advise me if rendering speed could be
improved by laying out the vertex vectors by iterating over the Z-axis
values first and keeping the X-axis constan as far as possible.
I.E. in pseudo code change:
for (z = 0; z < z_max; z++) for (x = 0; x < x_max; x++) { print (<x,y,z>)}
to
for (x = 0; x < x_max; z++) for (z = 0; z < z_max; z++) { print (<x,y,z>,)}
- or is the rendering speed affecte by how face indices are layed out
(not so simple to give an example, but i gues that the layout possibly also
should follow the principles laid out above.
Imporant to know is that the (orthographic) camera is facing parallell with
the Z-axis.
It is of course possible to try different aproaches and change the generator
of the trinagle mesh, but the algorithm is quite involved, and it would save
me a lot of work if someone could, if describe an exact method to lay out
the triangles, atleast give me a hint on what steps (if any!) could be taken
to improve rendering speed when generating meshes.
I will be glad to report my findings, or summarize any result (I will also
report if nothing, other than bying more memory, can be done) and would
allready now like to extend my thanks in advance if someone gives me advice
on how to improve rendering speed.
Also if anything is unclear - don't hesitate to ask (explaining
pictures in 3D is not that easy - and I may have left out some
crucial information considered "obvious").
Best regards
Jan
Post a reply to this message
|
|
|
|
On Tue, 18 Feb 2003 05:58:01 EST, "idoit" <ido### [at] tiscali se> wrote:
>Could someone with intimate knowledge of the PovRay mesh data structures
>or other relevant experiences advise me if rendering speed could be
>improved by laying out the vertex vectors by iterating over the Z-axis
>values first and keeping the X-axis constan as far as possible.
It's been some years since I messed with this lets see how much I
remember. POV-Ray allocates storage for each object as it's parsed, in
the order the objects are parsed. Then all objects are traversed to
build the bounding tree. Once rendering the system has to page in as
the objects are referenced, thus locality of reference has a lot to
say in avoiding paging. If the bounding tree doesn't fit in real
storage you're in for a really long trace.
>I.E. in pseudo code change:
>for (z = 0; z < z_max; z++) for (x = 0; x < x_max; x++) { print (<x,y,z>)}
>to
>for (x = 0; x < x_max; z++) for (z = 0; z < z_max; z++) { print (<x,y,z>,)}
Should make quite a difference, but reflections and light rays will
cause objects to be referenced 'outside' the area they occupy
on-screen. With 'well-behaved' meshes you can have memory usage up to
4-8 times real memory without much paging, once the bounding tree is
built.
/Erkki
Post a reply to this message
|
|
|
|
Thanks Erkki,
I hope to be able to finish the re-coding of my mesh generator this weekend
and i report back.
Best reagrds,
Jan
Erkki.Sondergaard wrote:
>On Tue, 18 Feb 2003 05:58:01 EST, "idoit" <ido### [at] tiscalise> wrote:
>>Could someone with intimate knowledge of the PovRay mesh data structures
>>or other relevant experiences advise me if rendering speed could be
>>improved by laying out the vertex vectors by iterating over the Z-axis
>>values first and keeping the X-axis constan as far as possible.
>
>It's been some years since I messed with this lets see how much I
>remember. POV-Ray allocates storage for each object as it's parsed, in
>the order the objects are parsed. Then all objects are traversed to
>build the bounding tree. Once rendering the system has to page in as
>the objects are referenced, thus locality of reference has a lot to
>say in avoiding paging. If the bounding tree doesn't fit in real
>storage you're in for a really long trace.
>
>>I.E. in pseudo code change:
>>for (z = 0; z < z_max; z++) for (x = 0; x < x_max; x++) { print (<x,y,z>)}
>>to
>>for (x = 0; x < x_max; z++) for (z = 0; z < z_max; z++) { print (<x,y,z>,)}
>
>Should make quite a difference, but reflections and light rays will
>cause objects to be referenced 'outside' the area they occupy
>on-screen. With 'well-behaved' meshes you can have memory usage up to
>4-8 times real memory without much paging, once the bounding tree is
>built.
>
>/Erkki
>
Post a reply to this message
|
|
