Well I’ve only spent maybe 5 days or so on this (plus a few days of in-head-planning), but here’s the checklist.
- database for storage
- spring for endpoints
- a skeleton JSON API
- user control panel
- admin control panel
– asset creation (with markdown support)
– staff approval for new assets
– staff approval for amendments to existing assets
- image uploading/serving
- youtube videos
It’s starting to look a bit like the part. Still a long way to go I guess.
In its current state you can only put the following external links:
- git repository
- documentation page
- publisher website
but adding published dependencies is obviously possible. I wrote a prototype before that used a custom protocol (i think it was jme://) to open links - which could be hooked up to the “auto-pull-build” local maven repository. Anyway. One step at a time. I’m writing the website at the minute. The “add-on” apps are for another day if they every come to light.
That could work when you just search for the jme3-darkmonkey.nbm from your sdk install and try to install it on a regular netbeans as module.
The problem there would be the gradle dependencies, I could at most only copy in the jars but then trouble starts with people trying to use it: Which version do you run? SDK!
Another thing I guess is the problem that I could not find a simple “gradle template for jme”, because there is nehon’s tool which I guess had to download and execute, there is stephen’s template, which I had to edit for some reason etc.
So there wasn’t some “just download this repo as zip and extract to see the blue quad”.
That is AWESOME! (Especially for 5 days work.) What toolkit are you using for the frontend UI?
Travis gave me that “this is not a tagged commit” BS again. Hang on.
This was my simple gradle game template:
For what it’s worth.
It’s semantic-ui - first time I’ve used it and it’s pretty cool. It’s not often I get the chance to choose the artistic ingredients. I usually just put things where they go and an artist does the rest.
v3.3.0-alpha1 is deployed. When you have a moment, @pspeed, please push the button.
166 new files will be publicly available shortly
Going to try the new animation system.
Ragdoll physics and inverse kinematics are known gaps in the new animation system. I expect
DynamicAnimControl will fill those gaps—for native Bullet, at least.
I plan to add
DynamicAnimControl without adding a new branch to the repo, simply integrating it one piece at a time into jMonkeyEngine’s
master. I think this can be done without breaking anything.
great idea, but you would need go depper to understand new animation system. like @Ali_RS said there are now Tweens. quote:
Action : An action is a composition of Tweens. It can be a single tween, a sequence of tweens, or tweens called in parallel way or a mix of all this. An Action is also a Tween, so it can be composed as part of another action and so on. An action can be provided with a Mask that will define a subset of targets on which it applies (a subset of Joints in an Armature or a subset of spatials for spatial animations)
Notables built in actions : (this may change a bit)
BaseAction : An action that wraps a Tween
ClipAction : an Action that plays an AnimClip
BlendAction : an Action that allows you to blend AnimClip together (think half walk / run animation varying depending on the forward speed)
That’s basically it. Note that Tweens can be basically anything, so the base action already provides virtually endless possibilities:
Stock Tweens that I plan to provide:
- SoundTween : play a sound
- EffectTween : fire a particle emitter
- MaterialTween: animate material’s properties
- ChangeActionTween: tells the AnimComposer to change the current Action
Stock Tweens available in Lemur (will probably be ported to jme’s core):
- Sequence tween: a tween that plays tweens in sequence.
- Parallel tween: a tween that plays tweens in parallel.
- Delay tween : a tween that just waits…
- Stretch tween: a tween that wraps another tween and change its duration.
- Camera tween: moves the camera…
so i think
DynamicAnimControl would need some integration to have both working properly. i belive there will be a lot conflicts. im not sure if you already analyzed this code or not, but looks like much more different system.
The 1st 2 pieces don’t involve animation, merely porting over Minie’s
MultiSphere collision shapes. After that, the integration will get more complicated. It seems prudent to plan ahead.
DynamicAnimControl interacts with the old animation system by interposing itself between the
AnimControl and the
SkeletonControl and reading/modifying
Bone transforms on the fly. I haven’t gone deep, but I’m hoping there’s a similar opportunity in the new animation system.
How does the new system communicate
Joint transforms from the
AnimComposer to the
Another problem is: I guess for now only GLTF uses the new animation system after import. Consistency has to be built there, but fortunately there seems to be a utility class which converts the old system structure to the new one.
Answering my own question: just as every
SkeletonControl has a
SkinningControl has an
DynamicAnimControl should have no difficulty reading and modifying the
Joint transforms in the
Armature before any skinning matrices are computed.
Tweening and blending seem to happen entirely in the
AnimComposer, where they’re invisible to
So good news: the class names have all changed, but as far as
DynamicAnimControl cares, the new animation system isn’t much different from the old one.
In case anyone is confused about my role here:
I have low interest in jMonkeyEngine 3.3. I’m not using it in my projects yet. I’m neither its architect nor its release manager nor its lead developer. Neither will I review every pull request.
I’m willing to cut alpha releases as desired, with the necessary help from @pspeed.
I will continue to report issues I find and fix them when I feel like it.
I will attempt to support any code I have contributed to jMonkeyEngine, including
So is there a lead developer or release manager / project overlord? I’ve always wondered.
Someone usually takes it upon themselves… which used to be easier when there were a lot of core devs.
Looks like I will be the stuckee this time.
Is it time for 3.3-alpha2?
Some notable changes since alpha1 (as I remember):
- Some bugfixes in physics and adding of new DynamicAnimControl
- Java 11 support
- Bugfix and improvement in AnimComposer
- Updates to joystick support
- Bug fix in joystick connection/disconnection in game. (this one is not merged yet, is waiting for @pspeed approval )
- Support for AmbientLight in PBRLighting
- Support for adding substeps in profiler
Support for TF would be nice PR #1078.
I also wonder who are the main contributors who can review/merge such PR. It also contains the change that VertexBuffer now extends BufferObject, which I briefly discussed with @pspeed, thus I can hardly imagine someone else reviewing the code. This can be separately viewed at (refactor base class buffer object · TehLeo/jmonkeyengine@0037e13 · GitHub) .
I know reviewing PRs can take considerate amount of time. I do not expect anything soon.
But even thou the PR is a bit bigger, with 50 hours spent on developing it I can say it was written carefully.
Anyone can review a pull request, but only the Owners and Members (of the jMonkeyEngine’s GitHub organization) can merge a PR. There are 32 of us: People · jMonkeyEngine · GitHub but most of those are inactive.
Reviewing PRs is the bottleneck. Due to human nature, shared responsibilities tend to suffer neglect. Sometimes it helps to ask a specific person. Sometimes I merge my own PRs without any outside review.