-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Feat: Add receivesShadows serialization for Material #2482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I'm slightly confused what this value would be used for, since the comment says:
So does this mean it is just a boolean value that gets flagged automatically on a material so that the shader/material can easily know if shadows are enabled or not? And by default, this does nothing else in the engine? If so then I could see cases where it could be useful to know if shadows are being recieved in the shader to potentially adjust brightness (if you want to avoid players turning off shadows to get an advantage from a brighter scene, for example). But I'm curious to know what else you have found it to be useful for as well. (the only issue I see here is in cases where there's a single material that is used by more than 1 geometry where the geometries are using different shadow modes, but I suspect that is probably unlikely to happen) Or am I completely misunderstanding this? |
The primary goal of this change is to bring consistency to the The potential use that I have seen is not at all about shaders, as you imagined. IMO according to the // e.g. String matDef = "Common/Materials/RedColor.j3m"
private Geometry makeShape(String name, Mesh mesh, String matDef) {
Geometry geo = new Geometry(name, mesh);
Material mat = assetManager.loadMaterial(matDef);
geo.setMaterial(mat);
if (mat.isTransparent()) {
geo.setQueueBucket(RenderQueue.Bucket.Transparent);
}
if (mat.isReceivesShadows()) {
geo.setShadowMode(RenderQueue.ShadowMode.Receive);
}
return geo;
} Edit: Here is another example of applying the same material to all the geometries of an entire scene by reducing the number of allocated objects and configuring transparencies and shadows via // e.g. String matDef = "Common/Materials/RedColor.j3m"
private void updateMaterial(Spatial scene, String matDef, Predicate<Spatial> filter) {
// All geometries use the same instance of Material.
final Material mat = assetManager.loadMaterial(matDef);
scene.depthFirstTraversal(new SceneGraphVisitorAdapter() {
public void visit(Geometry geom) {
if (filter.test(geom)) {
geom.setMaterial(mat);
if (mat.isTransparent()) {
geom.setQueueBucket(RenderQueue.Bucket.Transparent);
}
if (mat.isReceivesShadows()) {
geom.setShadowMode(RenderQueue.ShadowMode.Receive);
}
}
}
});
}
exactly, it's just a simple boolean marker, it doesn't do anything in the engine |
This PR introduces the capability to correctly serialize and deserialize the
receivesShadows
boolean field within theMaterial
class. Previously, this variable's persistence was overlooked during material saving and loading, despite its documented purpose as a marker for model loaders to indicate shadow reception for geometries. I've leveraged the existingsetReceivesShadows
functionality, which, as its Javadoc states, is a valuable marker that was not fully utilized in the serialization process.Key changes include:
Material.java
to read and write thereceivesShadows
field during serialization and deserialization.J3MRootOutputCapsule.java
to properly handle and include thereceivesShadows
property in the exported.j3m
file format.TestMaterialWrite.java
with a test case to ensure thereceivesShadows
value is correctly persisted and loaded.Edit:
Crucially, this modification is fully backward-compatible with existing .j3m files. Materials saved with older versions of the engine that didn't persist receivesShadows will still load without issues, and the field will simply default to its initial value (typically false) as if it were never explicitly set.
Test passed: