FOSS gamedev and creative worlds

EDIT: This post originally started a sub-thread on the Home Decor topic, and has been split off to it's own subject.
--VanessaE

VanessaE wrote:For any new objects I add to this mod, if they're complex shapes, they're best done with meshes rather than nodeboxes.

I don't know how to make meshes, what program do you use?

12Me21 wrote:

VanessaE wrote:For any new objects I add to this mod, if they're complex shapes, they're best done with meshes rather than nodeboxes.

I don't know how to make meshes, what program do you use?

Blender. There are a number of tutorials on youtube and the forum has a few.

12Me21 wrote:

VanessaE wrote:For any new objects I add to this mod, if they're complex shapes, they're best done with meshes rather than nodeboxes.

I don't know how to make meshes, what program do you use?

If you build your nodeboxes with nodebox editor it can export as a mesh. Or you can use Blender. But the learning curve is very high.

ExeterDad wrote:

12Me21 wrote:

VanessaE wrote:For any new objects I add to this mod, if they're complex shapes, they're best done with meshes rather than nodeboxes.

I don't know how to make meshes, what program do you use?

If you build your nodeboxes with nodebox editor it can export as a mesh. Or you can use Blender. But the learning curve is very high.

I can confirm that the learning curve is high. One day I will learn. Until then.......ExeterDad.

ExeterDad wrote:If you build your nodeboxes with nodebox editor it can export as a mesh.

Does this have any advantage over using regular nodeboxes?

You can UV-map the model in Blender or so, allowing you to precisely define what parts of your texture images are applied to which parts of the model. This means more flexibility in image layouts.

Plus, with a mesh node (regardless of how it was initially created), you can use multiple materials per model (up to 6 anyway), allowing you to use multiple images in different resolutions to texture your model, or even place two or more images in the same general area of the model (say, the top), but on different sets of polygons, in ways that are impossible with nodeboxes.

You could, for example, display the default animated water in a depressed hole in the middle of a face that's covered in non-moving default steel block texture if you wanted, as long as your model, UV maps, and materials are set up properly, without having to make new imagery.

Were it saved as just a plain set of nodeboxes, you'd be stuck with all of that method's usual limits.

For example, nodeboxes always "project" the textures onto the sides of the object from fixed locations in the images, e.g. a nodebox that occupies the quarter-node section of the lower-right corner of the "front" of the node gets its imagery from the lower-right 4x4 pixels of the -Z image (assuming a 16x16 pixel texture), no negotiation. :-)

Another limit of regular nodeboxes is that if you have two or more of them at the same coordinates on two axes, but different coordinates on the third axis, say 8,8,8 and 8,8,12 (four units apart on the Z axis but at the same X and Y position), the texture applied to one will be echoed through to the others on the same face. In this example, the Z faces would share a texture.

VanessaE wrote:You can UV-map the model in Blender or so, allowing you to precisely define what parts of your texture images are applied to which parts of the model...you can use multiple materials per model (up to 6 anyway), allowing you to use multiple images in different resolutions to texture your model, or even place two or more images in the same general area of the model (say, the top), but on different sets of polygons, in ways that are impossible with nodeboxes.

Huh. Sounds useful. How does that work? Is each texture used for a different assigned material?

No need really. Just assign a grouping of faces to the desired texture in the UV editor. Then before export unlink the image/images so irrlicht doesn't look for them and complain if they are missing. The textures are then fed to the mesh with lua one by one.

Actually yes that's exactly it. For each material in the model, you assign polygons to it, and perhaps give it a color (purely for reference in Blender), then in your Lua code, you specify a filename for each material in your tiles={} field in your node def.

The order of items matters in the tiles={} field, but just what that order is is a total mystery to me so far (it's not alpha-order by material name, it's not in order by creation time, nor by last-edited time, and it doesn't appear to be by position in the model). You'll have to guess at it and re-arrange your tiles={} entries until the model renders correctly in-game. Once they're right, they'll probably stay right even if you edit your model again.

When you export to .obj, turn on "material groups" in your export dialog, and disable writing of the materials file, as Minetest does not use it.

Excellent. Thank you VE.

Apparently more then one way to go about this. None of my blender models ever require materials to apply textures. Interesting.

I may be wrong, but from what I can tell, materials are only needed if you want to apply more than one texture onto a model, and then probably only if you're exporting to .obj.

While textured viewport rendering may take the image currently loaded in the UV image editor into consideration (no idea about the OBJ export plug-in), textures are only truly applied to objects in Blender through materials. You'll discover this quickly if you do a render, bake textures, etc. See Applying Textures in the Blender manual.

Oh. Question. Does the same application of textures to multiple materials apply to objects like the player model and entities with "mesh" visuals?

That, I am not sure of.

Somewhat alike Prestidigitator, the order you put them in doesn't matter, what does matter is that you use the right name for the textures in Blender. You need to have the same texture names in Blender that you will in Minetest.
Example in my More_fire here: https://github.com/NathanSalapat/more_fire/blob/master/init.lua

Edit:
Maybe I'm wrong about that, ExeterDad certain has more experience with it than I do.

With player models (and entities) the texture name is not important actually. You do however need a material for each texture you wish to use. Once you have finished texturing and are content with the results. You may unlink the texture from the materials AND from within the UV editor in Blender before you export. Then you assign the textures via lua. The order is in the same order the materials are listed within blender. Removing the textures will keep irrlicht from complaining it can't find the texture the model was built with. You may use any texture name you wish, as long as the stack order is the same.

ExeterDad wrote:With player models (and entities) the texture name is not important actually. You do however need a material for each texture you wish to use. Once you have finished texturing and are content with the results. You may unlink the texture from the materials AND from within the UV editor in Blender before you export. Then you assign the textures via lua. The order is in the same order the materials are listed within blender. Removing the textures will keep irrlicht from complaining it can't find the texture the model was built with. You may use any texture name you wish, as long as the stack order is the same.

Excellent. Thanks for the info.