Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [Manta] Wavefront .obj reader?


Chronological Thread 
  • From: James Bigler <bigler@sci.utah.edu>
  • Cc: manta@sci.utah.edu
  • Subject: Re: [Manta] Wavefront .obj reader?
  • Date: Fri, 8 Feb 2008 12:23:06 -0700

On Fri, 2008-02-08 at 12:09 -0700, James Bigler wrote:


Flat() can take both a Texture* and a Color (which will allocate a new Texture). There's no way for the class to know in the destructor if the texture was provided or allocated.
As a general rule any pointer passed in doesn't belong to the class. I guess we could add flags everywhere that say if it was allocated or not, but this hasn't been a priority.
It could change in the future, though, as we start to pay more attention to this.


Is there any reason not using a copy constructor for Texture and free
it in destructor?

Textures are often shared between materials. We don't want copies of them. This is especially true for image textures (heavy on the memory) and procedural textures (we want to share a single interface between them for updates and changes later).

This really screams for a smart pointer infrastructure, but we have only really begun this.

In practice we don't often try to delete things. They just disappear when we close the application. ;) With that in mind, though, there has been putting some effort lately in the memory issue. Steve has started the smart pointer class, and I have been looking at destroying things. Though this destruction will ultimately be the job of the application that generated the scene. In the case of bin/ manta it will just let the memory leak and disappear when the application terminates.

James





Archive powered by MHonArc 2.6.16.

Top of page