"Tony[B]" wrote:
> 
> Was it robbed or damaged?

	AFAIK Mark was supposed to move to his new home in mid-september
(see his last message in the "yet another bugfix version of MP+ for Linux"
thread, Aug. 29 in this newsgroup) so maybe he lost his computer on the
road ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

Oh, my...

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Neither; it's just one of those "Real Life" things.

  "Real Life"? What's that?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:39db0b13@news.povray.org...
> Ron Parker <ron### [at] povrayorg> wrote:
> : Neither; it's just one of those "Real Life" things.
>
>   "Real Life"? What's that?
>

Apparently it's that thing you run into between switching off your computer
and going to bed. Wear shoes, it has splinters in it.

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:

> For some objects, such as meshes, transformations are stored in a
> transformation matrix, leaving the base object untouched.  For a ray
> intersection, the ray must be transformed (a rather time-consuming
> calculation) into object space and then intersected with the base object.
> Then, the intersection point and normal must be transformed back into world
> space for the lighting calculation.

Hmm, if it's so expensive, why is a mesh so fast relative ot other objects
that don't need this transformation?  Is it simply because the mesh is all
triangles, which are easy to work with mathematically?

Geoff

Post a reply to this message

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote:
: Hmm, if it's so expensive, why is a mesh so fast relative ot other objects
: that don't need this transformation?  Is it simply because the mesh is all
: triangles, which are easy to work with mathematically?

  I think it's faster to test a ray-triangle intersection than a
ray-any-other-object intersection.
  There may also be something about triangle meshes being better for
octrees or something. I don't know.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   I think it's faster to test a ray-triangle intersection than a
> ray-any-other-object intersection.
>   There may also be something about triangle meshes being better for
> octrees or something. I don't know.

	I guess it's mainly the second. Just add a "hierarchy off" to
a big mesh and you will see a great saving of memory but a never-ending
rendering. Mesh are fast to render because the triangles are sorted and
the bounding-boxes put in a tree (octree ?). Unfortunately they are
also much longer to parse than an equivalent union of triangles. So
the question is: do we want to spend 15 minutes in parsing to get a
2 minutes rendering, or to get 5 minutes parsing and 10 for rendering ?
(numbers are completely random...)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
: do we want to spend 15 minutes in parsing to get a
: 2 minutes rendering, or to get 5 minutes parsing and 10 for rendering ?
: (numbers are completely random...)

  I don't think the parse-render time relation is so big. In my experience
meshes parse quite fast relative to their render time.
  Note also that parsing time is independent of image resolution while
render time isn't.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"Nicolas Calimet" <pov### [at] freefr> wrote...
>
> I guess it's mainly the second. Just add a "hierarchy off" to
> a big mesh and you will see a great saving of memory but a never-ending
> rendering. Mesh are fast to render because the triangles are sorted and
> the bounding-boxes put in a tree (octree ?). Unfortunately they are
> also much longer to parse than an equivalent union of triangles

Try mesh2.  Mesh objects save memory by making vertex & edge lists.  This
means that vertices are shared by adjacent triangles, so duplicates are
removed.  This removal of duplicates can take some time during parsing.  The
mesh2 object doesn't have to remove duplicates because it takes the edge and
vertex as its parameters and does not need to construct them.  Mesh2 objects
should parse very quickly.

-Nathan

Post a reply to this message

> Try mesh2.  Mesh objects save memory by making vertex & edge lists.  This
> means that vertices are shared by adjacent triangles, so duplicates are
> removed.  This removal of duplicates can take some time during parsing.  The
> mesh2 object doesn't have to remove duplicates because it takes the edge and
> vertex as its parameters and does not need to construct them.  Mesh2 objects
> should parse very quickly.
> 
> -Nathan

	Yes, I know all of that, and I definitely stopped using the good-old-
original mesh object when the mesh2 appeared in MegaPOV 0.3 (but I'm still
waiting the Linux port of 0.6/0.6a to get the new fixes related to textures
interpolation).
	Just a thought... Duplicates removal should not be so long since the
data are stored using hash tables. I noticed in POV 3.1g code (but not yet
checked the MegaPOV code) that the degenerate triangles are tested several
times in different places, so this is not very efficient and may slow down
the parsing.
	Also I think the mesh2 object is much faster to parse because its
size is predefined at the beginning (not necessary to allocate/reallocate
memory all the time) and there are much less data to parse for exactly the
same information. I know these are the reason why you guys created it and
I wanted to thank you for integrating the good stuff in POV 3.5 !


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message