Which is interesting on its own because in my experience gradle will do this “install” behavior right out of the box for a java project. Or at least, all of my projects support this and I’ve added nothing special to do it.
That was true with the old “maven” plugin, but it isn’t true with the newer “maven-publish” plugin:
2 Likes
In Riccardo’s absence (which I hope is temporary) I’ll start work on a PR to revert 2060. Perhaps in the process I’ll learn why 2060 caused behavioral changes.
EDIT: PR 2278
5 Likes
JME3.7.0-beta1.1 is ready for testing.
I ran the test app for testing the blurriness as side-mentioned in issue #2277 . It seems that the problem remains. It should solve the multiple anim composers issue (I didn’t check that).
Next, I’m going to use beta1.1 in my IDE project, see if it solved the animations issue that I have had and reported earlier in this thread.
Cheers!
7 Likes
Guys, please ignore this release. I built it from “master” instead of v3.7.
Fixing it right now and will report when it’s ready to use.
4 Likes
For a lot of the work on simulated genetics I’m going to have to get hold of bones in the skeleton (or Joints in the Armature) by name; for example, gracility/robustness will require adjusting at least the pelvis and clavicle. To get recognisably distinct faces I’m going to have to manipulate bones as well as mesh there too.
Simulated genetics morphs need to happen at the point that I’m reifying characters, so in the circle between about 300 metres and one kilometre from where the player character currently is, so they have to happen in-engine and pretty fast. If I’m walking towards a market in an urban centre, for example, all the characters who are on the street have to be reified before I get there, ideally without the cost of that interfering too much with rendering the scene I’m walking through as I go.
However, I will have loaded my base character models at game startup time, so recursive search for the elements of the models which will later need to be morphed can happen then. So it’s a startup cost not a runtime cost, so it’s something I can definitely live with.
What I don’t want to have to do is call out to the MakeHuman python libraries at runtime. They can do all the things I need, certainly; but my current understanding, on top of the potential stability issues of that stack, is that to do that I’d have to export the model to disk from the python code as glTF or Ogre XML, and then reimport it from disk into engine, and that is going to get seriously time expensive.
And my point here (had to read back on the off-topic topic to catch up again 
) would be that it’s less fragile to find the Geometry with the skeleton control than it is to blindly stab out to a “Plane.001” and hope it’s a Geometry with your control on it.
Note that getChild(“Plane.001”) is not doing any special magic… it’s traversing the scene graph just like you’d do with a scene graph visitor visiting the Geometry spatials.
3 Likes
In my project, I used to do a lot of .getChild(name) calls directly on the “right” node, but then I frequently ran into the issue you mention where it would break every time my model’s hierarchy changed. For some models this was easily avoidable (especially if I made the model myself), but not so much for other models.
So to avoid the issue altogether, I made a small utility class with convenience methods that search a node’s entire hierarchy to find the spatial (or list of spatials if there are multiples with the same name) that match the criteria (for example, you can search for spatials with a certain control attached, or for a specific name or name-starting-with, or based on spatial type)
Maybe it would be a good idea to finalize a utility class like this and add it to the engine or an easily accessible library. (if anyone is interested I can post the class in another thread, but I don’t want to go too far off-topic on this thread)
In my own cases, I almost never search by name. I will often search by control. I will sometimes search by material parameters (for example, all of my humanoid models should have similar skin/hair/etc. texture names).
I don’t remember the last time I looked for a child by name… it’s been at least 5+ years. Maybe longer. Quite frequently, my models reach a stage where I go through and standardize all of the naming and clean up the hierarchy (for blender quality of life reasons)… and that would be hell if I had getChild(“box.001”) all over the place.
I have occasionally put custom data on the objects in blender. That’s for more general purpose stuff, though… like marking a whole bunch of objects as doors or whatever. Then just search for spatials with that user data. (In those cases, I don’t care if it’s a Node or a Geometry, though.)
Searching by user-data is my preferred way now, but a lot of my old code and old models used unique names as identifiers, so sometimes I still do that for simple things out of habit.
But I did also add a search-by-user data method to my utility class as well. You can search by name, userData key, or spatial type (or any combination of these if thats necessary for some reason, such as only Nodes with a “door” userData key).
I personally find myself doing this a lot, but it could be due to the nature of the project I’m working on, since I’m using lots of custom models and very little procedural generation for setting up my scenes.
So I often find myself having to flag a lot of data when I’m making a model or a scene in order to tell the game what a Spatial is supposed to do once its loaded up in-game (for example, every interactable-building I make in Blender is comprised of multiple geometries, so I need to flag the door (as well as anything else that may move/spin/be interacted with) in Blender or my scene editor. Wheras games that use procedural generation to setup a building or scenes from modular pieces will already know what each modular piece is, and don’t require as much extra flagging prior to run-time)
For me, I don’t like searching for nodes by name directly in the code because it’s too fragile, but on the user side, searching for child nodes by name is the most natural and easy to think of the most direct and simple behavior.
In my editor, I can change the skin color of some characters dynamically at runtime, but sometimes the color of the entire model cannot be changed.
For example, if I only want to change the color of the hair, I search for the hair directly by the name entered by the user (it would be weird if it was by bone).
But I am also considering other ways that are more compatible and more natural to use.
OK. we have v3.7.0-beta1.2 targeting v3.7 branch, ready for testing:
8 Likes
Fully agree. What’s needed is a reasonably efficient way to get hold of elements within models, and recursive search is
- good enough, and
- not brittle.
There’s a new unofficial, experimental release of @ertugrulcetin’s jme3-clj, tracking this release, here.
If it breaks, pester me, not Ertuğrul!
I noticed a regression in jme3test.terrain.PBRTerrainAdvancedTest. The terrain looks “noisy,” especially when viewed from far away.
The noise is more apparent when the camera moves, so an image is not really adequate.
6 Likes
I forgot to add MipMaps when I made that test case / example, so I think that is the cause of the noisey rendering.
I submitted this PR to fix the issue
5 Likes
With the mipmaps above and Setting the resolution to match the old prevents calling reshape by tonihele · Pull Request #2290 · jMonkeyEngine/jmonkeyengine · GitHub… once those are included in 3.7 release… would that be all?
2 Likes
@Adi.barda What’s your opinion?
1 Like
I will do some testing with the latest PRs included in 3.7 and report.
7 Likes
@adi.barda any news? Anything we can do? Also no need to hurry and/or take pressure, if it is not ready, it is not ready Just querying.
2 Likes