Is there a reason why copying a CSG object doesn't work like copying
a mesh? I can't figure any reason why copying a mesh just by taking
another "reference" to it but not copying the mesh data itself is ok,
but doing it for a (big) CSG is not ok.
  I think that many scenes would definitely take advantage of the memory
saving, specially with very big CSG's.

-- 
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 wrote:
> 
>   Is there a reason why copying a CSG object doesn't work like copying
> a mesh? I can't figure any reason why copying a mesh just by taking
> another "reference" to it but not copying the mesh data itself is ok,
> but doing it for a (big) CSG is not ok.
>   I think that many scenes would definitely take advantage of the memory
> saving, specially with very big CSG's.

In the same category, I think somebody once posted a patch allowing
*_maps cacheing. What happened to it? Could it be integrated to some
nice patched version?
-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote...
>   Is there a reason why copying a CSG object doesn't work like copying
> a mesh? I can't figure any reason why copying a mesh just by taking
> another "reference" to it but not copying the mesh data itself is ok,
> but doing it for a (big) CSG is not ok.
>   I think that many scenes would definitely take advantage of the memory
> saving, specially with very big CSG's.

It really could be done, but would require a re-write of a good chunk of
POV.

The issue has to do with how transformations are handled and how textures
are stored.

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.

Other objects, such as boxes, spheres, and discs, are transformed by
modifying the object itself.  (e.g. If you translate a sphere, the center
point will be moved, and the transformation matrix will still be null.)
This means faster render times (no need to transform the ray, because object
space = world space).

A CSG object is just a collection of individual objects with special
intersection rules.  When a CSG is transformed, all of the child objects are
transformed at parse time.  To allow duplication of a CSG, a new
transformation stack would have to be created for the CSG, which would slow
things down.  Also, unions are often split apart before rendering.  This
will often greatly increase speed performance (due to bounding-box octree
storage and search).

Now, about textures:  As noted above, at the end of all intersection
routines, before lighting happens, the intersection and normal are in world
space.  They must be translated to texture space before texture calculations
can be done.  Each level of nested and layered textures can have their own
list of warps (including one or more linear transformation matrices).  When
a texture is applied to an object, a complete copy of the texture (along
with all of its warps) is made and attached to the object.  When the object
is transformed, all attached textures are transformed with it (just like the
transformation of child objects in a CSG).  This way the textures "go along
for the ride."  For speed reasons, these object transformations (which
affect the texture) are merged into the top-level warps for the texture.
(Two transformation matrices can be merged into a single one using matrix
multiplication.)

All of this means that textures are volatile.  After they are applied to an
object, they will change when the object is transformed.  That means that,
if two objects reference the same texture, and you move one object, the
texture on the other object would slide around.

Now, I'm not saying that it couldn't be done, but I am saying that it would
take a lot of very careful planning.  Personally, I'm going to wait until
POV 4 to try it.

-Nathan

Post a reply to this message

That was a fascinating read. I hope you guys do try it for 4.0. It's a very
good idea. :)

Post a reply to this message

Well, now I've got a much better perception/understanding
of the POV internals considering transformations on objects and
textures. That was a great, clear reading. Maybe this text should
be included in the POV docs so that anybody can figure out how
this raytracer is (partly) made. If I read that before, I probably
could avoid to bother you, Nathan, with all the questions rela-
ted to the mesh2 object and its triangle texture interpolation
some monthes ago...

	[Thanks for the new release of MegaPOV ! I hope M. Gordon
will have time to prepare the Linux version soon {ring,ring}]


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

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: Other objects, such as boxes, spheres, and discs, are transformed by
: modifying the object itself.  (e.g. If you translate a sphere, the center
: point will be moved, and the transformation matrix will still be null.)
: This means faster render times (no need to transform the ray, because object
: space = world space).

: A CSG object is just a collection of individual objects with special
: intersection rules.  When a CSG is transformed, all of the child objects are
: transformed at parse time.

  Ah, this makes it very clear. I understand now why it would be a problem.

-- 
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 wrote:

>         [Thanks for the new release of MegaPOV ! I hope M. Gordon
> will have time to prepare the Linux version soon {ring,ring}]

M. Gordon has been seperated from his computer these last few weeks
but hopes to have it in his possession again in the near future.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Was it robbed or damaged?

Post a reply to this message

On Tue, 3 Oct 2000 11:50:50 -0500, Tony[B] wrote:
>Was it robbed or damaged?

Neither; it's just one of those "Real Life" things.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.
Proudly not helping RIAA and SDMI steal my rights -- 
  http://www.eff.org/Misc/EFF/Newsletters/EFFector/HTML/effect13.08.html

Post a reply to this message

"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