Some JME3 questions

Ok, I have started with JME3, and there comes first questions (about materials of course, since this is new thingy)… :slight_smile:

Don't know if you have already discussed that but wouldn't be easier to have Java classes for common materials, which would extend Material. For example: You could have SimpleTexturedMaterial, which would extend Material and have a function to setTexture, because now it seems to me that user must know exactly which values to write in there. Example:


Material mat_tt = new Material(assetManager, "Common/MatDefs/Misc/SimpleTextured.j3md");
mat_tt.setTexture("m_ColorMap", assetManager.loadTexture("Textures/ColoredTex/Monkey.png"));


Here the user must know to write "m_ColorMap" when setting texture so that material could work right. This is not really intuitive for normal (not shader knowing) user... Could this be encapsulated in specialized class or should each user do this on his own?

Also I am looking at "Lighting" material, which looks the most obvious to use in most applications - small games (correct me if I am wrong), and I can see that there is no more Emissive color to set. Why is that so? :)

Another thing, now about lights, I see that there are no more constant, linear and quadratic variables to set, only radius. I suspect, calculating of those old values is based on radius now (or are there different lighting calculations now)?
How many lights can now be placed in the scene (OpenGL fixed functionality supported only 8 )?

Thanks for answers. :)

For the base materials, I have to disagree. Jme3's material system is based on shaders and material definitions and the "simple" materials only contain two or three parameters. Creating a material class to wrap two parameters does not make much sense… If you dont want to look up the parameters manually, thats what the material editor of jMP is for ;).

Material features can be extended very easily by changing or extending the corresponding j3md and shader files, so w/o creating new classes a splatting material or smth. could be created. Also emissive textures etc. should be no problem this way.

For the light features, ask Momoko :slight_smile: I guess its not completely done yet and some more light types and parameters will appear sooner or later.

Cheers,

Normen

The radius is actually its own variable independent of the coefficients, the shader uses the radius directly as it provides more accurate results.

You can place as many lights as you want in the scene, but performance won't be good, unless you use deferred rendering.

Thanks for your answers!

But! I have some more questions… :slight_smile:

  • First, deferred rendering is probably not yet supported by the engine, right?
  • One more thing I am missing from JME2 is fog. There was FogState, what to use now? Should I write my own shader for that?
  • About octree partitioning. How is this handled? Are nodes which are added to rootNode traversed through octree and placed in most optional branch? For JME2 I wrote custom loader for my linear levels, which put all the objects in some nodes and subnodes, looked like octree/quadtree in the end. I never tested if stats were better than before, I am just curious if octrees are used like this?
  • Last one hopefully, if my player gets hit by poison for example, I would like to change his vision so that it gets greeny blurred or smth (just an example). For this I should do post processing effect or change materials of objects or smth?

    Thanks for your patience… :slight_smile:

for the last one a postprocessing filter with a fitting shader would be good (blur color change ect)

InShadow said:

- First, deferred rendering is probably not yet supported by the engine, right?

Right.

InShadow said:

- One more thing I am missing from JME2 is fog. There was FogState, what to use now? Should I write my own shader for that?

It's actually a planned feature, we haven't gotten around to adding it yet.

InShadow said:

- About octree partitioning. How is this handled? Are nodes which are added to rootNode traversed through octree and placed in most optional branch? For JME2 I wrote custom loader for my linear levels, which put all the objects in some nodes and subnodes, looked like octree/quadtree in the end. I never tested if stats were better than before, I am just curious if octrees are used like this?

Octrees work fine, but they don't give better performance on high-end cards.
For integrated intel chipset though, they give much better performance.

InShadow said:

- Last one hopefully, if my player gets hit by poison for example, I would like to change his vision so that it gets greeny blurred or smth (just an example). For this I should do post processing effect or change materials of objects or smth?

Yeah, jME3 has a post-processing system which you can use to add effects like that.