Search results

Correct. There's no way to enforce it or stop it. Doesn't mean we should encourage it. Having to use a modified client raises the bar of entry significantly from the "download cheat and drop into modules folder" technique that would otherwise exist. Yes. Or to make it smoother, there could be...

Higher quality textures could alternatively be handled by having different qualities for the textures available in the standard modules, side-by-side. That said, quality levels is pretty much the one use case I that makes me consider it. What I do want to avoid is the issue where the server...

Modules are enabled on the server and every client. When a client connects to a server they are sent any modules they are missing that are active on the server, not any inactive modules. If you activate a module midgame, presumably you do that on the server and the enabling of that modules would...

To be clear, by in game I mean when you have loaded a saved game/created a new game and are in the world. It is by design that modules are not changed at this point. To support this has a number of complexities particularly when you consider multiplayer, because if you are loading and unloading...

A new game. This is partially a menu restriction - you can modify the modules a saved game uses by changing its manifest. The results of removing modules may not be desirable though. Certainly you cannot enable/disable modules once in a game.

Not yet. There is work happening in this space for world generators, and the input configuration menu is populated from all mods. In general, modules wouldn't contact the engine for this. You would mark something up with annotations (probably a component) and the engine would look for it.

As Josharias says, modules are loaded at runtime, per game, with the selection of modules stored in the game.

Another update: Sunlight algorithms are now reasonably performant - I haven't done any threading, but managed to tweak things to the point where it is acceptable. There is potential for threading in light merge itself, or possibly even usage of CUDA, but will leave this for the moment. So...

Will do. Basically I don't even want to begin again until the vertical chunking work is done, since there was a fair bit of math usage involved and I want to avoid merge conflicts. I probably chose a bad place to start with the replacement last time - Vector4f - since I immediately hit a mess...

React is only useful if someone is willing to port in the voxel handling. I would still recommend using Bullet itself. I notice the libgdx has done exactly this, although we would need to add the voxel shape support: http://code.google.com/p/libgdx/wiki/PhysicsBullet

I did start the branch, but got distracted with the vertical chunking sorry. I'll return to this after the chunking is done now. Basically the replacement will be a huge amount of work. Should be noted that unless someone is willing to work through tera-bullet and replace vecmath in it...

That article is quite interesting, Josharias . I'm intending to change the storage/network format of chunks to run length encoded as part of my current work anyway, and the interval tree approach sounds very interesting (the top level virtualized hash-map is already in place). manu3d On...

Could go the other way: Terra of Terror :P

A not-very-interesting update: I have been working away at the sunlight algorithm. I have the core algorithm down pat, and an optimised algorithm for initially connecting chunks. Unfortunately the performance is still too low to satisfy me - the lighting merge when connecting chunks is easily...

I think it would get kind of tricky having multiple passes from different cameras interleaved. Probably simpler to keep each camera for a single rendering pass, and then attach multiple cameras to the player/whatever for different things. The cost of having multiple cameras would be minimal -...

I'm saying it isn't useful as long as it cannot be used. :P My previous experience with octrees is that adding hierarchy adds unacceptable cost to data access and update, so I would definitely want to see benchmarks. A lot of processes, such as chunk mesh generation, heavily access block...

My thoughts: At the moment we have a single camera based rendering system. What we should do is add support for multiple cameras, with each rendering different entities based on some sort of label/filter system. These cameras would be given a rendering order. With that in place the skysphere...

On OpenVDB - it isn't a java project so it would require a fair bit of work to use, plus depending on the usage pattern will likely lose a lot of efficiency in the java<->native communication. It also deals with a different sort of voxel data from a brief look at it (we're voxel only in so far...

Terasology's internal mesh don't require texture coordinates, and do have support for vertex color values, so the Collada mesh importer should be able to handle that - does mean the mesh would have to be rendered with a shader that uses vertex color. This is a use case that hasn't been exercised...

That is the current situation, Esereja. So no issue there. The problem is if you have sets of modules you wouldn't use together that have binds, those binds cannot share inputs at the moment. This is mostly the case where disparate gametypes are involved - bind config should be different for...