[Solved] Is there a way to add new attribute in j3md? (No, but reuse existing attribute names)

General Discussion
1

Hi monkeys:
I’m learning the material system and trying to write my first j3md .
Is there any way that I can use an additional “attribute” (per-vertice) other than those in VertexBuffer.java.type ?
:grinning:

2

Or is the

/**
         * Information about this instance.
         *
         * Format should be {@link Format#Float} and number of components
         * should be 16.
         */
        InstanceData,

designed to act as a custom attribute receiver?
[EDIT]
NO.
The true purpose of this attribute is written in Common\ShaderLib\Instancing.glsllib

// Instancing GLSL library.
// 
// When the INSTANCING define is set in the shader, 
// all global matrices are replaced with "instanced" versions.
// One exception is g_NormalMatrix which becomes unusable,
// instead the function ApplyNormalTransform is used to transform
// the normal and tangent vectors into world view space.
3

You can’t define your own vertex buffer types unfortunately… but you can use them for whatever you want. So just pick one that’s close or that you’ll remember and use that.

2 Likes
4

It’s worth saying there are a bunch of TexCoord vertex buffers (i.e. TexCoord2, TexCoord3 etc) that can be used for whatever you want (i used them to have day and night pre-baked light, and so could do day night transitions on the shader level). And it doesn’t have to be 2D data (the way the name implies)

1 Like
5

In fact, any of the attributes can take whatever size data you want to give them. Vec2, vec3, vec4, etc… I also use Size quite frequently with sometimes vec4 if I have a lot of things I’m tracking.

…I long ago came up with a plan to make vertex type completely flexible (ie: get rid of the enum and replace it with a standard set of instances)… but it has many steps and is a lot of work for relatively minor gain. It’s unfortunate that this limitation was built in so early.

…careful with your enums, folks.

1 Like
6

Thanks speed.
You are right. We already have a lot of names in the enum “type” and their type inside the gl are flexible (vec4 3 2), so reuse these names can get the job done (sort of).
And we still have a gl_MaxVertexAttribs to be considered.

7

Thanks richtea.
:grinning:

1 Like
8

Plus, 99% of the time, the first thing the .vert shader’s main() does is stick it in a local variable… because accidentally modifying a vertex attribute directly is bad.

Edit:

And that’s the thing. Deep down, the code is flexible with respect to vertex attributes. It allocates them to the shader on the fly and assigns names and types at that time. The only limitation to the “fixed set of names” is because JME used an enum. (And that’s hard-coded all over the place in map implementations, etc… hard to undo.)

Moral of the story: the only time “enum” is acceptable in API design is when you know 100% (10000%) all of the values ahead of time. If there is even a 0.00001% chance that some API-user will want to define their own then an enum is not appropriate.

3 Likes