team-scandraid team mailing list archive

[Darius Blaszyk <dhkblaszyk@xxxxxxxxxxxxx>]

Hi Arno,

I've been thinking a bit on the VertexBuilder and MeshBuilder there are
two things I would like to discuss;

1. Currently there seems to be some inconsistency between both classes.
VertexBuilder seems to store "raw" data (which means no smoothing is
applied, it is directly calculated from the scanline be it an
interpolated scanline or not) and MeshBuilder which seems to be going to
store some smoothed data (ScanDraiD::create3DFile averages vertices in
horizontal and vertical direction).
I would like to propose to have MeshBuilder also store unsmoothed mesh
data. For this I would like to make the Mesh struct a linked list of
Vertex structs. So a Vertex struct in memory will be shared in the
vertex array and mesh array.
As smoothing is a very complex topic I would like to postpone this to a
later release version.

2. As VertexBuilder and MeshBuilder are so closely linked, do we need to
have two classes here? Would it be sufficient to have one class and
simply pass a boolean variable setting "CalcMesh"? If true then
following vertex calculations the mesh is determined, else only an empty
mesh vector is returned. Perhaps we could actually create a double
linked list with vector and mesh data. This way we could even loose one
struct.

Darius

On Fri, 2009-05-08 at 23:12 +0200, Darius Blaszyk wrote:
> On Fri, 2009-05-08 at 13:55 +0200, arno wilhelm wrote:
> > Hello Darius,
> > 
> > >> > - added Rectangle struct
> > >> > - ScanlineParameters now has a ClipRect variable
> > >> Ok think I have got it:
> > >>      this way you can select an area of the picture that is going to
> > >> be scanned for Scanline ?
> > >>     Good idea !
> > > It does exactly that yes.
> > 
> > I have seen that the motion detection software 'motion'
> > (motion.sourceforge.net) uses a picture as mask.
> > The black parts mask the picture to be scanned and so only the parts
> > under the transparent part are dealt with.
> > This might also be a possibility ...
> 
> Although this will give you more flexibility in terms of non rectangular
> areas, I don't see the true added benefit of this approach. Would like
> to propose to leave this one as it is right now. If needed we could
> always implement it at a later stage.
> 
> > 
> > >> Maybe we could also use a brightness parameter (or even a color?)
> > >> parameter for scanning the pics ?
> > >> I mean then you could only consider certain pixels and disregard others ?
> > > This is possible with what you call a convolution matrix, when you
> > > convert from RGB to gray-scale. We could expose this convolution matrix
> > > to the user of course, but the question is what would be the gain? I'm
> > > no expert in this field, so I can't judge well on this. Perhaps you have
> > > a resource or paper on this?
> > > In the end it's also about, how complex you would like to make the lib
> > > for usage.
> > No, dont have a paper about this. But maybe we should design the
> > library flexible enough, so that we can add these features later
> > without problems ?
> Yes, we could expose the convolution matrix at a later stage. 
> 
> > I also think it would be a good idea if a user of the library could
> > use such complex stuff if he wants, but if he does not he should not
> > even have to deal with advanced stuff like this.
> > This could probably be done with default parameters and method
> > overloading. What do you think ?
> True, but I don't see the added benefit right now.
> 
> Darius
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~team-scandraid
> Post to     : team-scandraid@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~team-scandraid
> More help   : https://help.launchpad.net/ListHelp