Material files

Hello! Since few weeks I work to integrate a material solution to JMonkeyEngine, which don't be perfect without material files interpretation!



I post here my W.I.P



FILES-UPLOAD.COM



This zip contains Java sources and material sample, plus a TestGrassMaterial.



They provide a simple way to declare material with shaders, multi pass and multi textures.



I think the .materials descriptor file is easy to use, but this version is a work in progress.

I must implement advanced operation on texture (wrap mode, mipmap etc…), and some uniforms declarations don't work (for few days also :P)



Let's me some comments :wink:

I'm working on a shader material library right now, so i will definitely look at your solution.

I wanted to suggest one, IMO jME should have a high-level material format because RenderStates are meh…

Checking zip now

"Sorry. You can not download this file today. Download traffic for your country is empty."

Momoko_Fan said:

I wanted to suggest one, IMO jME should have a high-level material format because RenderStates are meh..
Checking zip now


Funny you should say that... :)

"Now" == when I get back to this firefox tab :smiley:

I looked at the source, was too lazy to check it working, but i can assume how/what this does.



The parser looks very solid. Have you generated it with a tool?



One big question a material system rises, on what level should it operate? You implemented it to work on Node level, which is logical for passes and render-to-texture. Switching shaders/textures and other renderstates is more logical at Batch level. This solution requires that the scene is organized by Material.



Updating the materials. The vector to camera depends on the position of the rendered object. This means those would need to be updated for every object rendered. This complicates/would slow the updating.



You did not modify any jME classes, but i think making some (not so big) changes would solve the problems. Hint: pluggable RenderQueue, a separated queue for every pass, sorted by material. The material system then would not operate on Nodes, but on queues of RenderQueue.



Another approach would be to make the system non-intrusive. Which means, the user can request a material from the system, and the system would provide all the resources for using the material, but it would be the users responsibility to place those resources at proper places in the scene.



This is good stuff, has a lot of potential.

Thanks for your answers



I have generated the parser with my hands (and my keyboard), a small ant - boring work. Maybe it's not the best way to do this things also!


One big question a material system rises, on what level should it operate? You implemented it to work on Node level, which is logical for passes and render-to-texture.
Switching shaders/textures and other renderstates is more logical at Batch level.
This solution requires that the scene is organized by Material.


I have ask myself with the same question, but i think this is the best way to link common materials like bump-mapped and/or glow-mapped to an imported model. In jME, the imported models produce a Node with all geometry object as childs.
But maybe we can apply material states directly to geometry batchs. However, I don't know how to update this states to each call to Geometry.draw() method :s

For the material uniform updating, I will optimize to assume than constants uniform will not be updated each frame, but i don't understand: the vector to camera isn't computed in update, only the camera position (which lets static between each call)  :?
Maybe use of MaterialManager with all material's update calling method?

You did not modify any jME classes, but i think making some (not so big) changes would solve the problems. Hint: pluggable RenderQueue, a separated queue for every pass, sorted by material. The material system then would not operate on Nodes, but on queues of RenderQueue.


Badly, I don't know too much jME and I don't know how RenderQueue object can be plugged.


Else making methods to get all resources and work with thems is a very good idea, and I think I will work in this direction for the evolution of this work