FOSS gamedev and creative worlds

Hi all,

I'm working as a teacher and modeller (Blender) and I have huge problems with finding a good tool that would let kids model things easily for 3d printing classes (and apparently, so does the whole internet. Oh, believe me, how I searched... :|)

The present workflows I have require a lot of setups and supervison, and I thought about getting Minetest into the pipeline, but as far as I know, there is no way to export Minetest maps as objects. I pushed this subject on IRC suggesting a script that would take location data of existing cubes and generate cube objects in Blender from existing dataset, and got a really positive feedback on this from sfan5 (thx!) - however, I am not a programmer, so I can't do this nicely and in a finite amount of time (and there would be issues with such approach on the side of 3d slicers, they don't like separate meshes).

With below measures I would be able to reduce the 3d printing introductory age from 8 to 4-6 year olds, and increase for them the effectiveness of teaching above that currently available for 8 year olds. Personally I think that's a game worth playing (yes, that's an intended pun ;) ).


What would be awesome/what I would need:

most importantly - mesh converter:
-a script that would convert a Minetest map into a set of objects in Blender, or, preferably, into a single mesh (no internal geometry, no doubles, proper normals are less relevant).

of secondary importance - streamlined starting environment:
- edit: flat map that simulates 3d printer bed, and made of brick type ignored by script if possible.
- player in fly mode by default [solved]
- some limitation so the player doesn't get lost
- 2-3 kinds of monochromatic cubes in infinite amounts available for player

What I have to offer:
- Publicity. Metric tons of publicity. Likely hitting local governmental institutions/ministry.
- Some initial money for devs and/or the whole Minetest project. Though I need a cost estimate so I can discuss this project with my employer.

spin wrote:Some initial money for devs and/or the whole Minetest project. Though I need a cost estimate so I can discuss this project with my employer.

Oh cool! Some money in a FOSS project!

For the modelling I would suggest Blender.

For the "fly" priv as default:
https://github.com/minetest/minetest/bl ... ample#L290
Means

in your minetest.conf.

There aren't any world which would contain a 4x4x4 block only. Flat maps should work too.

I think Jordach might be able to help with this.

To put them in fly mode to start with, add this to minetest.conf

Krock wrote:Oh cool! Some money in a FOSS project!

Oh, don't get me started on this. IMVHO there's no such thing as free software, there's only donated software. Whoever writes software pays for it with his lifetime and costs of existence. Plus I know a lot of people who'd gladly write for FLOSS projects full time, but they have to eat and pay rent, so they write after hours (or not, due to tiredness).
I come from art background, there it's customary to comission people, and requests are frowned upon. I wish it was similar in case of FLOSS.

Krock wrote:For the modelling I would suggest Blender.

Personally, I wouldn't recommend anything else ;)

Krock wrote:For the "fly" priv as default:
https://github.com/minetest/minetest/bl ... ample#L290
Means

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

default_privs = interact, shout, fly

in your minetest.conf.

OK, that was a quick crash course at the conf file :)
Sorry, I'm not very familiar with Minetest's internals (though my kids play it in vanilla version, and I did back up their maps some time ago, so I had to mind-map the folder tree)

Krock wrote:There aren't any world which would contain a 4x4x4 block only. Flat maps should work too.

Hm, not sure.
MAYBE if there was a flat map simulating the print bed of a 3d printer, and only certain colour(s) of brick were interpreted by script as mesh... OK, that would be brilliant (if doable)! Thanks for the suggestion :)

rubenwardy wrote:To put them in fly mode to start with, add this to minetest.conf

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

default_privs = interact, shout, fly
free_move = true


OK, got it.

In the main directory of minetest, there is a file called minetest.conf.example. It contains all the possible settings that can exist in minetest.conf.

Evergreen wrote:In the main directory of minetest, there is a file called minetest.conf.example. It contains all the possible settings that can exist in minetest.conf.

Yes, yes, I've realized this already, but the biggest issue is not in the interface. It's getting the cube positioning data exported in mesh format recognizable by any 3d package.

sfan5 is doing a lot of great job with it atm on irc, come watch :)

I've already developed a solution that works backwards from what you want. Here : https://forum.minetest.net/viewtopic.php?f=9&t=7101 (Unfortunately this mod is lost).

Its my minetest g-code interpreter. You can model objects in FreeCAD, slice them using Slicer and then import the object back into minetest world. I can develop something that works by exporting G-Code compatible with reprap from the game. Blender is not in my expertise area.

Edit: Found the mod code in a forum post.



This code, like i explained earlier, takes a g-code file as input and "prints" it inside minetest (The version posted is quite simple, if i remember correctly, it is the latest that i have made, most work was done by jin_xi in the 3d bresenham line drawing translation to lua). It still needs a lot of polishing (but the basic concept is in place). It has similar restrictions as FDM printing. You cannot "move the pen up", you cannot build without supports etc.

I remember that once i made it work i was greatly impressed to see cones, cylinders and cubes being 3d printed right in the middle of the map.

From minetest to g-code is easier. I will need some help from the folks at reprap because i need to keep the g-code tuned to the limitations of FDM printing, so as not to export something that reprap cant print.

But its a good idea, i am excited by it.

sfan5 has completed the code for mesh exporter in 6 hours during today's irc chat. This was the quickest developer response I've f***in seen in my life. Man, I owe you big time.

Link to git here:
https://gist.github.com/sfan5/c8a647deadbdddf1e05a

I'll be testing this tomorrow to debug and establish a workflow I can use in the curriculum I'm preparing.
(for completeness, the deadline for it is tuesday, and I didn't think it was possible to include Minetest in the first run,I planned to update it later when the feature was done! sfan5, you changed those plans! I have to rewrite everything! Thank you! XD)

aldobr wrote:I've already developed a solution that works backwards from what you want. Here : https://forum.minetest.net/viewtopic.php?f=9&t=7101 (Unfortunately this mod is lost).

Its my minetest g-code interpreter. You can model objects in FreeCAD, slice them using Slicer and then import the object back into minetest world. I can develop something that works by exporting G-Code compatible with reprap from the game. Blender is not in my expertise area.

WHOA! I would absolutely try this if it was possible :O
There are so many ways this could be used, not only in teaching but in creative workflow also, in gcode visualization, in remeshing models!
edit:code found OK I'll be testing this tomorrow :D

As you've seen, sfan5 has written a script that takes an MTL file and translates it into cubes in .obj format that can then be imported into 3d modelling software. It assigns material types to cubes based on brick types.
If you would like to experiment with this, it would be awesome. The cubes are separate meshes afaik, so it may cause errors in the slicer.
The script has a working coordinate export module, if you would like to experiment with the coordinate cloud it can generate and change it into a data format acceptable by a slicer at some level, then... wow. That would be more than I dared to expect.
If you need any help or info on this, let me know, I'll do my best to help out.

I dont need a slicer. I can write g-code right from minetest.

That mesh exporter is going to be useful for more than just 3d printing. :3

[quote="aldobr"]I've already developed a solution that works backwards from what you want. Here : https://forum.minetest.net/viewtopic.php?f=9&t=7101 (Unfortunately this mod is lost).

https://dl.dropboxusercontent.com/u/65428713/reprap.zip

How about .we file? We just need a converter from .we to single mesh file

srifqi wrote:How about .we file? We just need a converter from .we to single mesh file

Worldedit can eport to an mts file. No need for an .we to .obj filter.

aldobr wrote:I dont need a slicer. I can write g-code right from minetest.

Man, i'm running out of vocabulary for how awesome that would be. Either that, or English has ran out of proper adjectives.
If I can give something in return for that, please tell. Offer from first message stands, I can also do 3d/2d art commissions in exchange for code :)

It would be great if it could slice for 2 or more extruders, depending on material (set in-game), and/or that certain material could be used as support (interpreted in slicer), but it all depends on how you intend to implement it. At this point - please go for whatever works, and whatever you feel motivated for best. From my side, I can adapt the lesson plan to whatever works.

Evergreen wrote:That mesh exporter is going to be useful for more than just 3d printing. :3

Yes, Blender + Cycles. Using sfan5's modified script you could make it pretty amazing:
- make .blend files for each cube type and custom objects, complete with textures and materials.
- export a piece of map from MT using Worldedit
- using Python and Blender's bpy libs generate the whole map piece:
- call the .mts file for brick coords and type using sfan5's script
- call Blender to import .blend of brick type in coords got from .mts file
- set light
- render

_____

Atm I'm still getting stuff organized and then will attempt to get a decent workflow so I can try printing some actual thing Monday-ish:
- win64 minetest build from sfan5's build thread: viewtopic.php?id=1523 (sorry lunix, still love you best)
- worldedit
- srifqi's Superflat MapGen: viewtopic.php?f=9&t=9772
- free move conf file (though I may favor setting it in-game, will see)

I'm happy that worldedit requires commandline-like stuff and counting abilities, kids will have to type things and memorize commands, though it will take more supervision with the younger ones. They will naturally try to swim for the bigger waves though.

I'm still overwhelmed by what Minetest became since I last played it. Guys, you are doing an awesome work on the game and mods, and I'm really happy and impressed that MT is getting such a great dev team and huge playerbase :) You rock!

spin wrote:2-3 kinds of monochromatic cubes in infinite amounts available for player

How about wool?

spin wrote:2-3 kinds of monochromatic cubes in infinite amounts available for player

You can use creative mode

spin wrote:- srifqi's Superflat MapGen: viewtopic.php?f=9&t=9772

:D May i see your sflat.BLOCKS param?

Blender+Python is far more powerful and versatile than Minetest+Lua. I would therefore recommend a very simple exporter mod that saves an intermediate format, coupled with a custom import plugin for Blender. For the intermediate format, a simple 3D bitmap for each material, or a single 3D voxel array with material data, would be extremely simple to implement using the voxel manipulator. The Blender import plugin could then take care of creating vertex/face data.

Note that if you wanted a more standard format for another 3D package, you could easily import into Blender then re-export in OBJ or whatever other format you like that Blender can handle.

"Far more powerfull".

Can you quantify that or is just something that you made up from your own prejudices ? By knowing the theory behind compilers and programming languages, i call that bullshit.

All that you can say is that both python and lua are turing complete, imperative - with multi-paradigmatic elements, object oriented high level languages. While python uses a object oriented model that ressembles Smalltalk (Class based), Lua has a object model that is similar to Self language (Prototype based). Thats all you can say, the rest is bullshit, because it cant be quantified.

aldobr wrote:"Far more powerfull".

Can you quantify that or is just something that you made up from your own prejudices ? By knowing the theory behind compilers and programming languages, i call that bullshit.

All that you can say is that both python and lua are turing complete, imperative - with multi-paradigmatic elements, object oriented high level languages. While python uses a object oriented model that ressembles Smalltalk (Class based), Lua has a object model that is similar to Self language (Prototype based). Thats all you can say, the rest is bullshit, because it cant be quantified.

By referring to "Minetest+Lua" and "Blender+Python" I was speaking of the entire platforms, not just the programming languages. Blender's API plus Python's standard library offers far, far, FAR more functionality than Minetest's API plus Lua's standard library, and you would have to link lots and LOTS of Lua extensions to even begin to close the gap. Blender's API is also much more useful for 3D mesh data manipulation. Of course, if we wanted to speak about the programming languages alone, Python allows you to do "more with less" in terms of verbosity, so it does offer an advantage in terms of development at the cost of being rather inappropriate for an embedded (game-oriented) scripting language.

I have nothing against Minetest or Lua (nor any particular fondness for Python to be honest, though its list comprehensions are a rather nice feature). They are good tools for their intended purposes. This project would just be far better served by a combination of the platforms. No need to get defensive about it.

Here is a very simple exporter. The files it exports are pretty large (1 MB for a 80x80x80 block of nodes) because they are full 3D voxel arrays (I don't even attempt here to crop to a useful region of the block or compress or use anything but plain ASCII data in a simple format). It also simply does a single block at a time (the one the player is currently in when using the "/exportblock" command) rather than trying to be clever and walk through them to find an "entire object". Obviously this solution would be a little TOO simple (unless combined with additional external tools to merge/compress/etc.), but it may serve as a decent starting point for the kind of solution I mentioned above.



EDIT: Fixed minor error: math.min -> math.floor

prestidigitator wrote:

aldobr wrote:"Far more powerfull".

Can you quantify that or is just something that you made up from your own prejudices ? By knowing the theory behind compilers and programming languages, i call that bullshit.

All that you can say is that both python and lua are turing complete, imperative - with multi-paradigmatic elements, object oriented high level languages. While python uses a object oriented model that ressembles Smalltalk (Class based), Lua has a object model that is similar to Self language (Prototype based). Thats all you can say, the rest is bullshit, because it cant be quantified.

By referring to "Minetest+Lua" and "Blender+Python" I was speaking of the entire platforms, not just the programming languages. Blender's API plus Python's standard library offers far, far, FAR more functionality than Minetest's API plus Lua's standard library, and you would have to link lots and LOTS of Lua extensions to even begin to close the gap. Blender's API is also much more useful for 3D mesh data manipulation. Of course, if we wanted to speak about the programming languages alone, Python allows you to do "more with less" in terms of verbosity, so it does offer an advantage in terms of development at the cost of being rather inappropriate for an embedded (game-oriented) scripting language.

I have nothing against Minetest or Lua. They are good tools for their intended purposes. This project would just be far better served by a combination of the platforms. No need to get defensive about it.

Subjective bullshit sold as objective argument. This is purely opinion. That kind of attitude is detrimental to software development in general. LuaFFI allows calling anything.

A language power is measured by it's level of abstraction, capability to call foreign code and its turing completeness. Lua is turing complete (just as python is), is capable of calling foreign code (in the form of system libraries) and is at the same level of abstraction that python is (high level languages). Thats all that can be said objectively. The rest is purely subjective.

aldobr wrote:Subjective bullshit....

Whatever you say. I really don't see the need or desire to engage further in responding to this kind of unwarranted, defensive argument. I wasn't trying to criticize anything or anyone, place judgement, or anything of the sort. Different languages and platforms DO make particular tasks easier, or we'd all be programming in machine code. I was simply suggesting a form of solution which I ("subjectively", sure) believe would help get to the OP's stated goal.

I'm done with the argument, though I may post more for the OP and other well-intentioned participants in the hope of helping approach a solution. Take care aldobr, and have a good day.

Guys, no quarrels, please.

Minetest -> Blender workflow would allow Blender's mesh tools to be applied to the resulting model. While this is powerful, it requires extensive knowledge of Blender. In this case, sfan5's OBJ exporter is more universal, as people can export mesh to the 3d packages they KNOW, thereby saving a lot of time, and getting the right result (even though it's harder to write than using Blender to generate the cubeset, I would assume from the code).

Blender exporter would be awesome for rendering, getting results not available from Minecraft exporters with some modeling effort, but I see that not many people know how to use bpy libraries, and this means additional strain for devs who would decide to work on it (and more motivation for me to actually learn the thing).

From my perspective as a teacher, simplest thing works best, because I don't have to push the pupils across different packages, each of which requires time to familiarize with. From this point of view, aldobr's solution is perfect, though it won't work with machines that use proprietary firmware/software, such as makerbot or clones that are fed with x3g format, and gcode would have to be reprocessed into it.

edit: On the other side, getting a mesh into blender would allow me to get the older kids, and the non-technical people to sculpt on it really fast. People have no easy way to make base shapes for sculpting, and starting from a cube or sphere is problematic on first contact with tools, so using a Minetest base mesh for the sculpt tools would be awesome

sfan5 has done more dev while on IRC today to allow custom cube placement with the script, again, https://github.com/sfan5/mt2obj/commits ... /mt2obj.py here's the repo.

We have 3 solutions emerging, all of which are perfect for different tasks, and allow huge versatility. I don't see overlap here.

spin wrote:We have 3 solutions emerging, all of which are perfect for different tasks, and allow huge versatility. I don't see overlap here.

Couldn't agree more. Overlap is okay too, of course. There is always room for multiple ideas and solutions. The part I was thinking would be easiest to do from a Blender plugin would be to create face data while eliminating unnecessary and unwanted internal geometry. Blender now even has "FGONs" (N-gon faces) which would probably allow a smooth workflow without the need for mod/plugin code to try to break faces into quads or triangles.

prestidigitator wrote: The part I was thinking would be easiest to do from a Blender plugin would be to create face data while eliminating unnecessary and unwanted internal geometry. Blender now even has "FGONs" (N-gon faces) which would probably allow a smooth workflow without the need for mod/plugin code to try to break faces into quads or triangles.

Yes, Blender supports n-gons, and recently they gave a huge boost to Boolean operations since the modifier was rewritten to use them.

I have no idea how to make a surface-only mesh from Minetest. For my purpose I care only about geometry, not textures, since FFF printers are rather monochromatic.
The approaches to building a single geometry can be different. Either:
- we try to merge the cubes using boolean operations as they are imported.
- we detect outermost faces by, idk, calculating mesh proximity or overlaps, and then remove doubles inside Blender to have them merged.
- we detect outermost vertices of cubes, and build a smooth mesh by connecting them together (in which case the result is smooth, and we treat Minetest's cubes kind of like metaballs)
-we spawn metaballs instead of cubes and let Blender do the processing :P
- something completely different. Meshlab + point cloud, idk.

spin wrote:Yes, Blender supports n-gons, and recently they gave a huge boost to Boolean operations since the modifier was rewritten to use them.

I have no idea how to make a surface-only mesh from Minetest. For my purpose I care only about geometry, not textures, since FFF printers are rather monochromatic.
The approaches to building a single geometry can be different. Either:
- we try to merge the cubes using boolean operations as they are imported.
- we detect outermost faces by, idk, calculating mesh proximity or overlaps, and then remove doubles inside Blender to have them merged.
- we detect outermost vertices of cubes, and build a smooth mesh by connecting them together (in which case the result is smooth, and we treat Minetest's cubes kind of like metaballs)
-we spawn metaballs instead of cubes and let Blender do the processing :P
- something completely different. Meshlab + point cloud, idk.

Cool. Yeah. Metaballs could be interesting. I was thinking of actually traversing voxels in each coordinate direction and merging islands. I still don't trust booleans much, but it is worth a try.

Since materials aren't interesting, here's the above mod I posted, modified to export a 3D (on/off) bitmap instead of "color" data:



EDIT: Fixed minor error: math.min -> math.floor

Unless we really do want smooth surfaces, the voxel nature of the data should make surface generation pretty easy. If we pretended we were descending through an object in the layers between nodes (in any of the coordinate directions), then there would be a horizontal (square) surface any time there was a node above a position but not below it, or below it but not above it. That's essentially an XOR of two 2D arrays. Then, once you know which positions have square node top/bottom surfaces (pretty sure it doesn't matter which, but that requires a little more thought), it is pretty easy to merge those into solid islands with no internal edges (but with holes). Again a traversal in one of the two remaining directions, keeping track of a list of on/off ranges, would allow for easy surface generation.

Well, given the algorithm I described above, I realized it shouldn't be too bad to do even in Lua, though it is a bit slow. It takes about 30 seconds to export a block on my machine. This exports in OBJ format, as a single mesh, with internal faces removed. The only minor issue is that I do the faces in stripes at the moment, so adjacent faces don't always share vertices. That means if you move a face or vertex it might create a rip in the mesh. That could be fixed later, but fixing it may generate quite a few extra vertices and faces too so it isn't that obvious of a gain.

(Note: I suspect the slow speed at least partially has to do with the fact that I do redundant requests for map data. I did this so that ideally the functions could be easily extended to work with sizes larger than a single 80x80x80 block later without requiring HUGE amounts of memory. All vertex data would still need to be kept around, but this way the memory requirements make it possible to have a physically large mesh as long as it is made up of mostly rectangular pieces.)

EDIT: You'll have to mirror the object in one direction in Blender. Stupid left handed coordinate system! I may fix that in the export at some point.

Results from sfan5's mt2obj exporter:

This is how the obj looks like imported to Blender. Separate cube objects, 1x1x1 blender units (0.5 radius cubes) arranged in pattern exported from Minetest. Origin point (yellow dot) in the corner of the object, this was the //pos1 I set in Minetest via Worldview.

I then selected everything and merged it into a single object (but not mesh), and exported to .stl. Then I ran it through Slic3r...

Slic3r 1.0.0RC3:
Unfortunately Slic3r failed to produce a printable model. It crashed on the loose meshes, not producing a good result. I used Repetier to display the data (imported into Repetier, sliced from inside Repetier via Slic3r, data display through Repetier). This is how it looked like:
1. is screenshot from import, visible non-manifold warning
2. is the toolpath visible halfway,
3. is the whole toolpath visible from top. This is not nice.


Let's proceed to Cura.

Cura 14.03 (?)
Not sure about the version, typing from memory
Cura did fine, though had some problems with toolpath display, so I imported the Gcode to Repetier.
Everything is OK, it's read correctly and very printable:


Now on to makerware.