Open TheDuckCow opened 5 years ago
Realized now that a command-line interface also already exists for jmc2obj, and should sufficiently work to include as an alternate option when using the bridge feature.
Sample execution to output a world to obj (and exporting the texture folder):
java -jar ./jMc2Obj-107.jar \
--dimension=0 --area=-40,-40,40,40 --height=0,256 \
--render-entities --object-per-mat \
--output=/..../test_jmc_cmd/ \
--objfile=test_jmc2_cmdlin.obj --mtlfile=test_jmc2_cmdlin.mtl \
--export=obj,mtl,tex "..../saves/world_save"
More options visible via --help. Note to self that I noticed at first the tex exporting was rather slow. Also calling out that newest jmc2obj appears to not be able to open old-format chunks, and so can only be used with newest world formats, which should generally be fine for users anyways, as they should be able ot just open their old worlds in the latest Minecraft version..
While little additional development done, I have much more of the design approach worked out. See the architecture diagram here (click for higher resolution):
This approach was designed keeping in mind submissions from the survey, where the biggest insights were:
I was not strongly in favor of supporting multiple worlds linked at once, but I see now it's important enough to strive for.
Minor update, this feature has not been forgotten, but has not been heavily prioritized due to other things that need to be done first before this can be launched effectively:
Another update, aiming to push out the next version (likely naming 3.3.0), after which this feature should be feasible for limited alpha testing. Due to the limited nature, I'm planning to make an opt-in toggle feature and/or a notice to press OK that feature is experimental, so that it's not depended on for production work (at least not without extra precautions).
Also saving this nbt link as I leveraged part of this and planning to bundle or extract the needed piece for reading player locations as a starting point.
Revisiting the issue (as well as some other old issues). I think we should create an MCprep Hackathon type of event for stuff that's on the back burner, but also too complex to label a "good first contribution"
Feature overview
Vision
To directly load in Minecraft saves without ever leaving Blender. To be able to not just load, but also refresh/reload, and to extend the world in case you later need more imported.
How?
By using the scripting feature of Mineways and jmc2obj, which is a way to control the application without user interactions. Calls to the program will still generate OBJ files which are then imported into blender automatically, seamlessly for the user.
Why not natively implement loading of worlds like e.g. MineBlend? Well, that's a ton of work, and hard to keep up to date, and as soon as this feature is created, users will depend on it heavily and it needs to be stable. Instead of reinventing an entire wheel, MCprep will lean on the existing and still maintained Mineways & jmc2obj projects.
Implementation steps/milestones
Rough order of tasks, and progress
1) Proof of concept:
Implementation architecture
This will be implemented with a split between a pure-pythonic wrapper which calls/communicates with Mineways, and then a parent blender python file which implements the blender-specific operators and user workflow.
Currently, Mineways can only be launched with scripts as a starting input script file, and after this script executes, the program either is still open (ie "orphaned") or closes (if the close command is included in the script). Because we want there to be no user interaction with Mineways itself, every command needs to end with a close statement.
To keep blender responsive, this should be implemented in a parallel process so that there can be interactions such as ESC to stop the current import where it is, or to cancel altogether. Because we cannot communicate to an already opened and running instance of Mineways (yet), this means batching the world out into chunks (where Mineways opens, exports a chunk or two, then completely closes down) and then offering to stop after some have ran, but always letting Mineways finish its current process.
To be decided: have this all running in a modal operator (most stable), or allow the parallel process to continue while user can interact with blender as chunks are loaded (likely quite unstable).
Additionally, the world should be managed and thought of more as a "bridge" than a once imported and done approach. Settings for how a world was imported will be saved, and features will allow for piece-wise reimporting of chunks, or even extending the imported world as-needed.
Links and references