![]() To update a local change only the instance information must be overwritten or masked and bus-traffic should be low. Since there is no need to store real vertices (only one real cube mesh and many instance information) this would be efficient. The advantage is that only a few data per cube is required on GPU. It is possible, but not probable, that I benchmark that later. I assume this to be fastest anyway but it requires plenty of space. Updating the information is somewhat tricky because we need to know a neighborhood. Drawing static meshes is just the fastest thing a GPU can do. One could create quads for each surface side of a cube. This approach would probably not be realtime. All models in the game have there own dynamic transformation, hence there would be many relatively small 3D textures and I have to test which objects are hit by a ray before using a sparse octree traversal. It is possible to use octrees - which are the natural representation of voxel hierarchies - to efficiently ray-cast a 3D texture. Following Ideas can suffice for this task: They allow much more dynamical updates because not every change causes a recomputation of complex meshes. There are people how don't like that and yes there are algorithms as marching cubes to create continuous surfaces but I considered real cubes as the way to go. Which approaches do exist?įirst of all I decided that I want to render voxels directly in the form of boxes. Even if we store only one byte for each this requires 962081 PB RAM or disc space. To store the earth in 1 m³ large volume elements we would need 10^21 of them. Therefore spaceships and planets and solar systems and. What is many? Well Monolith is a space strategy game based on voxels. The nice things with them is that the logical arrangement in a 3D textures allows simple algorithms, e.g. What is a Voxel? A voxel is a small volumetric element - it is a pixel in 3D. If r,g,b := palette.As it happens I try to render many voxels in my latest project Monolith (Project page is still pending, but you can look on github for it). (Message from the future: spot the obvious and accidental mistake which will cause this to fail.)Īt this point I have a good idea what my JSON will look like - something like this: I'm going to create a package called colour, of which the palette functions can be a small part.įirst let's create some structures in palette.go to store the data I know will be needed: package colour Loading a paletteĪ lesson from Transrender is that we need to do a lot of things with colours in addition to merely palette retrieval - prepare masks, lighten or darken them, and convert to or from 32bpp modes. More importantly I'll need to learn how to read JSON in Go, which is going to be useful in contexts far beyond GoRender. The ranges which identify where ramps of colours begin and end, and which special behaviour those have.The data structure will have two main types of data: I'd like GoRender to load all of its data from a JSON file, which has the advantage of allowing users to tune palette behaviour (and even use different palettes) without needing code access. TTDPalette.cs is one of the oldest and messiest parts of Transrender, combining responsibilities from all over the place including raw data storage, anti-aliasing, palette behaviour and even concurrency semantics. It therefore tracks a lot of information about how to lighten and darken colours without changing to an inappropriate hue, and combine them when downscaling a larger image to a smaller one. Transrender originally did all of its lighting and shading within this paletted domain. The Transport Tycoon palette is not just a list of colours as some of them have semantic meaning within the game, either for '90s-style palette cycling animation or for recolouring with the player's chosen company livery. Since MagicaVoxel files also use an 8-bit palette we need to have some palette support even to output the 32-bit sprites of our MVP, and it makes sense to use the Transport Tycoon one. OpenTTD is derived (via Transport Tycoon Deluxe) from Transport Tycoon, a 1994 game that was originally in 256-colour SVGA. I think the last useful thing I can do in terms of "learning Go while cleaning up an old project" rather than "watch me write software" is to add palette support and get to the flat-shaded MVP discussed in Part 2, maybe followed by a coda of cleaning up any mess I've made along the way. Last time round I had got to the point of raycasting a silhouette on a spritesheet, with a largely clean solution that only had a few areas of potential messiness.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |