I'll try to get back on IRC this evening....
Request Techne model converter / format support
- Thread starter Cervator
- Start date
I am of the opinion that every feature you have mentioned is already possible without custom rendering.I might suggest then, that we add the ability for dynamic entity rendering. There are some absolutely awesome "can't live without it" cool features that are available when the modder has the ability to do custom rendering... The hook would be relatively simple: the renderer draws whatever object it wants, however it wants it, and Terasology places the resulting graphics object at the proper rotation, scale, and location in the scene. Custom death animations, custom morphing, all sorts of things then become available to the game... It can/should then be extended to items and blocks... Yes, I have custom models for items too...
The interface to Terasology should/can be relatively painless too. "register this renderer for this class of item/entity/block". Then, whenever Terasology wants to render that particular type of object/class in a scene, the registered renderer is called... Its all dynamic and on-the-fly.
Sorry for my awful explanation, but I'm still learning the proper terms... Please feel free to correct me, so I can improve our communications!
We have support for an asset called a Skeletal Mesh (you may already be familiar with this, in which case skip to next paragraph). This is basically a mesh that is controlled through the position/rotation/scale of a hierarchical structure of 'bones'. Each vertex of the mesh is associated with one or more bones, so changes to the bones pull the vertices along with them. For box-based mesh, you may just have a bone per box.
In Terasology each bone is an entity and can either be manipulated by playing an animation (another asset) or by programmatic manipulation. So long as a mesh is set up as a skeletal mesh, you can do all the animations you want. And because skeletal meshes are a standard asset type, you can also visually create animations in any of the standard modelling apps like blender and export it for use in game.
At the moment this is implemented through a technique called CPU skinning, which essentially means we generate the mesh each frame. But by having a single centralised way in which this is done we have a path for moving to the more efficient GPU skinning where the bone information is sent to the GPU and the mesh transformation is done there.
Even without a skeletal mesh you can create an entity hierarchy, attach static mesh to each entity and manipulate the hierarchy to achieve a similar outcome.
The one thing this doesn't handle is extreme mesh morphing - this can be done either using a shader, or by having a mesh that is modified as needed. So again doesn't require custom rendering, just a system to modify the mesh.
In general, I would tend away from per-entity custom rendering because:
- Without custom rendering we have rendering centralised to a few systems, driven from a few components. This allows us to make performance improvements and other enhancements in one place.
- It exposes implementation details. We currently use LWJGL for rendering, but we may change to use LibGDX or something else in the future. Having modules work through assets means the implementation can be changed. It is also difficult to handle big centralised features like deferred rendering,
- Performance again - assets can be shared across entities (and thus a smaller memory footprint)
Okays, I looked into this weird tcn stuff and finally got it working using javascript:
http://synopia.github.io/tcnloader/
Press load to get the default ant. In the textarea, you may put the XML of any tcn model (rename the tcn to zip and unpack to get the model.xml). So the format should be clear, I am still unsure, how to get this into Terasology.
http://synopia.github.io/tcnloader/
Press load to get the default ant. In the textarea, you may put the XML of any tcn model (rename the tcn to zip and unpack to get the model.xml). So the format should be clear, I am still unsure, how to get this into Terasology.
Nice work, synopia. Unfortunately, I didn't immediately see anything I was doing differently.
But I did finally notice an incredibly-boneheaded mistake I made -- that I had been converting from degrees to radians and not the other way around.
That gets me "ALMOST" there.
But I did finally notice an incredibly-boneheaded mistake I made -- that I had been converting from degrees to radians and not the other way around.
That gets me "ALMOST" there.
I will have to understand your system much better, which will take some digging... But in a nutshell, I'd like custom rendering because I want all the artificial limitations removed. For example, if I wanted to make a ghost that could fade in and out. Or maybe I'd like to make a lightning entity, that doesn't use boxes at all and has no fixed set of, well, anything. Or perhaps I'd just like to make a clone, and replace myself with the player! (speaking of which, replacing the standard player with a "minecraft-ish" one with user-customizable skins is also a goal for me) In other words, some sort of registration/replacement mechanism for the renderer of the current class of entity. And well, not just for entities... for blocks, for items, for armor, and whatever else. Why? Well, because it is absolutely amazing what some of the creative people out there can come up with... So, I will continue to ask for custom rendering... for everything... because it's needed... and it's probably not a good thing to put artificial restraints on yourself...I am of the opinion that every feature you have mentioned is already possible without custom rendering.
We have support for an asset called a Skeletal Mesh (you may already be familiar with this, in which case skip to next paragraph). This is basically a mesh that is controlled through the position/rotation/scale of a hierarchical structure of 'bones'. Each vertex of the mesh is associated with one or more bones, so changes to the bones pull the vertices along with them. For box-based mesh, you may just have a bone per box.
In Terasology each bone is an entity and can either be manipulated by playing an animation (another asset) or by programmatic manipulation. So long as a mesh is set up as a skeletal mesh, you can do all the animations you want. And because skeletal meshes are a standard asset type, you can also visually create animations in any of the standard modelling apps like blender and export it for use in game.
At the moment this is implemented through a technique called CPU skinning, which essentially means we generate the mesh each frame. But by having a single centralised way in which this is done we have a path for moving to the more efficient GPU skinning where the bone information is sent to the GPU and the mesh transformation is done there.
Even without a skeletal mesh you can create an entity hierarchy, attach static mesh to each entity and manipulate the hierarchy to achieve a similar outcome.
The one thing this doesn't handle is extreme mesh morphing - this can be done either using a shader, or by having a mesh that is modified as needed. So again doesn't require custom rendering, just a system to modify the mesh.
In general, I would tend away from per-entity custom rendering because:
- Without custom rendering we have rendering centralised to a few systems, driven from a few components. This allows us to make performance improvements and other enhancements in one place.
- It exposes implementation details. We currently use LWJGL for rendering, but we may change to use LibGDX or something else in the future. Having modules work through assets means the implementation can be changed. It is also difficult to handle big centralised features like deferred rendering,
- Performance again - assets can be shared across entities (and thus a smaller memory footprint)
I'm a big fan of optimizations, but there is a big gray line somewhere between flexibility and performance... I'm sure some sort of optimizations can be done with Techne box models as well, and they have much less overhead than blender models, I'm sure. Take a look. They are usually just a dozen or so simple boxes. The same skin and boxes are shared by all the entities of the same type with custom rendering as well. In essence, I would register a class type with a renderer. That one renderer can do different things based on the state of the entity, pretty much the same as you do now. One renderer and all its assests shared by all entities of the same class.
I think we need to clarify terms a little... when I refer to entity, it is an active object or animal/creature in the mod. What is it that you call one of your creatures? If bones are entities, then what are creatures?
I've also found, that for most of my players, their computer is, well, of the antique variety... I would not count on players having impressive graphics cards with GPUs that are hungry for vertices and skins. For probably 50% or more of players, the CPU and GPU are one in the same. While abstraction and adding layers of fluff to make everything invisible to the programmer is sometimes a good thing in the name of flexibility, it is also one of the biggest killers of performance. In other words, it's not worth it to try to be everything to everyone and be infinitely flexible. Give me low-overhead-down-and-dirty access...
We'll talk a lot more, I'm sure...
Did some good bits of discussion on IRC tonight
Am realizing we probably need a Creature module, if for no other reason so we can have a CreatureComponent and attach that so we have Creature entities
Amusingly I can't actually think of anything that would go in a CreatureComponent yet, as every thing I've thought of so far (with very little effort, admittedly) would more appropriately go in a more specific module. But there's probably space for some utility code and templating
Anyway, progress! Yay!
Am realizing we probably need a Creature module, if for no other reason so we can have a CreatureComponent and attach that so we have Creature entities
Amusingly I can't actually think of anything that would go in a CreatureComponent yet, as every thing I've thought of so far (with very little effort, admittedly) would more appropriately go in a more specific module. But there's probably space for some utility code and templating
Anyway, progress! Yay!
I believe this is all doable under the current approach.I will have to understand your system much better, which will take some digging... But in a nutshell, I'd like custom rendering because I want all the artificial limitations removed. For example, if I wanted to make a ghost that could fade in and out. Or maybe I'd like to make a lightning entity, that doesn't use boxes at all and has no fixed set of, well, anything. Or perhaps I'd just like to make a clone, and replace myself with the player! (speaking of which, replacing the standard player with a "minecraft-ish" one with user-customizable skins is also a goal for me) In other words, some sort of registration/replacement mechanism for the renderer of the current class of entity. And well, not just for entities... for blocks, for items, for armor, and whatever else. Why? Well, because it is absolutely amazing what some of the creative people out there can come up with... So, I will continue to ask for custom rendering... for everything... because it's needed... and it's probably not a good thing to put artificial restraints on yourself...
But if you really need custom rendering...
So the Terasology world is composed of Entities, that have Components. This is a data model - entities are containers with no data of their own, and components are pure value types with no functionality. E.g. A boulder would be an Entity with a Location Component giving its position/rotation and scale, a Collision Component declaring how it collides, and a Mesh Component with data on how it appears (the mesh and material assets primarily).
We then we have systems that provide behavior to entities based on their components. So we have a MeshRenderer system that each frame iterates over all active entities with LocationComponents and MeshComponents, rendering them.
Then for custom rendering you would have your own FancyCustomAppearance component and FancyCustomAppearanceRenderer system. Every entity with the component would be rendered each frame by the system.
The limitation here is that our sandboxing of modules does not give modules access to LWJGL's rendering functionality at the moment. But adding support for permission levels is on the todo list for modules, and perhaps low level graphics access would be one of those permissions. I would still only use this sparingly. It is notable that we are both planning to switch to LibGDX eventually, and look into supporting Android platform - that latter would change us to working against OpenGL EL, which loses a lot of the older OpenGL methods (such as drawing lines/vertices directly - everything has to be done through buffers if I understand correctly).
See above, but in Terasology everything that exists is an entity or set of entities. A creature is certainly an entity, which happens to be the root of a hierarchy of entities for its skeleton. Each thing that has a unique location in the world is an entity, which is why it makes sense for a skeleton to be composed of entities - it allows you to attach other entities to the skeleton (like attaching a sword to a hand bone), find out whether than hand is touching something, check for collision against different limbs, etc.
This is about separating two concerns - how something appears and how appearance is rendered. If you want to change how something appears, there's no reason you should have to also mess with how it is rendered - all rendering is is drawing vertices with a given material. Otherwise, I don't know what to say - I firmly believe that nothing about this general approach is limiting. My experience is it is quite standard for 3D engines as well, and probably less limiting than many that don't support procedural meshes.
One other factor is robustness - we used to have a lot more OpenGL code around the place, particularly in the UI which predominantly used custom rendering for each UI widget. It was a source of hard to debug errors, because one item leaving OpenGL is a bad state would result in an issue in the rendering of another. Centralising rendering code and the use of assets has made life a lot easier for dealing with these issues and managing resources.
Immortius wrote:
"that latter would change us to working against OpenGL EL, which loses a lot of the older OpenGL methods (such as drawing lines/vertices directly - everything has to be done through buffers if I understand correctly)."
I believe you are referring to OpenGL ES, which indeed is buffer-oriented and targeting Embedded Systems (i.e. phones and tablets). Having only recently updated my knowledge on the matter I was a bit concerned about the change, but the more I read about it and the more it made sense. "Ancient" and new computers/platforms alike can greatly benefit from packing data into buffers first to then manipulate them later, potentially in multiple ways and in parallel.
Potentially, some if not all the work that has been discussed in this thread such as geometry generation, static/dynamic transformations and color changes could be done entirely via vertex, geometry and fragment shaders. I.e. the FancyCustomAppearance component mentioned by Immortius might only be responsible for creating one or more arrays of pure, non directly renderable data which would then be up to shaders provided by the FancyCustomAppearanceRenderer system to interpret and unpack (on the GPU) into geometry that gets rendered. This would sidestep the sandboxing issues as the FancyCustomAppearance component itself wouldn't necessarily use any OpenGL-related call apart from (potentially wrappable) buffers I/O operations, while the shaders aren't sandboxed, I'd think.
"that latter would change us to working against OpenGL EL, which loses a lot of the older OpenGL methods (such as drawing lines/vertices directly - everything has to be done through buffers if I understand correctly)."
I believe you are referring to OpenGL ES, which indeed is buffer-oriented and targeting Embedded Systems (i.e. phones and tablets). Having only recently updated my knowledge on the matter I was a bit concerned about the change, but the more I read about it and the more it made sense. "Ancient" and new computers/platforms alike can greatly benefit from packing data into buffers first to then manipulate them later, potentially in multiple ways and in parallel.
Potentially, some if not all the work that has been discussed in this thread such as geometry generation, static/dynamic transformations and color changes could be done entirely via vertex, geometry and fragment shaders. I.e. the FancyCustomAppearance component mentioned by Immortius might only be responsible for creating one or more arrays of pure, non directly renderable data which would then be up to shaders provided by the FancyCustomAppearanceRenderer system to interpret and unpack (on the GPU) into geometry that gets rendered. This would sidestep the sandboxing issues as the FancyCustomAppearance component itself wouldn't necessarily use any OpenGL-related call apart from (potentially wrappable) buffers I/O operations, while the shaders aren't sandboxed, I'd think.
Made some progress. I built a tcn asset loader, that creates skeletal meshes. Each cube in the tcn gets one bone in the skeletal mesh.
In addition there is a simple main method to create md5mesh files from a tcn. Just start TCNSkeletalMeshLoader#main with a tcn file as a program parameter.
I also assembled an example to play around with tcn files in its own module.
In addition there is a simple main method to create md5mesh files from a tcn. Just start TCNSkeletalMeshLoader#main with a tcn file as a program parameter.
I also assembled an example to play around with tcn files in its own module.
Attachments
That is what I meant, yes.
Finally, it seems to work
I totally thrown away the tcn import stuff - its not needed. Instead, I refactored the SkeletalMesh stuff a bit. Basically, I added a new method to SkeletalMeshDataBuilder, to construct a skeletal bone with a box at specified position and orientation.
Now, in DangerMod, there is a system that creates normal skeletal meshes through code using the builder. Animations are realized by manipulating the bone entities position and orientation. This is wrapped behind a fake minecraft API to make the models work without too many modifications.
In addition I added scale and translate properties to SkeletalMesh component. And I added a property provider editor to the debug screen (F1), to easily tweak parameters.
Speaking of parameters: I did not fully understand how the animations work in minecraft. In the end it comes down to BaseModel#render() with 7 parameters. The logic inside the render methods seems not to depend on any other states, so everything related to the animation is encrypted in these parameters. There is some research done already [1] but this does not fit to the models from @TheyCallMeDanger .
[1] http://schwarzeszeux.tumblr.com/post/14176343101/minecraft-modeling-animation-part-2-of-x
And a small clip:
I totally thrown away the tcn import stuff - its not needed. Instead, I refactored the SkeletalMesh stuff a bit. Basically, I added a new method to SkeletalMeshDataBuilder, to construct a skeletal bone with a box at specified position and orientation.
Now, in DangerMod, there is a system that creates normal skeletal meshes through code using the builder. Animations are realized by manipulating the bone entities position and orientation. This is wrapped behind a fake minecraft API to make the models work without too many modifications.
In addition I added scale and translate properties to SkeletalMesh component. And I added a property provider editor to the debug screen (F1), to easily tweak parameters.
Speaking of parameters: I did not fully understand how the animations work in minecraft. In the end it comes down to BaseModel#render() with 7 parameters. The logic inside the render methods seems not to depend on any other states, so everything related to the animation is encrypted in these parameters. There is some research done already [1] but this does not fit to the models from @TheyCallMeDanger .
[1] http://schwarzeszeux.tumblr.com/post/14176343101/minecraft-modeling-animation-part-2-of-x
And a small clip:
I tried to upload another couple files for you to try here, but it won't let me upload anything but images.
Please get in contact with me via email.
Please get in contact with me via email.
Lol! Now it's even worse... I can't even see anything in the file browser window except png and txt.
I'll email them to you.
I'll email them to you.
I can make a player model for MC skins if you need one. Pretty simple. Just let me know.
I wonder if we could do a unique player skin for a base MC type player model (for compatibility), perhaps something based on the Adventurer from Light & Shadow? If players want to look like Steve or their fav existing skin we should support that, but probably best to strike out looking differently by default
Maybe ideally we could have a few base models, but I figure you can't vary much if anything at all while still using MC skins as-is
Maybe ideally we could have a few base models, but I figure you can't vary much if anything at all while still using MC skins as-is
MC player skins are insanely easy to do. So easy, that they have web-browser pages that do them for you. It's just a small .png file.
We can very easily (15 minutes) make any custom default skin you like. More than likely though, people will find the default one
and immediately replace it with their own (that everyone already has for MC because pretty much the first thing you do in MC is make
your own custom skin).
If we had a nice way to let them pick ANY animal (and automatically scale it up or down to around player size), and let them edit that skin, well,
then they'd probably go completely apeshit... that would be the holy grail...
We can very easily (15 minutes) make any custom default skin you like. More than likely though, people will find the default one
and immediately replace it with their own (that everyone already has for MC because pretty much the first thing you do in MC is make
your own custom skin).
If we had a nice way to let them pick ANY animal (and automatically scale it up or down to around player size), and let them edit that skin, well,
then they'd probably go completely apeshit... that would be the holy grail...