While testing the save/load stuff, I put together a complex scenario of template based particles that are animated and use the Lighting.j3md material… also a JME primitive shaped emitter … but that’s not important right now. What is important, is it seems that lighting is being applied as if it were the original mesh that was loaded via assetManager. Meaning… the shading from lighting doesn’t follow the transformed verts.
Is there any reason you can think of that would cause this to happen? The material is applied to the particle mesh, not the original asset. The particle mesh is built using the original buffers as a map only.
This is not really that big of a deal, but it would be really nice if the lighting looked correct.
Well I guess your particles are all in one mesh right?
When you move a particle you transform the mesh but do you also transform Normals and tangents?
If you don’t, this is your issue.
@nehon said:
Well I guess your particles are all in one mesh right?
When you move a particle you transform the mesh but do you also transform Normals and tangents?
If you don't, this is your issue.
I sure don’t! Thanks a ton… I’m so brain fried atm, I was thinking my monitor was turned in the wrong direction
@nehon said:
You have an example of it in BatchNode or in the SkeletonControl.
BTW, the naked ladies helped a lot to diagnose the issue
Well, I didn’t have an actual tranform matrix to work with, but I borrowed the multNormal method’s code and used the the rotation matrix (which I did have). Off the top of your head, do you know if Quaternion.toRotationMatrix is returning a new Matrix each time it is called? I’ll get a chance to go take a look soon, but in case you see this before I do… !
Thanks for the point to the example, I’m thinking it may be smart to add a flag to the emitter, specifying whether or not it is using lighting so I can just skip this step if it is not necessary.
EDIT: Btw, is there a reason why Matrix4f gives public access to the individual cols/rows and Matrix3f requires using get(x,y)? Also, wouldn’t it be beneficial to add multNormal, multNormalAcross to Matrix3f, as this is specific to the rotation portion of a transform matrix?
q.toRotationMatrix() return a new matrix, but if you want to have a temp matrix on your side you can use q.toRotationMatrix(yourMatrix)
You don’t really need a flag to know just check if the buffer exits in the mesh.
About the methods in Matrix4f and Matrix3f you’re probably right, their methods should be the same.
I ended up adding it as a flag that can be part of setting the material. Reason being is, the normal buffer will exist in most cases no matter what material is being used. But really only need to be altered if they it is being used for lighting.
The update works great and I was able to add in support for color and alpha influencers for all materials that support vertex colors (this is specific to loaded assets as a particle template). Most of the models I’ve built and export from blender have no vertex color info, so it builds a default buffer if none exists and uses that instead.
The final outcome (though the example is silly, as you would never use it for this) has the proper lighting and makes use of an alpha fade using a fast curve at the end of the blend. It worked out really nice… Thanks for pointing me at an example… it really made this update (which has been bugging me) go fast.
