Post Tutorial Noob Questions

Hi,



I have a few questions after running through all the beginner tutorials. Everything worked fine, and I got through most of the exercises. I just had some questions about how a few things worked?



HelloLoop.java Tutorial

When I first did the section where you add a second cube, and rotated it, I noticed that on certain combined rotations, the 2nd cube seemed to be rotating around a center that wasn’t really the center (so there was a wobble) This happened when I created the cube 4 units to the right like this:

[java]Box b2 = new Box(new Vector3f(4,0,0), 1,1,1);[/java]



I fixed it by creating the box at 0, and instead moving the geometry afterwards using:

[java]player2.move(3f, 0f, 0f);[/java]



The box would then rotate around it’s proper center. Any idea what the difference is?



HelloTerrain.java Tutorial

When the splatting is being applied using the ALPHA map, how does the programme know to apply grass to the color red specifically? This goes for all the other colors? Is there a standard behaviour when it comes to alpha maps?

How does this expand to handle more textures? What color would you use to add a fourth texture?





Where to go next?

My initial desire is to create a train, that can follow a track and pull a wagon along it. I’m thinking I need to look at motionPaths for tracks (?) and maybe some physics for the pushing and pulling. Can anyone suggest some methods of making a wagon stay on a track but be pushed or pulled along it with bullet physics or otherwise. Are there any tutorials or methods that might be able to make it simple to tether one object to another?



Thanks for the help guys, and thanks to the JMonkey makers. I’ve been playing around the games area a while now, but this is the first engine that made me feel like I was getting anywhere!

  1. You move the mesh. The geometry center isn’t affected and the visual mesh is off-center in the first line.
  2. You need more maps (textures). The maps are but a way to get data to the shader (that much at that location), you don’t have to think about them as images necessarily.
  3. Reading the whole manual is definitely worth it as a next step. Even if you won’t remember every detail the overview you’ll get will give you a much better idea of what you can do and thus a better idea of what you want to do :slight_smile: We are proud of our documentation and think it gives a great introduction to the whole topic of gaming and 3d graphics. The SDK documentation is also worth a look as the SDK can do many things that are not quite so obvious on first look. Finally theres the JmeTests project you can create in the SDK to look at the test examples of most functions of the engine.
  1. So a geometry doesn’t take it’s center from the box mesh it is supplied with?



    eg:

    [java]Box b2 = new Box(new Vector3f(4,0,0), 1,1,1);

    player2 = new Geometry(“red cube”, b);[/java]


  2. So one alpha map can only handle 3 textures. And you would just add another alpha map for 3 more textures?



    3)I’ll go and read the manual some more then!



    Ta
  1. The geometry defines the location of the object. The mesh is a construct from vertices. You tell the Box class to create one that has its vertices all at locations with z+4 with that constructor.
  2. Best just use the SDK to paint on the terrain, it adds all necessary maps :wink:
  3. Thats a good idea :slight_smile:
@paulsermon said:
HelloLoop.java Tutorial
When I first did the section where you add a second cube, and rotated it, I noticed that on certain combined rotations, the 2nd cube seemed to be rotating around a center that wasn't really the center (so there was a wobble) This happened when I created the cube 4 units to the right like this:
[java]Box b2 = new Box(new Vector3f(4,0,0), 1,1,1);[/java]

I fixed it by creating the box at 0, and instead moving the geometry afterwards using:
[java]player2.move(3f, 0f, 0f);[/java]

The box would then rotate around it's proper center. Any idea what the difference is?


You are right! I fixed the example on the wiki also. It's kinda old and I changed it a million times. ;)

@paulsermon said:HelloTerrain.java Tutorial
When the splatting is being applied using the ALPHA map, how does the programme know to apply grass to the color red specifically? This goes for all the other colors? Is there a standard behaviour when it comes to alpha maps?
How does this expand to handle more textures? What color would you use to add a fourth texture?


I think I wrote that: If you assign a, say, "metal" texture to texture layer "Tex2", all GREEN pixels are replaced by the metal texture (because Tex2==green).

In the Terrain.j3md material, there is only "RGB", so you can only have three layers. In the more advanced material TerrainLighting.j3md, you have a few more layers at your disposal (12 I think).

Usually you don't do that by hand, you use the jmonkeyengine SDK. But you can do it by hand, if you want to.

@paulsermon said:Where to go next?
My initial desire is to create a train, that can follow a track and pull a wagon along it. I'm thinking I need to look at motionPaths for tracks (?) and maybe some physics for the pushing and pulling. Can anyone suggest some methods of making a wagon stay on a track but be pushed or pulled along it with bullet physics or otherwise. Are there any tutorials or methods that might be able to make it simple to tether one object to another?


The keyword would be "Physics hinges and joints", also look for Physics Vehicles (on the wiki -- might be a tad advanced for you, it's not trivial to change those samples and turn them into a train on physical rails, but it's possible).

There is also the question whether a physics simulation is really efficient for a train. (I assume you're not racing the trains or drifting through turns in the street, or crashing them into a pile of crates?) ;) Most games cheat a bit and replace physics with simpler approaches -- as you mention: prescripted motion paths are a very efficient non-physical option to steer a train along rails that gives you a lot of control. A physical train can fall over or get stuck.

You can use the existing TestPhysicsCar.java example code and experiment I guess.

PS: Here are the (possibly advanced) sections I mean:



https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:cinematics

https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:motionpath



https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:hinges_and_joints

https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:vehicles

@paulsermon



i rearranged your name and got

“u loan sperm”



:slight_smile:

There is also the question whether a physics simulation is really efficient for a train. (I assume you’re not racing the trains or drifting through turns in the street, or crashing them into a pile of crates?) Most games cheat a bit and replace physics with simpler approaches — as you mention: prescripted motion paths are a very efficient non-physical option to steer a train along rails that gives you a lot of control. A physical train can fall over or get stuck.


This is a conclusion I have come to, as thinking ahead, I will want to have many wagons and trains. I also think tethering can be simplified rather than using a physics solution.

First things first though, is to make a train and/or wagon model and get them in a world, then get them to adhere to a track, then add controls.

i rearranged your name and got
“u loan sperm”


Er thanks?

You could even do both!



Uwse a simple approch with a derail trigger, once the train derails use normal physic for it so it crashes nicly.

While it moves normaly you could use kinematic physic ( it is moved by code, but pushes other stuff away)