jMonkeyEngine / jmonkeyengine

A complete 3-D game development suite written in Java.
http://jmonkeyengine.org
BSD 3-Clause "New" or "Revised" License
3.8k stars 1.12k forks source link

Special material classes #2236

Closed codex128 closed 6 months ago

codex128 commented 6 months ago

This PR adds 3 classes extending Material for PBRLighting, Lighting, and Unshaded matdefs. The goal is to make these matdefs as easy to use as possible, since they are used so often.

capdevon commented 6 months ago

IMO the jme-core module should contain only the essential engine functions. This would allow users to create custom utility libraries that perfectly fit the needs of their projects. After all, user freedom is a fundamental principle of JME!

By keeping utility classes separate, we ensure that they can be easily tested, updated, and maintained without impacting the main engine. This is especially important considering the long release cycles of JME. Utility class bugs can be fixed much more quickly in external libraries than waiting for the next engine update.

So, let's empower users and keep the core engine lean! ;)

Stephen's approach of building external utility libraries is inspiring! It encourages innovation and reusability.

codex128 commented 6 months ago

I realize adding these classes to an external library is optimal. However, I think in this case they are better off in jme3-core. Otherwise they'd be buried in a utility library somewhere, and no one would know they exist. They might as well not exist at all in that case.

Also, I think these classes would primarily benefit new users, who are unlikely to download a utility library until they've learned the engine.

pspeed42 commented 6 months ago

re: "Also, I think these classes would primarily benefit new users" ...by teaching them that they cannot easily create their own materials.

The engine has avoided making such classes up until now to avoid locking users into fixed materials. One of the great benefits of the engine is how easy it is to roll a new material.

It's important to be careful of the "because this will be easier for new users" phrase because new users are already going to be cutting and pasting code to get something working... so it matters little whether it's one class or another at that point. But as we see over and over, new users get really confused when they try to at all stray outside of the 'demo level' code... see: every question about "why can't I access 'app' from my class?" and all of the mistakes from having every class in their game extend SimpleApplication.

If we are worried about new users, we need to get the code templates working in the SDK again (I assume they aren't). When I started with JME, I was able to write a whole test game in a weekend because of those little insertable code snippets.

codex128 commented 6 months ago

Hmm, good point. I didn't think of that.

I don't see much support for this PR, so I'm going to close it unless further interest is expressed.

pspeed42 commented 6 months ago

I appreciate the desire, though. I often catch myself getting caught up in a similar want... but usually five minutes later, I've forked my shader for some other reason and I'm suddenly glad all of my existing material code still works.

...could also be neat if IDE magic could make command completion work on material parameters... but I think that's a big ask even from the really advanced IDEs.

tonihele commented 6 months ago

If we are worried about new users, we need to get the code templates working in the SDK again (I assume they aren't). When I started with JME, I was able to write a whole test game in a weekend because of those little insertable code snippets.

If you mean these, go right ahead, fully maintained & ready to go: image