Can someone tell me how to update my 3D sharders for v4.0? I’m seeing compile errors to do with undefined variables CC_MVMatrix, CC_NormalMatrix, CC_PMatrix and others. I was expecting problems, but hope there is an easy workaround.
If you are still interested - this varriable’s have another names now. You should use u_MVPMatrix, u_MVMatrix, u_PMatrix, u_NormalMatrix.
Thanks solan. Yes I’m still interested. I’m having trouble creating a working 64bit-supporting release with 3.17.2, so swapping to 4.0 is still a useful branch of attack.
I just tried editing all the uses of those variables to match your suggestions and they’re still reported as undefined. Is there anything else you can think of that I might try?
I guess one possibility is to run the cocos2d-x tests and breakpoint where the shaders are passed and take a look at them. I think that’s how I obtained the starting points for my own shaders. Still, any further suggestions would be most welcomed.
I guessed that, unlike the old CC_ forms of the matrices, these new ones need declaration within the shader, so I declared u_MVMatrix and u_PMatrix to be mat4 and u_NormalMatrix to be mat3.
Also there was a similar problem with CC_Texture0, so I changed that to u_Texture0 and declared it as sampler2D.
That fixed the shader compile errors, but now my app crashes when trying to call getGLProgramState, so I guess the API for setting uniforms has changed.
Looks like I may have been using an undocumented API within 3.17.2.
local material = cc.Sprite3DMaterial:createWithFilename("materials/"..conf.method..".material") local glState = material:getTechniqueByIndex(0):getPassByIndex(0):getGLProgramState()
I wonder how I should be gaining access to the uniforms so as to set them in v4.0?
@Glidos Ecxuse me, I did not see your message.
About uniforms, as I properly understand you are right. On C++, You can obtain ProgramState* from Material -> Teqchnique->Pass->ProgramState. And than use the functions:
state->setUniform(location, void* data, sizeof(data)); - for types
state->setTexture(location, texture unit, texture backend GL); - for textures
‘location’ you can get from state->getUniformLocation(“uniform location name”);
I believe that lua should provide the similar API.
It is best to learn test programs, as you mentioned, since it have many good cases to use it for yourself.
Thanks solan. I think this works for C++, but not Lua. There is a setUniform method available in Lua, but it takes a table which it uses as an array of floats. I can trick it into passing a single float by simply making a table with one field, but I don’t think I can pass integers or arrays of integers using it. I may try adding a secong integer method, or giving the method a flag, although I’m a little worried as to how an ordering is determined on the values in the table.
Just now, I’m not looking at moving to v4.0 of cocos2d-x. I was originally because of problems I had with v3.17.2 crashing and also problems generating 64bit release builds, but I’ve discovered that the end of the v3 branch in git is in a really good state: using it, I seem to have a rock solid uncrashable, releasable app, thanks to the fine work of the cocos2d-x devs.
It is good, that V3 satisfy your needs.
I do not use Lua binding project myself, and do not know its API. But let me notice one thing, and fix me If I still wrong. There is the following code inside cocos2d/tests/lua-tests/src/MaterialSystemTest/MaterialSystemTest.lua
Are you not looking for the same thing?
If to say about integers, it is only suggestion, but you can treat the opportunity to pass only floats to the shader (in any case - if you really need even two bytes, like ‘short’ type), and then use type casting of that float to integer inside the shader itself.
Oh wow, thank you. cc.bytearray!! I missed that completely. Yes, that looks to solve the problem completely.
I feel such an idiot now, but a happy idiot.
And that worked perfectly. Thanks again solan. I don’t need to move to v3 yet, but it’s nice to know I can.
No problem - I’m glad to help you)
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.