Model (FBX & MD5), Texture, Scripting Considerations?
I'm so excited for DE 2 that i'm starting this thread without regaining my composure so forgive me if I seem a bit giddy/frantic/chaotic/swoony. I wasn't able to discover the answers to these questions but that might be because i'm being a bit hasty at the moment.
Model Considerations:
As I dive into this are there any FBX specific considerations, such as version compatibility, or other limitations that should be made in relation to developing models and animations for DE2?
Textures & Materials:
Are there any new fancy texture effects, and/or shaders (such as glow maps, normal maps, or metallic refraction) available now or coming down the pipeline that I should consider when designing for my new models?
Scripting:
Generally speaking, would the scripts look similar to the way they did for the pre-2.0 versions of DE? Is there very much that will be, or already is, depreciated that I should be aware of? Scripting is not my field of experience so all of my projects past scripts were made possible by harassing the hell out of DaniJ back in the day.
Model Considerations:
As I dive into this are there any FBX specific considerations, such as version compatibility, or other limitations that should be made in relation to developing models and animations for DE2?
Textures & Materials:
Are there any new fancy texture effects, and/or shaders (such as glow maps, normal maps, or metallic refraction) available now or coming down the pipeline that I should consider when designing for my new models?
Scripting:
Generally speaking, would the scripts look similar to the way they did for the pre-2.0 versions of DE? Is there very much that will be, or already is, depreciated that I should be aware of? Scripting is not my field of experience so all of my projects past scripts were made possible by harassing the hell out of DaniJ back in the day.
Comments
First a couple of words about the status of 3D model support. The model renderer is the first area of the renderer that is/has been undergoing significant improvements. I've been working together with Kurikai, Tea Monster and veirdo to ensure that everything is well-aligned with the practical needs of model authors. When it comes to file format support, we're basically using the unmodified Assimp library. Also, the scripting engine is in place, but only a very limited subset of animation features currently have script bindings. I will add more over time as needed by model authors.
You should take a look at the model assets reference, and the page about Doomsday 2 packages.
The Open Asset Import Library provides the FBX import code, but so far I haven't seen detailed documentation about exactly what is supported. @veirdo might be able to provide some insights about this. When it comes to Doomsday, the assumption is that each model provides a set of animation sequences (named or numbered) that Doomsday can then play back when triggered. These animations are not strictly synced to actual mobj states so that more natural-looking animations can be achieved. The plan (currently unimplemented) is to also do motion-controlled animations for walking/movement animations that are separate from attacks, etc.
For materials we have a set of generic GLSL shaders that support diffuse, specular, emissive, and normal/height texture maps. A number of shader variables are available that affect the appearance of these shaders, and the variables can be animated per object via scripts. However, a model package can also contain completely customized GLSL shaders (although that does come with the risk of compatibility problems as the renderer evolves).
Your model textures are automatically collected on atlas(es) by Doomsday. A model may also use multiple different texture sets and alternative shaders for dynamic appearance changes.
Model scripting is based on Doomsday Script, so it is more powerful and more flexible than what was possible with MD2 models. I'm working on an overview: http://dengine.net/manual/assets/scripting_with_stateanimator
here,
here,
or here
Then thoroughly read documentation, skyjake mentioned above.
For FBX, we tested versions up to 2015 (I'm personally using fbx-binary 2011) .
Model may have several meshes, animations should be baked on bones per-frame. Also multiple animations should be stored as separated "takes".
*Eyes morph into morbid heart shapes*
Absolutely wonderful!
I don't know how i missed the model assets reference page. I feel like I had seen it and passed over it somehow. Thanks for the link.
Formats:
Would MD5 and FBX be handled identically (other than extension referencing) with respect to scripting?
FYI - I favor FBX because it comes as a default export with every major modeling software out there and other modders would be able to easily take my work to edit and make their own which seems valuable. I wouldn't have to personally deliver assets through requests. The id team did not use Maya so finding an md5 exporter that works is very difficult and depending on the version of maya can be impossible.
Animations:
It looks like the animation frames are no longer tied to the default frames but I still have a question related to this. Are animations still tied to the default animation loop? Could I animate a long walk cycle that lasts ten seconds without affecting the actual monster's walking animation frames, tics, or speed, etc.? So, like, while my animation plays on for a trillion seconds, the default continues to cycle as normal under the hood?
Textures:
So happy that the engine automatically collects textures to an atlus.
Shaders:
Wait, wait, what?... Diffuse?... Specular?... EMISSIVE?... NORMALS?!!! And I can animate them i.e., pulsing emissive lights?
<dead>
These are honestly the only things an artist needs to make their models look a trillion times better. I'll use all four of them with great joy.
I can at least get started with what you've already provided. So elated right now!
Oh wow! Your project has really come a long way since I last payed attention. What a wonderful resource for the community. These are far more loyal to the source material than mine are LOL. I love it! I'm excited to see this completed.
You mentioned that you can use several meshes with FBX. Is there a hard cap to that?
I used many meshes on a bunch of the outdated models for my project to cheat the MD2 2000 vertex limitation AND to apply different effects to different parts like full-bright on monster eyes etc. Now that both of those things are no longer an issue for me i'm mostly interested in making varying versions of monsters so they can have different heads or armor parts ect. Knowing any hard limitations would help me immensely.
Tea Monster and I have release our sources for the dhmp(not including the highres model though[as they are quite large]
Feel free to check out how we have done it.
https://github.com/KuriKai/dhmp
Also feel free to Ask TeaMonster or myself any questions you have
Tea Monster and I use blender to export our models to fbx
&
@Tea Monster
Oh man, both of you are still here. Very glad to see that. The work you guys have done is truly amazing.
So, yeah, I have no love for MD5 but I guess at least it's not MD2. About a decade ago I worked with MD5 professionally on a handful of mobile games and exporting was agony.
However, I love FBX because it is widely supported and is relatively clean (not a lot of junk data) for such a commonly used format. It's problems generally come from the potential for data loss during export.
I'll just data mine the stuff you guys have made available to learn how things are different than they were pre 2.0.
I probably won't have questions until after next weekend. Finals week is about to start and i'm finishing up 18 credit hours.
Oh I do have a question to leave here before I go. I wasn't going to ask this just because I assumed I probably just don't use the same verbiage but veirdo said "animations should be baked on bones per-frame".
1) What exactly does that mean?
2) Do I need set key-frames on every frame before or during export?
3) Are there interpolation issues if I don't (or some similar junk)?
I'm asking those questions because this may effect the way I rig my models.
2-3) Doomsday using Assimp library to read model formats, and this library have its own limitations. Interpolations between keyframes not working, so we need a keys for each frame of animation.
Oh okay. Makes sense. It was one of my theories. Yikes, I've never done this before. I hope those examples are extreme cases. That looks unwieldy to say the least. Interested to see how it turns out and what kind of quirks are involved in the process. It can't be anywhere near as bad as vertex animations of MD2.
So does doomsday still interpolate between those key-frames when animations are stretched (if that is even a thing anymore)?
Oh wait. I realize now that those are not the same animations. At first I thought I was seeing the animations being greatly effected by the process. No, this all makes sense to me. Sorry, I responded too hastily.