support for GL_TEXTURE_3D and GL_TEXTURE_2D_ARRAY

[joshuajnoble]

This allows ofTexture to load data for arrays of 2D textures and texture 3D. No drawing methods are included as this would require re-writing parts of ofMesh to allow for 3D texture-coordinates, but an example rendering it with GLSL will be created. Sorry for all the weird whitespace issues.

[tgfrerer]

Great stuff! Is it possible to write ofTexture::loadData() a bit more DRY i.e. using one method for all loadData() variants?

Curious to hear what would need adapting in ofMesh to deal with 3d texture coordinates.

Strange what's going on with the line endings - i believe @bilderbuchi has hunted down a similar issue some time ago, he might have an idea of how best to tackle that.

[arturoc]

yes i think this should be in the same method we use for other textures. that way it'll also support short and float pixels

[joshuajnoble]

I looked but it seemed like there were a lot of assumptions that textures would be Rectangle only that I didn't want to mess with. Also, I was sure about whether we should be pushing people to use the ofTextureData object more, because the logic can be put there, but then some of the allocate() methods (I think, can't remember) would over-write the textureTarget and I didn't want to touch those.

Obligatory phone disclaimer

On Oct 18, 2013, at 1:40, Tim Gfrerer [email protected] wrote:

Great stuff! Is it possible to write ofTexture::loadData() a bit more DRY i.e. using one method for all loadData() variants?

Curious to hear what would need adapting in ofMesh to deal with 3d texture coordinates.

Strange what's going on with the line endings - i believe @bilderbuchi has hunted down a similar issue some time ago, he might have an idea of how best to tackle that.

—
Reply to this email directly or view it on GitHub.

[joshuajnoble]

As far as the mesh tex coords, it's just moving to an ofVec3f and changing all the methods to allow either 2f or 3f. Same goes for renderer::draw(), needs to be able handle 3f tex coords. That's all really.

Obligatory phone disclaimer

On Oct 18, 2013, at 1:40, Tim Gfrerer [email protected] wrote:

Great stuff! Is it possible to write ofTexture::loadData() a bit more DRY i.e. using one method for all loadData() variants?

Curious to hear what would need adapting in ofMesh to deal with 3d texture coordinates.

Strange what's going on with the line endings - i believe @bilderbuchi has hunted down a similar issue some time ago, he might have an idea of how best to tackle that.

—
Reply to this email directly or view it on GitHub.

[tgfrerer]

++1

3d tex coords would be useful for other stuff, too: How about we internally use 4d texture coordinates in ofMesh/ofVboMesh? OpenGL internally treats texcoords as vec4f, and it will make shadow / projection mapping easier for people who are into advanced stuff.

Might even be faster to transfer to the GPU, since it would give us a clean 8 byte chunk per texcoord.

On 18 Oct 2013, at 12:07, joshua noble [email protected] wrote:

As far as the mesh tex coords, it's just moving to an ofVec3f and changing all the methods to allow either 2f or 3f. Same goes for renderer::draw(), needs to be able handle 3f tex coords. That's all really.

Obligatory phone disclaimer

On Oct 18, 2013, at 1:40, Tim Gfrerer [email protected] wrote:

Great stuff! Is it possible to write ofTexture::loadData() a bit more DRY i.e. using one method for all loadData() variants?

Curious to hear what would need adapting in ofMesh to deal with 3d texture coordinates.

Strange what's going on with the line endings - i believe @bilderbuchi has hunted down a similar issue some time ago, he might have an idea of how best to tackle that.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[joshuajnoble]

I like 4f. I started down 3f. I'll finish up 4f and append to this commit. Sound good?

Obligatory phone disclaimer

On Oct 18, 2013, at 4:23, Tim Gfrerer [email protected] wrote:

++1

3d tex coords would be useful for other stuff, too: How about we internally use 4d texture coordinates in ofMesh/ofVboMesh? OpenGL internally treats texcoords as vec4f, and it will make shadow / projection mapping easier for people who are into advanced stuff.

Might even be faster to transfer to the GPU, since it would give us a clean 8 byte chunk per texcoord.

On 18 Oct 2013, at 12:07, joshua noble [email protected] wrote:

As far as the mesh tex coords, it's just moving to an ofVec3f and changing all the methods to allow either 2f or 3f. Same goes for renderer::draw(), needs to be able handle 3f tex coords. That's all really.

Obligatory phone disclaimer

On Oct 18, 2013, at 1:40, Tim Gfrerer [email protected] wrote:

Great stuff! Is it possible to write ofTexture::loadData() a bit more DRY i.e. using one method for all loadData() variants?

Curious to hear what would need adapting in ofMesh to deal with 3d texture coordinates.

Strange what's going on with the line endings - i believe @bilderbuchi has hunted down a similar issue some time ago, he might have an idea of how best to tackle that.

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

[joshuajnoble]

Ok, now I'm fully awake and not on my phone and I'm not sure how ofMesh can be ofVec4f without having everything duplicated and all the accessors copy to ofVec2f (i.e. getTexCoords()) which would be slow.

Also I think rewriting loadData() means rewriting at least one of the allocate() methods or putting depth at the end as an optional parameter:

    virtual void allocate(int w, int h, int glInternalFormat); //uses the currently set OF texture type - default ARB texture
    virtual void allocate(int w, int h, int glInternalFormat, int glFormat, int pixelType); //uses the currently set OF texture type - default ARB texture
    virtual void allocate(int w, int h, int glInternalFormat, bool bUseARBExtention); //lets you overide the default OF texture type
    virtual void allocate(int w, int h, int glInternalFormat, bool bUseARBExtention, int glFormat, int pixelType); //lets you overide the default OF texture type

[tgfrerer]

hey @joshuajnoble - i think i can see what you mean.

if we internally store all the texcoords as a vector, the main issue would be the bulk(i.e. whole vector)-assignments, right? I wonder how much of a speed difference it would make to copy a ofVec2f source assignment vector by 'manually' pushing back into ofMesh's internal storage vector. But then, vector::push_back() is highly optimised, and if used with iterators this should be very fast...

i'd think individual (piece-wise) texCoords getters / setters could do well with a copy/convert on allocation - these need not to be super-optimized - after all, the data flow is more from cpu memory to gpu memory, and querying texture data from a mesh is something you'd rarely do under time constraints.

i'm wondering if there's a more elegant way to assign vectors of ofVec2f to ofVec4f's for the bulk assignments - or avoid the whole issue with a different approach altogether. maybe @arturoc has an idea ?

I'll see if i have any more ideas having slept on it (alas, time zones =)

[arturoc]

i guess texcoords would be vec4f for the vector that contains them internally and for the parameter and return types, since there's copy constructors from vec2f <-> vec4f you could still pass or get ve2f without problem.

we should test though that having vec4f texcoords won't slow down to much the typical case

another posibility would be to have a templated ofMesh which gets a custom Vertex class like:

struct VertexTex{
    ofVec3f pos;
    ofVec4f tex;
}

ofMesh<VertexTex> vertexTex;

but that would break old code and will be difficult to use since you would need to specify the offsets for each component... although it should be faster than the current implementation since every component will be in contiguous memory

[joshuajnoble]

Maybe like this:

class VertTex2f{
    ofVec3f pos;
    ofVec2f tex;
};

class VertTex4f{
    ofVec3f pos;
    ofVec4f tex;
};


typedef ofBaseMesh<VertTex2f> ofMesh;
typedef ofBaseMesh<VertTex4f> ofVolume;

Or we could just have something that extends ofMesh, ofVolumeMesh or whatever, that allows you to use ofVec4f textures.

[bilderbuchi]

regarding the whitespace, @tgfrerer, maybe this has changed since this PR has been opened, but I don't see (m)any line-ending changes, but there's lots of changed indentations. could be that some (automated) code styler triggered and corrected/changed indentation levels, or tab-to-space or vice-versa, that's what it looks like to me.

[arturoc]

the problem is that having a templated mesh will complicate the api a lot and will break compatibility. also having vec4f for texcoords is useful for other things apart from volumes so not sure volumeMesh is a proper naming, i would try first to benchmark just changing ofMesh to use ofvec4f as tex coordinates and see whats the difference

[joshuajnoble]

Quick update: works fine in programmable renderer with (afaict in limited bench-marking) no performance hit. Can't get it to work with a regular ofMesh in the ofGLRenderer tho. Will continue to look at it but it might make sense to only have as a feature of programmable renderer.

[joshuajnoble]

Just noticed that of3dPrimitive already has texcoords as vec4f, which is nice. Seems like someone else already had this in mind?

[arturoc]

i think that's just 1 vec4f used for mapping the tex coords of a texture to a primitive, the name is kind of confusing though