Build Map from Blender or other 3D File?

[CalemBendell]

Is it possible to build map from a Blender or other 3D file?

I want to use the Spring Engine, having a considerable AI and some flexibility, for a university robotics project that I may do.

We would be creating a 3-D map of an environment and then importing that into the Spring Engine as a map. The robot could then function as a unit in-game, giving it advanced commands and AI without me having to program one or having to use some convoluted, bulky robot AI.

Challenges:
1. importing the map
2. constantly updating and improving the map, maintaining the 3D version as well
3. checking the robot is not out of sync with the map


Would this even be possible or will I have to look elsewhere?

Thanks for any help or suggestions you can give! I understand if Spring isn't really built for this at all, which is why the workaround in my mind would be creating a dynamic map so that Spring can function smoothly just as it would running a game. If you can think of a better work around, that would be great!

[knorke]

1. importing the map

Read here on map making:
http://springrts.com/wiki/Map_development
Maps are made of greyscale heightmaps, so if you can transform your 3d file into that, you can put it ingame.
On map making: http://springrts.com/wiki/Game_and_Unit_development

2. constantly updating and improving the map, maintaining the 3D version as well

Spring has some Lua functions to manipulate the heightmap. Or do you mean that changes to your 3D file should translate instantly to the map ingame? That is not possible.

3. checking the robot is not out of sync with the map

Not sure what you mean.

We would be creating a 3-D map of an environment and then importing that into the Spring Engine as a map. The robot could then function as a unit in-game,

Depends on what you want...
If you want lawnmower robot that drives around in a park/garden and cuts grass, that might be possible to simulate.
If you want a robot that crawls through a pipelines network, that will not work.
Also if you want any kind of sensors on your robot (say an IR sensor to detect walls) you would have to program their working too etc.

[CalemBendell]

Not sure what you mean. [referring to part 3]

The problem with having the robot think of itself as an ingame unit is if it gets off map. Say it slips, for example, or doesn't move as fast as it thought it would. If it is a numerous points off the grid, it wouldn't be able to interact with its environment very well.

Having a map that can constantly update would solve that problem.

I'm still looking into what types of sensors would be used but creating a greyscale height map shouldn't be too bad...


With Lua having changes to heightmap available, would there be a way of rigging changes to the heightmap ingame as a reaction to surroundings? The base purpose of having the map update in 'realtime' is so that the robot can avoid obstacles and make an obstacle map. The final 'output' is the map that it generates.



Thank you so much for your response!

[Columbus]

Why do you need spring there?

You could just make a simple 2d/grayscale map of your surroundings and hook up the pathfinder logic with it or something, without spring?

Adding spring there seems like creating a big laggy bloatware to me, unless you have some supercomputer attached to the robot, and usually these kind of projects involve netbook HW or similar.

[KaiserJ]

the map part though is possible. you'd want to mock it up in a 3d cad program and then make a heightmap and import to spring in a large format (i could help you/give you details or a process for this)

not sure exactly the methodology, and haven't a clue about the robot control side of it (but i can understand what you're after, you want a heightmap that represents a real room, and then to use the pathing within the engine to move the robot around. interesting.)

[CalemBendell]

Why do you need spring there?

...

Adding spring there seems like creating a big laggy bloatware to me, unless you have some supercomputer attached to the robot, and usually these kind of projects involve netbook HW or similar.

It is essentially 'laggy bloatware,' but the computer system that will be on the robot will be little more than a wireless slave to a considerably more powerful computer (... mine).

I thought Spring Engine would be best because it allowed me some flexibility in controlling the robot. There are some other things I think would be possible with the Spring Engine, but they'd only be possible if the mapping is possible, which should be one of the more difficult parts. Another idea is to be able to track moving objects and give them a rough representation (as a unit) relative to their size in Spring.

Wouldn't Spring make for a fair GUI? I would be removing much of the 'large' parts of the Spring Engine, as well as all units, and simplifying (or perhaps removing) all/most textures.
Is there a better option you can think of?


Another reason I chose Spring is that it is OpenSource and has a great, responsive community (not meaning to flatter).

[CalemBendell]

the map part though is possible. you'd want to mock it up in a 3d cad program and then make a heightmap and import to spring in a large format (i could help you/give you details or a process for this)

not sure exactly the methodology, and haven't a clue about the robot control side of it (but i can understand what you're after, you want a heightmap that represents a real room, and then to use the pathing within the engine to move the robot around. interesting.)

I plan to start grinding the details of it relatively soon. Unfortunately (yay academia), I don't really get supplies or funding until I already have some stuff to show, so controlling the robot really depends on what sorts of parts I can get. I'm hoping it's something I'll be able to program myself.

All Spring should theoretically need to do is output the current position and direction of the unit that the robot represents. From there, I can program the robot to simply (ha... simply...) match the direction and position of the unit ingame with a combination of environment checking and keeping track of the vectors the robot has moved.


Would Blender be a suitable program or would I have to use a different program such as BRL-CAD? I know BRL-CAD may be better suited to making and exporting heightmaps from data, but I would like to use Blender:
a) because I'm more familiar with it
b) after collecting data, Blender is a good space for texturing and detailing the environment should I choose to do so.

Would the files transferred be of a manageable size for a small computer (not a netbook, too bulky and a waste of funds, probably going to build a small, linux-based, battery powered computer and mount it)? Any predictions on file sizes?

Thank you!

[KaiserJ]

one thing i can think of that might be a dealbreaker here is the detail level or resolution of the spring map in relation to the real room.

measurements in reality are of course analogue, wheras with a spring map you will be limited to working within the resolution of the heightmap. even a *large* spring map (32x32 spring size equates to a heightmap resolution of 2049x2049 pixels) may not be fine enough detail for your work... you'll have to look into it for yourself i guess...

in order to create a spring map from a 3d model, you want to be using something like xNormal to turn your model into a cavity map, which means design-wise that you can't have multiple intersecting planes (so no caves or bridges)

you could circumvent this by making a spring map first and then recreating it to scale in a real-life model... but yes... spring heightmaps are meshes rendered from 2d images so there is a limit to the scale of detail

the other problem i can concieve is that it might be tough to sync RL robotic movement with said movement in the spring simulation (if your robots wheel slips on a slope for instance... not sure how the spring model would compensate. you'd need a robot that matched well with how spring pathing handles collision detection) someone else might offer a suggestion)

check out the engine and maps before you invest a ton of time. spring may not be suitable if you require a lot of detail and accuracy to your mapping and robot movement (but i imagine it would be fairly effective for applications like 1000 robots all driving about in a small area)

heh anyways i'll shut up now because i'm probably the least qualified to speak (let alone write a novel) about accomplishing a compicated task like this; but i do like the idea and wish you the best of luck

edit:

challenge 1- possible
challenge 2- not really qualified to say, but extremely difficult (would have to hack a lot with the terraform script and you're limited by heightmap resolution)
challenge 3- very tough, but more feasible than 2. IMO.

[CalemBendell]

Sure sounds like you know what you're doing .

Any way to edit the max map size? Never mind how much processing power any of this will take.



Also, Blender would be used for the detailed map output, all the Spring Map is for is to avoid major collisions.

[Columbus]

What kind of conditions will your robot be running in? Outdoors on terrain, indoors, controlled environment, such as a labyrinth or a game field? What size is it?

Knowing this can greatly help on deciding what mapping/pathfinding technology you should use and the sensors you should use.

I have a bit of experience with robotics and machine vision.

[CalemBendell]

It will likely not be running in any truly adverse conditions. Inside, generally flat floor, numerous obstacles, a labyrinth would be an excellent demonstration of what I would want it to basically do.

I'm honestly not sure how big it would have to be, but nothing more than a couple feet long and wide. It would be fairly square with two large wheels or treads for tank-style movement. If it needs to be larger to support electronic equipment, that would be fine.

Maybe include a front-mounted ultrasonic range finder for extra collision avoidance. I'm not sure what sort of sensor would be able to map a 3D environment from a single location; I'm hoping its possible. Maybe with some type of sonar.

The goal at this point is to deploy the robot to a location, have it scan its surroundings (preferably with some ability to penetrate and map solids), get a map output the user can see in Blender and Spring, use Spring or another engine to guide it to a new location.

Some nice things I'd like it to do:
a) repeated scan that collects all the data and merges it into one map
b) ability to identify moving objects and represent the objects as temporary in Blender (maybe with translucency or colour coding, shouldn't be hard to do that part) and as a moving unit in Spring.


Fortunately, I haven't stated any mission goal yet, so my goals are pretty flexible.

[CalemBendell]

And I'm totally fine with exploring an absurd number of options.

[knorke]

I'm not sure what sort of sensor would be able to map a 3D environment from a single location; I'm hoping its possible. Maybe with some type of sonar.

How would that work if the sonar is at ground level, a wall behind a wall is invisible to the robot. Unless you have an overheard camera or something. The robot would have to move around to map everything.

I'd start with putting whatever sensor (ultra sonic range thing maybe) on a 360┬░ rotating plattform and try to get a plot like

[CalemBendell]

That would work great for objects avoidance and basic object tracking, but not as well for intelligently finding a way through a maze.

Perhaps a camera and a series of mirrors would work best. It would probably not be too bad if the robot was a little tall, as long it remained considerably heavier on the bottom and it had enough power to move itself without using a huge amount of battery.

[Columbus]

If you have a maze, the you could just keep following one side of the wall until you are out. Any path calculation is pretty much pointless, since you can't see the entire maze anyway.

Or.. do you have a bird-s eye view of the maze?

Mapping to Spring would only benefit if you are on a large 3D terrain and you need to know if the slopes are climbable, and compute a path between land features etc.

For indoors, I think a simple B&W image/map would do

[CalemBendell]

Or.. do you have a bird-s eye view of the maze?

Mapping to Spring would only benefit if you are on a large 3D terrain and you need to know if the slopes are climbable, and compute a path between land features etc.

For indoors, I think a simple B&W image/map would do

I want to figure out how to get a bird's eye view. A combination of ultrasonic sensors, cameras, and mirrors may be able to accomplish this. There may also be a sensor available now for this. It is theoretically possible with an ultrasonic sensor in a room with a ceiling, bouncing the waves off the ceiling (it's been done... I don't have those sorts of funds, of course). So rather, there may be a sensor I can afford.

If necessary, I could make a separate device (maybe give it a human companion), that can create and send a map to it wirelessly (that would be bluetooth perhaps).


I'm worrying about that later (sort of... worrying about it now, but not the hard details)- was wanting to go ahead and get a setup for Blender --> Spring.

Going to start figuring out how it could be done with xNormal soon.

If the ability to make a 3D map proves a futile ambition (though it would be a great leap in the movement intelligence of the robot, like the difference between a bacteria and a basic insect), then I could continue with the other ideas, maybe making a map with ultrasonic sensors while running but not using it for intelligent movement.

[KaiserJ]

sorry it took me a while to respond; im home now though

you can theoretically go to double that heightmap resolution to be within engine limits; but there's a trick possibly to making such a large map known only to some of the wizards around here... the largest i've been able to compile was 40x40

here's one way this -could- work (the map bit)

once you've created the map in blender, xnormal can be called from the command line. what you want to do is apply your model to a flat plane of identical size and render a heightmap (what xnormal is used by most for is doing a high-low poly bake to get normal maps, but it can be used for many many things)

once you've got a heightmap you can call mapcon from the command line, using an existing SMD file (text w/ map properties) and a texture file (a bitmap that is 8x +1 the dimensions of the heightmap, you can find the info in the wiki) to generate a playable map

why would this be bad? you need to generate and compile the map before the engine starts. thusly a truly dynamic map is probably not attainable in this manner (like if you wanted to plonk a box in the middle of your robot sim... map would need to recompile with this method and you'd need to restart the engine)

the other option (probably closer to what you want) is to begin with a completely flat map, and then once the engine starts, somehow pass the information from the physical maze to the engine and use the terraform gadget (in CA and ZK games and some others) to alter the heightmap in realtime

(when i said i wasnt an expert: to clarify... i'm pretty knowledgeable with mapping... the format, jamming in as much detail as possible etc... but i'm a super noob with the engine and LUA)

so yeah. if i were to attempt this... i would mark out maybe a 2 meter square area in RL, paint it with a grid that corresponds to the pixels in my heightmap, and then to alter the maze, i would place colored blocks within the RL space...

i would have a cam-capture running with something for image analysis (flash maybe, i made a game once using webcam as input and it was fairly simple to set up) to analyze the image from the top down every few seconds; camera would recognize (for sake of example) a red box placed on the RL surface and would parse that information into an array containing an entry for each individual grid square (lets say 0 is open, 1 is blocked) in order to figure out where the robot can and cannot go

then i would use said array as a reference every few seconds by the terraform gadget to determine which squares (referring now to pixels that make up the heightmap) are passable and which are not

it all sounds like it's going to require a lot of CPU juice, and at the moment, the biggest problem i could see would be syncing your RL robot with a unit in spring engine... it might be very difficult to exactly match things like speed, position, bearing etc but heck if you're the robot man you know more of such things than i.

a hacky way to "fix" this problem would be to tie RL movement to movement within the simulation (RL robot cannot be given a new command until it is aligned perfectly with sim robot, meaning that it can maneuver and change its position to match that of the sim without having to be given instruction)

[CalemBendell]

Will be testing stuff out with changing the map with terraforming.

Thanks for the help.