Environment modelling using raster planes

In my eternal quest for an easy way to model game environments, I have come across an idea that seems effective. Obviously I could just build up an environment by transforming bits of geometry one piece at a time, but that is too much like work. I could also build an environment out of cubes in the Minecraft style, but that’s too restrictive. I want something between these two options so that it restricts me enough to streamline the process without stifling my creativity.

I suggest that environments are dominated by flat surfaces in various positions and angles, so imagine modelling an environment as a collection of planes where each plane has a 2D image to define the geometry and materials within that plane. It’s like making a dollhouse by painting and cutting a sheet of cardboard for each floor. Once you have the floors, you can transform them as necessary to put them in the correct relationship with each other and use geometry to connect them with stairs (or ladders, elevators, etc.) and fill them with furniture. In the simplest case, if your environment is a building with only one floor, then modelling it is a one-step process: just draw a map.

Each plane of the model should naturally be stored as a raster image. This allows us to freely draw the geometry without fiddling with vertices and edges. We would have a palette of materials so that each pixel can store a small number to select the material of that spot on the floor. The rest of the bits of the pixel can be used to store a pair of texture-mapping vectors so that the material can be transformed as necessary.

Once we have drawn the raster for each plane, we can use a vectorization algorithm to convert the raster into a mesh. This process should give us easy control over level of detail because we can choose to vectorize the raster precisely for high-detail, or aggressively for low-detail. The user should be able to divide the plane into appropriate regions and then set the level of detail that should be visible in each region from each other region in every plane of the environment. Each level of detail can be loaded into the game as a separate mesh, and then the currently visible mesh would be switched as the point-of-view moves between regions.

Is this a good idea? Should this be my JMonkeyEngine project? Is there already a modeller available that can do this?

I feel like you are probably better off using a vector format rather than rasters. Just seems like a lot of work to go from a raster (that was probably drawn with lines) to some algorithm that’s going to try to extract lines from it. Else it will look like Minecraft with only columns.

It seems like every minute you save not having to ‘draw walls’ in some editor you will lose trying to fix all of the random glitches that come from your vectorization algorithm. Unless ‘minecraft with only columns’ is what you are looking for in which case it would work fine, I guess.

I thought that vectorization was a great idea both to simplify drawing for the user and because it allowed for various levels of detail to be automatically generated. How should level of detail be handled? I can handle drawing my own walls if I must, but must I manually generate multiple models for the same environment to cover various levels of detail?

But what exactly would the ‘automatic level of detail’ be doing? A line is a line.

I mean, the alternative is that up close you have a wall drawn with 100 triangles because it happened to be at an angle the vectorization didn’t like… when it could have just been drawn with 2 triangles near, far, mid, wherever. What’s to LOD in that case?

For interiors, 90% of the time you aren’t even drawing stuff that far away. A good ‘potentially visible set’ algorithm will go much farther, I think.

And even if your level is made of 2D polygons extruded into walls and such… the algorithms to LOD that are pretty trivial.

I’m expecting that the vectorization algorithm would produce solidly reliable results due to the raster being drawn with vectorization in mind. Sharp lines of solid color with no anti-aliasing ought to produce unambiguous vectors. Then I should be able to force the vectorization to cut corners by merging walls that aren’t quite flat, and in the extreme any room could be turned into a rectangle.

I wouldn’t want to restrict myself to interiors, but I see your point about level of detail not being important in that case.

Perhaps I am misguided in using a raster. The thought of instantly modelling an environment from a quickly sketched map is just so enticing and vertices are so fiddly by comparison. Perhaps there is some way to compromise and use 2D polygons without slowing down the modelling process as much as I fear.

Note: the math to merge two lines into one based on angle is WAAAAAAAAAY easier than getting vectorization right.

Sketched with what? Freehand? Then your lines won’t be very straight and you will end up with lots of polygons.

And if you sketched it with lines in the first place… then might as well save the lines.

I once wrote a program that let me pull up a floor blueprint (office with like 500 offices in it) and draw the walls, windows, and doors on it as lines. The app took me about a day to write. It took me a couple days to make a map from the offices. The blueprints would have been impossible to vectorize with any remotely useful accuracy because of a random pixel here and there or a place where a line slightly extended, etc…

The closer you can get your modeling to your final data structure, the happier you will be.

Maybe find a good SVG editor and write something that reads SVGs. Then you will have pretty rich vector and shape data.

I’m convinced that vectorizing raster images is more trouble than it’s worth. Thank you.

Unfortunately using an external vector graphics tool is also not a real option because drawing the geometry in one tool then modelling in another tool would be impractical. I’d at least want to be able to apply materials as I draw, and being able to bounce quickly back and forth between modelling and drawing is sure to be important. If I needed to adjust how two planes line up, I would hardly want to jump out to Inkscape, make a blind adjustment to the original map, re-export, then import in the modelling tool, then check how close I came and repeat until good enough.

Even so, studying SVG editors will be useful. I may want to imitate a good one, or perhaps I could find a Java-based SVG editor that I can embed in my modeller.