Last post we talked about the early attempts, and shortfalls of each attempt. I am not sure I am doing justice to the learning that went on to get to this final workflow, that worked for us, but to put it in some 'time' perspective, it was multiple weeks of data, attempts, research, more attempts, more data, more attempts... well you get the idea.
But, all that aside, here is the final workflow that worked for us and our data. As mentioned in the previous post, all the data was provided to me in .obj files exported from 3dsMax, in a process that I did not have, or want, direct access to.
There is this really neat, really really neat in fact, program called Qubicle, which can import almost any 3D file and 'voxelise' it. Even better if you pay for it, has an export to schematic function built in. This piece of software, shown to me by Adam is a key part in the path. However there are limitations along the way, the biggest being that you cannot take all the data and just mash it into it. The scale for this particular project, is very important, and sectioning the data was definitely a big part of the key that makes this world infinitely expandable. You see, it appears that Qubicle has this 'hard limit' on how many 'blocks' it can effectively scale. For me, it was around 256 on the vertical axes, once you started to scale models beyond that size, things started going awry. The models would be 'pulled apart' in odd ways, and the 'verticality' of the data would get all kinds of messed up, like this:
So, you can see that is a bit of an issue if you are trying to recreate a whole heap of a city. There is no way you could do it using that as a basis. So after a whole heap of messing about, working with those that held the data in 3dsMax, we solidified a size that we would work from, 200 meters squared was the most reliable.
Another interesting thing I found along the way about Qubicle, was that when you import a model, it tries to automatically scale it as big as it can, and the 200m model size, seemed to make Qubicle not mess with the scale on import, which was a huge win, and in hindsight, likely to be because 200 cannot be doubled and still be under 256. This caused us some issues with the tallest building in Melbourne, causing the scale of those sections to be slightly off, so I had to learn how to edit this particular section in Qubicle and export it in 2 vertical parts, and 'tweak' the scale accordingly so it aligned properly with the 1 block = 1 meter of the rest of the map.
Originally we were talking about 100m models, as shown in the image above, but I am glad we were able to push it out to 200m because it cut down the work required to stitch it all together by three quarters. I also, for completeness sake should tell you that I tried to stitch each of these 200m squared models together in Qubicle, but it was just too much for the software to cope with, and started causing me issues in terms of accurately aligning the models.
The time taken to render and move models around as more and more models were added was very problematic, and I am not working on a potato of a computer. On top of that, after persisting with it and getting everything to a point that I thought it was close it turns out it was unable to export such a large model to .schematic, it kept crashing when I tried and those sections I did manage to export were actually not aligned very well at all, despite appearing OK in Qubicle... 3D modelling is all about perspective, and making sure you are checking things from all of possible perspectives.
So enter the final piece of software along the way, MCEdit. To be honest, I have never been a huge fan of MCEdit in the past, not because I don't like the program, or what it was capable of, but more because I was unfamiliar with it, and while it looks like Minecraft, there is a massive difference in the way the controls work, and the way the 'player' (camera) moves and I really struggled with that.
This is why, back in the MinecraftEdu days, I loved WorldEdit so much, it was in game, powerful, and the controls made sense! But boy do I love MCEdit now, I learnt so much about MCEdit 'as required' during this project, which was an awesome way to learn actually, and I am still nowhere near an expert, not like Adrian, nope, nothing like that, but I am now proficient enough to do most of what I need to get done in a timely and what I believe is an efficient manner, or efficient enough for me anyway.
Stitching the pieces together took a lot of practice, and involved aligning each piece, very carefully. There were multiple restarts and throw away worlds along the way, but once I figured out the proper way to nudge parts around when importing, it was actually quite easy to do. It was also way easier to align the different pieces properly in MCEdit than it was in Qubicle, because Minecraft is very explicit with regards to the coordinate system, which means there are significantly less 'misalignment' opportunities.
I did realise early on, that I couldn't always align the edges of the models in a fixed grid type way, as, despite my requests to have everything in 200m square slabs you can see from the map image provided above, that if you combine a 2x2 grid of those squares together, that not all would end up square, nor 200m. So I had to devise a plan regarding finding the corners of each 'square' as it came in so that I could more easily align the pieces, 28 in all. What I ended up doing was 'marking' each corner of the piece after I imported it with a different block so that I could more easily align the adjacent pieces.
See that very faint blue spot in the middle of the gray sea of stone? Yep, that is my marker! Now, as you can clearly see the big downfall of all of this work was that, while all of the data was now in Minecraft, it was all made of stone, and well, didn't look much like Melbourne at all. We did explore texturing the models in Qubicle, as the obj file exports I received had material files associated with them, but we decided 'translating' those materials across into Minecraft blocks just was not worth the time it would take to do properly, when we could texture the buildings in MCEdit for 'broad strokes' and in-game for the finer details.
So that wraps up the 'getting the data into' Minecraft aspect of this series, next up, will either be how I started detailing the world, or heading back to the next stages of development of the Dig Experience, I am not really sure which I will feel more like writing about, since they were concurrent processes at this early stage, but stay tuned, and as always thanks for reading, feel free to drop a comment below.
But, all that aside, here is the final workflow that worked for us and our data. As mentioned in the previous post, all the data was provided to me in .obj files exported from 3dsMax, in a process that I did not have, or want, direct access to.
There is this really neat, really really neat in fact, program called Qubicle, which can import almost any 3D file and 'voxelise' it. Even better if you pay for it, has an export to schematic function built in. This piece of software, shown to me by Adam is a key part in the path. However there are limitations along the way, the biggest being that you cannot take all the data and just mash it into it. The scale for this particular project, is very important, and sectioning the data was definitely a big part of the key that makes this world infinitely expandable. You see, it appears that Qubicle has this 'hard limit' on how many 'blocks' it can effectively scale. For me, it was around 256 on the vertical axes, once you started to scale models beyond that size, things started going awry. The models would be 'pulled apart' in odd ways, and the 'verticality' of the data would get all kinds of messed up, like this:
So, you can see that is a bit of an issue if you are trying to recreate a whole heap of a city. There is no way you could do it using that as a basis. So after a whole heap of messing about, working with those that held the data in 3dsMax, we solidified a size that we would work from, 200 meters squared was the most reliable.
Another interesting thing I found along the way about Qubicle, was that when you import a model, it tries to automatically scale it as big as it can, and the 200m model size, seemed to make Qubicle not mess with the scale on import, which was a huge win, and in hindsight, likely to be because 200 cannot be doubled and still be under 256. This caused us some issues with the tallest building in Melbourne, causing the scale of those sections to be slightly off, so I had to learn how to edit this particular section in Qubicle and export it in 2 vertical parts, and 'tweak' the scale accordingly so it aligned properly with the 1 block = 1 meter of the rest of the map.
Originally we were talking about 100m models, as shown in the image above, but I am glad we were able to push it out to 200m because it cut down the work required to stitch it all together by three quarters. I also, for completeness sake should tell you that I tried to stitch each of these 200m squared models together in Qubicle, but it was just too much for the software to cope with, and started causing me issues in terms of accurately aligning the models.
The time taken to render and move models around as more and more models were added was very problematic, and I am not working on a potato of a computer. On top of that, after persisting with it and getting everything to a point that I thought it was close it turns out it was unable to export such a large model to .schematic, it kept crashing when I tried and those sections I did manage to export were actually not aligned very well at all, despite appearing OK in Qubicle... 3D modelling is all about perspective, and making sure you are checking things from all of possible perspectives.
So enter the final piece of software along the way, MCEdit. To be honest, I have never been a huge fan of MCEdit in the past, not because I don't like the program, or what it was capable of, but more because I was unfamiliar with it, and while it looks like Minecraft, there is a massive difference in the way the controls work, and the way the 'player' (camera) moves and I really struggled with that.
This is why, back in the MinecraftEdu days, I loved WorldEdit so much, it was in game, powerful, and the controls made sense! But boy do I love MCEdit now, I learnt so much about MCEdit 'as required' during this project, which was an awesome way to learn actually, and I am still nowhere near an expert, not like Adrian, nope, nothing like that, but I am now proficient enough to do most of what I need to get done in a timely and what I believe is an efficient manner, or efficient enough for me anyway.
Stitching the pieces together took a lot of practice, and involved aligning each piece, very carefully. There were multiple restarts and throw away worlds along the way, but once I figured out the proper way to nudge parts around when importing, it was actually quite easy to do. It was also way easier to align the different pieces properly in MCEdit than it was in Qubicle, because Minecraft is very explicit with regards to the coordinate system, which means there are significantly less 'misalignment' opportunities.
I did realise early on, that I couldn't always align the edges of the models in a fixed grid type way, as, despite my requests to have everything in 200m square slabs you can see from the map image provided above, that if you combine a 2x2 grid of those squares together, that not all would end up square, nor 200m. So I had to devise a plan regarding finding the corners of each 'square' as it came in so that I could more easily align the pieces, 28 in all. What I ended up doing was 'marking' each corner of the piece after I imported it with a different block so that I could more easily align the adjacent pieces.
See that very faint blue spot in the middle of the gray sea of stone? Yep, that is my marker! Now, as you can clearly see the big downfall of all of this work was that, while all of the data was now in Minecraft, it was all made of stone, and well, didn't look much like Melbourne at all. We did explore texturing the models in Qubicle, as the obj file exports I received had material files associated with them, but we decided 'translating' those materials across into Minecraft blocks just was not worth the time it would take to do properly, when we could texture the buildings in MCEdit for 'broad strokes' and in-game for the finer details.
No comments:
Post a Comment