I am working on a project where I have to be able to move buildings from a menu to a landscape similar to SimCity. Is this decently feasible in jMonkey? Or will it be extremely difficult? Thank you.
Absolutely feasible. The level of difficulty depends on your own skill with the language, programming structure and jmonkey itself. If you already know java, go practice in the tutorials with jmonkey. I can tell you with great certainty that however you accomplish this goal of yours, jmonkey will be one of, if not THE easiest implementation method.
any-things possible with imagination
wezrule said:
any-things possible with imagination
+time +skill +patience. ;)
1 Like
+alcohol
1 Like
wezrule said:
+alcohol
Why am I suddenly thinking of a Homer Simpson quote: "Ah, alcohol... the cause of, and solution to, all of life's problems..."
2 Likes
Haha lol. I am ok with java. Im no expert but I can hold my own. And I have until around mid-december for it so that should be enough time.
Thanks everyone for the help, and a couple laughs.
Definitely possible in jME. We’ve got an application (using jME2) that allows users to upload new buildings, move them around (if they have the right permissions), and post comments.
A few things.
- Think long and hard about your GUI. The modality is a bit different from a game unfortunately and requires more programming than your typical 'point crosshairs and shoot target' interactions.
- Scale. Depending on the size and area of your scene, you likely won't have the headroom in float-precision to have a scale like 1 unit = 1 meter. Make sure your modelers understand this while they're working.
- Keep artists in the loop. As noted above, make sure they understand scale. Also make sure they understand the concept of zeroing out models before import (so that they can be placed and located effectively) and check that the procedures they're using in their DCC tools are translating correctly into the engine.
Having spent just shy of three years on this project so far, I can say we'd have saved a lot of time just by following one or two of these :)
sbook said:
- Scale. Depending on the size and area of your scene, you likely won't have the headroom in float-precision to have a scale like 1 unit = 1 meter. Make sure your modelers understand this while they're working.
Very respectfully, universally changing scale will not give you more precision. float doesn't care if you are adding 10 + 10 or 100 + 100 or 0.001 + 0.001. It does care when you try to add 1000000000 to 0.0000001. So, either there is a missing element to your advice or zeroing out the buildings was the real fix. :)
Generally, if you want better visual precision out of float then (at least conceptually) you have to make things relative to a reference grid of some kind and then recalculate the grid as relative to the camera, ie: camera doesn't move but the world does and never very far. Or do all of your own transforms in double converting them to floats relative to the camera.
Either way, scene size is the factor... if all of your models are relative to a city-center origin then you could make a pretty big city and still have centimeter resolution, I'd think. (I haven't done the math but I guess you start losing centimeter precision somewhere between 10,000 and 100,000 meters.)
...and I could just be missing something.
1 unit = 1 meter is fine, ever noticed that most open world games (e.g. Far Cry 2, Red Faction: Guerrilla) have a map size of about 50 square kilometers? 50.000 - 100.000 is also the value where physics calculations can start to become inexact when high forces appear, so it seems “real” game devs are coping with this for long already.
pspeed said:
Very respectfully, universally changing scale will not give you more precision. float doesn't care if you are adding 10 + 10 or 100 + 100 or 0.001 + 0.001. It does care when you try to add 1000000000 to 0.0000001. So, either there is a missing element to your advice or zeroing out the buildings was the real fix. :)
I should've phrased it better. Doing small translations on numbers as low as the 50,000 range, will give you issues. That said, putting an object at {x:50000, y:0, z:50000} won't actually put it there in OpenGL (as you said above)..
Cutting down the scale helps, as does (and I really should've mentioned this, luckily @pspeed did) calibrating the camera location in the scene. For us it meant a translation layer where the starting point in a city is {x:0, y:0, z:0} in OpenGL while it may be {lat:40, lon:-73} in real world terms.
I'll also stop here because I almost just shot off into a tangential topic about coordinate systems and different projections of the Earth... I'm sure you don't want to hear any of that :)