Mesh

[SirGolan]

I can get you a .3ds file of it if you can convert that, but I don't recall if that file type supports skeletons.

But yeah, in order to support changeable gear, everything needs to be a separate mesh, and preferably, they all have the same skeleton.

[multiverseuser]

Ok,

I haven't done any changeable gear stuff before with ogre.
My understanding of meshes and skeletons is that
meshes contain face, vertex, uv information and vertexbone assignments.
the skeleton in the other hands contains bone hierarchy and animations.

Also ogre specifies that every vertex must be part of bone. So I'm not sure
how to handle interchangeable gear, because by definition they are not assigned
to any bone

Perhaps you know how to this. I would be happy to learn something new!!

thanks

[SirGolan]

Actually, for weapons and stuff that isn't flexible, we should probably not attach them to a skeleton now that I think about it. In code, you can load meshes and attach them to a bone in a skeleton, so we'd probably do that instead. But for clothing, it usually has to move with the person and bend and such, so just attach it to the same skeleton that the main mesh is attached to. You can see a broken example of it if you download all the body parts here:

http://dev.mv3d.com/~mike/mv3d/Example/Models/

(hair/head/hands/feet/etc) I think the torso is rotated the wrong way in that, and I wasn't able to fix it. But all the body parts use the same skeleton. Well, at least that was the intent. I think the exporter had different ideas and they ended up using multiple copies of the same skeleton.

[multiverseuser]

Hello,

I exported one of the columns from the fresnel demo.
They look good by I couldn't get the DDS light map to work.
Also the dragon goes through it. I'm not sure how to add collision
to this mesh.

Mesh/material here
http://myfreefilehosting.com/f/06c94d6b13_0.15MB

The textures can be extracted from the FresnelDemo.zip (pythonogre/media/packs)
stone1.jpg
marble3.png

[SirGolan]

Cool.. What were you using to get those models into the game? Did you just replace the cube model (or trees)?

Anyway, You could probably just change the size of the box collider that the cubes use to make it a lot taller.

[multiverseuser]

Hello,

I just added some code in the client. The reason why I did this, is because I couldn't figure out
how the server knows where to put this or that tree or column for that matter.

Overall, I think the server should have a file that contains this information and It shouldn't be a line argument
when creating the server. A while ago I asked for XML support. This is the reason why.

Meshes, (nodes) can be placed, rotated and scaled. Having this information in an XML
would make it a lot simpler to create worlds. Most people would not need to mess with python.
They just create XML files and MV3D loads them and things get placed where the XML tell them too.

My 2 cents!

[SirGolan]

In MV3D, nothing is treated as static, and everything is persistent when using object stores. Because of these two things, loading a static game world from an XML file isn't very helpful. When the stores are enabled, everything in the game world is persisted to disk regularly so that when you restart the server, things are exactly the way you left them.

The stuff in SetupAssets.py and worldgen.py is all just for testing purposes so that when I'm testing out a new feature, I can quickly spin up a small world to try it out in. People looking to create their own worlds will not be using it. Once the in game editor is working again, it'll be possible to create your own world and populate it with objects. By turning on the object stores, your changes will persist even after you stop the server.

I'm not saying it wouldn't be possible for someone to add in the ability to load up a static game world from a file, and in fact, this is one possible way to handle instancing of dungeons or whatnot. Mostly what I'm saying is that once the editor is working, it won't be needed (nor will SetupAssets or worldgen-- except for those people who want to test in a simple world).

Btw, have a look at the createBox function in worldgen.py. You should be able to change the asset it uses for the box and have it be a column instead.

In either this release or more likely the next, here will be the steps to starting your own world:

1. Start a server
2. Create your account using a web browser
3. Give your account admin abilities on your server
3. Log in with the client and create a PC
4. When you connect to that PC, the world will be empty.
5. Bring up the editor and add terrain/trees/grass/etc.
6. All your changes are automatically persisted to a datastore. If you shut down the server and restart it, everything will still be there.

One thing, though. While you will definitely be able to create a nice world with the editor, doing anything complicated or non-standard will require working in Python.

[multiverseuser]

Hello,

We'll it seems the editor it is going to be a big piece of the project.
Since it has to handle how to load things, make them comply with the
physics engine. I was thinking in traditional term of creating a world
where you specify the location of everything and then it is render in OGRE.

By the way, How will MV3D handle "bots"? Characters that are part of the game.
How would they be animated?

Thanks for some of the details,

[SirGolan]

Yeah, the editor is very important. It'll be possible to make external editors, but they'd have to just hook into the server's RPC api. I used to have a few examples of those a while ago actually. There was a web app you could use to register assets. I'll definitely be bringing that back, though it'll be integrated into the server as an interface to the asset service.

Before getting into NPC's, lets talk simpler things. Things like say a draw bridge that opens and closes with a lever, or a trap in the wall that shoots arrows. Those would require some custom Python coding (though that code could be reused for similar things). That code would just run on the normal Sim service. Pretty much anything that doesn't require any brains.

As far as NPCs go, there will be a new service built specifically to handle NPCs. Because it's a service, it will be able to either run in the same process/server as everything else, or in a separate server process (on a different server even). This service is sort of like the PlayerService, except instead of players connecting, NPCs will run inside it. I haven't thought a lot about the architecture other than that, though it will definitely be as easy as possible to plug in your own NPC brains. I'll probably only provide some basic ones to start.