
PolyOne 0.3.4.2, Hybrid Graphics Design Application
This is a piece of software I started working on the oldest version of 8 or more years ago now. The original version that looks nothing like this iteration was made to take advantage of how many game engines allow you to pass over the points of triangles, to make more complex shapes. In this case the idea at the time was to break free of the grid-based limitations of the built-in level editor in Game Maker (which I no longer use).
However, I realised the software wouldn't have to be limited to a particular genre of 2D games and could have many other potential uses outside of creating levels for 2D games (although that's what it might be most effective for), such as creating maps for tabletop RPGs or applying foreshortening to patterned or textured surfaces in artwork you've created outside of the software. The latest version in the screenshot here allows you to select a portion of the work you've created and save it as a PNG file.
The kind of fusion of vector/mathematical information contained in the properties of each point of each triangle and the raster (pixel) data of textures put it in this kind of weird space between vector graphics software like Inkscape and more conventional raster graphics image editing software like Photoshop, with its own set of advantages and disadvantages. The textures are loaded from a folder defined in a config file, and one subfolder deep. Here, I've used many textures from Half-Life 2 to demonstrate that the software can handle numerous high-resolution textures being loaded.
The level files themselves are saved and loaded in JSV format, a lightweight combination of JSON and CSV originally conceived by ServiceStack. This version also allows you to export JSON files, although no import for that format is supported yet. If you were to use this in your own games, it would be a matter of either using something that already exists to read the JSON, or writing a JSON deserializer of your own, then feeding the polygon data into your graphics pipeline to render it appropriately.
Honestly, this software was built with some game development software that isn't especially well-documented, and I only found out has user interface components included well into development. However, having to create the entire user interface myself means it has ultimate flexibility that can facilitate very specific needs. Other than the little things that help with that and which I haven't seen in other software, the inspiration for the user interface design comes from a combination of other image editing software, Valve Hammer Editor and Visual Studio. However, it's somewhat customizable, as custom colour schemes can be created, the user interface scale can be changed and there is theoretically no limit to the size of the window you can use, although these do need to be set in the config file before running.
This is actually the second alpha release and I'm intending to go with a semi-open alpha model for the moment, where anyone can request a copy but it'll be up to my judgement who to actually give a copy to. The previous release was fully a closed alpha.
However, I realised the software wouldn't have to be limited to a particular genre of 2D games and could have many other potential uses outside of creating levels for 2D games (although that's what it might be most effective for), such as creating maps for tabletop RPGs or applying foreshortening to patterned or textured surfaces in artwork you've created outside of the software. The latest version in the screenshot here allows you to select a portion of the work you've created and save it as a PNG file.
The kind of fusion of vector/mathematical information contained in the properties of each point of each triangle and the raster (pixel) data of textures put it in this kind of weird space between vector graphics software like Inkscape and more conventional raster graphics image editing software like Photoshop, with its own set of advantages and disadvantages. The textures are loaded from a folder defined in a config file, and one subfolder deep. Here, I've used many textures from Half-Life 2 to demonstrate that the software can handle numerous high-resolution textures being loaded.
The level files themselves are saved and loaded in JSV format, a lightweight combination of JSON and CSV originally conceived by ServiceStack. This version also allows you to export JSON files, although no import for that format is supported yet. If you were to use this in your own games, it would be a matter of either using something that already exists to read the JSON, or writing a JSON deserializer of your own, then feeding the polygon data into your graphics pipeline to render it appropriately.
Honestly, this software was built with some game development software that isn't especially well-documented, and I only found out has user interface components included well into development. However, having to create the entire user interface myself means it has ultimate flexibility that can facilitate very specific needs. Other than the little things that help with that and which I haven't seen in other software, the inspiration for the user interface design comes from a combination of other image editing software, Valve Hammer Editor and Visual Studio. However, it's somewhat customizable, as custom colour schemes can be created, the user interface scale can be changed and there is theoretically no limit to the size of the window you can use, although these do need to be set in the config file before running.
This is actually the second alpha release and I'm intending to go with a semi-open alpha model for the moment, where anyone can request a copy but it'll be up to my judgement who to actually give a copy to. The previous release was fully a closed alpha.
Category Screenshots / Abstract
Species Unspecified / Any
Size 1280 x 800px
File Size 291.8 kB
Listed in Folders
I don't know what that is a reference for.
Despite everything I sacrifice for this it's going to be a long time before any real progress after this version, it just takes so long to work on.
It would have been great to have some sort of validation that this is a worthwhile project and not just a massive waste of time, but it seems as if already, the testers of the first closed alpha version have lost interest or couldn't find a use for it in the first place.
Despite everything I sacrifice for this it's going to be a long time before any real progress after this version, it just takes so long to work on.
It would have been great to have some sort of validation that this is a worthwhile project and not just a massive waste of time, but it seems as if already, the testers of the first closed alpha version have lost interest or couldn't find a use for it in the first place.
This is pretty interesting. So from the looks of this screenshot the objects are built from some kind of poly mesh with a texture associated with it, allowing you to kind of draw out your objects similar to a simple vector art object? I can see this kind of thing being useful for quickly generating content.
How does it perform with higher poly objects? Would you have any plans for implementing almost spline-like curves for it?
You seem like you're very talented
How does it perform with higher poly objects? Would you have any plans for implementing almost spline-like curves for it?
You seem like you're very talented
That's about right. It's situationally faster to work with than something that uses raster graphics like Photoshop but there is much I could add to make it faster to work with. Even so, The polygon approach has its own advantages, like providing a perfect collision mesh as a byproduct, I've been able to get this working in practice with my own point-to-polygon collision detection algorithm (used in the A* demo actually).
The above map is actually for a tabletop RPG. It just happens that the software works well as a virtual tabletop if you don't want to mess around with things like Roll20 because you can easily hide tokens and do your own dynamic lighting stuff, the obvious drawback is that you have to screenshot stuff yourself and have your players tell you where they want to move their tokens then do it yourself.
I think the most polygons I've ever had is probably no more than 2000 across probably 50 layers. I've never had performance issues even with levels with large textures and comparatively a lot of polygons like this (I wouldn't expect most games with maps made in PolyOne to need this many large textures or large numbers of Polygons). I'd be more worried about the user interface, which I had to write using nothing but basic drawing functions, to cause performance problems. It's not heavily optimized, at best it doesn't redraw the contents of scrollable areas unless something else triggers it even if that's as simple as a mouseover. Meanwhile the way the layers are designed to have one texture each means games should be able to have minimal render state changes, which can be a cause of performance issues. I'm not even using vertex buffers here so it's likely someone that did use them in their own game could get even more out of it.
There isn't yet anything that splines would be applicable to, since there are no line-drawing tools and it's just limited to "drawing" vertex-by-vertex, a polygon at a time, a rectangular pair of polygons or a copied/pasted selection. The outlines you see just indicate the vertices which are on the current layer and can thus be edited. I am planning to add a line drawing tool though, so splines are certainly something to consider for that.
Thanks for the compliment! If you'd like to try it yourself I can note you a download link of the latest version. I noticed you use XNA. You could reference something like ServiceStack.Text to load the JSON or JSV files that PolyOne saves to an object with little work, you'd only have to set up a class hierarchy then I believe it'd be a single line to load a file.
The above map is actually for a tabletop RPG. It just happens that the software works well as a virtual tabletop if you don't want to mess around with things like Roll20 because you can easily hide tokens and do your own dynamic lighting stuff, the obvious drawback is that you have to screenshot stuff yourself and have your players tell you where they want to move their tokens then do it yourself.
I think the most polygons I've ever had is probably no more than 2000 across probably 50 layers. I've never had performance issues even with levels with large textures and comparatively a lot of polygons like this (I wouldn't expect most games with maps made in PolyOne to need this many large textures or large numbers of Polygons). I'd be more worried about the user interface, which I had to write using nothing but basic drawing functions, to cause performance problems. It's not heavily optimized, at best it doesn't redraw the contents of scrollable areas unless something else triggers it even if that's as simple as a mouseover. Meanwhile the way the layers are designed to have one texture each means games should be able to have minimal render state changes, which can be a cause of performance issues. I'm not even using vertex buffers here so it's likely someone that did use them in their own game could get even more out of it.
There isn't yet anything that splines would be applicable to, since there are no line-drawing tools and it's just limited to "drawing" vertex-by-vertex, a polygon at a time, a rectangular pair of polygons or a copied/pasted selection. The outlines you see just indicate the vertices which are on the current layer and can thus be edited. I am planning to add a line drawing tool though, so splines are certainly something to consider for that.
Thanks for the compliment! If you'd like to try it yourself I can note you a download link of the latest version. I noticed you use XNA. You could reference something like ServiceStack.Text to load the JSON or JSV files that PolyOne saves to an object with little work, you'd only have to set up a class hierarchy then I believe it'd be a single line to load a file.
Comments