Before I start typing this whole thing up, if this was posted in the wrong section to begin with sorry in advance. If possible move it or point me towards the correct section to place this, as though I've skimmed(without a registered account) these forums I've never bothered posting until this thread.
A while ago while playing Garrysmod seeing the minecraft themed maps others had created, I had disliked how plain the maps seemed. One having small mountains, maybe one or two with trees, sporadically placed on top of a flatgrass world. Which it had just seemed these mountains were just copies pasted of each other then rotated possibly with a lone tree and no actual way of getting up on one without noclipping there.
While others just seemed to lack proper sizing compared to minecraft, such that if you assumed in a source engine game the player should be about as tall as a minecraft player is, it seemed some areas were a bit off that I couldn't check out certain areas of the map without crouching and hoping the minecart train they built on a track in the map didn't come along. (If one touched (or may have been pressed the use key on) the cart it triggered the game to place your viewpoint as a camera parented to the cart, so it appeared you rode in it, least until you got to a certain place where it had you exited the view.)
So I decided to find a way if possible to convert the NBT format of minecraft alpha worlds into a vmf file able to be loaded by hammer, and compiled into a bsp while keeping it as optimized as possible (both the vmf and program itself). As having 1 block per brush in a vmf would be costly in resources since as most probably know, the bsp format has its limits of what it can hold compared to minecraft's (more or less) infinite bounds.
After starting it a couple weeks ago (originally just posted this on a community I help run/ code for in garrysmod, but thats a different story), I found a decent method I could use to convert various blocks to brushes for a vmf file. This being a combination of the already made NBT IO class for java on minecraftwiki.net, rather than write my own. While I had decided to do this in java at the time compared to C++ (From college courses I had learned both already to a decent level.) as I had reformatted recently and had not installed visual studios 2010 yet. Plus it seemed it could be a bit easier or quicker to code in java rather than c++, as this way I didn't have to worry about people needing vC++ run time libraries or the .NET Framework installed depending on how I approached it. (Plus java being capable of running on multiple OS's helped too).
I had decided to make it so that it only converted those brushes of a chunk that touched air in any direction (up, down, left, right, front or back, no diagonals included). Which in concept worked in my head pretty well though at the time I had forgotten about shrubs, flowers, mushrooms being counted as blocks. Which is one area I have to recode it.
At the moment when testing it in an unoptimized way, such that it converts every block in a chunk to a brush,(excluding air and some other block types) It appears to convert it thoroughly and correct. As below I placed 2 pictures, one of the vmf and one of the same exact area in the minecraft world.
Note torches in the minecraft world mark the selected brushes in hammer:
VMF (May have been messing with the optimized version of a function during this screenshot or deleted unneeded brushes):
Minecraft World:
Such in meantime what I have to add is texturing the brushes to the equivalent of minecraft or other replacement textures (as in source the textures I've seen that people use from minecraft stretch out badly to appear blurry even with the texture detail on very high). As well as coding a UI for it to allow scaling of the size of the converted chunks, converting more types of blocks possibly than what I have set up at the moment ( a bulk of the normal blocks are set up to be recognized and a brush wrote for them at the moment). If not a checklist allowing specific blocks to be ignored. Fixing some functions for optimizing what blocks are made into brushes based on whats surrounds them (as mentioned earlier) and the unoptimized version ignoring certain brushes due to the functions scripting being an edit of the optimized copy (some false booleans changed to true (or functions returnign true instead of false changes it at the moment as the optimized version is more intricate then just 1:1 conversion of every block.
Also current stats for converting 1 chunk's blocks into hammer brushes:
For 16,636 blocks I had in a single chunk I tested the unoptimized version on, it converts and writes the vmf in 2.8 seconds.
I also know this has been discussed various places before, not sure if it has specifically on these forums, but I have seen it discussed on other forums ike steam's forums. Such that it isn't an original idea, nor do I know if something like this has already been made once before. (Searches checking if one has been, only linked back to the same things as I already saw (discussions) or the thread I had made on the forums of the gmod community I mentioned above).
Note, work may be slow on this as college is taking up a lot of my time as it nears thanksgiving and thus the end of the semester.
I don't really see limits of the current source engine possibly as much of a limiter as is the number of vertex made, as with the orange box engine and updates maps have been allowed to be come fairly complex, with larger sizes and more brushes. Though at the same time I've seen maps that were extremely small but detailed hitting the limit. Since say you have a large flatgrass area that is about 2 chunks in width and length, so 4 chunks total. With the optimized area the chunks would at minimum presuming there are no trees or other random blocks, would have 256 blocks per chunk.
Hammer currently has a limit of around a bit over 8,000 brushes, which 4 chunks is 1024 brushes at minimum. Thus 16 chunks (256 blocks across in every direction) would be about half the brush limit of the current source engine, presuming the developer wiki valve maintains has its information up to date. As in the past occasionally it has been a bit outdated on some topics when I went to search for some pages for friends interested in source sdk developement.
Thus 32 chunks ends up exactly at the brush limit of hammer, allowing a decent sized map depending on the scale used to make distance in minecraft equal distance in the source engine's unit measurement. Meaning classic maps could be decently converted too depending on if it was a generated one with nothing built yet.
A while ago while playing Garrysmod seeing the minecraft themed maps others had created, I had disliked how plain the maps seemed. One having small mountains, maybe one or two with trees, sporadically placed on top of a flatgrass world. Which it had just seemed these mountains were just copies pasted of each other then rotated possibly with a lone tree and no actual way of getting up on one without noclipping there.
While others just seemed to lack proper sizing compared to minecraft, such that if you assumed in a source engine game the player should be about as tall as a minecraft player is, it seemed some areas were a bit off that I couldn't check out certain areas of the map without crouching and hoping the minecart train they built on a track in the map didn't come along. (If one touched (or may have been pressed the use key on) the cart it triggered the game to place your viewpoint as a camera parented to the cart, so it appeared you rode in it, least until you got to a certain place where it had you exited the view.)
So I decided to find a way if possible to convert the NBT format of minecraft alpha worlds into a vmf file able to be loaded by hammer, and compiled into a bsp while keeping it as optimized as possible (both the vmf and program itself). As having 1 block per brush in a vmf would be costly in resources since as most probably know, the bsp format has its limits of what it can hold compared to minecraft's (more or less) infinite bounds.
After starting it a couple weeks ago (originally just posted this on a community I help run/ code for in garrysmod, but thats a different story), I found a decent method I could use to convert various blocks to brushes for a vmf file. This being a combination of the already made NBT IO class for java on minecraftwiki.net, rather than write my own. While I had decided to do this in java at the time compared to C++ (From college courses I had learned both already to a decent level.) as I had reformatted recently and had not installed visual studios 2010 yet. Plus it seemed it could be a bit easier or quicker to code in java rather than c++, as this way I didn't have to worry about people needing vC++ run time libraries or the .NET Framework installed depending on how I approached it. (Plus java being capable of running on multiple OS's helped too).
I had decided to make it so that it only converted those brushes of a chunk that touched air in any direction (up, down, left, right, front or back, no diagonals included). Which in concept worked in my head pretty well though at the time I had forgotten about shrubs, flowers, mushrooms being counted as blocks. Which is one area I have to recode it.
At the moment when testing it in an unoptimized way, such that it converts every block in a chunk to a brush,(excluding air and some other block types) It appears to convert it thoroughly and correct. As below I placed 2 pictures, one of the vmf and one of the same exact area in the minecraft world.
Note torches in the minecraft world mark the selected brushes in hammer:
VMF (May have been messing with the optimized version of a function during this screenshot or deleted unneeded brushes):
Minecraft World:
Such in meantime what I have to add is texturing the brushes to the equivalent of minecraft or other replacement textures (as in source the textures I've seen that people use from minecraft stretch out badly to appear blurry even with the texture detail on very high). As well as coding a UI for it to allow scaling of the size of the converted chunks, converting more types of blocks possibly than what I have set up at the moment ( a bulk of the normal blocks are set up to be recognized and a brush wrote for them at the moment). If not a checklist allowing specific blocks to be ignored. Fixing some functions for optimizing what blocks are made into brushes based on whats surrounds them (as mentioned earlier) and the unoptimized version ignoring certain brushes due to the functions scripting being an edit of the optimized copy (some false booleans changed to true (or functions returnign true instead of false changes it at the moment as the optimized version is more intricate then just 1:1 conversion of every block.
Also current stats for converting 1 chunk's blocks into hammer brushes:
For 16,636 blocks I had in a single chunk I tested the unoptimized version on, it converts and writes the vmf in 2.8 seconds.
I also know this has been discussed various places before, not sure if it has specifically on these forums, but I have seen it discussed on other forums ike steam's forums. Such that it isn't an original idea, nor do I know if something like this has already been made once before. (Searches checking if one has been, only linked back to the same things as I already saw (discussions) or the thread I had made on the forums of the gmod community I mentioned above).
Note, work may be slow on this as college is taking up a lot of my time as it nears thanksgiving and thus the end of the semester.
Hammer currently has a limit of around a bit over 8,000 brushes, which 4 chunks is 1024 brushes at minimum. Thus 16 chunks (256 blocks across in every direction) would be about half the brush limit of the current source engine, presuming the developer wiki valve maintains has its information up to date. As in the past occasionally it has been a bit outdated on some topics when I went to search for some pages for friends interested in source sdk developement.
Thus 32 chunks ends up exactly at the brush limit of hammer, allowing a decent sized map depending on the scale used to make distance in minecraft equal distance in the source engine's unit measurement. Meaning classic maps could be decently converted too depending on if it was a generated one with nothing built yet.