(October 2021) Monthly WIP Screenshot Thread

The Classic Motorcycle has (at last!) been officially added to the More Advanced Vehicles project. This marks a major milestone: the project’s first 2-wheeled vehicle!

A 2-minute, 20-second video is available from YouTube:

Source code at GitHub: https://github.com/stephengold/jme-vehicles

19 Likes

What a great edition to the vehicles project!!
Can you control the physics behavior of the bike? I mean the rear & front suspension - compression & rebound damping.
Also under hard acceleration, the slightest movement of the handlebars will loose traction and produce rear wheel drifting. Can we simulate that in this version?
I think you should prevent tilting the bike in slow speed. it looks weird. at least we need to give the programmer some control on tilting behavior as a function of speed & handlebar movement.
It looks like the rider and the bike are tightly connected. If in the future we will be able to loosen this connection it will be much more realistic. especially to rider’s bottom. it’s very dynamic. maybe it’s not an issue at all - the programmer can just run any rider’s animation he wants according to the bike’s situation…
Does the COG (center of gravity) computed automatically or we can set it manually
Is it easy to add & configure other bikes & wheels models?

Thanks a lot!

2 Likes

I’m glad you’re interested in the bike, Adi!

In a 2-wheel vehicle, the compression and damping of each suspension can be configured in Java, the same as for a 3- or 4-wheel vehicle. For the demo, I made the suspensions very stiff since any compression would misalign the brake pads with the rotors and the axles with the hubs.

Drifting occurs at high speeds. I believe there are examples in the video.

For “Classic Motorcycle”, the tangent of the tilt angle is proportional to the lateral acceleration. That formula isn’t hardcoded into the library (yet) so you can customize it as you wish. And I’m open to PRs.

In the demo, the rider doesn’t move at all. Even when the handbars turn, the rider’s arms and hands remain frozen! You are right that the programmer can run any animation they wish—unfortunately I don’t have good skills for creating animations.

The new Bike class creates a vehicle with 2 rigid bodies: one for the engine and one for the steering. It expects the 3-D model to follow certain conventions, such as having Y-up/Z-forward orientation and a distinct subtree for each body. Each body has its own center of gravity, located at the origin of its subtree. I never calculate an overall center of gravity for the bike.

Bike wheels are interchangeable with the wheels of other vehicles, so their 3-D models have to follow the same conventions as other wheels.

It’s not easy to add models to More Advanced Vehicles. When I gain more experience, I may be able to write a “cookbook”. For now, I’m available to help with troubleshooting.

4 Likes

Hi everyone, I haven’t been here in a while. I spent a long time studying jMonkey and some other engines. Try to develop a webGL-based renderer, including a variety of RenderPipeline, such as Forward, Deferred, TileBasedDeferred, and Shader definition methods similar to Unity3d. I know this has nothing to do with jMonkey, I just want to share this project that I spent a long time developing. :grinning: :grinning:






https://github.com/JohnLKkk/try3d

12 Likes

I have just managed to create a custom blendAction with some custom blendSpace, one of good ideas indeed was to build a PieChartSpace in which the blendingWeight is a rational number from 0 to 1 or 100%, the percentage or the ratio get calculated at runtime on each update through the setBlendAction() method by using the central angle & the circle radius ((a/360) * area) to calculate the area of the selected chunk which gets scaled later on with respect to the unit circle (part * (area/unitArea)), the net result is to adjust the blending weight of the blendableAction based on an easy way such as the PieChart chunks :

=> Example of angles (45 - 90 - 150) runs in series with a constant radius(0.887f) :

=> Example of angles (260 - 8 - 90) :

=> Source :

-Values of radius & angles can be blended through the states update(ex : enclosing a BlendSpaceImpl into an AppState).

-The 2 ClipActions in which we blend between them on these 2 vids are the (firstAction=>Rotation of the dataBase model around Y-axis), (2ndAction=>Rotation of the dataBase model around X-axis).

-The blending weight or the ratio gathered from the angles & the radius can also control which actions would last longer & loop in the animation, some actions can be shut down through the blending weight.

I am still learning jme new animation system, and by time i hope i will understand its pattern well…

7 Likes

Maybe JME engine can profit from your studies and knowlegde. :+1:

2 Likes

In fact, I refer to a lot of jmonkey content :rofl:

And if we want to blend between 3 or more actions, this code works :

        //blendAction one
        blendSpace = new CustomBlendAction.PieChartSpace(RADIUS, 45f);
        blendAction = new CustomBlendAction(blendSpace, capRotationClip, bottleTractionClip);
        //blendAction 2
        final BlendSpace blendAction1 = new CustomBlendAction(new CustomBlendAction.PieChartSpace(RADIUS, 180f), blendAction, magnifyingEffectAction);
        //baseAction supporting Tweens, blendingActions, & regular ClipActions
        final BaseAction baseAction = new BaseAction(blendAction1);
        baseAction.setLength(10f);
        baseAction.setSpeed(2f);
        //10)add that BlendAction to the AnimComposer using addAction(...)
        animComposer.addAction("SimulateBottleFall", baseAction);
        animComposer.makeLayer(LayerBuilder.LAYER_BLENDABLE_ANIM, new ArmatureMask());

=> 4 Actions & so on:

        //blendAction one
        blendSpace = new CustomBlendAction.PieChartSpace(RADIUS, 45f);
        blendAction = new CustomBlendAction(blendSpace, capRotationClip, bottleTractionClip);
        //blendAction 2
        final BlendSpace blendAction1 = new CustomBlendAction(new CustomBlendAction.PieChartSpace(RADIUS, 180f), blendAction, magnifyingEffectAction);
        //blendAction 3
        final BlendSpace blendAction2 = new CustomBlendAction(new CustomBlendAction.PieChartSpace(RADIUS, 180f), blendAction1, effect4);
        //baseAction supporting Tweens, blendingActions, & regular ClipActions
        final BaseAction baseAction = new BaseAction(blendAction2);
        ........

=> Example :slight_smile: :

3 Likes

This month I’ve been working on simplification. I realised that One Million Worlds was simply too complicated for players to actually play (I think I’ve known that for a while but wasn’t sure what to do about it)

To resolve that I’ve removed (or made optional) the whole concept of wiring up engines to command chairs (which allow keys on the keyboard to control wires in the game). Previously it was very difficult to build an interesting looking ship that was easy to add engines to such that going forward didn’t make it turn upwards if the engines weren’t perfectly symmetrical around the centre of mass (which was really boring!).

What I’ve done is have the standard WSAD keys as inputs to “the concept” of going forwards/backwards left/right and given that to a linear optimisation library to figure out which engines should fire. This makes it much easier to build ships, and also allows much smaller ships to be built (as no need for room for wiring)

In addition to being smaller because no need for wires this ship design would also have pitched down if all its rear engines were on full, but the linear optimisation library can figure out it needs to put the bottom rear engines on full and the top rear engine on just a little bit and that gives straight and level flight.

This keeps it true to my original vision though, that if you haven’t got engines that could make you move forward without pitching up then it still won’t magic it into going smoothly forwards. But if there is a complex solution to achieving that it will achieve it.

If straight and level flight can’t be achieved with the engines placed on the ship the linear optimisation library “does its best” and activates engines that make the ship go more or less forwards, so it degrades nicely if engines are destroyed (or just not placed by the player)

12 Likes

nice!!!

1 Like

That’s a neat idea. What linear optimization library did you use?

2 Likes

I tried a couple, the one I ultimately went with was org.apache.commons:commons-math3

It doesn’t hold your hand at all (I had to properly get an understanding of linear programming before I understood how to use it) but it does get the answer right (unlike some of the others).

It’s able to find “non obvious” solutions; like firing unbalanced rear engines (which led to a turning moment because they are unbalanced) then using other engines to trim out that turning moment.

I was initially concerned that performance would be a problem and was thinking about caching results, but in the end it was so fast I didn’t bother.

4 Likes

Drawing practice.

4 Likes

Hello,

so finally I was able to go back to Tunisia.
That - lucky I am - mean I have some spare time to do some coding.

During last few days I have tried to understand what I have done the last time I was active.
I have also updated JME to 3.4. I have solved some gamma correction issue (forum).

I had planned to finish my custom made lemur element “Readfield” (I told you in WIP 07/2019 about it).

Hint: There is two pictures in that album

Tweaked it a bit. The goal is to have one element that is able to show an optional picture or scene and an optional text as well as an optional headline → and its size is always the same. For that I am using my other modified lemur stuff.
But of course there is still some small issues e.g. the dynamic slider (it comes only if text is added and is wrapped and need more space as is available for text) that eats a lot of space to.

Anyhow I spend hours today on the styling as there might have been an issue in the styling class.
I am eager to build an element, that can be used as
unit chooser/description as well as a chat window.
Maybe I will add additional (lemur) mousepickers, that will enable the user to move and resize the element. Think of a strategic info window that you move to the left on your screen, or that you just want a bit smaller.
I have all that stuff somewhere in my tests… so my main issue is time and getting in tocuh with the code again.

4 Likes

Amen.

1 Like

project 2% complete

jme3-recast4j + blocks,

11 Likes

A turret:
Imgur

8 Likes

Practice.

2 Likes

Some advertising for Issue solving here:

As I had worked on wordwrap etc. before for my lemur adjustments I decided to work on Issue 1158 insteadt of working on my small project (as stated above). Issue = showing right to left text in a correct way.
With a bigger family around and not on my home continent it is of course hard to find more then 10 minutes of concentrated work time in a row (I know you guys know what I am talking about).

Anyhow after it took me ages to clone the JME github repo and make it work in my SDK of choice (“you need to update that”, hmm why its not an active class → “you need to use google” and then do this, download android SDK, you need another update, another plugin → wtf I just want to work on this class…)
So before it looked like that:

grafik

After a few adjustment it evolved from
grafik

to grafik

I was like - Hey you did everything right. Kerning is calculated correct, but why is it 0 all the time. Where is it even coming from. Is (Bitmap)Fontloader class not working ? Going line to line through so many files.
It took me two days (during them I only sit on code for like 2h in toal) to figure it out. My idea of reversing the existing stuff is good. But writing down a lot of number and variables even on paper took me on the right path to look.

In the end it seemed that the differences had been in a variable called “xadvance”. Once it is xadvance of the current letter and once from the next letter. I thought I took the right one on first try.
Anyhow to make a long story of “bug” hunting short. It was a change of a few words in code, that lead to the current result:

grafik

Currently @Ali_RS is testing the changes (I cant use Arabic or Persian font on my SDK). His first feedback seems positive.
So maybe (!!) with a bit of additional testing and proberly code styling (Im not an IT guy) the issue of Right to Left text can be implemented soon.

And for me - I would say I am more familiar with how Fonts are displayed in JME. As I am trying to do something very textbased I may profit from that in future. If someone else could profit from it, its an additional encourage.

10 Likes

Thank you so much for your time and effort. I’m glad I can help you with testing the issue. :slightly_smiling_face:

1 Like