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
login/logout/sessions
user control panel
avatars
admin control panel
Assets
– asset creation (with markdown support)
– editing
– tags
– staff approval for new assets
– staff approval for amendments to existing assets
image uploading/serving
youtube videos
endless javascript…
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”.
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.
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 EmptyShape and 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 SkinningControl?
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 Skeleton, every SkinningControl has an Armature. 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 DynamicAnimControl.
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.
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 DynamicAnimControl.
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.
)