Request Techne model converter / format support

[Cervator]

So with the arrival of OreSpawn we suddenly have a ton of models from TheyCallMeDanger to use in Terasology -yay! But they're built in Techne, a popular Minecraft custom modelling tool, a bit akin to VoxelShop by @flux I expect.

Figuring out how to make all those models usable in Terasology is probably a good first project, as reusing art assets generally is a lot easier than reusing code. We started on COLLADA support in the VoxelShop thread, with @Mike Kienenberger getting it working. That's a more general format though, unlike the MC-specific Techne.

Doing a bit of quick Techne research shows it is apparently being rewritten to a 2.0 right now, but with not a lot of obvious activity by the author since June. Not sure how that impacts stuff, or what Danger's future plans there are

Anyway, I wanted to start a discussion on the topic to see what we can do, and hope we have some people familiar with Techne or related topics. Pinging @flux @Mike Kienenberger and even @overdhose since they've done stuff in the area. Pinging @Immortius @glasz and anybody else here already active these days as well for ideas

 

[Mike Kienenberger]

So with the arrival of OreSpawn we suddenly have a ton of models from TheyCallMeDanger to use in Terasology -yay! But they're built in Techne, a popular Minecraft custom modelling tool, a bit akin to VoxelShop by @flux I expect.

Figuring out how to make all those models usable in Terasology is probably a good first project, as reusing art assets generally is a lot easier than reusing code. We started on COLLADA support in the VoxelShop thread, with @Mike Kienenberger getting it working. That's a more general format though, unlike the MC-specific Techne.

Doing a bit of quick Techne research shows it is apparently being rewritten to a 2.0 right now, but with not a lot of obvious activity by the author since June. Not sure how that impacts stuff, or what Danger's future plans there are

Anyway, I wanted to start a discussion on the topic to see what we can do, and hope we have some people familiar with Techne or related topics. Pinging @flux @Mike Kienenberger and even @overdhose since they've done stuff in the area. Pinging @Immortius @glasz and anybody else here already active these days as well for ideas

Well, you know I live to convert things from one obscure format to another obscure format. You caught me just as I was looking at openMW (open Morrowind Engine) and considering how hard it would be to import data into it

 

[Florian]

I searched for it a bit and found out that techne is actually open source.

So instead of making a converter it might also be possible to just write an exporter addon for techne.

If someone is interested in making an exporter, here is a link to the Techne repository:

https://bitbucket.org/Brunner/techne-online/

 

[Mike Kienenberger]

Thanks. That link is definitely helpful.

https://bitbucket.org/Brunner/techne-online/src/d7c132d32f53/src/File/?at=default seems to be the most relevant section if we are going to import data with our own software rather than creating an exporter for Techne. This looks like it exports block shapes and textures. It looks pretty trivial, but without an actual model, it's hard to be sure.

Do we have an actual model file to look at somewhere? I wasn't able to create one myself, but it's probably due to not understanding how to work the tool.

And it's all in json, which we all love so much

UPDATE 1: So I downloaded orespawn164v19.zip to see what that contained. From what I can tell, it's ogg files, png files, and java class files. I'm guessing that this format of the data contains all of the information we want in the .class files. That's probably not a workable format for us, so I'm hoping we have access to the data in another format as well.

 

[Cervator]

I searched for it a bit and found out that techne is actually open source.

So instead of making a converter it might also be possible to just write an exporter addon for techne.

If someone is interested in making an exporter, here is a link to the Techne repository:

https://bitbucket.org/Brunner/techne-online/

If I understand it correctly though that's the v2.0 the author is working on, but isn't done with yet? The OreSpawn models are probably still in v1

 

[TheyCallMeDanger]

Thanks. That link is definitely helpful.

https://bitbucket.org/Brunner/techne-online/src/d7c132d32f53/src/File/?at=default seems to be the most relevant section if we are going to import data with our own software rather than creating an exporter for Techne. This looks like it exports block shapes and textures. It looks pretty trivial, but without an actual model, it's hard to be sure.

Do we have an actual model file to look at somewhere? I wasn't able to create one myself, but it's probably due to not understanding how to work the tool.

And it's all in json, which we all love so much

UPDATE 1: So I downloaded orespawn164v19.zip to see what that contained. From what I can tell, it's ogg files, png files, and java class files. I'm guessing that this format of the data contains all of the information we want in the .class files. That's probably not a workable format for us, so I'm hoping we have access to the data in another format as well.

Hi Mike!
I just signed up to chat here yesterday, and it wasn't quite working then. Seems fine now today...
At any rate, Cervator should have forwarded you a few sample files, along with my email address.
If you are the one who is taking on the project of making a Techne model renderer, then you and I should probably talk!
It really shouldn't be very hard. It is a very simplistic model editor.
I've got somewhere between 50 and 100 models... I don't count any more...
So you can see where the desire comes from!


Thanks!

 

[Mike Kienenberger]

Hi Mike!
I just signed up to chat here yesterday, and it wasn't quite working then. Seems fine now today...
At any rate, Cervator should have forwarded you a few sample files, along with my email address.
If you are the one who is taking on the project of making a Techne model renderer, then you and I should probably talk!
It really shouldn't be very hard. It is a very simplistic model editor.
I've got somewhere between 50 and 100 models... I don't count any more...
So you can see where the desire comes from!


Thanks!

Yes, Cervator fowarded your email to me. I won't have time to look at it in detail until tonight at the earliest.

UPDATE 1: I have a few minutes while waiting for my kids to get some things done, so I took a look at the files @TheyCallMeDanger provided. I'm including the 3 files dealing with the Ant model. I was a little worried when he mentioned that Terasology needed to call rendering methods on his entities. I think converting the models is going to be a difficult, although maybe not impossible.

Minecraft models are dynamically built out of shapes at run-time, and then manually modified (shapes translated or rotated, possibly shapes are also modified/added/deleted although not sure about this yet) each step by a rendering system defined on each entity. This is quite different than how Terasology currently operates, where we only modify world blocks and all models are predefined static 3d models with set animations built in.

There's at least a couple of different approaches we can take. The Techne model is similar to Collada. It might be possible to create a standard 3d model out of the data set on load. I'm not yet sure whether the java code provided by @TheyCallMeDanger is what Techne generates (my limited experience with it yesterday appears to imply that it does generate such java code) or if it's been modified since it was generated from the Techne model. If it's been modified afterward, then this approach won't be all that helpful.

A second approach might be to create Minecraft-compatible systems for rendering and managing models where the models are not loaded on startup but are instead dynamically created and adjusted each step of the game timer. It's going to depend on just how complicated the manual changes to a model are, but if all we are allowing to be changed is the rotation of the shapes that make up a model, then we can probably create the shapes on startup and treat each individual shape as a separate model, then have groups of shapes operate as a larger model. This may not be too much different than what we are doing now.

@TheyCallMeDanger, correct me if I am wrong, but only the rotation commands in the ModelAnt.java(.txt) file's render() method is hand-crafted. The rest is generated by Techne.

@Cervator, why can't we upload *.java files?

 

[TheyCallMeDanger]

Yes, Cervator fowarded your email to me. I won't have time to look at it in detail until tonight at the earliest.

UPDATE 1: I have a few minutes while waiting for my kids to get some things done, so I took a look at the files @TheyCallMeDanger provided. I'm including the 3 files dealing with the Ant model. I was a little worried when he mentioned that Terasology needed to call rendering methods on his entities. I think converting the models is going to be a difficult, although maybe not impossible.

Minecraft models are dynamically built out of shapes at run-time, and then manually modified (shapes translated or rotated, possibly shapes are also modified/added/deleted although not sure about this yet) each step by a rendering system defined on each entity. This is quite different than how Terasology currently operates, where we only modify world blocks and all models are predefined static 3d models with set animations built in.

There's at least a couple of different approaches we can take. The Techne model is similar to Collada. It might be possible to create a standard 3d model out of the data set on load. I'm not yet sure whether the java code provided by @TheyCallMeDanger is what Techne generates (my limited experience with it yesterday appears to imply that it does generate such java code) or if it's been modified since it was generated from the Techne model. If it's been modified afterward, then this approach won't be all that helpful.

A second approach might be to create Minecraft-compatible systems for rendering and managing models where the models are not loaded on startup but are instead dynamically created and adjusted each step of the game timer. It's going to depend on just how complicated the manual changes to a model are, but if all we are allowing to be changed is the rotation of the shapes that make up a model, then we can probably create the shapes on startup and treat each individual shape as a separate model, then have groups of shapes operate as a larger model. This may not be too much different than what we are doing now.

@TheyCallMeDanger, correct me if I am wrong, but only the rotation commands in the ModelAnt.java(.txt) file's render() method is hand-crafted. The rest is generated by Techne.

@Cervator, why can't we upload *.java files?

Mike, yes, most of the code is generated by Techne, and it works exactly as you said, that each block of a model is dynamically redrawn with every screen update. This allows for completely dynamic rendering and animation of entities. The code I add to the renderer is to change the angles and positions. No static models here. I can even create multiple blocks on the fly by simply changing their rotations and positions and rendering them multiple times. The first part of the file is produced completely by techne, and is simply the initial declaraion of the cubes. The render(arg1,arg2,arg3...) routine is where I do all the animations in the code, and the render(arg1) function is what actually renders the individual cubes. With this, I have the ability to make completely dynamic animations, change textures on the fly, render or not different parts, etc, etc. And, just as important, I can call back to the entity to get i's state so I know what I want to do as far as animations (attack, walk, run, fly, sit, etc). As long as there is a way for the rendering routines to get state from the entity, that's all I need... excett that in some entities I go so far as to declare large structures of information that get passed to the renderer, but mostly it's a simple integer flag. The new giant robots are an example of a renderer that gets a structure of arrays (for the leg angles and positions).

What I would like, is a way to register a callback for when an entity should be rendered. The model code will do the rendering dynamically....

Thanks!

Richard

 

[Immortius]

This should be doable, if less than performant.

Ideally the mesh would be loaded as skeletal mesh, and then the animations either converted to skeletal animations or left as code that manipulates the bones of the skeletal mesh (which are represented in the entity model as an entity per bone following the bone hierarchy). While we are doing CPU skinning at the moment (so basically dynamically generating the mesh each frame) it would allow us to move to GPU skinning in the future (with a shader that applies the bone state to the static mesh).

Alternatively if a skeleton could be determined at least, each bone (entity) in the skeleton (entity hierarchy) could have a cube attached (or whatever shape) and animation could be done by manipulating the bones/entities. This would be trading off uploading a mesh each frame to the GPU for a higher draw count though.

 

[TheyCallMeDanger]

I don't need to reload the mesh every frame, as long as I can force it to reload every once in a blue moon... I do have fireflies, and some other things, that change the brightness of the mesh every second or two, but that's about as fast as I need. Would I still have access to openGL calls at that level too? I do have some models where I adjust the transparency as well...

I would be fine with manipulating pre-defined-meshed cubes, as long as there is a mechanism where I can change them (the mesh) every once in a while... But... a head's up... that there may be other MC models that do require changing the mesh every frame. It's not out of the realm of possibility. The mechanism should be there, although I don't necessarily need it at the moment.

Honestly, call me a noob or something, but I don't see the problem with just drawing a bunch of cubes... granted I can understand it's faster to load them up in the GPU first, and that's fine, just give me a simple mechanism to reload them when the texture needs changing... Girlfriends, for example, have a texture that the player can change when they get clicked with a yellow flower. The Queen changes texture when she gets mad. It's not every frame, but would still need to be relatively quick...

Thanks!

 

[TheyCallMeDanger]

And yes, there can be multiple Girlfriends all running around at the same time, each with an entirely different skin... so... maybe what I said above doesn't quite work? Each individual Girlfriend's skin would then need to be loaded up to the GPU... I don't know enough about GPU programming to have much valuable input on that... is it a problem? Because there's players too... and each player needs to have their own unique skin...

 

[Cervator]

Not to steal @Mike Kienenberger's thunder, but since he just poofed off IRC without posting here I thought I'd at least mention he got the conversion working to the point of showing something in game. Said something might not look like much yet, but I am thrilled to even see that much progress this soon

Any content in modules wouldn't have direct access to OpenGL, but we can add new abstract methods as needed in the engine to cover stuff. It is all really just getting the right pieces to the right places

 

[TheyCallMeDanger]

Not to steal @Mike Kienenberger's thunder, but since he just poofed off IRC without posting here I thought I'd at least mention he got the conversion working to the point of showing something in game. Said something might not look like much yet, but I am thrilled to even see that much progress this soon

Any content in modules wouldn't have direct access to OpenGL, but we can add new abstract methods as needed in the engine to cover stuff. It is all really just getting the right pieces to the right places

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!

 

[TheyCallMeDanger]

OK... so... after a crash course in opengl today...
It looks like we can have both speed *and* flexibility...

PNG textures can be read and loaded into opengl in the model init routines, so that they are all handy when needed.
Critters that have more than one texture can simply pre-load more than one texture.
The main model render routine simply re-binds the desired current texture, which is essentially a pointer assignment.
Each model cube can also pre-initialize its set of vertexs to save a little computational time.
With that all done, the main model render routine will mostly be setting position and rotation of the cubes,
and then calling the render routine for each cube. The actual cube render routine then doesn't have much
work to do other than gltranslate, glrotate, and then draw the cube with the preset texture and pre-generated vertexs.

Should work! In theory...

Will still be an annoyance to implement, as everything appears to have different versions of which way x,y, and z go,
and which part of a texture is where... but should be doable with some perseverance and trial and error...

 

[Mike Kienenberger]

It's not that what you have suggested in the last two posting is technologically impossible. It's that it doesn't fit our current engine model. You'll have to convince @Immortius of this approach. At one point I might have agreed with you when I first started on this project, but I've become a fan of modules only specifying states rather than executing graphics code and letting the engine figure out what is necessary. I'm definitely not the person you have to convince though as my "architect" experience here is very minimal.

So far, the three models you have provided to me only specify rotational state for various cubes, which fits well enough with our current architecture.

Here are some screenshots of what I've managed so far with the frog model. The rotation is most likely the culprit, but I haven't figured out exactly where it's wrong, and there are probably hundreds of possibilities. And I'm not entirely certain what the initial view of the model should look like anyway (although I can guess what boxes represent which body boxes based on your one rendered frog image). Note that there is zero support for textures so far -- I randomly assign each box a vertex color when I build the static model on startup.

UPDATE 1: One other issue I just remembered is that these models have a y-is-down orientation rather than our standard y-is-up orientation. I suppose this might also be affecting how things are being mis-rendered.

UPDATE 2: I managed to get techne v1 running on my windows laptop, and the frog looks just like the picture when I load it. So I've created a simplier non-rotated model to see if I can get that working as a first step, now that I have access to the modeler.

UPDATE 3: My non-rotated model is also put together wrong, so I'm going to guess that the problem isn't just rotation (and might not be rotation at all).

 

[Cervator]

I'm even less of an architect so I won't make a fool of myself by suggesting anything that sounds right in my head but comes out completely wrong

I'll just say that I'm sure we can get it all working, but it might take some back and forth on the exact architecture. I'll point to @Immortius as well for the best engine wisdom since he did a huge chunk of it

In the meantime I'll be grooving out to the abstract art hypnotoad above. All glory to the abstract hypnotoad!

 

[Mike Kienenberger]

Well, the interaction between position and offset (rotational center) is pretty bizarre. I'm not completely certain yet how position fits in. But I've managed to get things working pretty well except for rotation(some boxes are at the wrong rotation or were rotated around the wrong point), texturing (box sides have random colors), and flipping the y axis (everything is upside down).

Frog is still a mess, but ant and alosaurus can always be made out.

 

[TheyCallMeDanger]

These particular models and style of rendering cannot be fit into the current design, I agree.
The problem is how to best make an interface that will fit them. Dynamic models and rendering is a must.
At some point in the code, you decide you need to draw an entity at point x,y,z, with rotation rx,ry,rz, at scale s.
I would expect to be called with the translation, rotation, and scaling done by Terasology. All we have to do is
render the model, not knowing anything about the scene. I've already poked around and know that
the existing renderers know about the entity they are rendering. That's pretty much all we need.
Entity state can be gotten directly from the entity itself or from information sent by the server entity
to the client entity.

Congrats on the frog, ant, and alosaurus! At least you've gotten the parts to render!
Here you can find what they actually look like (and many more): http://www.orespawn.com/mobs.html

Perhaps we should talk a bit about client and server entities and how information can be passed
from server to client? And can client entities keep information? I have not researched this at all yet...
I supposed I need to!!! For the most part, there are only a few words of data that are updated from
the server to client (besides location and movement). But for a few client entities, I keep and calculate
things for the renderer to use, like where the feet should go for the giant spiders...

I assume that you have a callback for each entity where it updates its current state and can interact
with the world around it? Both on the server and client sides? Could you perhaps point me at a good
place to look in the code to see how entities work in Terasology?

 

[Cervator]

We've been missing you on IRC when this topic starts getting discussed for sure! @Mike Kienenberger is often on in the US evenings, if you can make it

As for an entity example, I really hope somebody can come up with a perfect example. The basics I can explain, but they might not relate to this specific case.

Have you seen this video on the behavior tree AI on Youtube? The behavior tree logic lives in the engine, with nodes for handling logic, and @synopia is back to help out some more with a newer version. It works in the Light & Shadow module, where you might find some additional code, and the creatures there might have some good examples for how they get defined. I get the idea this might not hit the spot, however, since we're really talking about sub-model dynamic fun like adjusting limbs as per world terrain. But maybe that can be a new thing. Anyway - wanted to post it just in case

 

[Cervator]

On a slight tangent (I am a talented tangenter after all!) @synopia is getting in on the code side of this, making me think about how more dynamic model limbs would work. It has always bothered me in games when you fight huge creatures and essentially spend the whole fight hacking at a leg while a single HP bar slowly drops, until you've killed the baddie entirely by violent manicure.

The king and a few other of these models have multiple hit boxes and we're talking about supporting stuff like a giant spider intelligently placing its feet independently to match the terrain. How about we add in support for a proper anatomy system at the same time? So the giant spider legs would be both independent parts of the model and also functionally for the creature. One leg gets hit? That specific leg takes damage, which contributes to the spider's overall health and might cause some general bleed damage, but won't kill it. Ideally the spider would react to the damaged leg by using others to compensate, limp, or with enough damage eventually fall over, exposing the meaty center to lethal damage

We already had started getting support for positional damage in the old physics based combat system, how cool would it be if we could both support fancy models AND a crazy neat combat system?