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?
-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

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