Voxelands Forum

The official Voxelands discussion forum

You are not logged in.

#1 2015-02-05 13:16:52

darkrose
Administrator
Registered: 2013-10-05
Posts: 743

Bigger Things

Meshgen:
The current meshgen sucks, there is no way to animate a node or texture without having to regenerate at least one entire block (4096 nodes) every time the animation updates. Minetest's "solution" is to add an urgent flag to mapblock mesh generation so that animated things get updated quickly; this still means updating an entire 4k nodes just to animate one though. Additionally, updating lighting requires a complete regeneration of the mapblock mesh, and for sunlight updates - i.e. time of day - regeneration of every mesh for every loaded block. Also, smooth lighting is still not truly smooth for special drawtypes.
Possible solutions:
Instead of creating a single static mesh, have only static nodes in a static mesh, then give dynamic/animated nodes their own mesh, this way animation updates don't have to regenerate the entire block.
There's only 18 day/night lighting values, so instead of regenerating all the mesh data when time of day changes, precalculate all the lighting values and just update the existing vertex light values when the time change affects the light values. This would slow down meshgen, with the trade off of not having to update as often.
For far away meshes, simplify meshgen so that all nodes are seen as cubelike, this will be ugly, but will be fine for far off terrain, and should enable more of the map to be rendered with a faster framerate.
To fix the drawtype lighting:
1. treat the node as it's own block of 16x16x16 subnodes, and translate lighting as done for mapblocks
1a. this may be slow, the other option is to leave as is and use shaders to fix the bugs.
2. create special lighting rules for non-cubic nodes (such as rooflike) so that when asking for it's light value, the result varies according to position
Fixed:

  • New meshgen calculates day and night values for lighting, which is then diffed for the time of day and the mesh's light values updated, no more regen's.

  • New meshgen interpolates face-biased light values for each vertex, smooth lighting is truly smooth.

  • New meshgen has support for single nodes to have their own mesh, allowing for future animation support.

Mobs:
Spawning is finally getting somewhat sane, but there's still a bug causing duplication sometimes when a block is unloaded then loaded. Most of the current models suck, they only vaguely resemble what they're meant to be and the textures for the model aren't pixel-aligned with mesh faces. There's currently 3 draw types which slows down client-side mob stepping due to having to check what kind of mesh it has. Lighting is non-smooth, there are no darker or lighter faces, the underside of the mob is the same brightness as the top. Server-side stepping is a mess, collision detection seemed like a good idea at the time but is utter bollocks, path-finding should not occur on every server step.
Possible solutions:
Dump all the models, don't use sprites; instead opt for nodeboxes with rotation support (like mapnodes), add support to specify per-frame rotation of each nodebox, then find a way to fit this into irrlicht's mesh system so that it can update the rotations as appropriate. This would speed up client-side stepping as well.
The above also means we can specify per-face or per-vertex light (colour) values, these could be pre-calculated for each light value as per meshgen above, maybe.
Write a proper path finder, with nodebox and special drawtype support in the collision detection. This would also speed up server-side stepping, and remove a lot of crud from the step functions.
Fixed:

  • Spawning is fixed, with much swearing.

  • Not in game yet, but Melkiors models are awesome, prebaked lighting fixes shading

Network:
It's slow, and is the cause of most lag in the game. It's also butt ugly, slow, and massive.
Possible solutions:
Freeminer replaced Minetest's network code with enet (http://enet.bespin.org/) which apparently gives massive performance improvements both in cpu usage and response time. This is worth looking into.
The other option would be to rewrite the entirety of the network code ourselves.
Even with this, both the server and client packet processing is utter crap, these both need to be rewritten so they're not just a single function of several thousand lines. Also, standardise the handling of packet data, sometimes we manually access the byte buffer, sometimes we use streams, and sometimes other random methods are used.
Fixed:

  • Server ProcessData function work has begun, ground action has been rewritten but not moved to it's own function, yet.

Environment:
Urgh, environment stepping. Slow, cpu intensive, ugly, and huge. Using voxel manipulators (e.g. tree growth) on the map is just an automated way to break lighting. The current blockstep iterates over every node in the world every 10 seconds, ABM's as used by Minetest/Freeminer aren't a solution as they still iterate over every node, but also iterate over every ABM for every node - even if the node doesn't use the ABM.
Possible solutions:
Speed can be improved by using addNodeAndUpdate() instead of addNodeWithEvent(), then manually setting block updates. This should also reduce network traffic, as instead of sending data to clients for every node change, it would only send data once for each block. Also, should speed up the client a bit, as it won't try to regenerate the mapblock meshes multiple times.
Probably register dynamic nodes when a block is loaded, and deregister when unloaded. This would use more memory, but would mean only iterating over nodes that may actually change. What's our memory usage like anyway?
Might need seperate tree growth code for environmental growth vs mapgen, this could use addNodeAndUpdate() as above, which would solve the lighting issue, but would mean some similar-but-not-quite-duplicated code would then exist.
Could then improve on addNodeAndUpdate() by creating a function that doesn't update lighting, but instead just adds the nodes. Then lighting could be updated for all modified blocks after blockstep, then block data sent to clients.
Fixed:

  • New treegrowth code fixes lighting issues

  • New farm code speeds up part of the env loop

Last edited by darkrose (2015-06-06 08:05:56)


Support Voxelands on Patreon: https://www.patreon.com/voxelands

Offline

#2 2015-02-23 03:40:56

darkrose
Administrator
Registered: 2013-10-05
Posts: 743

Re: Bigger Things

Could probably reduce network lag a bit by changing the way player inventory is sent. Currently the entire player inventory is sent every time a node is dug, and if the node contains a mineral (i.e. stone with coal) then the entire inventory is sent twice. Considering that a mese pick can easily dig 10 nodes per second, this means we could be sending player inventory 20 times per second per player. Plus it's sent as reliable, so there's ack's in there too. Serialised inventory is about 4kB.
Better idea: add a TOCLIENT_INVENTORY_UPDATE network command that send only the position, content type, and count of a single inventory slot when there's a change (such as node dig), send as unreliable, mark inventory as unsent, and send the entire every X seconds or changes. This would reduce inventory network overhead from about 80kB/sec to 4.2kB/sec (assuming once-per-second full inventory send, less if it's sent less often).


Support Voxelands on Patreon: https://www.patreon.com/voxelands

Offline

#3 2015-04-11 18:46:25

melkior
Member
From: Sacramento, CA
Registered: 2015-04-08
Posts: 52
Website

Re: Bigger Things

darkrose wrote:

Meshgen:
Mobs:
Spawning is finally getting somewhat sane, but there's still a bug causing duplication sometimes when a block is unloaded then loaded. Most of the current models suck, they only vaguely resemble what they're meant to be and the textures for the model aren't pixel-aligned with mesh faces. There's currently 3 draw types which slows down client-side mob stepping due to having to check what kind of mesh it has. Lighting is non-smooth, there are no darker or lighter faces, the underside of the mob is the same brightness as the top. Server-side stepping is a mess, collision detection seemed like a good idea at the time but is utter bollocks, path-finding should not occur on every server step.
Possible solutions:
Dump all the models, don't use sprites; instead opt for nodeboxes with rotation support (like mapnodes), add support to specify per-frame rotation of each nodebox, then find a way to fit this into irrlicht's mesh system so that it can update the rotations as appropriate. This would speed up client-side stepping as well.
The above also means we can specify per-face or per-vertex light (colour) values, these could be pre-calculated for each light value as per meshgen above, maybe.
Write a proper path finder, with nodebox and special drawtype support in the collision detection. This would also speed up server-side stepping, and remove a lot of crud from the step functions.

I'm not sure I agree with the proposed approach yet ; but obviously I'm new on the project so I haven't had nearly the amount of time to look at it as you.

However I wanted to share some thoughts.

I was looking in to the models / meshes / animations this morning and going over the features that the irrlicht engine supports.

Firstly you mention we have 3 model types? I assume this is due to having some static models and some animated models? I saw some of the monsters/animals were in the blitz 3D  (.b3d) format ; however in data/models I did not find any other formats ... ?  So I  am not sure if that is the correct thing you are talking about?

Secondly I would suggest while .b3d is working at the moment we might actually rather want to swap to a different format alltogether, the reason being that .b3d is really not a widely known nor supported format.  Very few modelling programs support it ; and as near as I can tell at the moment the Blender 3D exporter probably wont work because of the 2.7 updates(a quick search seems to suggest the last b3d exporter was for 2.4).

Irrlicht supports 5 animated formats - of those only one is actually fairly 'major' and that is the Microsoft DirectX format; which also happens to have support in Blender 3D.  The reason that format is Major is because many Windows and XBox games use it.

Why does this matter to us? Well because we want whatever tools we use to continue to support the format we have for years to come; if .b3d finally falls off the earth - we will be in trouble.  .x is not going to fall off the earth any time soon as XBox and Windows are going strong. People will continue to demand working exporters for that format for a long time.

Furthermore I suggest we either go to  .x (or stick with .b3d if we must) for the reasons that mesh composition and animation are not trivial tasks. By trying to turn everything into a voxel and animation via code you are literally cutting the possibility of any artists ever being able to reasonably contribute to the game development. 

So you are taking an area the project is already weak in - and making sure it stays that way forever by moving the format to the territory of 'programmer only'. 

So I'm saying - lets move the models and animations towards areas that modelers and animators can work on them (whether we have them right now or not).

I'm not going to say I can immediately do all these models myself ; but I can certainly over time re-do them if needed as I am capable ; its just a matter of time.

But the odds of getting a 3d modeler/animator on the team who can produce good stuff for is 900% higher if they can just use Blender and export to a currently supported format! smile

Next the concerns of the lighting on the model. I'm not sure what is going on here but I can definitely say models can have shading on them .. in fact they are capable of incredibly detailed shading if we use normal maps.

But even simple polygon models with no normal maps should be capable of receiving some primitive shading / lighting on them such as goraud, phong etc.  It might be a problem with the .b3d files or something were not doing right in the engine - but there should be no technical reason that we have to move the models to a voxel format to get them lit/shaded properly.

Another option though is to have the models textured "properly" and by properly I mean with a fair bit of lighting 'baked' in to the model via the actual texturing process.

Check out this texture  I did for Quake 2 ; this texture

if you look at the back of the jacket you'll see 'folds' that are light and dark ; this is what I'm talking about - baking lighting into the actual 2d texture pixels.

Also finally - while we do have a 'pixel' style of game going on here there's lots of room for mesh complexity that attempting via code would be a nightmare.  Again just another reason to keep these in the area of existing art tools so artists can contribute.

Offline

#4 2015-04-11 19:39:29

darkrose
Administrator
Registered: 2013-10-05
Posts: 743

Re: Bigger Things

The 3 draw types for mobs at present are 2D sprites, models, and static boxes. So 3 completely different draw types rather than just 3 model formats.

The models are in 3ds formats either because it's what I could get them in, or they were converted to that from .x format to shrink the file size down a bit: sdzen, who did most of the world textures, had a thing for shrinking file sizes.

If we can get decent models, and a modeller who'd be interested in sticking around to get them right, I'd be more than happy to keep them; the box mesh idea is just my thoughts on "how can this be improved with who we have helping now".  The main issue with the current ones is the texture wrapping, if you check them out in game there's splats of colour in odd places because the textures coordinates don't align with the pixels... and this is after I spent several days improving them, at least they're reasonable at a slight distance now.

The issue with lighting is that we currently don't use hardware lighting (exception, skybox), it's all done with vertex colours calculated off the node light values at meshgen time. I've experimented with hardware lighting some (see here), but that's as far as we've gotten. The biggest slow down on hardware lighting is that it seems to be designed for prebaked fixed maps, rather than massive dynamic sandbox worlds with potentially millions of light sources. Shaders would improve the matter, but I don't want to rely on them. But while we're using vertex colours for map lighting, it limits the models to just one colour/light value for the entire mesh.

Baking the lighting into the model textures would improve the matter, yes, and I'm also not opposed to dumping the completely blocky look - it's been done to death in voxel worlds. Just fixing the texture wrapping on the current models would be a big leap forward at present, as we could then bake in some shading.

That Quake texture is awesome... I need sleep.


Support Voxelands on Patreon: https://www.patreon.com/voxelands

Offline

#5 2015-04-12 03:13:03

melkior
Member
From: Sacramento, CA
Registered: 2015-04-08
Posts: 52
Website

Re: Bigger Things

Do we have the .3ds source available for current models? I have no way to open .b3d models?

Offline

#6 2015-04-12 05:06:11

darkrose
Administrator
Registered: 2013-10-05
Posts: 743

Re: Bigger Things

gah, I meant b3d, no idea why I said 3ds.


Support Voxelands on Patreon: https://www.patreon.com/voxelands

Offline

#7 2015-04-12 16:27:02

melkior
Member
From: Sacramento, CA
Registered: 2015-04-08
Posts: 52
Website

Re: Bigger Things

lol - well that's no good ha big_smile

Offline

#8 2015-04-12 17:25:14

darkrose
Administrator
Registered: 2013-10-05
Posts: 743

Re: Bigger Things

I can probably dig up some .x versions though, at least of some

... probably even sitting in some old commit somewhere in git.


Support Voxelands on Patreon: https://www.patreon.com/voxelands

Offline

#9 2015-04-12 18:15:56

melkior
Member
From: Sacramento, CA
Registered: 2015-04-08
Posts: 52
Website

Re: Bigger Things

Eh probably don't worry about it; like you said yourself they are bad enough really that they probably just need re-doing entirely so its not a big loss.

I'm thinking of working on a prototype for a new model for one of them - haven't decided which. I have only seen a deer and a sheep and the player model so far -- not even sure what most of the others look like? smile

Offline

Board footer

Powered by FluxBB