Menche wrote:That is a source patch, not a mod, and can only be applied to a very old version of minetest.Dragonop wrote:
THIS MOD MAKES PLAYER 3D! http://minetest.net/forum/viewtopic.php?id=897
3D meshes for players and creatures [Models are now upstream!]
-
- Member
- Posts: 1233
- Joined: Tue Oct 23, 2012 12:59
- GitHub: Dragonop
- IRC: Dragonop
- In-game: Dragonop
- Location: Argentina
NO IT WORKS FINE IN 0.4.3 !Menche wrote:That is a source patch, not a mod, and can only be applied to a very old version of minetest.Dragonop wrote:
THIS MOD MAKES PLAYER 3D! http://minetest.net/forum/viewtopic.php?id=897
- Menche
- Member
- Posts: 1001
- Joined: Sat Jul 02, 2011 00:43
- IRC: Menchers
- In-game: Menche
- Location: An island in a lava lake.
How? I tried applying it, it wouldn't build with the patched files.Dragonop wrote:NO IT WORKS FINE IN 0.4.3 !Menche wrote:That is a source patch, not a mod, and can only be applied to a very old version of minetest.Dragonop wrote:
THIS MOD MAKES PLAYER 3D! http://minetest.net/forum/viewtopic.php?id=897
An innocent kitten dies every time you top-post.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
If that's ok, I'd prefer discussion about that patch is kept in its own topic. Not that I mind, but I'm trying to get focus on finishing the models code, and since I posted about needing help no one has taken one look at the code yet. Otherwise, I think the nodebox player patch would still work after this too, but IMO I see no point in it now that we can use real meshes.
- PilzAdam
- Member
- Posts: 4026
- Joined: Fri Jul 20, 2012 16:19
- GitHub: PilzAdam
- IRC: PilzAdam
- Location: Germany
For those who cant wait for 3D players: http://minetest.net/forum/viewtopic.php?id=3585
Its a simple mod (yes, a mod; you can install it like other mods) that adds simple 3D players.
Its a simple mod (yes, a mod; you can install it like other mods) that adds simple 3D players.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
There are some technical updates on this (no new functionality yet). I managed to get the mesh node of the child object to know what the mesh node of the parent is (client-side), which has been the biggest issue in the last days. Attachments are also hidden and ignored when attached to the local player, which was the reason for the last segmentation fault. Credits for the help here go to thexyz, and TheRedMood also offered to look into the code and help which I appreciate.
Right now I just finished coding in the Irrlicht functions to attach the object (mainly child->setParent(parent)), but for some reason they don't work yet. This should be the last major issue with attachments... why isn't the child being attached visually for clients?
The image above is a random screenshot I took during testing. The object to the left is me (I connect with 2 clients to test) and the one to the right is the attachment (lua entity) which is displaying at origin 0 0 0 instead of sticking to my player's mesh. Tested with both bone and direct object attachments and neither work.
Right now I just finished coding in the Irrlicht functions to attach the object (mainly child->setParent(parent)), but for some reason they don't work yet. This should be the last major issue with attachments... why isn't the child being attached visually for clients?
The image above is a random screenshot I took during testing. The object to the left is me (I connect with 2 clients to test) and the one to the right is the attachment (lua entity) which is displaying at origin 0 0 0 instead of sticking to my player's mesh. Tested with both bone and direct object attachments and neither work.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Today was some big progress on the code. Client attachments and detachments should technically work now. They're properly attached to the parent, but for an unknown reason their origin changes a few ticks after. Will try to find out why tomorrow. Bone attachments were not tested yet but should work too, and other major bugs likely exist. I still get some segmentation faults as well and must find out why.
Another important change is that all features in this code are now sent to new clients when initializing entities. Previously, a player would only see attachments or animations working if he was near the object when the script was triggered. With the latest GIT, if a client logs in after those settings are set the server will send them. Therefore the script only needs to run once per entity (or whenever it wishes to make a change), not every X seconds to update clients that might be seeing our object for the first time.
There's still stuff left to do, but the code is slowly reaching testing point. Once that happens I'll probably make a more solid test script and post a list of what's left to fix and check. If all goes well I'll get working on the player model too, but for now the code stays the biggest concern.
Another important change is that all features in this code are now sent to new clients when initializing entities. Previously, a player would only see attachments or animations working if he was near the object when the script was triggered. With the latest GIT, if a client logs in after those settings are set the server will send them. Therefore the script only needs to run once per entity (or whenever it wishes to make a change), not every X seconds to update clients that might be seeing our object for the first time.
There's still stuff left to do, but the code is slowly reaching testing point. Once that happens I'll probably make a more solid test script and post a list of what's left to fix and check. If all goes well I'll get working on the player model too, but for now the code stays the biggest concern.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
If anyone's been wondering what happened in the last days, yes... I'm still working on the code. And I'm happy to announce big progress.
I've been fixing the remaining segmentation faults, which were caused by a lot of weird and complicated factors. After analyzing the code for a day, I realized that the bad memory reads were due to children remaining parented to an object in Irrlicht while that object's mesh node was removed (including to update its visuals). I addressed that by implementing a new way of storing children and parents, and detaching all children of a parent when updating its visuals then attaching back. This was the biggest and hardest issue still present in the code.
Not only that the segmentation faults should now be gone. But with today's changes, client-side attachments are finally working. I can attach a lua object to a player, and other players properly see it attached. No jittering, no lag, all good.
But it's not all that perfect and working either: If the player disconnects, its attachment goes to origin 0,0,0 which should have been addressed in my code. Tomorrow I will check why. Also, bone attachments don't work as they should. When the child is parented to a bone, it properly copies its origin and rotation. But as the parent mesh is animated, the attachment doesn't keep following the bone. This too needs to be investigated.
Things are going well pretty fast, so expect more good news soon. Here's a screenshot of attachments in action:
I've been fixing the remaining segmentation faults, which were caused by a lot of weird and complicated factors. After analyzing the code for a day, I realized that the bad memory reads were due to children remaining parented to an object in Irrlicht while that object's mesh node was removed (including to update its visuals). I addressed that by implementing a new way of storing children and parents, and detaching all children of a parent when updating its visuals then attaching back. This was the biggest and hardest issue still present in the code.
Not only that the segmentation faults should now be gone. But with today's changes, client-side attachments are finally working. I can attach a lua object to a player, and other players properly see it attached. No jittering, no lag, all good.
But it's not all that perfect and working either: If the player disconnects, its attachment goes to origin 0,0,0 which should have been addressed in my code. Tomorrow I will check why. Also, bone attachments don't work as they should. When the child is parented to a bone, it properly copies its origin and rotation. But as the parent mesh is animated, the attachment doesn't keep following the bone. This too needs to be investigated.
Things are going well pretty fast, so expect more good news soon. Here's a screenshot of attachments in action:
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
The last two days have once again brought a lot of progress. Yesterday, all remaining issues with attaching and detaching lua entities have been fixed. Today, attached players have also been completed and are fully functional. An attached player will be unable to move and will see himself smoothly following the parent, without any additional data needing to be sent by the server. As of the last commit, object to object attachments should work flawlessly. Vanessa's patch for anisotropic filtering and mip-mapping was also merged today, so I enabled those features on models too.
At this moment, there's only two known issues with the models code: Attempting to manually animate joints doesn't work and breaks animations instead. Also, bone attachments don't work properly either. Those are problems regarding the Irrlicht functions, and I'm currently waiting for input from the Irrlicht people about them. If anyone has experience with this engine, feel free to look at the code and figure out what's happening. Here are the topics on the Irrlicht forum about those issues in detail:
http://irrlicht.sourceforge.net/forum/v ... =1&t=47579
http://irrlicht.sourceforge.net/forum/v ... =1&t=47580
I'm currently waiting on this last problem. But in a few days, I'm planning to announce the code as finished and ready for testing. I'll post information here as to what and how needs to be tested, so stay tuned.
At this moment, there's only two known issues with the models code: Attempting to manually animate joints doesn't work and breaks animations instead. Also, bone attachments don't work properly either. Those are problems regarding the Irrlicht functions, and I'm currently waiting for input from the Irrlicht people about them. If anyone has experience with this engine, feel free to look at the code and figure out what's happening. Here are the topics on the Irrlicht forum about those issues in detail:
http://irrlicht.sourceforge.net/forum/v ... =1&t=47579
http://irrlicht.sourceforge.net/forum/v ... =1&t=47580
I'm currently waiting on this last problem. But in a few days, I'm planning to announce the code as finished and ready for testing. I'll post information here as to what and how needs to be tested, so stay tuned.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
It is, but the player in the cart becomes smaller. That's because the visual_size of the cart is not 1,1 and in Irrlicht children also copy the size of the parent. This can't be helped... the cart will either need to resize itself in another way, or set the visuals of the player to be larger too in order to compensate. I'd prefer the first method... currently testing this to see what can be done.jin_xi wrote:hi there, ive been testing your latest code along with PilzAdams carts mod. Its so cool to see how this works smoothly, and i cant wait to see all the cool rides people are gonna build. One thing tho is that the mesh of the player attached to (riding) a cart is not visible to other players.
Last edited by MirceaKitsune on Sun Nov 11, 2012 00:00, edited 1 time in total.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Doing some final tests on the bone functions, until I get news from Irrlicht users about the issues I can't solve. It seems bone transformations do work, although enabling them breaks animations and inverts the mesh normals. Here's me giving a large value to the position of a joint for the test player mesh, via the lua script. The result is funny
[EDIT] W00t! Just tested bone attachments again, and they also work! I attached the second player to the animated bone of the first player. The third player can see him leaning together with the bone as the mesh animates. This means that visibly hand-held tools should now be possible. But once again, enabling joint control does not work properly and breaks everything, which is the last remaining issue. Here is a screenshot showing this in action... the child player leans back and forth as the parent mesh animates:
[EDIT] W00t! Just tested bone attachments again, and they also work! I attached the second player to the animated bone of the first player. The third player can see him leaning together with the bone as the mesh animates. This means that visibly hand-held tools should now be possible. But once again, enabling joint control does not work properly and breaks everything, which is the last remaining issue. Here is a screenshot showing this in action... the child player leans back and forth as the parent mesh animates:
Last edited by MirceaKitsune on Wed Nov 14, 2012 13:23, edited 1 time in total.
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
And the moment everyone's been waiting for is here: We have a 3D player! I created the model in Blender today, rigged and UV mapped it, and added the basic animations: Standing, walking (forward backward left and right) and mining / punching. The player.lua script contains definitions for all frame ranges so they can easily be used. It is a lot like the MineCraft model, only that arms and legs can be bent.
There's also a surprise I've had in store for this model: It's fully compatible with any MineCraft skin. I did the UV mapping so the exact same areas of the texture are used. So if you have a favorite custom skin you use in MC, simply apply it as a texture to the mesh and it will work Just for clarity... this is not to copy MineCraft, but to allow people to use their custom skins in both places, since I think many would like that.
In my test I use the default MineCraft player skin... but for obvious licensing reasons it's not included in GIT. To use it, get the texture from HERE, rename it from Char.png to player.png, and place it in the same folder (models) as the mesh.
Needed next is help from lua scripters: The player script needs functions to detect when the player is walking forward, backward, or strafing left or right... and with what speed. Also when the player is mining (holding the left mouse button). If you can help with that, please checkout the game branch and modify player.lua accordingly. Feel free to put the changes on your own repository or pastebin them to me or post them here. This is very needed, since currently the script just loops one player animation!
Also, we need a MineCraft skin that's license compatible. If you know one link it here, or feel free to make your own. This shouldn't be hard.
Other than that, the code is now ready for testing. I still haven't figured out why manually editing joints makes the mesh break, but hopefully that will be fixed soon. I'll post instructions later about how to test. Soon after that I will pull request it so it can be added to MineTest.
Code branch: https://github.com/MirceaKitsune/minetest/tree/models
Game branch: https://github.com/MirceaKitsune/minete ... ree/models
Screenshots:
http://i50.tinypic.com/35kvrro.png
http://i49.tinypic.com/2w7jt02.png
http://i48.tinypic.com/2jg2fx3.png
http://i50.tinypic.com/1zmmrd5.png
http://i50.tinypic.com/1zzjgb8.png
http://i47.tinypic.com/2nvuvmf.png
http://i49.tinypic.com/4fu1a9.png
http://i47.tinypic.com/rvk1vp.png
There's also a surprise I've had in store for this model: It's fully compatible with any MineCraft skin. I did the UV mapping so the exact same areas of the texture are used. So if you have a favorite custom skin you use in MC, simply apply it as a texture to the mesh and it will work Just for clarity... this is not to copy MineCraft, but to allow people to use their custom skins in both places, since I think many would like that.
In my test I use the default MineCraft player skin... but for obvious licensing reasons it's not included in GIT. To use it, get the texture from HERE, rename it from Char.png to player.png, and place it in the same folder (models) as the mesh.
Needed next is help from lua scripters: The player script needs functions to detect when the player is walking forward, backward, or strafing left or right... and with what speed. Also when the player is mining (holding the left mouse button). If you can help with that, please checkout the game branch and modify player.lua accordingly. Feel free to put the changes on your own repository or pastebin them to me or post them here. This is very needed, since currently the script just loops one player animation!
Also, we need a MineCraft skin that's license compatible. If you know one link it here, or feel free to make your own. This shouldn't be hard.
Other than that, the code is now ready for testing. I still haven't figured out why manually editing joints makes the mesh break, but hopefully that will be fixed soon. I'll post instructions later about how to test. Soon after that I will pull request it so it can be added to MineTest.
Code branch: https://github.com/MirceaKitsune/minetest/tree/models
Game branch: https://github.com/MirceaKitsune/minete ... ree/models
Screenshots:
http://i50.tinypic.com/35kvrro.png
http://i49.tinypic.com/2w7jt02.png
http://i48.tinypic.com/2jg2fx3.png
http://i50.tinypic.com/1zmmrd5.png
http://i50.tinypic.com/1zzjgb8.png
http://i47.tinypic.com/2nvuvmf.png
http://i49.tinypic.com/4fu1a9.png
http://i47.tinypic.com/rvk1vp.png
- VanessaE
- Moderator
- Posts: 4655
- Joined: Sun Apr 01, 2012 12:38
- GitHub: VanessaE
- IRC: VanessaE
- In-game: VanessaE
- Location: Western NC
- Contact:
Beautiful work!
Suggestion: name the skin file player_3d.png to distinguish it from default 2D player skins, so texture packs won't break.
Suggestion: name the skin file player_3d.png to distinguish it from default 2D player skins, so texture packs won't break.
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
I noticed this causes the sprite player to get the texture too. I think I'd rather rename its texture instead... not sure. But I'll look into that.VanessaE wrote:Beautiful work!
Suggestion: name the skin file player_3d.png to distinguish it from default 2D player skins, so texture packs won't break.
BTW, another thing I need help with and forgot to post earlier: Does everyone think the arms and legs bending looks ok? There's only one edge loop, so bending them too much will cause the limbs to look as if they're shrinking toward the middle. I'm tempted to remove that and make the limbs whole boxes... but then this will be exactly like the MineCraft model and will give people more reason to accuse us of copying MC I think it looks very good apart from this, and might go for whole limbs since I'm unsure about the deformations.
- InfinityProject
- Member
- Posts: 1009
- Joined: Sat Mar 17, 2012 00:52
- Location: World of Infinity, US
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Not that part... no implementation for wearables yet. But that can be easy to add later on perhaps.InfinityProject wrote:The helmets that can be added to minecraft skins; is that supported?
Also, it seems the bug with animating joints is a known Irrlicht issue regarding skinned meshes, and won't be fixed in any recent update. The functions will stay coded in MineTest of course, but won't be usable for probably many months from now. So things like the head looking where the player is facing will have to wait... but thankfully that's a less important part. More info here:
http://irrlicht.sourceforge.net/forum/v ... =1&t=47579
http://irrlicht.sourceforge.net/forum/v ... =7&t=47041
- BrandonReese
- Member
- Posts: 839
- Joined: Wed Sep 12, 2012 00:44
- GitHub: bremaweb
- IRC: BrandonReese
- In-game: BrandonReese
- Location: USA
The title says players and creatures, will we be able to create 3D mobs in lua with your new feature?
My Twitch Channel - https://www.twitch.tv/brandonreese81/profile
- VanessaE
- Moderator
- Posts: 4655
- Joined: Sun Apr 01, 2012 12:38
- GitHub: VanessaE
- IRC: VanessaE
- In-game: VanessaE
- Location: Western NC
- Contact:
No, don't rename the old 2D player texture - that'll break too much stuff (namely, every MT skin in existence, plus some texture packs). Leave the old player skin as player.png, and give the 3D model its own filename.
It causes less work for us texture pack authors, plus it makes it much easier to support both player sprites and 3d models, since not everyone will necessarily run the latest version of the game.
It causes less work for us texture pack authors, plus it makes it much easier to support both player sprites and 3d models, since not everyone will necessarily run the latest version of the game.
You might like some of my stuff: Plantlife ~ More Trees ~ Home Decor ~ Pipeworks ~ HDX Textures (64-512px)
- MirceaKitsune
- Member
- Posts: 924
- Joined: Sat May 21, 2011 22:31
- GitHub: MirceaKitsune
- IRC: Taoki
- In-game: MirceaKitsune
- Location: Romania, Bucharest
Certainly. The feature is intended to allow models for both players and lua entities, and has been tested on both. The same lua functions are used for either of the two. So yes, current code should easily allow 3D players for the animals mod and other mobs.BrandonReese wrote:The title says players and creatures, will we be able to create 3D mobs in lua with your new feature?
Ok, I'll try to use different file names for mesh player. The sprite player will only stay useful for consistency however... perhaps I should modify it into a "loading" skin with my branch, since it's now only meant to be visible before the script sets its mesh (as fallback).VanessaE wrote:No, don't rename the old 2D player texture - that'll break too much stuff (namely, every MT skin in existence, plus some texture packs). Leave the old player skin as player.png, and give the 3D model its own filename.
It causes less work for us texture pack authors, plus it makes it much easier to support both player sprites and 3d models, since not everyone will necessarily run the latest version of the game.
Clients need to have the new code to see models. Haven't tested what happens if not.Mito551 wrote:what happens if client with default mt (e. g. sfans build) joins this server?
Who is online
Users browsing this forum: No registered users and 9 guests