Proposal: More strict use of ofPoint / ofVec*f.

[bakercp]

With this great PR, #1819 it seems every more important to be a little more strict about our use of ofPoint. 90% of the time in the API (not a scientific estimate) we use ofPoint/ofVec3f when we mean ofVec2f. Since the ofVec*f notation can be a little confusing, I'd propose a ofPoint2D typedef of ofVec2f. Most 2D primitives (such as ofRectangle, the current version of ofPolyline are 2D in their current form.

Out of curiosity, are people using the .z in ofPoint when using ofRectangle, etc? I can see how it might be more convenient. But ofPoint implies things that ofRectangle can't deliver (think ofLineSegmentIntersection etc).

Alternatively, perhaps we should go the route of others (like cinder, toxiclibs, etc) and create a templated point / primitive, setup? From a data and drawing standpoint 2d is no different from 3d, but when we start doing functions like inside() or intersects() then we could subclass.

Anyway, just throwing this out there for discussion -- perhaps this is part of the larger API discussion that @ofZach and others have in mind.

[bakercp]

Also, please feel free to close this issue if this has already been discussed/resolved in the past and I missed it.

[arturoc]

i was looking at something similar for ofPath when looking into rendering thick lines, any libraries that do this need a 2d path not 3d so we would need something like ofPath2d. perhaps even just port ofPath to be 2d only since ofPath is mostly used for things that need to be tesselated... so 3d doesn't make very much sense

not so sure about ofRectangle, don't think either that most people use z in it but we ported all the core to support z a while ago so it seems like a regression somehow

[bakercp]

Yeah, I understand how it might seem like a regression. I assumed that someone had put some thought into it at some point and had some good reasons. I guess my main reason is to make the api a little clearer when it comes to using utility functions in particular -- for instance you can ask ofRectangle if it contains a 3d point. Most experienced people would just "know what you mean" :), but the ofDraw* discussion and the idea of easier api discovery, the idea of moving away from base assumptions in favor of more clarity, etc has me thinking through some of the assumptions embedded int the current oF API.

Part of this is motivated by my desire to start integrating oF into my courses here @SAIC. With the RaspberryPi show moving into town, I'd like to get beginners working with oF on the RPi, even if they haven't yet mastered Processing (which is what I usually teach / recommend) :)

[roymacdonald]

It sound quite reasonable. +1 for it.

a bit out of topic, @arturoc have you been able to get any working results for rendering thick lines? I began an addon for it based on an incomplete lib of which zach tweeted about last week. take a look at it. https://github.com/roymacdonald/ofxFatLines it still need a lot of love esp. when there are narrow angles between line segments. besides that it looks really nice. Hope to give it some time today.

Best!

[arturoc]

yes but it uses the nvidia path rendering extension which doesn't work on osx yet

[elliotwoods]

i presume the subclasses could implement .x, .y, .z etc through a reference initialised in the constructor, e.g.:

ofVec3f : ofPoint_<3> {
public:
    ofVec3f() : x(this->operator[](0)), y(this->operator[](0)), z(this->operator[](0));
    float & x;
    float & y;
    float & z;
}

can anybody see any issues with this type of thing? looking at:

template<int dimensions>
ofPoint_<dimensions>::dot(const ofPoint_<dimensions> & other) {
    float result = 0.0f;
    for (int i=0; i<dimensions; i++) {
        result += this->operator[i] * other[i];
    }
}

looking at this i think:

1. we're introducing funky error messages (e.g. imagine if somebody tries to vec3.dot(vec2))
2. a good optimiser should make this equivalent to our existing implementation, but there's a larger chance that it won't.
3. is this really saving anything anywhere?

[bakercp]

Closing this since glm is now integrated and ofVec* is being deprecated.