3D meshes for players and creatures [Models are now upstream!]

[lkjoel]

Guess what? We can use nodeboxes to do this!

[MirceaKitsune]

Guess what? We can use nodeboxes to do this!

What do you mean? If you mean blocky meshes out of scripted vertice positions (which I think is what MineCraft does) I support using a real skeletal model format instead. They're much easier to work with and better IMO, especially since animation is bone-based. Also in my case, I might make custom games with high-poly meshes like those in modern shooters, and they wouldn't work being made of boxes (unless you're a godlike hacker). Not sure if that's what nodeboxes are or you meant something else.

[lkjoel]

Nodeboxes are the new thing c55 implemented. Look at the 3D Forniture Mod.

[MirceaKitsune]

Nodeboxes are the new thing c55 implemented. Look at the 3D Forniture Mod.

Wow, totally a nice feature! I still support 3D mesh format implementations as well however. But node boxes are indeed very awesome and detailed... I think both would be quite useful overall.

[lkjoel]

Yep! I'm not sure how ready C55 would be to importing meshes to the game though...

[kingtux]

I have used irrlicht and I know that it can load plenty of mesh types, so it won't be all that hard to use meshes.

[MirceaKitsune]

There are two things I'm unclear about. First of all, can the current nodeboxes be animated? So you can animate the arms and legs of the player as he walks around for example, in those cases where players are made with node boxes. I seen a screenshot of someone adding 3D animals with these, but can't tell if they were animated or like a statue.

As for 3D mesh support, I'm unclear as to when someone will consider implementing it. Many are waiting for this feature but no one's looking into it yet. I'm actually worried a bit, since I can't consider working on my custom games until this is added (as well as LUA biomes and natural blocks).

When can we get started on implementing this? Note that I'm bad at C++ and don't know the MineTest code, so I'll likely be helpful with testing and maybe making some models in Blender. I'll also be away for about 3 weeks. But like I said on IRC, we likely don't have to code support for 3D meshes, because Irrlicht already has that. We just need to code the proper LUA hooks to allow the API to point to a 3D model, an animation to play on it (for skeletal formats) and render that for players and mobs... that's likely it.

[Nubelite]

I made some modifications and added some collar and uvmaps to your mesh MirceaKitsune hope you don't mind :). If this model is to be used i am willing to make some animations and add a skeleton system to it. Total of 86 vertices. The shirt and pants are mapped so they can be customized for armor, jackets, layer shirts all with optical illusion graphics of course. I think just changing the jpg file for some clothing mods would be doable not fully sure.

Download Zip

[MirceaKitsune]

I made some modifications and added some collar and uvmaps to your mesh MirceaKitsune hope you don't mind :). If this model is to be used i am willing to make some animations and add a skeleton system to it. Total of 86 vertices. The shirt and pants are mapped so they can be customized for armor, jackets, layer shirts all with optical illusion graphics of course. I think just changing the jpg file for some clothing mods would be doable not fully sure.

Download Zip

Not a problem, do whatever you wish with it :) It looks pretty good so far, nice work.

[VanessaE]

Looks interesting. Just adjust the shapes of the hands and head and you have a lego minifig there. :-)

[Nubelite]

Found this today Thread

Does this no longer work? i tired it and got no where

[wokste]

Found this today Thread

Thanks for adding the reference.
Unfortunately, this patch has a more or less a hardcoded model in it. Therefore it is not directly usable.
Secondly, there have been reports on performance issues. (whether they are true, I don't know)

[rubenwardy]

Animations are not possible yet with node boxes

[MirceaKitsune]

Ok. Since I got bored of waiting for this to happen, I decided to dive into it and try to implement it myself. I have not coded anything yet, but found some useful information. I tend to finish something first then post about it, but in this case I'd rather post what I discovered then see if I can do it (I am a n00b coder so I can't promise anything).

After quickly digging through the MineTest code, it appears you'd first define a new rendering type then set individual objects to use it (in this case the player). Some of the current types are "cube" or "upright_sprite". To find them easily, do a grep in the minetest/src/ folder. They seem to be handled in two parts of the code, here it is for the cube:

Code: Select all

content_cao.cpp, line 783: else if(m_prop.visual == "cube"){
content_cao.cpp, line 1025: if(m_prop.visual == "cube")

The first line seems to set the draw properties, while the second line to handle the material configuration for the selected kind of mesh. The player itself is set to use "upright_sprite" in the following line:

Code: Select all

content_sao.cpp, line 785: m_prop.visual = "upright_sprite";

From my understanding, we need to define a new drawing type where "cube" and "upright_sprite" are, which I will probably call "mesh". Like I said I'm not interested in animated nodeboxes for players and mobs (maybe for some items), I want to see this done with rigged models. Irrlicht natively supports such and works with various formats, and this is what I'm trying to achieve. Apparently it's easy... one of the current draw types should be possible to modify and simply point to a mesh instead. I also looked at how this is done for Irrlicht and am working with the following resources:

http://irrlicht.sourceforge.net/docu/
http://irrlicht.sourceforge.net/docu/example004.html

The first link has a section called "Short example" that shows the following line of code:

Code: Select all

scene::ISceneNode* node = scenemgr->addAnimatedMeshSceneNode(scenemgr->getMesh("quake2model.md2"));

In MineTest for the "cube" type (those lines of code I mentioned first in the post) we see something like this:

Code: Select all

scene::IMesh *mesh = createCubeMesh(v3f(BS,BS,BS));
m_meshnode = smgr->addMeshSceneNode(mesh, NULL);
mesh->drop();

scenemgr in one code and smgr in the other represent the same thing. So the switch seems to be fairly easy. I don't know if there's something I'm missing and if other complications may occur, we will see. This should conclude how to set a 3D mesh using the native Irrlicht implementation to a MineTest node, if everything is correct.

Next topic is how to change animations on nodes with models. I spoke with the Irrlicht people on IRC and they pointed out the second resource link I listed. The command in their example would be:

Code: Select all

anms->setFrameLoop(0, 13);
anms->setAnimationSpeed(15);
anms->setMD2Animation(scene::EMAT_RUN);

Not sure if the last line is of any use, but that's what I got. What the first line does is setting the mesh to loop between frames 0 and 13, while the second line sets animation speed to 15. So whenever changing animation (eg: Because we pressed the forward key to go forward), at least the setFrameLoop function needs to be called to change what animation is played on the model. This is a bit more complicated and I haven't checked where it should be done in the MineTest code yet. Each animation of the model is placed in a specific frame range (eg: frames 0 to 15 could be the standing animation, 16 to 38 the walk animation, 39 to 53 the mine / use animation, and so on).

The last concern was what mesh format to use for MineTest. Quake md2 is an Irrlicht standard, but I want a *rigged* format that uses an animation skeleton and is easy to export from Blender. The users on #irrlicht suggested obj, which is a common format and Blender has a native exporter for it. Seems like the best option for me so far, and it's what I will try to go with.

The trickiest part is where to set the LUA hooks for specifying the model and triggering animations, and I'm pretty bad at this one too. There will probably be a lot of other things that need doing, but I think these are some of the most important basics. I'll try to see where I get with this, but if I don't succeed this should be a very good starting point for anyone else who tries. If I do I'll post the changes on my GIT remote and let everyone know.

[MirceaKitsune]

I began work on coding the feature. The news is better than what I expected for today: I was able to render the player as a static mesh. Here is a screenshot:



The black sphere is a simple obj file I made and exported in Blender. Unfortunately I was wrong in my earlier post... obj is a static format, and I need to find something else for rigged models.

Next step is to work on getting a material to show, and perhaps create a good player model similar to the one in MineCraft. Player appearance is currently hard-coded, I may try to change that as well. After that I shall see if I can add the LUA hooks to allow nodes and items to use 3D models as well. I will put my code on GIT soon and post instructions on how to access my remote.

[EDIT] Created a GIT branch for this on my remote, where I will be updating the code. https://github.com/MirceaKitsune/minetest/tree/models

[Temperest]

This is awesome! I can't wait for the Git repo to be put up.

The black sphere is a simple obj file I made and exported in Blender. Unfortunately I was wrong in my earlier post... obj is a static format, and I need to find something else for rigged models.

Yes, OBJ is a static format. Not very flexible either, but it's text based and basically every 3D application can export it. In fact, you can even write it out by hand. People do animation with OBJ files by making one for each keyframe and interpolating between them, or just making one for every single frame.

[MirceaKitsune]

This is awesome! I can't wait for the Git repo to be put up.

Thank you. Just finished that, see https://github.com/MirceaKitsune/minetest/tree/models

Yes, OBJ is a static format. Not very flexible either, but it's text based and basically every 3D application can export it. In fact, you can even write it out by hand. People do animation with OBJ files by making one for each keyframe and interpolating between them, or just making one for every single frame.

If it can't be animated it's useless for players however. I need to find a more sane format that supports rigging. The bright side is that the same code should work for any mesh format, as Irrlicht does the reading of those... so that can be done later.

[irksomeduck]

Well, I think that minetest is in desperate need of 3D characters, and I would support it all the way.

[MirceaKitsune]

Been a full day of work on the feature today, but I'm very happy with the progress. The code now requires LUA to set player appearance to a mesh, and a simple script can already do so. Error handling was added and texturing should also work (needs testing however). Nodes other than players should also be possible to mesh now, but I haven't tried those yet. Grab the latest code here:

https://github.com/MirceaKitsune/minetest/tree/models

Use the following LUA script to mesh players (inspired by another script):

Code: Select all

function switch_player_visual()
        prop = {
            mesh="player.obj",
            texture="player.png",
            visual="mesh",
        }
    for _, obj in pairs(minetest.get_connected_players()) do
        obj:set_properties(prop)
    end
    minetest.after(1.0, switch_player_visual)
end
minetest.after(1.0, switch_player_visual)

There's still no player model as I'm looking for a good format, and the code needs to be finished first. Once that's done I'll probably try to make one. Last part will be animations, which should also be fairly easy if all goes well.

[MirceaKitsune]

New improvements since the last update: Properly read the mesh and texture from their mods folder. During testing the model had to be located in /bin next to the minetest binary, now it's read from .../minetest/games/minetest_game/mods/default/models. Fixed material rendering, lighting was not being set and models appeared black. Tested with a texture and UV-mapped mesh, confirmed to work well on local server. Fix texturing for multi-material (segmented) models. Meshes now use the same "textures" field as blocks, and multiple textures are added to an array under LUA. Also added a property which should allow LUA to read the mesh of a player, not tested yet. This should make room for working on animations next. Here is the latest code comparison:

https://github.com/MirceaKitsune/minetest/compare/models

The updated (but still incomplete) script to mesh players is:

Code: Select all

function switch_player_visual()
    local modpath = minetest.get_modpath("default")
    prop = {
        mesh=modpath.."/models/player.obj",
        textures = {modpath.."/models/player.png", },
        visual="mesh",
    }
    for _, obj in pairs(minetest.get_connected_players()) do
        obj:set_properties(prop)
    end
    minetest.after(1.0, switch_player_visual)
end
minetest.after(1.0, switch_player_visual)

How textured meshes look like (still uses the test mesh, that's the last part to get to):



[EDIT] Created a minetest_game branch which contains the LUA script and current test model and texture. When a player model will be ready this will also contain it. https://github.com/MirceaKitsune/minetest_game/tree/models

[Shadowmang]

that's a lot of progress of ~2days. Well done.

I wish my skills were good enough to aid you

[Temperest]

That is simply incredible, do you have a plan for animation and how that's going to be exposed in Lua? I think simply using the frame numbers system should be more than sufficient. Something like LuaEntity:seek_animation(frame) and play_animation(framecount) should be a great start.

I'd love to see support for animated nodes too, but I suppose that's something to consider at another time.

[MirceaKitsune]

Animation support was delayed by a discovery I made, that the mesh and its texture were not being put through the media stream. I fixed it with celeron55 and meshes are now sent from the server to clients like everything else.

I'm currently working on getting an animated test model working, but it's hard to find a skeletal format for Irrlicht. The b3d format works and I'm trying it out. A blender exporter was hard to find but I got one... so far the mesh isn't rendering like obj did, and I'm trying to find out why. It's unlikely I'll get any animation code done until tomorrow, and I'm still thinking how exactly LUA will handle this.

@ Shadowmang: Thanks for the support, it helps to know everyone finds this useful.

@ Temperest: From what I understand animation works in the following way: The mesh has a number of frames in order. Walk animation could be frame 0 to 10, jump animation could be frame 11 to 23, punch / mine 24 to 32, and so on. The way you set a model to animate is by using mesh->setFrameLoop(x, y); where x is the start frame and y the end frame. So LUA will simply parse those two values at the time it wants to animate the player, with the frame range of a specific animation. Yes, that means the start and end frames must be manually coded in LUA by who exports the mesh, but that's normally never a problem.

As for nodes with animated meshes, this should already be possible. Any drawing type the player can be set to anything else can. But I haven't tested with notes yet, just the player.

[MirceaKitsune]

Important update: I was just able to get a skeletal mesh with looping animation to render (not controlled by the code yet). b3d would not work, so I'm going with the x format (DirectX). Blender has a native exporter for it, and Irrlicht supports it natively as well, so it's all good. This means the next part is getting working on the code to specify animation ranges. I might make a video if I find a working way to record my screen under Linux.

[Mito551]

you're doing such a great job!~ keep it up!