Ut_kdtree

[Mario Marengo]

Hey all,

I'm a little unsure about one of the UT_KDTree members, and would appreciate some clarification if possible...

The name given to the pure virtual function:

virtual fpreal const *getP(int ndx) const = 0;

seems to indicate that what's expected is a const pointer to the first float in some positional ("P") type whose data is stored as a contiguous array of fpreal's (presumably UT_Vector3 or UT_Vector4 data).

But I intend to use the kd-tree with a 6-dimensional split (3 for position P, and 3 for normal N) -- or maybe even 8; not sure yet --, and so now I'm starting to wonder if what is *really* expected as a return from getP() is a pointer to (at least) 'dim' fpreal's. Implying that 'P' stands for a "positional" value in a space with 'dim' dimensions (in my case 6, and not the 4 of UT_Vector4).

I'm just organizing my data at the moment, so I haven't put it to the test yet. For the moment, I've decided to keep my kd-tree related vars (P and N) in contiguous storage just in case my suspicion is correct, but I could simplify some things if this requirement didn't exist... so I thought I'd ask

TIA for any hints.

[crunch]

Hey all,

I'm a little unsure about one of the UT_KDTree members, and would appreciate some clarification if possible...

The name given to the pure virtual function:

virtual fpreal const *getP(int ndx) const = 0;

seems to indicate that what's expected is a const pointer to the first float in some positional ("P") type whose data is stored as a contiguous array of fpreal's (presumably UT_Vector3 or UT_Vector4 data).

But I intend to use the kd-tree with a 6-dimensional split (3 for position P, and 3 for normal N) -- or maybe even 8; not sure yet --, and so now I'm starting to wonder if what is *really* expected as a return from getP() is a pointer to (at least) 'dim' fpreal's. Implying that 'P' stands for a "positional" value in a space with 'dim' dimensions (in my case 6, and not the 4 of UT_Vector4).

I'm just organizing my data at the moment, so I haven't put it to the test yet. For the moment, I've decided to keep my kd-tree related vars (P and N) in contiguous storage just in case my suspicion is correct, but I could simplify some things if this requirement didn't exist... so I thought I'd ask

TIA for any hints.

18510[/snapback]

UT_KDTree should be able to handle up to 254 dimensional positional

data. I believe that

virtual fpreal const *getP(int ndx) const = 0;

Returns a pointer to the offset of the contiguous array of floats.

Thus, you could have:

    class MyElement {
    public:
        fpreal	myP[6];
    };

    class MyTree : public UT_KDTree {
    public:
        MyTree() : UT_KDTree(6, 100);
        virtual const fpreal	*getP(int idx)	{ return myData[idx].myP; }

    private:
        MyElement	myData[100];
    };

The only thing that the KD tree requires is that you have the positional data contiguous in memory (i.e. an array of fpreal types).

I hope this helps.

[Mario Marengo]

UT_KDTree should be able to handle up to 254 dimensional positional

data.  I believe that

virtual fpreal const *getP(int ndx) const = 0;

Returns a pointer to the offset of the contiguous array of floats.

18512[/snapback]

Thanks Crunch!

Yeah.. the more I thought about it, the more that seemed to be the only thing that made sense. Too bad this will mean some duplication of data just to make it "kd-tree compatible", but I guess that's unavoidable... bye bye pointers...

Thanks again!