I have a class that extends Material and adds other properties (such as how it reacts to different damage types, physics forces, etc)
I am currently trying to use the ShaderBlow SimpleRefractionProcessor to make a cool effect for a space gravity material. The problem is it produces a material, and I want to convert it to my gameMaterial class.
Since there seems to be no constructor for making a Material from another material (Material m = new Material(someOtherMaterial)) I am not sure of the best way to go about this. Anyone have any ideas?
Currently I am thinking something like getting the MaterialDef from the material, and then using super(MaterialDef)
Will that have all the data or do I need to get more?
I wrote this, this probably gets the rest of the data, anyone know?
[java]for (MatParam param : m.getParams()){
this.setParam(param.getName(), param.getVarType(), param.getValue());
}[/java]
This is similar to a problem I’m dealing with for single pass materials. If you do what you do it might lead to some material stuff not being copied etc. When I transition from the regular editor-friendly lighting mat to other materials, I go over each important param individually to ensure they’re all ok etc. There aren’t that many anyways.
You might want to copy the renderstate as well I guess, and also keep in mind when you duplicate the weirdo material for some reason (batcher does it automatically for example), things can go wrong. Better keep track of how you use it.
1 Like
Its not a good idea putting this into the jme geometry material system just because the name is similar. The proper structure would be that there is a base class or system that manages this kind of information for an object (physical appearance) and then controls subsystems (the jme material system and physics) to achieve the desired result.
@normen said:
Its not a good idea putting this into the jme geometry material system just because the name is similar. The proper structure would be that there is a base class or system that manages this kind of information for an object (physical appearance) and then controls subsystems (the jme material system and physics) to achieve the desired result.
Are you saying there is something inherently wrong with including, for instance, friction coefficient with a material?
Well, that isn't even the main purpose of my material extending class. I also have convenience methods and procedural texture generation code and such. At it's core it's a material though.
Yes, there is something inherently wrong. You are mixing visual appearance with game mechanics and opening up a whole world of limitations, botches, fixes, patches, and unexpected effects further down the line.
You would be much better to put the game mechanics stuff into specific bits of user data intended to store that stuff and attach the user data to the object.
@zarch said:
Yes, there is something inherently wrong. You are mixing visual appearance with game mechanics and opening up a whole world of limitations, botches, fixes, patches, and unexpected effects further down the line.
You would be much better to put the game mechanics stuff into specific bits of user data intended to store that stuff and attach the user data to the object.
I don't understand.
I do get the limitation that it is harder to say this(my class extending material) = someMaterial (jme material class)
But I don't get how having a few pieces of data lying around in a material object affects anything except what I use them for.
How about you ignore the game mechanics portion if you will for the moment.
Is there something wrong with extending Material and adding a method that generates a texture using Graphics2d?(something I already do and have zero problems with)
Hell, are you saying extending Material at all is bad? If so, why?
@normen said:
Its not a good idea putting this into the jme geometry material system just because the name is similar. The proper structure would be that there is a base class or system that manages this kind of information for an object (physical appearance) and then controls subsystems (the jme material system and physics) to achieve the desired result.
It has nothing to do with the name being similar, and also I don't intend to put the code anywhere except in my games so no-one else has to worry about that.
So lets say I have something made of steel. What does it look like? Steel. What does it react like to physical stimulus? Steel.
That's why I put it in the same object. I could always move the physical parts out and make a PhysicalMaterial class or something and then associate it by name with a given appearance, but I still want to generate the metallic texture and determine things based on an extension of a metallic appearance class etc.
Are you not supposed to extend material?
@yuxemporos said:
It has nothing to do with the name being similar, and also I don't intend to put the code anywhere except in my games so no-one else has to worry about that.
So lets say I have something made of steel. What does it look like? Steel. What does it react like to physical stimulus? Steel.
That's why I put it in the same object. I could always move the physical parts out and make a PhysicalMaterial class or something and then associate it by name with a given appearance, but I still want to generate the metallic texture and determine things based on an extension of a metallic appearance class etc.
Are you not supposed to extend material?
Yes, this kind of thinking is what I mean and it causes people to try and extend objects that were supposed to do other stuff. I explained how a proper solution would look. Theres no need to do a mashup and you don't get into trouble with mixed functionality or changes to the systems you "extend". What you want to do is like welding your trailer to your car instead of using a trailer coupling :)
@normen said:
Yes, this kind of thinking is what I mean and it causes people to try and extend objects that were supposed to do other stuff. I explained how a proper solution would look. Theres no need to do a mashup and you don't get into trouble with mixed functionality or changes to the systems you "extend". What you want to do is like welding your trailer to your car instead of using a trailer coupling :)
I don't see how changes in the Material class could possibly effect the parts relating to other things.
I just want to understand why it's a problem.
It would be easy enough to change my class to have a material instead of be a material.
@yuxemporos said:
I don't see how changes in the Material class could possibly effect the parts relating to other things.
Well for starter the very purpose of this thread...
You are stuck with your model already and have to make some parameter to parameter copy to put a JME material into your material class.
If you'd have a separate object/system for friction/texture generation your question would never have come up.
What people are trying to say here is that you probably went the wrong way.
It's not too late to reconsider your system to avoid such limitation as your development go further.
@nehon said:
Well for starter the very purpose of this thread...
You are stuck with your model already and have to make some parameter to parameter copy to put a JME material into your material class.
If you'd have a separate object/system for friction/texture generation your question would never have come up.
What people are trying to say here is that you probably went the wrong way.
It's not too late to reconsider your system to avoid such limitation as your development go further.
As I said, I probably just have to make the class have a material, and replace all calls for "this" with "this.material" but I still think that if it's that bad to extend material, then you shouldn't be able to extend it.
@yuxemporos said:
As I said, I probably just have to make the class have a material, and replace all calls for "this" with "this.material"
That would be a solution yes.
@yuxemporos said:
I still think that if it's that bad to extend material, then you shouldn't be able to extend it.
We could make the Material final.... but we don't really like the idea of forbidding something. (we had a looong discussion about readonly attributes once...)
What you did is not "wrong", it's a solution. But it can have draw backs, and you've just hit one of them.
1 Like
I can understand that you don’t like that I talk about your idea like that but its a fact, its bad programming style. Theres no reason to do it all in one class and you get all kinds of issues. Material.java in jME3 was created with a specific purpose, your own purpose is a completely different one. Hence as you said your “Material” should “have” a jME3 Material so that you can get the correct visual effect for your “Material”.
See if you do it like I say, you could easily reuse all of your code and just replace one reference and a bit of handling code if you wanted to use e.g. Ardor3D or libgxd. If you derive your class from our Material class then you can’t do that.
Your example was metal.
Now lets say you want a metal grate in the wall.
So either you end up duplicating your metal material and having a “metal in wall” material separate from “metal in sword” material - or someone uses your metal in sword material without realising and then strange things start happening later when you change it.
All we are saying is that you are close-coupling something that doesn’t need to be close-coupled. Unless things need to be/are connected then don’t connect them - then you can reuse the bits wherever you need without unexpected effects…
Now, extending it and adding functionality directly relevant to a texture makes more sense, but even then it doesn’t make complete sense as again you are tying things too tightly together. For example lets say you are using Nifty for your user interface…so you want to use your graphics2d modification thing to modify an image to use for Nifty…but Nifty doesn’t use materials…so now what?
Also you should look at ImageRaster and ImagePainter (I’m going to update ImagePainter to work with ImageRaster one of these days, just got way too much other stuff to get on with atm). They might help you out.
(If you do need ImagePainter let me know, if a few people say they definitely need it then I’ll prioritise it).
@nehon said:
That would be a solution yes.
We could make the Material final.... but we don't really like the idea of forbidding something. (we had a looong discussion about readonly attributes once...)
What you did is not "wrong", it's a solution. But it can have draw backs, and you've just hit one of them.
Thank you, that is a much better answer than the *screw you don't do that vibe* I was getting earlier.
Anyway I think I'll almost never need to use things like this in the context of my games, which is why I want to use something to copy the material's information over in this one instance.
@androlo said:
This is similar to a problem I'm dealing with for single pass materials. If you do what you do it might lead to some material stuff not being copied etc. When I transition from the regular editor-friendly lighting mat to other materials, I go over each important param individually to ensure they're all ok etc. There aren't that many anyways.
You might want to copy the renderstate as well I guess, and also keep in mind when you duplicate the weirdo material for some reason (batcher does it automatically for example), things can go wrong. Better keep track of how you use it.
The exact situation I am trying to use this for is when I get the material from SimpleRefractionProcessor.getMaterial()
I want to be able to use that but add properties to it...
@zarch said:
Your example was metal.
Now lets say you want a metal grate in the wall.
So either you end up duplicating your metal material and having a "metal in wall" material separate from "metal in sword" material - or someone uses your metal in sword material without realising and then strange things start happening later when you change it.
All we are saying is that you are close-coupling something that doesn't need to be close-coupled. Unless things need to be/are connected then don't connect them - then you can reuse the bits wherever you need without unexpected effects...
Now, extending it and adding functionality directly relevant to a texture makes more sense, but even then it doesn't make complete sense as again you are tying things too tightly together. For example lets say you are using Nifty for your user interface...so you want to use your graphics2d modification thing to modify an image to use for Nifty....but Nifty doesn't use materials...so now what?
Also you should look at ImageRaster and ImagePainter (I'm going to update ImagePainter to work with ImageRaster one of these days, just got way too much other stuff to get on with atm). They might help you out.
(If you do need ImagePainter let me know, if a few people say they definitely need it then I'll prioritise it).
What's ImagePainter? Is it supposed to be a better alternative to Graphics2d?
Also, I do separate out some of the image making functionality in situations where I am re-using it.
Also, as of right now all my materials are duplicated because I modify them on the objects I apply them to.
Shared materials (i.e. all objects with the same material definition and parameters use the same java Material object) are best for performance I believe.
Graphics2d isn’t supported on all platforms (i.e. Android). If you are confident you never want to support Android then go ahead and use it…
@zarch said:
Shared materials (i.e. all objects with the same material definition and parameters use the same java Material object) are best for performance I believe.
This right here is the best reason I have heard so far to not extend materials with object specific information.
It's frustrating to have someone say something you're doing was based on a misunderstanding (God knows, I've done this plenty), but honestly... the problems that this approach will lead to will become more and more apparent the further you continue with it :(
Early you said it would be no problem handling the material as a property rather than extending it. Best to do that soon and avoid a HUGE performance issue down the road and have to rewrite everything you did that extends materials after writing other code that relies on this.
Ok, let me also try to explain, because I had the same problem in the beginning. 
Material is probably misleading name for you (and probably for other not experienced people).
Material in JME3 and in other game engines is not what the definition of the word material is in the dictionary.
Material in game engines is usually just a description of how some thing looks, but in a rough way. Lets just say that material in JME3 is directly connected to a shader - so whatever the shader is, this is how the object will look like. So there is lighting material - shader and unshaded material - shader, each defining its own way of drawing objects on the screen.
Material as you understand it are actually some properties as seen in nature and this should surely be decoupled from properties of how something should be drawn on a screen. 