Hi guys,
First and foremost: Hi, I’m Ollie! This is my first actual post on the forum, but it seems great so far!
Anyway, my query is thus:
We’ve all played games where the player wanders around and picks up objects for points/gold/fame/whatever. I wondered how the locations of pick-up-able objects are generally stored and managed? I briefly considered having a scene file containing the “world” and a scene file holding the objects in their respective locations (that I put together in Blender or some such), but I wasn’t sure if I’d be able to check for collisions with the objects individually if I were to load the object-locations scene file into the game as a spatial?
In my pre-game engine days I’d just hardcode the locations, but this never felt like a particularly graceful/scalable solution and now that I can import models into my games I’d like to start doing things the right way!
So, tl;dr: How should I store the locations of my objects that I wish to be able to pick up?
Hope that was clear enough, gimme a shout if not and I’ll clarify.
Thanks for reading,
Ollie.
Well, if you give each node a unique id/name, you could do a symbolic link between the 3D object and the other “non visual model” where you store information about whether an object is in your inventory, weight, value, whatever. The same way you can translate the objects to their right spot depeding on location info you have stored in your model representation.
Hi Johncl, thanks a lot for your swift answer.
I’m afraid that I’m still a relative newbie (I’ve gone through the “hello X” tutorials, and skimmed over the intermediate/advanced ones) and I didn’t really understand what you mean.
I meant that I simply export a blender file which contains something like this:
________________
| -o
o
|
|
o
|
|---o
|
|________________ |
Where the lines are just the scene boundary and the 'o's are meshes which I want to pick up. If I export this, and import it as a Node could I check for collisions with the individual parts of the scene? Or would that require some advanced programming shenanigans?
I really need this to be as basic as possible, as I'm a bit overwhelmed at the minute!
Thanks again,
Ollie
Well, have you checked out the Hello_Picking sample?
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:beginner:hello_picking
This one casts a ray from the cameras location and its direction and you get a list of all objects it “hits”. This information can be used for “picking up” objects. You can e.g. based on the distance allow the user to pick it up, and if its within distance you just remove the Node from the scene (removeChild). If you just want to keep a track of what nodes the player has picked up you could just add this Node to your own list (List) you call inventory or something. To drop/place an object you could do the same by removing it from your inventory list and add it to the scene again with attachChild.
My reply was perhaps a bit more advanced where you would want a separate “model” (when I say model I dont mean 3d model, but a class with some general data about the object) where you store information about the actual “thing” so you distinguish better between the view-model and the business-model to use the appropriate terms. For that to work you could either make it so that your business model also loads/instanciates Node objects with geometry (either loaded or created) and stores a link to these or make a more “loose” connection through the use of string identifiers. Each Node can after all have a name which if kept unique is a nice key to connect the physical world (Node) to the logical world (e.g. MyObject). Saving the state of the world is then only about serialising these objects to disk and not the 3d models themselves.
Another approach is of course to make a class that inherits Node and gives it all your logical game world properties, including the ability to initialise itself with its geometry and materials whenever its needed for a scene. Adding and removing it to the scene is then very easy. A nice thing with the jMonkeyEngine is that its very open and extensible. 
Again, thanks Johncl! That answer was a lot more informative to me as a beginner.
I just popped a few teapot meshes into a scene in the scene explorer, and when I call loadModel() on the scene, I cast it to a node. It turns out that I can then loop through the node/scene’s children and do ray based collision detection on them (they explode in a shower of tacky flame sprites currently! :D)
So this pretty much answers my question regarding “can you reference meshes within meshes”!
Next question I guess is what’s the most widely regarded way of making my character collide with things? I went through the hello-collision tutorial but the way of attaching a collisionshape to the camera felt a bit clunky (especially when you have to start manually making the physics object move with strange boolean variables, and then attaching the camera to it…) For example if you look at the floor and hold the “down” or “back” trigger key then you actually fly, which isn’t the desired behaviour!
It could be that I’m expecting too much hand-holding from the engine, if so please tell me to shut up and point me in the direction of another character movement/physics tutorial!
Thanks again Johncl/whoever moved my topic to the correct forum; despite my moaning/queries I’m loving the engine!
i think he means like a coin. You go on top of it and “collect it”, it gives you points etc.
@lolliver0342 said:
________________
| -o
o
|
|
o
|
|---o
|
|________________ |
Where the lines are just the scene boundary and the 'o's are meshes which I want to pick up. If I export this, and import it as a Node could I check for collisions with the individual parts of the scene? Or would that require some advanced programming shenanigans?
If you have your model:
[java]Node n = (Node)assetManager.loadModel("Scenes/myScene.j3o);
Spatial coin = n.getChild("coin1");
//then do w/e with coin, add a collisionshape maybe
[/java]
then its up to you how you "collect" them. Either using the bounding volumes, or create a collision shape using the bullet engine, and detect collisions, and react accordingly.
You could add something like coin.setUserData("pickable", true); and then check that inside in the PhysicsCollision object, to see if the object which was collided, has pickable set to true. Theres quite a few ways to check for this tho, comparing specific objects, childNames etc
Hi Wezrule,
That’s exactly what I was referring to, thanks.
I hadn’t even considered using the setUserData function, so thanks for that! I’ll have a go at doing something with that this afternoon/evening.
In the meantime how do people normally deal with the movement of their character? As I mentioned above using a CollisionShape/CharacterController on the flyCam doesn’t seem like the tidiest route to go down. I’d ideally like to keep the first-person viewpoint for this game, if that affects your response at all.
Thanks again for all the help guys.
@lolliver0342 said:
As I mentioned above using a CollisionShape/CharacterController on the flyCam doesn't seem like the tidiest route to go down.
Why? You got all movement/character related code in two nice, replaceable Control classes.. You can replace them later, stick with them, add other/your own Controls.. Whats "not tidy" about it? Using Controls and UserData is a good and expandable way.
Well the tutorial where you’re introduced to the CharacterController and CapsuleCollisionShape (“hello collision” I believe) results in a character which can still fly (by looking at the floor and holding back/down/S/whatever binding), and the booleans to keep track of direction etc didn’t seem like the simplest way of moving the camera. I just wondered if there was a “standard” way that people use to handle the character/collisions/camera?
Also this is my first day of solo development with the JME and I have no experience/understanding of the way that Controls work yet!
I meant no offense Normen, perhaps “tidiest” was the wrong word 
Thanks for all the replies so far all! 8)
Hi Ollie,
As far as I remember, the default actually works quite well, just make sure to disable the flycam. You need to make sure that the character control has weight and that gravity is turned on though.
I ended up writing my own character control which includes a physics control for it, because I wanted to be able to give users the ability to adjust sensitivity. Take a look at some sample code, its not difficult.
Regarding your the questions in the main part of your thread, I probably wouldnt have the objects that you want to pick up as part of your mesh. I mean, you could, I just dont really like the idea of having them “belonging” to the same mesh as your parent. But then again I am no expert - perhaps that is how you would really do it?
Actually, thinking about it, perhaps that is the best way. I was going to say that you could insert them into the scene at runtime, which you can, but you will have to fine tune the coordinates. So it might be easier to just include it in the scene.
Once you detect a collision with a pickable item, maybe just hide it, or remove it from the scenegraph, and change the state of the player/players inventory?
Ancalagon,
That’s what I was thinking. As soon as my dude smashes into a coin then it’ll be removed from its parent and I’ll increment some itemCount variable. Just gotta work out the collisions stuff and I’ll be there I reckon!
I’ll report back with my findings in a while; cheers all!
Ollie
I think the flying thing is a result of the movement force being stronger than the gravity and the mass of your capsule is able to hold you down in the example. Meaning that you will surely “take off” if you move. Try tweaking the physics parameters until you get the desired behaviour.
As for user data I was actually unaware that Node’s had such a thing. You learn something new every day. I guess a good way to use this is to still create a class of your own for every entity you need to keep track of and use the userdata to link back to this whenever you need to figure out what “real entity” you are messing with when traversing from the Nodes.
Hey folks,
I’ve done a fair amount of Googling and hacking about with my code but I can’t for the life of me work out how to check if my player’s CapsuleCollisionShape intersects my teapot’s bounding volume?
I’ve tried casting the capsulecollisionshape every which way and the CharacterControl doesn’t seem to have any other methods which offer a solution here.
It’s probably something really simple, but I can’t see it!
Ollie.
Apologies for the double post, but scrap the above; I found a way of implementing it with a cylinder generated from the capsulecollisionshape.
Thanks for reading,
Ollie.
You could also just calculate the distance between the player and the coin which is very simple to do with the Vector3f object and pick up those who are within a certain distance. In many cases that often works well if you just want to pass objects to pick them up like you want.
Fair point Johncl, that might actually be a better way of doing it. At the minute I loop through every teapot and check to see whether I’m inside it with CollisionResults etc, your way would provide quicker checks I imagine as it’s just a bit of vector maths!
I’ll get a little youtube video up tonight if I get time demonstrating my super fun game: “Run Into Teapots So They Explode” 
Thanks for all the help folks.
Ollie. 8)
Np, glad to help out. At least you are making a real game! I got to stop fiddling and tweaking visuals and create something to do in mine! After all, its the gameplay that is the most important… I just got to try out a bit of particle effects first. 
lol I’m the exact opposite man, I have very little interest in making my game visually appealing; so I focus completely on making nice features etc. but at the end of the project it still looks like a PS1 game!
I know what you mean, I’m a little bit in love with the particle effects in JME to be honest!
My background is straight C++ and OpenGL so this all feels a little bit like wizardry to me
Well, although I am using a 4 to 5 year old 8800 gtx card I still want to get minimum 30 fps so I am really just experimenting how to use jMonkeyEngine at its best. Its very easy to just add tons of terrain, models everywhere, physics on it all and at the end you have a slideshow running. So I am trying to figure out stuff like:
- Terrain LOD, could it be tweaked to get LOD triggering earlier? A bare terrain generated from 512x512 height map images like in the tutorial is over 1 million polys rendered when I test it. I am sure there is quite a bit of performance to be had by lowering the amount of polys it renders.
- My asset generators for trees, rocks, etc that I am working on, how can I make them look good at the same as I keep the mesh size down? Its easy to use some generator of the shelf and you get a tree with 100k polys and you can add a couple of trees and be happy. But I want to have 300+ trees in my view at any given time, both close and distant. I definitely need to generate LODs as well for these and need to find a way to do this most efficiently.
- Simple things like if I create a rock mesh and plop it down somewhere, could I optimize the mesh after that to remove the vertices and polygons that will always be hidden since its stuck in the ground? An advantage of having complete meshes is that I can ofc reuse them many times by just rotating it in a different position to get a “new rock”. But jme3 doesnt support instancing so it wont improve framerates.
- Should I create dynamic physics mesh’es on the fly as required, or just add it for every object in the scene? I know physics space also take memory so that might be a problem eventually. The scenes need some sort of segmentation anyway, so the memory conservation would definitely come out of this as well, but should I do something to improve it further like only physics meshes on stuff around the player. This wont work if there are other NPCs or objects requiring physics to work as well. The most important thing is to know if physics objects take any CPU time at all while not active. I know that even if they “sleep” something is still iterating perhaps 10000 physics nodes every frame so there definitely is an improvement to be had by adding and removing stuff to the physics space as needed. I also have problems with smaller objects falling through terrain and need to solve that.
- Java Garbage Collection! I notice already that the GC is doing sweeps in the background as I get stuttering now and then. Like all garbage collection languages I have to use more recycling. Even things like modifying RGBAColor objects instead of creating new ones every frame will reduce these stutters. Creating pools of assets is also a good thing, reusing them as much as possible. I have even thought about stuff like only having a pool of grass quads, pebble meshes and other “scenery clutter” and just move them about the scene as needed based on view distance. But rather than iterate over them all every frame I can spread the calculation out on several frames.
- Transparency/culling challenges. I still have a lot of problems like alpha edges of my billboard quads showing background colour, which looks rather bad. Can I fade in/out whole models based on distance, if so how? How to do dynamic culling that arent based on frustrum culling (e.g. some things are culled halfway into the frustrum). Particle effects are hidden by the post water effect as well as the fog. I probably need to change fog to be per material like someone has done. No idea how to solve the particle effect problem.
- Learning to model in Blender! I made my first model yesterday and was able to UV-map a texture, convert it to j3o and load it just fine! But its easy to forget that models need to be optimized or you end up with 1 million polygons for simple objects. I guess my biggest challenge in Blender will be the creation of a humanoid figure, skinning and rigging it for animation. The Sinbad char is cool, but I want to make my own! Challenging stuff like clothing, how easy/hard is that? ofc one could swap out simple texture maps, but not all wearables can be just textures. How hard will it be to divide the char into “placeholder parts” and have the bones animate the parts where I attach clothing to the placeholders? I know that animation modify the mesh as well so this might be a tough challenge and might require the model to be all one mesh. I know it will take time to build these skills.
- How much does the numbers of texture layers affect shading performance? I’d like my models to have at least a diffuse and normal map (and sometimes also a specular layer), but distant LOD versions could very well only have diffuse if that can increase their rendering performance.
- Learn more about shaders and to use optimized versions if they exist for some of my materials (like the fog fading tweaks someone has done here, and the faster LightBlow shader).
- Have fun coding! - Yeah its really just about having fun and seeing you world come alive. I am really excited about creating more Controllers, as the moment your Nodes get some behaviour going on, that’s when the fun starts. I have coded simple interaction with the environment like picking up and dropping objects which was rather easy, and playing a bit around with showing some stats and interface components on the HUD. I am wondering a bit if I should add scripting support as well as I know it could be nice to script AI behaviours and see them changed “live” rather than doing it in code and having to recompile/start over and over. Java supports Javascript straight out of the box so that might be the simplest path.
Anyway, just some jMonkey ranting there.
Whoa, that’s a mighty rant!
10) I’m definitely having fun! It’s so easy to get bogged down by language/API/syntax etc (Which is the reason I moved away from doing everything myself to using the almighty Monkey engine.), it’s nice to be able to see results quickly for a change; it’s a definite motivator.
9) Shaders… bleh. I’ll stick to happy exploding teapots and ridonkulously unoptimised terrain for a while longer!
8 ) When I did the tutorial which introduces bump mapping, I honestly felt like a pro gamedev haxxor! Beats the heck out of the simple flat shapes I’ve programmed with so far 8)
7) I know what you mean, I recently made a little terrain with a “tunnel” made out of an extruded, hollowed cylinder which goes through one of the mountains. Topped off with a little wooden paddock! The whole thing took me about 4/5 hours and I loved every minute of it!
6 - 1) see number 9!
My main focus at the minute is making a first person 3D platformer. It’s simple enough to implement but it can be easily expanded and gives me a good chance to get my feet wet with collision/particle effects/asset management/AI.
So far I have some nice terrain (the world), some platforms and some spinning exploding teapots! I took your suggestion on board regarding the collision checks with the teapots and it’s definitely quicker; so thanks for that.
Viva “Collect Teapots and Smash Bad Guys”!
Ollie